]> git.puffer.fish Git - matthieu/frr.git/commit
bgpd: Ensure BGP does not stop monitoring nexthops
authorDonald Sharp <sharpd@nvidia.com>
Mon, 6 Nov 2023 18:02:01 +0000 (13:02 -0500)
committerDonald Sharp <sharpd@nvidia.com>
Wed, 6 Dec 2023 16:42:01 +0000 (11:42 -0500)
commit40dd3946a664695396b471a4dc4e03272a0e7739
tree07f271efc19d24e999d9fa3a4009ea38bea9dcba
parentcad5ee56be313c3d5b96082a5133435839af6cca
bgpd: Ensure BGP does not stop monitoring nexthops

In some cases BGP can be monitoring the same prefix
in both the nexthop and import check tables.  If this
is the case, when unregistering one bnc from one table
make sure we are not still registered in the other

Example of the problem:

r1(config-router)# address-family ipv4 uni
r1(config-router-af)# no network 192.168.100.41/32
r1(config-router-af)# exit

r1# show bgp import-check-table
Current BGP import check cache:
r1# show bgp nexthop
Current BGP nexthop cache:
 192.168.100.41 valid [IGP metric 0], #paths 1, peer 192.168.100.41
  if r1-eth0
  Last update: Wed Dec  6 11:01:40 2023

BGP now believes it is only watching 192.168.100.41 in the nexthop
cache, but zebra doesn't have anything:

r1# show ip import-check
VRF default:
 Resolve via default: on
r1# show ip nht
VRF default:
 Resolve via default: on

So if anything happens to the route that is being matched for
192.168.100.41 bgp is no longer going to be notified about this.

The source of this problem is that zebra has dropped the two different
tables into 1 table, while bgp has 2 tables to track this.  The solution
to this problem (other than the rewrite that is being done ) is to have
BGP have a bit of smarts about looking in both tables for the bnc and
if found in both don't send the delete of the prefix tracking to zebra.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
bgpd/bgp_nexthop.h
bgpd/bgp_nht.c