Hey Rafał, *> To exercise this BGP NG may not be ASBR loopback as it stays in IGP as long as ASBR is UP.*
Completely not true if you properly configure your ASBRs :). Imagine next hop self is using loopback 100 and I redistribute it to IGP. Further observe that interface in a shutdown state is not advertised into IGP. So all what is needed is to run BFD session to peer which in turn will remove the connected subnets from global RIB and therefor trigger a shutdown of your loopback 100. Very simple and effective :) And if your peer does not like BFD you can monitor it's interfaces reachability with help of a lot of different protocols from just your ASBR side. You can set different reaction timers to UP vs DOWN events, you can configure thresholds if you have a lot of peers etc ... Simple example: /* Tracking your peer’s subnets */ track 1 ip route [peer1_net_address] [peer1_subnet_mask] reachability track 2 ip route [peer2_net_address] [peer2_subnet_mask] reachability … /* Triggering action only when both go down */ track 100 list boolean and object 1 object 2 ! /* Action DOWN and removal from IGP */ event manager applet LO100-DOWN event track 100 state down action 1 cli command "conf t" action 2 cli command "interface loopback100" action 2 cli command "shut" action 3 cli command "end" action 4 syslog priority errors msg "eBGP peers unreachable; shutting down lo100" ! ! /* Action UP and advertising it in IGP */ event manager applet LO100-UP event track 100 state up action 1 cli command "conf t" action 2 cli command "interface loopback100" action 2 cli command "no shut" action 3 cli command "end" action 4 syslog priority errors msg "eBGP peers reachable; activating lo100" ! *> In draft we track state and EoR of set of sessions. So if session is ESTABLISHED but * *> still in initial learning, ANH is not in IGP. This is to prevent:* When BGP sessions come up and are still in learning mode BGP is (or well should be) in "READ_ONLY" mode and should not advertise anything to any peer till EoR is received or timeout happens. Perhaps this is implementation thing, but I hope all good BGP implementations do support BGP READ_ONLY mode. Using lack of Abstract Next Hop to suppress advertised BGP paths somewhere in the network is a pretty bad idea. Note that it also does not work if your ANH is AS_WIDE and is common across more then one ASBR. - - Bottom line is that solution to all what you are describing has been shipping commercially in some implementations for years without any 20 page IETF draft. Moreover your document is really not even describing a BCP, but how one vendor solved it - rather in a bit suboptimal way (EoR point) or with much less control (BGP based ANH removal). IMO it is perfect text to become such vendor’s white paper, but not really a fit to be an IETF document regardless if it would be of Informational or BCP character. Cheers, R. >
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
