IPoE Subscribers

Module Introduction

Before you start the hands-on part of this module, you should load the appropriate configuration and verify that the testbed is up and running by executing the corresponding robot file:

student@tour:~/trainings_resources/robot$ robot ipoe/ipoe_setup.robot

In order to get a better understanding, the lab setup is shown in the picture below.

ipoe lab
Figure 1. IPoE Subscriber Lab

IPoE Overview

Internet Protocol over Ethernet (IPoE) is a method of delivering broadband internet access to customers or subscribers. With IPoE, the subscriber session is established and maintained using Ethernet protocol between customer and ISP and IP connectivity is run directly over Ethernet. A public IP address is assigned to the subscriber’s residential gateway (e.g., CPE). This IP address is unique and routable on the internet, enabling the device to communicate with other devices and services across the web. IPoE eliminates the need for traditional dial-up or PPPoE (Point-to-Point Protocol over Ethernet) connections, simplifying the setup and management of the broadband service and reducing overhead.

Dynamic Host Configuration Protocol

The Dynamic Host Configuration Protocol (DHCP) is a network protocol used to automatically assign an IP address, subnet mask, default gateway, and other network configuration parameters to devices on a network. In IPoE deployments, the ISP uses DHCP to dynamically assigns an IP address to the customer’s device from a pool of available addresses. When a user’s device connects to the ISP’s network, it typically does not have a pre-assigned IP address. The assigned IP address is typically leased to the customer’s device for a specific period, known as the lease duration. Once the lease duration expires, the device may request a lease renewal to continue using the same IP address or receive a new IP address.

Let’s have a more detailed look on how DHCP works:

  1. When a device (also called DHCP client) connects to a network, it sends a DHCP Discover message as a broadcast request to find a DHCP server. The broadcast message is sent to the limited broadcast address (255.255.255.255).

  2. When a DHCP server receives the DHCP Discover message, it responds with a DHCP Offer message. The DHCP Offer contains an available IP address, subnet mask, lease duration, default gateway, DNS server addresses, and any other network configuration parameters the server is configured to provide. The server reserves the offered IP address for the client for a specified lease duration.

  3. Upon receiving the DHCP Offer, the DHCP client evaluates the offered IP address and other parameters. If the client accepts the offer, it sends a DHCP Request message to the DHCP server, confirming its acceptance and requesting the offered IP address.

  4. The DHCP server receives the DHCP Request message and checks if the offered IP address is still available. If the address is available, the server sends a DHCP Acknowledge message to the client, confirming the IP address assignment. The Acknowledge message includes the lease duration and any other network configuration parameters. If the offered IP address is no longer available (e.g., assigned to another client), the server may send a DHCP NACK (Negative Acknowledge) message, and the client will restart the DHCP process.

ipoe dhcpv4
Figure 2. DHCPv4 Message Exchange

Once the client receives the DHCP Acknowledge message, it configures its network interface with the assigned IP address, subnet mask, default gateway, DNS server addresses, and any other provided parameters.

IPoE Configuration

Building Blocks

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

  • access-profile configuration

  • aaa-profile configuration

  • access interface configuration

ipoe config
Figure 3. IPoE Configuration Building Blocks

Basic Access Profile Configuration

The access profile defines the access protocol being used by the customer. In case of IPoE, the corresponding protocol is DHCP(v4) or DHCPv6 or both. 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.

Exercise 1: Configuring IPv4 Address Pool

Configure an IPv4 address pool named IPOE_POOL_IPV4 with addresses within the range 192.168.160.0/22.

In order to make these IPv4 addresses reachable, they need to be distributed via BGP to other peers. Create a static route 192.168.160.0/20 with next-hop null0 and redistribute this static route into BGP. Note, that the static route covers a large prefix allowing to configure additional pools later.

Click to reveal the answer
cfg> set access pool IPOE_POOL_IPV4 ipv4-address low 192.168.160.0
cfg> set access pool IPOE_POOL_IPV4 ipv4-address high 192.168.163.255
cfg> set instance default static route ipv4 192.168.160.0/20 unicast DISCARD
cfg> set instance default static nexthop-profile DISCARD exit-interface null0
cfg> set instance default protocol bgp address-family ipv4 unicast redistribute static
cfg> commit
Address pools can be removed and changed without impact to existing subscribers. This means that they remain the address from a pool after pool is deleted.

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

