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 <[email protected]> On Behalf Of Ross Halliday
via cisco-nsp
Sent: søndag 9. oktober 2022 22:39
To: [email protected]
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 [email protected]
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
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
