[c-nsp] Sanity check OSPF/BGP

[aaron1 at gvtc.com]

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> On Behalf Of Drew Weaver
Sent: Thursday, October 8, 2020 8:01 AM
To: 'cisco-nsp at puck.nether.net' <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
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/