cfg> show subscriber pool summary
Pool Name                        AFI  Usage           Range
IPOE_POOL_IPV4                   IPv4 0/1024          192.168.160.0 - 192.168.163.255

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 two parts that need to be configured:

  • The access protocol needs to be defined. In case of IPoE, dhcp needs to be enabled to support DHCPv4.

  • The corresponding address-family needs to be enabled and the IP address pool needs to be associated with the access-profile. Optionally, DNS servers can be configured.

Exercise 2: Configuring IPoE Access Profile

Configure an access profile named IPOE_ACCESS. The profile should support IPv4 only. Associate the IPv4 address pool IPOE_POOL_IPV4 defined in the last exercise with this profile. Also add DNS servers 192.168.200.1 and 192.168.200.2 to the access-profile definition.

Click to reveal the answer
cfg> set access access-profile IPOE_ACCESS
cfg> set access access-profile IPOE_ACCESS instance default
cfg> set access access-profile IPOE_ACCESS protocol dhcp enable true
cfg> set access access-profile IPOE_ACCESS address-family ipv4 enable true
cfg> set access access-profile IPOE_ACCESS address-family ipv4 pool-name IPOE_POOL_IPV4
cfg> set access access-profile IPOE_ACCESS address-family ipv4 primary-dns 192.168.200.1
cfg> set access access-profile IPOE_ACCESS address-family ipv4 secondary-dns 192.168.200.2
cfg> set access access-profile IPOE_ACCESS address-family ipv4 instance default
cfg> commit

Note, that the default routing-instance is default, so this command can be skipped.

AAA Profile Configuration

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.

Exercise 3: Configuring AAA Profile

Configure an AAA profile named IPOE_AUTH. The AAA profile should not support any accounting and authentication should be set to NONE.

Click to reveal the answer
cfg> set access aaa-profile IPOE_AUTH authentication order NONE
cfg> commit

Access Interface Configuration

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.

It is also possible that multiple customers share the same VLAN which is called N:1 VLAN mode. This mode typically requires a per VLAN limitation set to the maximum number of sessions per VLAN with an additional limitation of one session per MAC.

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:

  • Configure the type (untagged, single-tagged, or double-tagged) along with the physical interface name (IFP) and the corresponding VLAN range in case of single-tagged, or double-tagged.

  • Configure the mandatory access type to be IPoE

  • Associate the access profile with the access interface configuration

  • Associate the AAA profile with the access interface configuration

  • Optionally, additional attributes like service profile or session limits can be configured.

Exercise 4: Configuring IPoE Access Interface

Configure hostif-0/0/4 to support IPoE subscribers. Subscriber will use double-tagged VLANs (outer VLAN range: 128-159, inner VLAN range: 1-100). Associate the access-profile and aaa-profile configured in previous exercises to the access interface configuration. Also define interface lo-0/0/0/0 as gateway-ifl.

Click to reveal the answer
cfg> set access interface double-tagged hostif-0/0/4 128 159 1 100 access-type IPoE
cfg> set access interface double-tagged hostif-0/0/4 128 159 1 100 access-profile-name IPOE_ACCESS
cfg> set access interface double-tagged hostif-0/0/4 128 159 1 100 aaa-profile-name IPOE_AUTH
cfg> set access interface double-tagged hostif-0/0/4 128 159 1 100 gateway-ifl lo-0/0/0/0
cfg> commit

Monitoring IPoE Subscribers

In order to see some useful CLI output, we need some IPoE subscribers to establish sessions with our RBFS device. The virtual lab environment comes with a service node (SN) that has BNG Blaster pre-installed - an open-source test tool that allows to emulate IPoE subscribers. A short introduction to the BNG Blaster can be found in the Supplementary Material in section BNG Blaster. For more details refer to the BNG Blaster Documentation.

Now let’s open another terminal, log into the service node and start the BNG Blaster.

