Appendix: Subscriber management in distributed access aggregation devices
This model requires an aggregation network with high-capacity Ethernet-centric aggregation devices that are highly scalable in terms of filter policies, queues, policers, QoS scheduler, and accounting capabilities, which are applied to subscribers as part of subscriber management. These nodes are referred to as Broadband Service Aggregators and are highly distributed, connecting large number of access nodes to the VPLS aggregation network. Sometimes this deployment is referred to as a "bridged model in distributed service edge".
Through Layer 2 aggregation switches, subscriber traffic is aggregated toward the Layer 3 edge router. This edge router terminates Layer 2 access and routes subscriber traffic over various transport technologies (such as IP, MPLS, VXLAN, and SRv6) with the full set of routing protocols, including multicast routing. The edge router supports sophisticated QoS for per service and per-content or source differentiation.
The connectivity between BSAs and the edge router is a secure VPLS infrastructure shown in Bridged Broadband Service Delivery Architecture. This VPLS forms a multipoint Ethernet network with security extensions to prevent unauthorized communication, denial of service, and theft of service. One of the advantages of using VPLS for this application is that VPLS instances can be automatically established over both "hub and spoke" and ring topologies providing sub-50 ms resilience. Regardless of the fiber plant layout, VPLS enables a full mesh to be created between the BSAs and edge router, ensuring efficient traffic distribution and resilience to node or fiber failure.
Other unique features of the BSA and the edge router that contribute to this secure VPLS infrastructure are:
- Using Residential Split Horizon Groups (RSHG), direct user-user bridging is automatically prohibited, without the need for address-specific ACLs.
- RSHG combined with the ARP reply agent perform ARP and broadcast suppression to ensure that addressing information is restricted.
- Protection against theft of service and denial of service is provided by MAC or IP filters automatically populated using DHCP snooping, and by MAC pinning.
- Using the RADIUS interface, it is possible to perform RADIUS authentication of users before allowing a DHCP discover to progress into the network.
This model, subscriber management in distributed access aggregation devices, is considered a legacy model that relies on DHCPv4 snooping functions in BSA for subscriber identification and, therefore, is supported only for IPoEv4 devices. Because IPoEv6 and PPPoEv4/v6 devices are not supported in this model its use has been limited and replaced by the RCO model, where subscribers are terminated on the BNG in a central office location.
Configuration example
This configuration example focuses on subscriber management in a distributed aggregation network implemented in a VPLS on BSA. In such environment, the key configuration concepts in subscriber management, such as SLA profile, subscriber profile, subscriber ID, and subscriber identification policy, are optional. If these configuration concepts are omitted, a subscriber with all of its devices is equated to a SAP where DHCP lease state of the hosts is snooped, and consequently managed in the Layer 2 environment. This configuration example deliberately excludes the setup of these optional concepts, which is explored in more detail in Subscriber management concepts, particularly within the context of the commonly employed RCO model.
BSA Configuration
VPLS configuration:
- DHCP snooping is enabled on the subscriber-facing SAP and the spoke SDP facing the edge router.
- This example includes only one SAP, which represents a subscriber. For multiple subscribers in the network, a SAP per subscriber must be configured.
- All SAPs are part of a split-horizon group, preventing direct communication between the subscribers. For inter-subscriber communication, traffic must flow through the BSR for security purposes.
- Antispoof is set to subscriber MAC and IP address.
- Subscribers are authenticated based on DHCPv4 Option82 Circuit-Id.
- The BSA replies to the ARP request from subscribers, utilizing a distributed environment, instead of propagating ARP communication to a central point – edge router.
- MAC addresses and IP addresses of the subscribers are learned through DHCP snooping (mac-pinning is used to populate MAC address into VPLS learned through DHCP).
- Filters and QoS setting are configured on ingress and egress for this subscriber.
The following example shows a VPLS configuration.
VPLS configuration (MD-CLI)
[ex:/configure service vpls "demo-bridged"]
A:admin@node-2# info
service-id 10
customer "1"
split-horizon-group "RSHG" {
residential true
}
spoke-sdp 100:50 {
dhcp {
snoop true
}
}
sap 1/2/6:10 {
anti-spoof source-ip-and-mac-addr
split-horizon-group "RSHG"
arp-reply-agent true
radius-auth-policy "radius-1"
ingress {
qos {
sap-ingress {
policy-name "demo-ingress"
}
}
filter {
ip "sub1-ingress"
}
}
egress {
qos {
sap-egress {
policy-name "demo-egress"
}
}
filter {
ip "sub1-egress"
}
}
stp {
admin-state disable
}
fdb {
mac-pinning true
}
dhcp {
snoop true
option-82 {
action keep
}
}
}
VPLS configuration (classic CLI)
A:node-2>config>service# info
----------------------------------------------
vpls 10 name "demo-bridged" customer 1 create
split-horizon-group "RSHG" residential-group create
exit
stp
shutdown
exit
sap 1/x1/1/c1/4:10.10 split-horizon-group "RSHG" create
arp-reply-agent
dhcp
shutdown
snoop
exit
authentication-policy "radius-1"
anti-spoof ip-mac
ingress
qos 10
filter ip 10
exit
egress
qos 20
filter ip 20
exit
no shutdown
exit
spoke-sdp 100:50 create
dhcp
snoop
exit
no shutdown
exit
no shutdown
exit
----------------------------------------------
The following example shows a persistency configuration for DHCP lease states on BSR.
persistency configuration for DHCP lease states on BSR (MD-CLI)
[ex:/configure system persistence]
A:admin@node-2# info
subscriber-mgmt {
location cf3
}
persistency configuration for DHCP lease states on BSR (classic CLI)
A:node-2>config>system>persistence# info
----------------------------------------------
subscriber-mgmt
location cf3:
exit
----------------------------------------------
The following example shows RADIUS configuration for authentication.
RADIUS server configuration for authentication (MD-CLI)
[ex:/configure router "Base" radius]
A:admin@node-2# info
server "free-radius-1" {
address 192.168.114.2
secret "98a4Z4jC9e5KtqVzEN24jTYa+9lOnwQask5IqOdfshV0BB7of64BFUcEdsr88XvwRNV2 hash2"
}
RADIUS server configuration for authentication (classic CLI)
A:node-2>config>router>radius-server# info
----------------------------------------------
server "free-radius-1" address 192.168.114.2 secret "98a4Z4jC9e5KtqVzEN24jTYa+9lOnwQask5IqOdfshV0BB7of64BFUcEdsr88XvwRNV2" hash2 create
exit
----------------------------------------------
RADIUS configuration for authentication (MD-CLI)
[ex:/configure subscriber-mgmt radius-authentication-policy "radius-1"]
A:admin@node-2# info
password "ncd8qyrNUMhYfa2SfrUqHMDZ9IXn3sVSmYBzbw== hash2"
pppoe-access-method pap-chap
radius-server-policy "radius-server-1"
user-name {
format circuit-id
}
include-radius-attribute {
circuit-id true
nas-identifier true
}
RADIUS configuration for authentication (classic CLI)
A:node-2>config>subscr-mgmt# info
----------------------------------------------
authentication-policy "radius-1" create
password "ncd8qyrNUMhYfa2SfrUqHMDZ9IXn3sVSmYBzbw==" hash2
user-name-format circuit-id
pppoe-access-method pap-chap
include-radius-attribute
circuit-id
nas-identifier
exit
radius-server-policy "radius-server-1"
exit
----------------------------------------------
RADIUS configuration for AAA (MD-CLI)
[ex:/configure aaa]
A:admin@node-2# info
radius {
server-policy "radius-server-1" {
servers {
router-instance "Base"
server 1 {
server-name "free-radius-1"
}
}
}
}
RADIUS configuration for AAA (classic CLI)
A:node-2>config>aaa# info
----------------------------------------------
radius-server-policy "radius-server-1" create
servers
router "Base"
server 1 name "free-radius-1"
exit
exit
----------------------------------------------
Edge router configuration
The edge router acts as the DHCPv4 relay, which is sending DHCP messages to the server. DHCPv4 snooping is not enabled on the edge router. In addition to the remote DHCPv4 server, only the BSA maintains lease state in this environment.
Edge Router Configuration (MD-CLI)
[ex:/configure service ies "BSR" interface "towards-vpls"]
A:admin@node-2# info
spoke-sdp 101:34 {
}
ipv4 {
primary {
address 192.0.2.254
prefix-length 24
}
dhcp {
server [172.16.0.254]
trusted true
Edge Router Configuration (classic CLI)
A:node-2>config>service>ies>if# info
----------------------------------------------
address 192.0.2.254/24
dhcp
shutdown
server 172.16.0.254
trusted
exit
spoke-sdp 101:34 create
no shutdown
exit
----------------------------------------------