Previously, when we had this issue it was determined that it was because there was still a route to the BGP neighbor in the routing table (because the neighbor IP was part of our IP announcements and it would wait until the hold time to expire) but we got around that particular issue by using RFC1918 IPs for the neighbors and BGP Next hop address tracking took care of the rest (made it much faster, like 1-2 seconds) but it seems like in our current architecture with the new core it’s operating differently.
It’s almost like the new core routers are continuing to be seen as a path to this neighbor by the old core routers and vice versa even though OSPF went down on both of them at the same exact time. It’s a mystery for sure. From: Aaron <[email protected]> Sent: Thursday, October 8, 2020 11:52 AM To: Aaron <[email protected]> Cc: Drew Weaver <[email protected]>; cisco-nsp <[email protected]> Subject: Re: [c-nsp] Sanity check OSPF/BGP You didn't specify the platform or code version it is running. Would help with platform specifics On Thu, Oct 8, 2020 at 11:47 AM <[email protected]<mailto:[email protected]>> wrote: I wonder if bgp neighboring isn't timing out quickly enough for your satisfaction and holding routes for a few minutes -----Original Message----- From: cisco-nsp <[email protected]<mailto:[email protected]>> On Behalf Of Drew Weaver Sent: Thursday, October 8, 2020 8:01 AM To: '[email protected]<mailto:[email protected]>' <[email protected]<mailto:[email protected]>> Subject: [c-nsp] Sanity check OSPF/BGP Hello, I have two sets of core routers due to a transition period from one set to the other. I have noticed that when there is a connectivity disruption between the two sets of core routers and one upstream peering/edge router: Oct 7 12:01:14 EDT: %OSPF-5-ADJCHG: Process 1, Nbr <removed> on TenGigabitEthernet2/1 from FULL to DOWN, Neighbor Down: BFD node down <Two+ minutes of null routing traffic for no reason> Oct 7 12:03:29 EDT: %BGP-5-ADJCHANGE: neighbor <removed> Down BGP Notification sent 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. Things I have implemented to avoid this: The peering edge router and the core routers peer with IP addresses that are only learnable via OSPF and aren't available in any other protocol. [It's not part of our IP space] I guess I just need a sanity check regarding whether my assumption that it shouldn't be null routing traffic for 2+ minutes if one of our peering edge routers gets hit by a meteor is correct since we have 5 peering edge routers. Thanks in advance friends, -Drew _______________________________________________ cisco-nsp mailing list [email protected]<mailto:[email protected]> https://puck.nether.net/mailman/listinfo/cisco-nsp<https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_cisco-2Dnsp&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw&m=tarlS9_N9KOgbzThRUtBamnS96bi7lxKn6B4IhBwQGE&s=dEDvP0xBa0A44BIbRgqX1ZXJIWYtAST8C81l0z6ami0&e=> archive at http://puck.nether.net/pipermail/cisco-nsp/<https://urldefense.proofpoint.com/v2/url?u=http-3A__puck.nether.net_pipermail_cisco-2Dnsp_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw&m=tarlS9_N9KOgbzThRUtBamnS96bi7lxKn6B4IhBwQGE&s=xxFbEjuX0EZUFK8EZRtPJdxtXaBxHgMkrklDwV0cY9A&e=> _______________________________________________ cisco-nsp mailing list [email protected]<mailto:[email protected]> https://puck.nether.net/mailman/listinfo/cisco-nsp<https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_cisco-2Dnsp&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw&m=tarlS9_N9KOgbzThRUtBamnS96bi7lxKn6B4IhBwQGE&s=dEDvP0xBa0A44BIbRgqX1ZXJIWYtAST8C81l0z6ami0&e=> archive at http://puck.nether.net/pipermail/cisco-nsp/<https://urldefense.proofpoint.com/v2/url?u=http-3A__puck.nether.net_pipermail_cisco-2Dnsp_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw&m=tarlS9_N9KOgbzThRUtBamnS96bi7lxKn6B4IhBwQGE&s=xxFbEjuX0EZUFK8EZRtPJdxtXaBxHgMkrklDwV0cY9A&e=> _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