student@tour:~$ rtb-ssh SN
Logging into SN as supervisor ...
<...>
supervisor@SN:~ $ sudo bngblaster -C subscriber_ipoe_v4only.json -c 3
[sudo] password for supervisor:
Jul 19 10:43:40.400732 Resolve network interfaces
Jul 19 10:43:40.400887 All network interfaces resolved
Jul 19 10:43:41.514560 ALL SESSIONS ESTABLISHED
The password for user supervisor is simply supervisor on the virtual training environment.

Once the message ALL SESSIONS ESTABLISHED appears on the screen, you can switch to the RBFS CLI and execute some monitoring commands. The BNG Blaster session is terminated using Ctrl+c. The switch -c 3 instructs the BNG Blaster to establish 3 sessions. You can vary the number of session count. You can also execute the BNG Blaster with the option -I which start the interactive mode.

Switching back to the RBFS CLI, we can verify that three IPoE sessions are active. You can use either the show subscriber and the show ipoe subscriber command to verify the status of the subscriber sessions. While the first one is more generic and also applies to other subscriber types (e.g., pppoe), the second one is applicable to IPoE subscribers only.

cfg> show subscriber
Subscriber-Id          Interface        VLAN      Type   State
216454257090494465     hostif-0/0/4     128:1     IPoE   ESTABLISHED
216454257090494466     hostif-0/0/4     128:2     IPoE   ESTABLISHED
216454257090494467     hostif-0/0/4     128:3     IPoE   ESTABLISHED
cfg> show ipoe subscriber
Subscriber-Id          Interface        VLAN      MAC               State
216454257090494465     hostif-0/0/4     128:1     02:00:00:00:00:01 ESTABLISHED
216454257090494466     hostif-0/0/4     128:2     02:00:00:00:00:02 ESTABLISHED
216454257090494467     hostif-0/0/4     128:3     02:00:00:00:00:03 ESTABLISHED

The state ESTABLISHED means that the session is fully operational. When a large number of subscribers are online, the list whole subscriber list might not be useful to start with. You can get an overview of active subscribers on a per box, per interfaces and per protocol basis using the command show subscriber count (or show ipoe subscriber count):

For each IPoE subscriber, a username is generated automatically using the client’s MAC address followed by @ipoe, e.g., 02:00:00:00:00:03@ipoe.
cfg> show subscriber count
                       Total        Setup        Established  Terminating  Standby
Summary                3            0            3            0            0
  PPPoE                0            0            0            0            0
  L2TP                 0            0            0            0            0
  IPoE                 3            0            3            0            0
  L2BSA                0            0            0            0            0
  Test                 0            0            0            0            0
hostif-0/0/4           3            0            3            0            0
  PPPoE                0            0            0            0            0
  L2TP                 0            0            0            0            0
  IPoE                 3            0            3            0            0
  L2BSA                0            0            0            0            0
  Test                 0            0            0            0            0
cfg> show ipoe subscriber count

Global:
    Total:                  3
    Established:            3

Interface hostif-0/0/4:
    Total:                  3
    Established:            3

If you are interested in a specific subscriber, the show subscriber commands offers some filter options to limit the output. Filters can be applied for subscriber mac addresses (mac), the subscriber state (state), or vlans (inner-vlan and/or outer-vlan), among others.

cfg> show ipoe subscriber filter outer-vlan 128 inner-vlan 2
Subscriber-Id          Interface        VLAN      MAC               State
216454257090494466     hostif-0/0/4     128:2     02:00:00:00:00:02 ESTABLISHED

Once you have learned the subscriber identifier, you can get more specific information about the subscriber session:

cfg> show ipoe subscriber 216454257090494482 detail
Subscriber-Id: 216454257090494466                (1)
    State: ESTABLISHED
    Uptime: Wed Jul 19 11:45:42 GMT +0000 2023 (0:00:37.545389)
    Interface: hostif-0/0/4                      (2)
    Outer VLAN: 128                              (2)
    Inner VLAN: 2                                (2)
    Outer VLAN Encapsulation: 802.1q
    Client MAC: 02:00:00:00:00:02                (3)
    Gateway Interface: lo-0/0/0/0
    Gateway Instance: default
    Gateway IPv4: 192.168.0.1/255.255.255.255
    Gateway MAC: 7a:77:1f:c0:00:04
    Agent-Remote-Id: GLOBAL.RTBRICK.2
    Agent-Circuit-Id: 0.0.0.0/0.0.0.0 eth 0:2
    DHCPv4:                                      (4)
        Mode: server
        State: Bound
        Address: 192.168.160.1/255.255.255.255
        Primary DNS: 192.168.100.1
        Secondary DNS: 192.168.100.2
        Lease Created: Wed Jul 19 11:45:42 GMT +0000 2023 (0:00:37.559994)
        Lease Time: 300 seconds
        Lease Expire: 263 seconds
