[c-nsp] Sanity check OSPF/BGP

[Drew Weaver]

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 <dudepron at gmail.com>
Sent: Thursday, October 8, 2020 11:52 AM
To: Aaron <aaron1 at gvtc.com>
Cc: Drew Weaver <drew.weaver at thenap.com>; cisco-nsp <cisco-nsp at puck.nether.net>
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 <aaron1 at gvtc.com<mailto:aaron1 at gvtc.com>> 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 <cisco-nsp-bounces at puck.nether.net<mailto:cisco-nsp-bounces at puck.nether.net>> On Behalf Of Drew Weaver
Sent: Thursday, October 8, 2020 8:01 AM
To: 'cisco-nsp at puck.nether.net<mailto:cisco-nsp at puck.nether.net>' <cisco-nsp at puck.nether.net<mailto:cisco-nsp at puck.nether.net>>
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  cisco-nsp at puck.nether.net<mailto:cisco-nsp at puck.nether.net>
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  cisco-nsp at puck.nether.net<mailto:cisco-nsp at puck.nether.net>
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=>