I've typically seen this happen when there is a covering route causing the next-hop tracking to not work correctly. It happens quite a bit when there is a local null0 route covering the NH. You can use a route-map to specify only OSPF routes are used under the specific AFI.
You can also look at the state of a next-hop using "show bgp nexthops" Thanks, Phil On 10/13/20, 2:58 PM, "cisco-nsp on behalf of Drew Weaver" <[email protected] on behalf of [email protected]> wrote: Hello, For clarity's sake: Each of the 5 edge/peering routers have the full routing table installed and they are totally unaware of one another as far as BGP is concerned Downstream from there, the view from any of the four core routers is this: Neighbor V MsgRcvd MsgSent InQ OutQ Up/Down State PfxRcd PfxAcc 192.168.222.25 4 45082982 171835 0 0 6d05h Estab 812608 812608 192.168.222.26 4 56573846 173130 0 0 18d04h Estab 812623 812623 192.168.222.27 4 45082982 171835 0 0 6d02h Estab 812609 812609 192.168.222.28 4 56573846 173130 0 0 118d04h Estab 812625 812625 192.168.222.29 4 45082982 171835 0 0 7d02h Estab 812607 812607 The issue I was running into and asking about was regarding the delay between when OSPF closes (next-hop is no longer reachable) and when the next-hop that is no longer reachable stops being used as a route to a destination. Not only is the next hop unreachable once OSPF closes, there isn't even a route to that next hop anymore. So the reason I asked the question was to validate my thinking that if there is no longer a route to the next-hop than the router shouldn't be waiting for the hold timer to expire prior to selecting a different path. But I still need to validate a few things. Thanks, -Drew -----Original Message----- From: [email protected] <[email protected]> Sent: Monday, October 12, 2020 10:40 AM To: Drew Weaver <[email protected]>; [email protected] Subject: RE: [c-nsp] Sanity check OSPF/BGP > Drew Weaver > Sent: Thursday, October 8, 2020 2:01 PM What I expect to happen is: > > The route to the peering edge router's loopback > interface is withdrawn when OSPF/OSPFv3 closes. > The core router will close the BGP session when the > route to the dead > peering edge router is withdrawn and will begin using one of the 5 > other copies of the same route that it has. > Number of things come to mind since you provided no details regarding the setup Case A) If all 5 peering points are not advertising best-external prefixes -then there's only a single path for each of the 700K prefixes in the entire AS via one of the 5 peering points. -in case one peering point fails all prefixes it offered a best path for will be withdrawn from all BGP speakers in the AS at OSPF convergence speeds, but then the remaining 4 peering points needs to realize they now have the overall best path for a given prefix and start advertising it to all BGP speakers in the AS -tedious process that converges at "BGP-speed". Case B) If all 5 peering points are advertising best-external prefixes and all BGP speakers in the AS already have all 5 paths available in RIB, but none of the BGP speakers has hierarchical FIB so there's a direct correlation between a prefix and it's NH, -in case one peering point fails all prefixes it offered a best path for will be withdrawn from all BGP speakers in the AS at OSPF convergence speeds, but now each BGP speaker will need to painstakingly update its FIB on a prefix by prefix bases for each of the each of the 700K prefixes. Case C) If all 5 peering points are advertising best-external prefixes and all BGP speakers in the AS already have all 5 paths available in RIB, and all BGP speakers not even have hierarchical FIBs but also PIC-CORE enabled where a backup path for each prefix is programmed in FIB, -in case one peering point fails all prefixes it offered a best path for will be withdrawn from all BGP speakers in the AS at OSPF convergence speeds and each BGP speaker will then just need to change 5 HN pointers to point to remaining 4 peering points in FIB. Note, The above assumes full mesh between all BGP speakers or otherwise assumes the RR infrastructure emulates full-mesh with regards to prefix distribution to all BGP speakers in the AS via one of the several available mechanisms. Adam _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