1 Each subscriber is uniquely identified by a 64bit number called subscriber-id.
2 Incoming interface and the corresponding VLANs of the subscribers are displayed.
3 MAC address of the subscriber, which is used to build the username.
4 IP-related information including leased IPv4 address and DNS servers are listed.
Similar information can be retrieved using the show subscriber <subscriber-id> detail command.

Finally, you can monitor the usage of the IP address pools defined on the node:

cfg> show subscriber pool summary
Pool Name                        AFI  Usage           Range
IPOE_POOL_IPV4                   IPv4 3/1024          192.168.160.0 - 192.168.163.255
cfg> show subscriber pool ipv4 IPOE_POOL_IPV4 allocation

Subscriber-Id          Timestamp                            Address/Prefix
216454257090494465     Wed Jul 19 10:43:40 GMT +0000 2023   192.168.160.0
216454257090494466     Wed Jul 19 10:43:40 GMT +0000 2023   192.168.160.1
216454257090494467     Wed Jul 19 10:43:40 GMT +0000 2023   192.168.160.2

When users are experiencing connectivity issues, it is often useful to see the history of their disconnections. RBFS provides the show subscriber history command which provides the reason why subscribers are terminated for the last 24 hours. In case of hundreds or thousends of users, the command supports a filter knob to limit the amount of output:

cfg> show subscriber history filter mac 02:00:00:00:00:02
Subscriber-Id          Type   Timestamp                            Terminate Code
216454257090494466     IPoE   Wed Jul 19 10:43:41 GMT +0000 2023   IPoE Lower Layer Down
216454257090494471     IPoE   Wed Jul 19 11:04:30 GMT +0000 2023   IPoE Lower Layer Down
216454257090494476     IPoE   Wed Jul 19 11:05:28 GMT +0000 2023   IPoE Lower Layer Down

RADIUS Authentication and Accounting

We already know that configuring subscriber management services requires the configuration of an aaa-profile. For beginning, we have set the authentication method to NONE in order to bypass the authentication. Next, we will add RADIUS authentication and accounting to our configuration.

RADIUS Overview

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.

ipoe dhcpv4 radius
Figure 4. RADIUS Message Exchange

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.

Configuring RADIUS Authentication

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).

Exercise 5: Configuring RADIUS Server

Configure a RADIUS server named SN with IP address of 172.16.101.18. The secret key should be set to SecretKey. Also enable authentication and use non-default port 1645.

Note, that you have no IP connectivity to the RADIUS server which is directly connected to R1. Configure hostif-0/0/0 with VLAN 20 and IP address of 172.16.101.17/28 and use this address as source-address for communication with the RADIUS server.

Click to reveal the answer
cfg> set interface hostif-0/0/0 unit 20 instance default
cfg> set interface hostif-0/0/0 unit 20 vlan 20
cfg> set interface hostif-0/0/0 unit 20 address ipv4 172.16.101.17/28
cfg> set access radius-server SN address 172.16.101.18
cfg> set access radius-server SN source-address 172.16.101.17
cfg> set access radius-server SN secret-plain-text SecretKey
cfg> set access radius-server SN routing-instance default
cfg> set access radius-server SN authentication enable true
cfg> set access radius-server SN authentication port 1645
cfg> commit

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.

cfg> show radius server
RADIUS Server            Address          Authentication State Accounting State
SN                       172.16.101.18    ACTIVE               DISABLED

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.

Exercise 6: Configuring RADIUS Profile

Configure a RADIUS profile named MYRADIUS which includes the RADIUS server SN defined in the last exercise for authentication. Set the nas-identifier to BNG, the nas-ip-address to your lo-0/0/0/0 address and the nas-port-type to Ethernet.

