08-12-2018 09:18 AM - edited 03-01-2019 02:01 PM
BNG Geo-Redundancy provides redundancy for subscriber sessions (state full) across two or more BNGs which may be geographically spread out and without any dedicated layer-1/2 connectivity between the devices (i.e. they have L3 connectivity over a shared core network via usual IP/MPLS routing). Geographical redundancy for subscribers is delivered by transferring relevant session state from master to slave BNG which can then help in failover (FO) or planned switchover (SO) of sessions from one BNG device to another
SRG (Subscriber Redundancy Group): is a set of access interfaces (or just single one) and all subscribers over them would FO/SO as a group
Master/Slave: SRG system is a pair of 2 BNG nodes where one is Master and other acts as Slave in the context of SRG groups. The notion of master/slave is always in the context of a specific SRG and not for the BNG device as a whole
Active/Active SRG system: SRG system where both BNG nodes acting as Master/Slave for redundancy groups. Like BNG1 is master for some SRGs and for which BNG2 acting as slave AND BNG2 as master for some groups for which BNG1 is acting as Slave. Load balancing can be achieved In this deployment model as overall upstream/downstream subscriber traffic is taken over both BNGs
Active/Standby SRG system: here same BNG node will be set as master for all hosted SRGs. Like BNG1 node as master and BNG2 as slave for all SRGs hosted in the system
Revertive switchover: after Master role switch to the other node because of any failure on current master role switch back will be triggered to preferred master node once the failure get recovers on that node.
Virtual-mac: this defines the common MAC to be used for redundant BNG gateways. Both BNGs will use this MAC for their BNG access interfaces which are defined under the SRGs. This has group level scope. This is the MAC address which is seen as the gateway MAC by all subscribers in that SRG group and helps to switch the data from old Master to new Master seamlessly even after switchover due to core/access failures as both the gateway address and MAC remain unchanged. All the control packets (like DHCPv4, DHCPv6 ) and data packets will use vMAC as the source MAC at L2. Similarly, client will use the vMAC as the destination mac in upstream direction
Core-tracking: this parameter is to define the tracking object for core link.SRG SO reason can be access link failure, core link failure OR administratively triggered SO, so here SRG SO will be triggered when core-tracking is down
Access-tracking: this parameter is to define the tracking object for access-link. So here SRG SO will be triggered when access-tracking is down
SRG SO/FO: SRG switchover/failover is group level. SO/FO can be triggered by access link/core link failure, node level failure OR else switchover can be triggered administratively
Preferred-role: we can define which BNG node to be set as Master or Slave as per the network preference we have
Hold-timer: This configuration helps to avoid back-to-back SRG switchovers if want to be avoided. Once SRG-SO triggered by any means, hold timer kick in on current Master so that no more switchover until hold-timer expires.
Revertive-timer: this timer helps to enable revertive SO and revertive SO will be held till timer expires. By default, revertive-SO is disabled and this configuration enables it.
Slave-mode: slave mode can be hot-standby OR warm-standby, where hot-standby means subscriber sessions synced on slave node will be consuming HW resource on Slave also as complete HW programming of sessions happens on it. Warm-standy means HW resources won’t be consumed on slave and it just holds the sessions in PI and don’t program in HW. Currently warm-standby is not supported.
State-control-route: subscriber routes will be available on both master & slave nodes. With that we can’t distribute subscriber routes in dynamic routing protocols as upstream nodes will see subscriber reachability through both BNG nodes. To avoid that we can configure state-control route (usually subscriber network prefixes, ipv4/ipv6) under each SRGs based on that respective subscriber address pools. And these state-control routes can be redistributed over dynamic protocols based on route-policy. And only master node installs state-control routes in RIB so there won’t be any routing inconsistency.
With SRG vMAC configured, ND on BNG will send out two RAs to the client
Both RAs will hit client and order is not guaranteed, so the client could pick the default gateway from any of these RAs who comes late. This behaviour is undesirable in geo-redundancy since we want the client to populate IPv6 Gateway as vMAC from the RA received. This behaviour will also ensure that the client sees the same gateway even after the switchover so that data switches seamlessly from old master to new master.
By default, ND on BNG sends RAs with preference as medium; We can modify the preference from the default to other values ‘Low’ or ‘High’
either through configuration on access-interface or through configuration on dynamic-template (Introduced in 5.2.2 release)
interface <if-name>
ipv6 nd router-preference high|medium|low
[no] ipv6 nd router-preference
dynamic-template …
ipv6 nd router-preference high|medium|low
[no] ipv6 nd router-preference Route advertisement:
So to solve the problem explained above, we need one of the below pieces of configuration code which will ensure that the client selects the RA with vMAC always to populate its ipv6 default gateway.
interface Bundle-Ether7.10
ipv4 point-to-point
ipv4 unnumbered Loopback1
ipv6 nd other-config-flag
ipv6 nd router-preference low
ipv6 nd managed-config-flag
ipv6 enable
service-policy type control subscriber DUAL-STACK
ethernet cfm
mep domain OLT10 service OLT10 mep-id 111
!
!
encapsulation dot1q 10
ipsubscriber ipv4 l2-connected
initiator dhcp
!
ipsubscriber ipv6 l2-connected
initiator dhcp
!
!
OR
dynamic-template
type ipsubscriber DUAL-STACK
ipv4 unnumbered Loopback1
ipv6 nd other-config-flag
ipv6 nd router-preference high
ipv6 nd managed-config-flag
ipv6 enable
!
!
Without “fast-switchover” feature enabled:
To avoid this local switching, we have ‘fast-switchover’ feature which works as below
Configuration example:
subscriber
redundancy
group 100
preferred-role Master
virtual-mac 0001.0301.0301
peer 1.0.0.1
enable-fast-switchover
!
!
!
Trigger |
Upstream convergence (subscriber to CORE) |
Downstream convergence (CORE to subscriber) |
Admin SO | 50msec |
250msec
|
Access down | 50msec | 200msec |
Master node power down | 40sec | 45sec |
Trigger |
Upstream convergence (subscriber to CORE) |
Downstream convergence (CORE to subscriber) |
Admin SO | 1.4sec | 250msec |
Access down | 1.5sec | 500msec |
Master node power down | 65sec | 40sec |
Above mentioned common configuration need to be replicated on BNG2 as well.
Only SRG master will hold these stats
If in DHCP proxy mode, Does this mean that only the BNGs in the master state will advertise the subnet route of the giaddr interface to the upper layer router? So that the downstream DHCP messages also return to the Master but not slave?
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: