PPPoE Subscribers

Once the PPPoE session is established, the client device initiates the PPP connection. The Link Control Protocol (LCP) is used to negotiate link parameters, e.g., maximum transmission unit (MTU), which determines the largest size of a data packet that can be transmitted over the link without fragmentation, and authentication type. LCP uses Configuration Request messages to suggest a setup o parameters and the peer responds with Configuration Acknowledge messages to accept these parameters.

If authentication is required, the devices use LCP to agree on an authentication method to verify each other’s identity. RBFS supports

The IP Control Protocol (IPCP) is used to negotiate the configuration of IP addresses and related parameters (such as DNS server, etc.) between the client and the BNG. The peer initiating the connection sends an IPCP Configuration Request message to the remote side including the desired IP address and any other IP-related configuration options. The receiver responds with an IPCP Configuration Acknowledgment message, indicating that it has received the request and accepts it. If the receiver does not want to accept the parameters, it can send an IPCP Configuration Not Acknowledge (NAck) and reject the parameters. At the same time, it can suggest alternative parameters.

Once IPCP negotiation is successful, the PPP link is considered established and data traffic is forwarded between user’s device and the BNG.

The PPP session can be terminated by either side using LCP Termination Request. Reasons for PPP session termination can be user initiated, session timeouts, or link layer failures.

In order to configure PPPoE subscriber services, there are three mandatory configuration blocks:

The access profile defines the access protocol being used by the customer, i.e., in our scenario PPPoE. In addition, address families must be enabled explicitly and the mechanism of the address assignment must be defined, being either static or via a pre-defined address pool.

An IP address pool is a set of continuous IP addresses that is locally defined on the BNG and used for address assignment to the subscriber. An address pool is defined using the set access pool <pool_name> ipv4-address|ipv6-prefix syntax.

Once you have configured an IP address pool, you can monitor it via the show subscriber pool command:

Now that we have an IPv4 address pool defined, let’s configure the access-profile via the set access access-profile <profile_name> CLI syntax. Within the access-profile, there are the following steps that need to be configured:

Subscriber management requires the mandatory configuration of an Authentication, Authorization, and Accounting (AAA) profile. For authentication, local authentication based on locally defined user profiles and RADIUS authentication are supported as well as disabling authentication by accepting all credentials.

The AAA profile is configured using the set access aaa-profile <profile_name> syntax hierarchy. The simplest aaa-profile disables the authentication using the keyword NONE (which accepts all sessions) and skipping any accounting definition.

A customer is connected to a physical interface of the BNG. Due to aggregation of multiple customers within the access network, a customer line is typically represented by one VLAN (single-tagged) or two VLANs (double-tagged) on a physical interface with a limitation to one session, which is also called the 1:1 VLAN mode.

In contrast to routed interfaces, access interfaces are defined using the set access interface command hierarchy. There are four major configuration tasks that need to be done:

Remote Authentication Dial-In User Service (RADIUS) is a networking protocol used for centralized authentication, authorization, and accounting (AAA) for users who connect and access network services. In the context of broadband internet access, RADIUS plays a critical role in authenticating users and granting them access to the ISP’s network.

When a subscriber connects to the BNG, the BNG sends an authentication request to the RADIUS server. Note, that in RADIUS terminology the BNG is called network access server (NAS). The RADIUS server is responsible for validating the user’s credentials, such as username and password, against a centralized user database. If the credentials are correct, the RADIUS server responds to the NAS with an authentication success message, allowing the user’s device to access the network.

RADIUS also facilitates accounting and logging of user activities, including the duration of the session, data usage, and other relevant information. This information can be used for billing purposes and network management.

RADIUS messages encode specific information about a user or session using key-value pairs called RADIUS attributes. Each attribute has a unique identifier (attribute number) and contains a value associated with that identifier. These attributes are used to communicate between the RADIUS client (e.g., the BNG) and the RADIUS server, which is responsible for handling the authentication of users. Some common RADIUS attributes include User-Name and User-Password. There are also vendor-specific attributes (VSAs) defined by vendors to carry proprietary information or additional features.

The first step is to define one or more RADIUS servers using the set access radius-server command hierarchy. The radius-server configuration includes the IP address of the RADIUS server, the source address and the routing-instance used by RBFS to send the RADIUS messages, as well as the key to authenticate the RADIUS messages (either in plain text or encrypted). Furthermore, authentication and/or accounting need to be enabled and optionally the ports need to be defined if the differ from the default ports (1812 for authentication and 1813 for accounting).

You can verify the proper configuration of the RADIUS server using the show radius server command which lists all available RADIUS servers including their authentication and accounting state.

Next, we need to create a RADIUS profile via the set access radius-profile <profile_name> syntax hierarchy. The RADIUS profile defines the network access server (NAS), which in our case is the BNG device. It also defines which RADIUS servers are to be used for authentication and accounting. A RADIUS profile can contain multiple RADIUS servers for sake of redundancy or load balancing. If several servers are used, then you can define the algorithm-type to be either DIRECT (same server is used unless it fails) or ROUND-ROBIN.

Finally, we need to modify the existing AAA profile which is currently set to skip authentication.

Now, let’s check that RADIUS authentication is working. Therefore, we log into the service node SN once again and restart BNG Blaster with session count of three. As a result, we can verify that all PPPoE sessions are established:

Looking at the IP address pool utilization, we notice that only two IPv4 addresses are used from the pool, although we have three active PPPoE sessions:

After we have identified which PPPoE subscriber has no IP address allocation from the local IP address pool, we can analyze the subscriber details a little more:

It turns out, that this subscriber got an IP address from the RADIUS server directly and did not consume an IP address from the local pool. In addition, the DNS servers are different than the ones defined in our access profile.

Using RADIUS to manage session parameters of subscribers is a very common deployment model in broadband access as it allows to maintain user information in a central database, reduces the amount of local configuration and simplifies user migration from one device to another.

RADIUS accounting is used to collect data for statistical, monitoring and subscriber billing purposes. Once a user is granted access by the RADIUS server, the BNG sends an Accounting Start message to the RADIUS server containing username and the unique session identifier. When a particular subscriber session is terminated, the BNG sends a Accounting Stop message with comprehensive session information such as total time, data and packets transferred, etc., to the RADIUS server. In addition, the BNG can also send Interim Updates at regular intervals to reduce loss of information in the event of loss of an Accounting Stop message and also to provide a more detailed picture for long-live sessions.

Subscriber accounting is based on multiple sources, e.g.,

Now let’s start the BNG Blaster once again. We can now verify that accounting is enabled:

More important, these information are written to the RADIUS server. Switching to the service node (SN), you can find the accounting messages in file /var/log/radius/detail.log