Hello,
I'm trying to set up redundancy between a pair of ASR9ks for IPoE (DHCP) subscribers and am having a hard time wrapping my head around how one step is supposed to work.
In "BNG Geo-Redundancy for L2-connected IPoE Subscriber Sessions"[1] there's the following logical flow under Control Plane Establishment:
1. BNG nodes negotiate master/slave role while SRG peering establishment
2. DHCP discover broadcasted in the bridge-domain on access-SW
3. Discover message hit on both BNG nodes, but only Master node process it and Slave drops it
4. RADIUS authorization kick in as per the control policy configuration and Master BNG trigger RADIUS access request to RADIUS server
5. RADIUS server responds with access-accept to Master with associated user-profile
6. Master BNG processes the discover and forwards unicast discover towards the server as per the dhcp proxy profile attached to the access interface
7. Source address of DHCP message egress out of Master BNG will be Gi-addr configured in proxy profile. If Gi-addr is not configured then subscriber facing access interface IP will be used as the Gi-addr
8. DHCP server respond to Master node with DHCP offer as the Gi-addr route prefix received from master [.state control route active only on Master so master only advertise it to CORE]
I understand the basic theory of how this is supposed to work but I don't know what how to make steps 7 and 8 a reality. In my understanding, gi-addr is supposed to be the same as the address configured on the subscriber-facing interface. So if I have the following for a subscriber pool 12.34.56.0/24 (some bits omitted for brevity):
Te0/0/0/0.9
description Subscriber interface
ipv4 unnumbered Loopback9
service-policy type control subscriber DHCP-9
ipsubscriber ipv4 l2-connected
initiator dhcp
!
interface Loopback9
description Subscriber network 9
ipv4 address 12.34.56.1 255.255.255.0
Then should the DHCP configuration not be...
dhcp ipv4
interface TenGigE0/0/0/0.9 proxy profile Auth-9
profile Auth-9 proxy
helper-address vrf default 192.0.0.1 giaddr 12.34.56.1
!
...but doing so makes the gi-addr a connected route rather than a static one, and with both the active and standby BNGs having this interface up, replies from the DHCP server will not go to the correct box.
The aforementioned document and two others I've read[2][3] suggest using tracking to withdraw a static route for the subscriber pool, which makes sense on PPP(oE), but I do not understand how this works with "unnumbered" interfaces with DHCP.
I'm inclined to throw a secondary address on Lo9 so that each BNG can have a unique gi-addr and I can dump /32s into the RIB but that doesn't help me out if an SRG switchover occurs unless I also redistribute subscriber /32 routes as the loopback interface won't go down.
What is the right way to do this?
Thank you
Ross
[1] https://community.cisco.com/t5/service-providers-knowledge-base/bng-geo-redundancy-for-l2-connected-ipoe-subscriber-sessions/ta-p/3686641
[2] https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r6-0/bng/configuration/guide/b-bng-cg60xasr9k/b-bng-cg60xasr9k_chapter_01110.html
[3] https://community.cisco.com/t5/service-providers-knowledge-base/asr9000-xr-using-and-understanding-bng-geo-redundancy/ta-p/3158636
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
I'm trying to set up redundancy between a pair of ASR9ks for IPoE (DHCP) subscribers and am having a hard time wrapping my head around how one step is supposed to work.
In "BNG Geo-Redundancy for L2-connected IPoE Subscriber Sessions"[1] there's the following logical flow under Control Plane Establishment:
1. BNG nodes negotiate master/slave role while SRG peering establishment
2. DHCP discover broadcasted in the bridge-domain on access-SW
3. Discover message hit on both BNG nodes, but only Master node process it and Slave drops it
4. RADIUS authorization kick in as per the control policy configuration and Master BNG trigger RADIUS access request to RADIUS server
5. RADIUS server responds with access-accept to Master with associated user-profile
6. Master BNG processes the discover and forwards unicast discover towards the server as per the dhcp proxy profile attached to the access interface
7. Source address of DHCP message egress out of Master BNG will be Gi-addr configured in proxy profile. If Gi-addr is not configured then subscriber facing access interface IP will be used as the Gi-addr
8. DHCP server respond to Master node with DHCP offer as the Gi-addr route prefix received from master [.state control route active only on Master so master only advertise it to CORE]
I understand the basic theory of how this is supposed to work but I don't know what how to make steps 7 and 8 a reality. In my understanding, gi-addr is supposed to be the same as the address configured on the subscriber-facing interface. So if I have the following for a subscriber pool 12.34.56.0/24 (some bits omitted for brevity):
Te0/0/0/0.9
description Subscriber interface
ipv4 unnumbered Loopback9
service-policy type control subscriber DHCP-9
ipsubscriber ipv4 l2-connected
initiator dhcp
!
interface Loopback9
description Subscriber network 9
ipv4 address 12.34.56.1 255.255.255.0
Then should the DHCP configuration not be...
dhcp ipv4
interface TenGigE0/0/0/0.9 proxy profile Auth-9
profile Auth-9 proxy
helper-address vrf default 192.0.0.1 giaddr 12.34.56.1
!
...but doing so makes the gi-addr a connected route rather than a static one, and with both the active and standby BNGs having this interface up, replies from the DHCP server will not go to the correct box.
The aforementioned document and two others I've read[2][3] suggest using tracking to withdraw a static route for the subscriber pool, which makes sense on PPP(oE), but I do not understand how this works with "unnumbered" interfaces with DHCP.
I'm inclined to throw a secondary address on Lo9 so that each BNG can have a unique gi-addr and I can dump /32s into the RIB but that doesn't help me out if an SRG switchover occurs unless I also redistribute subscriber /32 routes as the loopback interface won't go down.
What is the right way to do this?
Thank you
Ross
[1] https://community.cisco.com/t5/service-providers-knowledge-base/bng-geo-redundancy-for-l2-connected-ipoe-subscriber-sessions/ta-p/3686641
[2] https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r6-0/bng/configuration/guide/b-bng-cg60xasr9k/b-bng-cg60xasr9k_chapter_01110.html
[3] https://community.cisco.com/t5/service-providers-knowledge-base/asr9000-xr-using-and-understanding-bng-geo-redundancy/ta-p/3158636
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/