- play_arrow AAA for Subscriber Management
- play_arrow AAA for Subscriber Management
- play_arrow RADIUS for Subscriber Management
- RADIUS Servers and Parameters for Subscriber Access
- Storage and Reporting of Interface Descriptions to Uniquely Identify Subscribers
- Session Options for Subscriber Access
- RADIUS NAS Port Attributes and Options
- RADIUS Logical Line Identification
- RADIUS Authentication and Accounting Basic Configuration
- RADIUS Reauthentication As an Alternative to RADIUS CoA for DHCP Subscribers
- Configuring RADIUS Reauthentication for DHCP Subscribers
- RADIUS Accounting for Subscriber Access
- Verifying and Managing Subscriber AAA Information
- Session Termination Causes and RADIUS Termination Cause Codes
- AAA Termination Causes and Code Values
- DHCP Termination Causes and Code Values
- L2TP Termination Causes and Code Values
- PPP Termination Causes and Code Values
- VLAN Termination Causes and Code Values
- play_arrow Domain Maps for Subscriber Management
- play_arrow Testing and Troubleshooting AAA
- play_arrow RADIUS Dictionary Files
- Junos OS Release 15.1 Subscriber Management RADIUS Dictionary [DCT]
- Junos OS Release 16.1 Subscriber Management RADIUS Dictionary [DCT]
- Junos OS Release 16.2 Subscriber Management RADIUS Dictionary [DCT]
- Junos OS Release 17.1 Subscriber Management RADIUS Dictionary [DCT]
- Junos OS Release 17.4 Subscriber Management RADIUS Dictionary [DCT]
- Junos OS Release 18.2 Subscriber Management RADIUS Dictionary [DCT]
- Junos OS Release 18.4 Subscriber Management RADIUS Dictionary [DCT]
-
- play_arrow DHCP and DHCPv6 for Subscriber Management
- play_arrow DHCP for Subscriber Management
- DHCP Overview
- DHCP Access Profiles for Subscriber Authentication and Accounting Parameters
- Overrides for Default DHCP Local Server and DHCP Relay Configuration Settings
- Delaying DHCP Offer and Advertise Responses to Load Balance DHCP Servers
- DHCP Options and Selective Traffic Processing
- Using DHCP Option 82 Information
- Default Services for DHCP Subscribers
- DHCP Client Attribute and Address Assignment
- DHCP Lease Times for IP Addresses
- DHCP Leasequery Methods
- DHCP Client Authentication With An External AAA Authentication Service
- Receiving DHCP Options From a RADIUS Server
- Common DHCP Configuration for Interface Groups and Server Groups
- Number of DHCP Clients Per Interface
- Maintaining DHCP Subscribers During Interface Delete Events
- Dynamic Reconfiguration of Clients From a DHCP Local Server
- Understanding Deferred NACK on DHCP Reconfigure Abort
- Conserving IP Addresses Using DHCP Auto Logout
- DHCP Short Cycle Protection
- DHCP Monitoring and Management
-
- play_arrow IPv6 for Subscriber Management
- play_arrow IPv6 for Subscriber Management
- Introduction to IPv6 Addresses
- Migration to IPv6 Using IPv4 and IPv6 Dual Stack
- IPv6 WAN Link Addressing with NDRA
- IPv6 WAN Link Addressing with DHCPv6 IA_NA
- Subscriber LAN Addressing with DHCPv6 Prefix Delegation
- WAN and LAN Addressing Using DHCPv6 IA_NA and DHCPv6 Prefix Delegation
- Designs for IPv6 Addressing in a Subscriber Access Network
- Dual-Stack Access Models in a DHCP Network
- Dual-Stack Access Models in a PPPoE Network
- Best Practices for Configuring IPv4 and IPv6 Dual Stack in a PPPoE Access Network
- Dual Stack for PPPoE Access Networks Using DHCP
- Dual Stack for PPPoE Access Networks Using NDRA
- IP Demultiplexing Interfaces on Packet-Triggered Subscriber Services
- Conservation of IPv4 Addresses for Dual-Stack PPP Subscribers Using On-Demand IPv4 Address Allocation
- Dual Stack Subscribers Monitoring and Management
-
- play_arrow DHCPv6 for Subscriber Management
- play_arrow Packet Triggered Subscriber Services
- play_arrow Packet Triggered Subscriber Services
-
- play_arrow Address-Assignment Pools for Subscriber Management
- play_arrow Address-Assignment Pools for Subscriber Management
-
- play_arrow DNS Addresses for Subscriber Management
- play_arrow DNS Addresses for Subscriber Management
-
- play_arrow Access Node Control Protocol and the ANCP Agent for Subscriber Services
- play_arrow Access Node Control Protocol and the ANCP Agent for Subscriber Services
-
- play_arrow Diameter Base Protocol and its Applications
- play_arrow Diameter Base Protocol and its Applications
- Diameter Base Protocol
- Gx-Plus for Provisioning Subscribers
- 3GPP Policy and Charging Control for Wireline Provisioning and Accounting
- NASREQ for Authentication and Authorization
- JSRC for Subscriber Provisioning and Accounting
- JSRC and Subscribers on Static Interfaces
- Monitoring and Management Diameter Information
- Tracing Diameter Base Protocol Events for Troubleshooting
- Troubleshooting Diameter Networks
- Monitoring and Managing Static Subscriber Information
- Tracing Static Subscriber Events for Troubleshooting
-
- play_arrow Configuration Statements and Operational Commands
N+1 Support for BNG M:N Subscriber Service Redundancy
Learn about N+1 support for broadband network gateway (BNG) M:N subscriber service redundancy, which provides remarkable reduction in the reserved resources for the backup BNG.
N+1 Support for BNG M:N Subscriber Service Redundancy Overview
The N+1 support for BNG M:N subscriber service redundancy is a mechanism to back up
multiple primary BNGs to a single backup BNG. This mechanism provides reduction in
the reserved resources for redundancy purpose by over-subscribing the secondary
Packet Forwarding Engine in backup chassis. In this redundancy model we’ve
introduced a service-activation-on-failover mode. In the
service-activation-on-failover mode, you can configure the
subscriber state for an interface using less resources in the backup BNG to forward
traffic. When the primary BNG fails, the traffic switches over to the backup BNG
with basic statistics. The additional services such as CoS and firewall
automatically come to action in the background after the backup interface becomes
active and consumes the additional resources. The operational state of the backup
interface transitions from basic forwarding to full service restoration.
The new programming mode enables the system to consume less resources on the backup
BNG. Hence, you can back up more subscribers when the Packet Forwarding Engine is
not handling any traffic. This backup subscription is known as Packet Forwarding
Engine over-subscription on the backup BNG. With the
service-activation-on-failover mode, you can host three times
more subscribers on the backup BNG than the primary BNGs.
Benefits of N+1 Support for BNG M:N Subscriber Service Redundancy
- Reduces the cost of deploying backup BNGs.
How N+1 Support for BNG M:N Subscriber Service Redundancy Works
Figure 1 illustrates N+1 support for BNG M:N subscriber service redundancy. There are four BNGs shown in the topology. The BNGs A, C, and D are the active BNGs with 64000 dual-stack subscribers on each BNG. The backup BNG B with one line card backing up the other three active BNGs. You can use any MX Series device that can support MPC7 or MX10003 device with LC2103 as a backup BNG.
A1, C1, and D1 are the primary subscriber redundancy groups handling traffic of 64000
subscribers on each BNG. A2, C2, and D2 are the secondary subscriber redundancy
groups in service-activation-on-failover mode.
By default, the M:N subscriber redundancy feature configures the backup BNG in
hot-standby mode. To specifically enable the Packet Forwarding Engine
over-subscription, you need to configure the
service-activation-on-failover mode on the backup BNG.
When the subscribers log in to the primary BNGs, the active leasequery brings the
subscriber state to the backup BNG. As the backup BNG hosts the
service-activation-on-failover mode, the backup BNG consumes
minimal Packet Forwarding Engine resources and back ups up to 192000
subscribers.
- Subscriber Service Redundancy When Primary BNG Fails
- Subscriber Service Revert When the Primary BNG Becomes Active
Subscriber Service Redundancy When Primary BNG Fails
Let's see how the system manages when a BNG fails or a BNG becomes inactive. Considering the Figure 1, when the BNG C fails, the subscribers connected to the BNG C re-routes the traffic through the backup BNG B. As soon as the traffic re-routes to the secondary subscriber redundancy group C2, the BNG B performs the following:
- Starts forwarding the upstream and downstream traffic immediately with best-effort.
- Initiates background programming for the services such as CoS and firewall by utilizing the additional resources allocated in BNG B.
- The BNG B restores the full SLA for subscribers and the operational state becomes full-service when the background programming completes.
- The other secondary subscriber redundancy groups A2 and D2 continue to back up the BNGs A and D.
Subscriber Service Revert When the Primary BNG Becomes Active
You can configure the primary BNG C to revert the traffic flow from the backup BNG to the primary BNG when it becomes active. We recommend to use manual revert after checking the state of both BNGs for subscriber programming and confirming that a revert back will succeed. Consider the following scenarios when you enable the auto-revert traffic switchover functionality:
- If the primary BNG fails due to link failure, the background programming of the backup BNG takes several minutes depending on the number of subscribers. A quick revert is not desirable.
- If the primary BNG fails due to the line card or chassis failure, the time to synchronize the original primary chassis or line card using active leasequery or bulk leasequery depends on the number of subscribers.
- The system requires more time to analyze unplanned failures and make the line card or chassis into active service.
N+1 support for BNG M:N subscriber service redundancy does not support redundancy on multiple BNG failures at a time. If multiple BNGs fail at a time, the system back ups only the first BNG. The data of the remaining subscribers on the other failed BNGs are lost completely.