Click to reveal the answer
cfg> set access radius-profile MYRADIUS nas-identifier BNG
cfg> set access radius-profile MYRADIUS nas-ip-address 192.168.0.1
cfg> set access radius-profile MYRADIUS nas-port-type Ethernet
cfg> set access radius-profile MYRADIUS authentication radius-server-profile-name SN
cfg> commit

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

Exercise 7: Update AAA Profile Configuration

In a previous exercise, the authentication was set to NONE for AAA profile IPOE_AUTH. Update the configuration to use RADIUS for authentication and associate the MYRADIUS profile with the AAA profile.

Click to reveal the answer
cfg> set access aaa-profile IPOE_AUTH aaa-radius-profile MYRADIUS
cfg> set access aaa-profile IPOE_AUTH authentication order RADIUS
cfg> commit

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 IPoE sessions are established:

cfg> show ipoe subscriber
Subscriber-Id          Interface        VLAN      MAC               State
216454257090494488     hostif-0/0/4     128:1     02:00:00:00:00:01 ESTABLISHED
216454257090494489     hostif-0/0/4     128:2     02:00:00:00:00:02 ESTABLISHED
216454257090494490     hostif-0/0/4     128:3     02:00:00:00:00:03 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 IPoE sessions:

cfg> show subscriber pool summary
Pool Name                        AFI  Usage           Range
IPOE_POOL_IPV4                   IPv4 2/1024          192.168.160.0 - 192.168.163.255

cfg> show subscriber pool ipv4 IPOE_POOL_IPV4 allocation
Subscriber-Id          Timestamp                            Address/Prefix
216454257090494489     Wed Jul 19 16:22:20 GMT +0000 2023   192.168.160.23
216454257090494490     Wed Jul 19 16:22:20 GMT +0000 2023   192.168.160.24

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

cfg> show ipoe subscriber 216454257090494488 detail
Subscriber-Id: 216454257090494488
    State: ESTABLISHED
    Uptime: Wed Jul 19 16:22:20 GMT +0000 2023 (0:01:40.710220)
    Interface: hostif-0/0/4
    Outer VLAN: 128
    Inner VLAN: 1
    Outer VLAN Encapsulation: 802.1q
    Client MAC: 02:00:00:00:00:01
    Gateway Interface: lo-0/0/0/0
    Gateway Instance: default
    Gateway IPv4: 192.168.0.1/255.255.255.255
    Gateway MAC: 7a:77:1f:c0:00:04
    Agent-Remote-Id: GLOBAL.RTBRICK.1
    Agent-Circuit-Id: 0.0.0.0/0.0.0.0 eth 0:1
    DHCPv4:
        Mode: server
        State: Bound
        Address: 192.168.170.1/255.255.255.255    (1)
        Primary DNS: 192.168.200.3                (2)
        Secondary DNS: 192.168.200.4              (2)
        Lease Created: Wed Jul 19 16:22:20 GMT +0000 2023 (0:01:40.722182)
        Lease Time: 300 seconds
        Lease Expire: 201 seconds
1 IP address assigned by RADIUS server
2 DNS server assigned by RADIUS server

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.

RADIUS attributes can overwrite generic parameters that are defined in profiles. When a user is successfully authenticated by a RADIUS server, the RADIUS server can send specific attributes back to the BNG based on the user’s identity or other criteria. Thus, RADIUS attributes can be used to define specific IP address assignments, access control lists, bandwidth limits, or any other parameter relevant to the user’s session. These attributes will take precedence over generic settings.

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.

Configuring RADIUS Accounting

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.

Exercise 8: Configuring RADIUS Accounting

Configure the following steps to enable RADIUS accounting:

  • Enable accounting with port 1646 in your RADIUS server configuration

  • Add the RADIUS server to your radius-profile as accounting server

  • Add accounting to your aaa-profile. Set the interim-interval to 30.

Click to reveal the answer
cfg> set access radius-server SN accounting enable true
cfg> set access radius-server SN accounting port 1646
cfg> set access radius-profile MYRADIUS accounting radius-server-profile-name SN
cfg> set access aaa-profile IPOE_AUTH accounting order RADIUS
cfg> set access aaa-profile IPOE_AUTH accounting interim-interval 30
cfg> commit
cfg> show radius server
RADIUS Server            Address          Authentication State Accounting State
SN                       172.16.101.18    UP                   ACTIVE

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

  • Session counters are calculated using the LIF statistics by default

  • Class counters are filled by queue counters which ensures that only traffic leaving the device is counted here.

  • Policy counters are populated by ingress policiers.

