[c-nsp] BNG Geo-Redundancy
Rimestad, Steinar
Steinar.Rimestad at altibox.no
Mon Oct 10 09:18:13 EDT 2022
Hi Ross.
I faced the very same issue when deploying BNG Geo Redundancy on some ASR9k's and solved it by assigning the giaddr as a /31 to be controlled with the state-control-route's and blocking the connected Loopback /32 from being redistributed into the network (BGP,ISIS)
This way the remote systems will follow your routing table and end up on the master which is whichever BNG with the current master. This solves the issue 7 and 8 with DHCP reply messages and RADIUS CoA's etc.
To make sure the correct IP is used in the DHCP message I use giaddr 0.0.0.0 which will pick the primary address allocated to the unnumbered loopback.
-
interface Bundle-Ether100.2
description ### S-Tag=2 BNG ###
ipv4 point-to-point
ipv4 unnumbered Loopback100
arp learning disable
service-policy type control subscriber BNG_2
ipsubscriber ipv4 l2-connected
initiator dhcp
!
encapsulation ambiguous dot1q 2 second-dot1q 2-4094
interface Loopback100
description ### BNG for BE100 ###
ipv4 address 10.0.116.58/32
ipv4 address 10.0.144.1/32 secondary
ipv4 address 10.0.234.1/32 secondary
subscriber
redundancy
group 100
description ### SRG100 ###
preferred-role master
slave-mode hot
peer 10.2.0.131
core-tracking uplinks
access-tracking downlink_be100
enable-fast-switchover
state-control-route ipv4 100.64.144.0/22 vrf default tag 100
state-control-route ipv4 100.64.234.0/23 vrf default tag 100
state-control-route ipv4 10.0.116.58/31 vrf default tag 100
interface-list
interface Bundle-Ether100.2 id 2
dhcp ipv4
profile IPoE_BNG_100 proxy
allow-move
helper-address vrf default 10.1.0.94 giaddr 0.0.0.0
helper-address vrf default 10.1.0.54 giaddr 0.0.0.0
relay information option
relay information policy keep
relay information option allow-untrusted
!
interface Bundle-Ether100.2 proxy profile IPoE_BNG_100
-
As mentioned. For the connected2bgp or connected2igp make sure to block redistribution of the /32's on the loopbacks. I also just match on the tag in my subscriber2bgp rpl.
route-policy SUBSCRIBER2BGP
if tag is 100 then
set community (1:100) additive
pass
else
drop
endif
end-policy
-
Hope this helps.
Regards,
Steinar
-----Original Message-----
From: cisco-nsp <cisco-nsp-bounces at puck.nether.net> On Behalf Of Ross Halliday via cisco-nsp
Sent: søndag 9. oktober 2022 22:39
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] BNG Geo-Redundancy
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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommunity.cisco.com%2Ft5%2Fservice-providers-knowledge-base%2Fbng-geo-redundancy-for-l2-connected-ipoe-subscriber-sessions%2Fta-p%2F3686641&data=05%7C01%7C%7C14e27bbc280c41820e7708daaa366a5a%7C22ca942f06c24f3894070e447dedbb67%7C0%7C0%7C638009447954055350%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=V7YTcPRQrrM0FIS1WbbUxZjBmiZr5S3GICtg1bNh1Go%3D&reserved=0
[2] https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cisco.com%2Fc%2Fen%2Fus%2Ftd%2Fdocs%2Frouters%2Fasr9000%2Fsoftware%2Fasr9k_r6-0%2Fbng%2Fconfiguration%2Fguide%2Fb-bng-cg60xasr9k%2Fb-bng-cg60xasr9k_chapter_01110.html&data=05%7C01%7C%7C14e27bbc280c41820e7708daaa366a5a%7C22ca942f06c24f3894070e447dedbb67%7C0%7C0%7C638009447954055350%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=BFptOR5ma5GRhKutDp8nLA6ByqHE9vXUzRUf5MYDo74%3D&reserved=0
[3] https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommunity.cisco.com%2Ft5%2Fservice-providers-knowledge-base%2Fasr9000-xr-using-and-understanding-bng-geo-redundancy%2Fta-p%2F3158636&data=05%7C01%7C%7C14e27bbc280c41820e7708daaa366a5a%7C22ca942f06c24f3894070e447dedbb67%7C0%7C0%7C638009447954055350%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=MRwBseWRFr6IuWQ%2Boj9mEYhdmA0ToDTKLg%2FNWPBNxHQ%3D&reserved=0
_______________________________________________
cisco-nsp mailing list cisco-nsp at puck.nether.net
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-nsp&data=05%7C01%7C%7C14e27bbc280c41820e7708daaa366a5a%7C22ca942f06c24f3894070e447dedbb67%7C0%7C0%7C638009447954055350%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=DCaHmLWTRkNd6FOePgP8Ehq1d0T4irMm%2BoB9Szs4y3w%3D&reserved=0
archive at https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpuck.nether.net%2Fpipermail%2Fcisco-nsp%2F&data=05%7C01%7C%7C14e27bbc280c41820e7708daaa366a5a%7C22ca942f06c24f3894070e447dedbb67%7C0%7C0%7C638009447954055350%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ohpq2Y4M02Sdq%2Bv8tq%2BaaKvbnxzHAQvriSGKHrRxyGc%3D&reserved=0
More information about the cisco-nsp
mailing list