summaryrefslogtreecommitdiff
path: root/tests/topotests/ospf_basic_functionality/test_ospf_ecmp_lan.py
diff options
context:
space:
mode:
authorDonald Sharp <sharpd@nvidia.com>2022-04-18 14:06:26 -0400
committerDonald Sharp <sharpd@nvidia.com>2022-04-18 14:15:23 -0400
commit7f2e9cce7f22d82a16487dc8e1946ba07fbb6624 (patch)
tree80d3bb245127b5b62112bb90ffe5d2be8ae7f5ac /tests/topotests/ospf_basic_functionality/test_ospf_ecmp_lan.py
parent1258cfcd8c1ac619c9ea61908d608685625bf1bd (diff)
bgpd: Allow type 5 routes to be handled better when link is flapping
In some stress testing, we are seeing type-5 evpn routes being left in a rejected state in zebra. Sequence of events as I am seeing it: a) Interface comes up that type5 routes nexthop depends on b) zebra processes creates the connected and lets bgp know via nht c) bgp installs the route to zebra d) zebra processes and sends install to kernel e) before route is installed, the interface the nexthop points at flaps f) the route install is rejected, notify zebra g) the interface comes up h) zebra gets the notification about the route install rejection i) zebra processes the down/up and turns it into a single up event j) BGP never reinstalls the type 5 route This up event does not translate into a nexthop tracking event when the events happen quickly enough and/or zebra is extremelyh busy and bgp would never see that the nexthops changed even very quickly. This is the same thing that was going on with https://github.com/FRRouting/frr/pull/7724 in PBR. To fix this let's notice the interface up/down events for v4 in bgp now as well. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Diffstat (limited to 'tests/topotests/ospf_basic_functionality/test_ospf_ecmp_lan.py')
0 files changed, 0 insertions, 0 deletions