Accounting information in RBFS is based on hardware resource of the device. Therefore, in virtual nodes all counters are zero.

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

cfg> show subscriber 216454257090494471 accounting
Subscriber-Id: 216454257090494471
    IFL: ipoe-0/0/4/216454257090494471
    Start Timestamp: Wed Jul 19 15:05:29 GMT +0000 2023
    Idle Timestamp: never
    Session-Timeout: 0 seconds
    Idle-Timeout: 0 seconds
    Session Statistics:
        Ingress: 0 packets 0 bytes
        Egress: 0 packets 0 bytes
    LIF Statistics:
        Ingress: 0 packets 0 bytes
        Egress: 0 packets 0 bytes
    Egress Class (Queue) Statistics:
        class-0: 0 packets 0 bytes dropped: 0 packets 0 bytes
        class-1: 0 packets 0 bytes dropped: 0 packets 0 bytes
        class-2: 0 packets 0 bytes dropped: 0 packets 0 bytes
        class-3: 0 packets 0 bytes dropped: 0 packets 0 bytes
        class-4: 0 packets 0 bytes dropped: 0 packets 0 bytes
        class-5: 0 packets 0 bytes dropped: 0 packets 0 bytes
        class-6: 0 packets 0 bytes dropped: 0 packets 0 bytes
        class-7: 0 packets 0 bytes dropped: 0 packets 0 bytes
    Ingress Policer Statistics:
        Level 1: 0 packets 0 bytes dropped: 0 packets 0 bytes
        Level 2: 0 packets 0 bytes dropped: 0 packets 0 bytes
        Level 3: 0 packets 0 bytes dropped: 0 packets 0 bytes
        Level 4: 0 packets 0 bytes dropped: 0 packets 0 bytes

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

IPv6 Support

IPoE subscribers can be either single-stack IPv4, single-stack IPv6 or dual-stack. So far, we have configured our subscriber to be single-stack IPv4. The same configuration steps are necessary to enable IPv6 support. The main difference between IPv4 and IPv6 is that IPoE subscribers usually get two IPv6 prefixes, one for the link between residential gateway and BNG and another one to use within the customer’s LAN. The later one is called a delegated prefix and removes the need for NAT.

Exercise 9: Configuring IPv6 Address Pool

Configure two IPv6 address pools, IPOE_POOL_IPV6 (fc00:c0a8:ff01::/64 - fc00:c0a8:ff01:03ff::/64) and IPOE_POOL_V6PD(fc00:c0a8:ff10:0000::/56 - fc00:c0a8:ff13:ff00::/56). Also add two static routes fc00:c0a8:ff01::/52 and fc00:c0a8:ff10::/44 to the configuration and redistribute them into BGP.

Note, that the static routes cover more prefixes than the configured IPv6 address pools to allow extension in the future.

Click to reveal the answer
cfg> set access pool IPOE_POOL_IPV6 ipv6-prefix low fc00:c0a8:ff01::/64
cfg> set access pool IPOE_POOL_IPV6 ipv6-prefix high fc00:c0a8:ff01:03ff::/64
cfg> set access pool IPOE_POOL_V6PD ipv6-prefix low fc00:c0a8:ff10:0000::/56
cfg> set access pool IPOE_POOL_V6PD ipv6-prefix high fc00:c0a8:ff13:ff00::/56
cfg> set instance default static route ipv6 fc00:c0a8:ff01::/52 unicast DISCARD
cfg> set instance default static route ipv6 fc00:c0a8:ff10::/44 unicast DISCARD
cfg> set instance default protocol bgp address-family ipv6 unicast redistribute static
cfg> commit
Exercise 10: Configuring IPv6 Support in Access Profile

Update the existing access profile IPOE_ACCESS by enabling dhcpv6 protocol and address-family ipv6. Also add the IPv6 address pool and delegated prefix pool as well as two DNS servers (fc00:c0a8:ffff::1 and fc00:c0a8:ffff::2) to the existing access profile.

