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 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:
-
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).
-
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.
-
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.
-
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.
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
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.
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.
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.
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
, ordouble-tagged
) along with the physical interface name (IFP) and the corresponding VLAN range in case ofsingle-tagged
, ordouble-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.
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.
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).
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
.
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.
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.
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 theinterim-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.
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
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