[c-nsp] BNG Geo-Redundancy

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