Click to reveal the answer
cfg> set access access-profile IPOE_ACCESS protocol dhcpv6 enable true
cfg> set access access-profile IPOE_ACCESS address-family ipv6 enable true
cfg> set access access-profile IPOE_ACCESS address-family ipv6 pool-name IPOE_POOL_IPV6
cfg> set access access-profile IPOE_ACCESS address-family ipv6 prefix-delegation-pool-name IPOE_POOL_V6PD
cfg> set access access-profile IPOE_ACCESS address-family ipv6 primary-dns fc00:c0a8:ffff::1
cfg> set access access-profile IPOE_ACCESS address-family ipv6 secondary-dns fc00:c0a8:ffff::2
cfg> set access access-profile IPOE_ACCESS address-family ipv6 instance default
cfg> commit

Now let’s open another terminal, log into the service node and start the BNG Blaster again. We now need another BNG Blaster configuration file (subscriber_ipoe_dualstack.json) to include IPv6:

student@tour:~$ rtb-ssh SN
Logging into SN as supervisor ...
<...>
supervisor@SN:~ $ sudo bngblaster -C subscriber_ipoe_dualstack.json -c 3
[sudo] password for supervisor:
Jul 19 10:43:40.400732 Resolve network interfaces
Jul 19 10:43:40.400887 All network interfaces resolved
Jul 19 10:43:41.514560 ALL SESSIONS ESTABLISHED

Verifying that IPoE subscribers sessions are established and utilization of IP address pool can be monitored exactly the same way as with IPv4-only subscribers:

cfg> show ipoe subscriber
Subscriber-Id          Interface        VLAN      MAC               State
216454257090494494     hostif-0/0/4     128:1     02:00:00:00:00:01 ESTABLISHED
216454257090494495     hostif-0/0/4     128:2     02:00:00:00:00:02 ESTABLISHED
216454257090494496     hostif-0/0/4     128:3     02:00:00:00:00:03 ESTABLISHED
cfg> show subscriber pool summary
Pool Name                        AFI  Usage           Range
IPOE_POOL_IPV4                   IPv4 2/1024          192.168.160.0 - 192.168.163.255
IPOE_POOL_IPV6                   IPv6 2/1024          fc00:c0a8:ff01::/64 - fc00:c0a8:ff01:3ff::/64
IPOE_POOL_V6PD                   IPv6 2/1024          fc00:c0a8:ff10::/56 - fc00:c0a8:ff13:ff00::/56

Diving into more details of a specific subscriber you notice that now additional information about the IPv6 are available:

cfg> show ipoe subscriber 216454257090494495 detail
Subscriber-Id: 216454257090494495
    State: ESTABLISHED
    Uptime: Wed Jul 19 16:45:30 GMT +0000 2023 (0:02:41.367475)
    Interface: hostif-0/0/4
    Outer VLAN: 128
    Inner VLAN: 2
    Outer VLAN Encapsulation: 802.1q
    Client MAC: 02:00:00:00:00:02
    <...>
    DHCPv6:                                      (1)
        Mode: server
        State: Bound
        Client DUID: 00030001020000000002
        Server DUID: 0003001b78771ffffec00004
        IA_NA:
            Address: fc00:c0a8:ff01::            (2)
            IAID: 50331648
            Active: True
        IA_PD:
            Prefix: fc00:c0a8:ff10::/56          (3)
            IAID: 67108864
            Active: True
        Primary DNS: fc00:c0a8:ffff::1           (4)
        Secondary DNS: fc00:c0a8:ffff::2         (4)
        Lease Created: Wed Jul 19 16:45:30 GMT +0000 2023 (0:02:41.385336)
        Lease Time (Lifetime): 14400 seconds
        Lease Expire: 14239 seconds
        Preferred Lifetime: 1800 seconds
1 DHCPv6 section
2 Assigned named address
3 Assigned delegated prefix
4 IPv6 DNS server entries

Summary

This module outlined the building blocks of IPoE subscriber management. You should be familiar with concepts of DHCP and DHCPv6 as well as RADIUS autthentication and accounting. In addition, you should be able to setup access profiles and aaa profiles.

If you have completed the exercise, you can check the results by executing

student@tour:~/trainings_resources/robot$ robot ipoe/ipoe_verify.robot