The nexthop reveived for a prefix in a BGP update is cached in the

nexthop cache in BGP and registered for resolution with the nexthop
tracking (NHT) component. If the prefix were to be received from the
same peer with a different nexthop, the prior nexthop needs to be
processed for cleanup and unregistered and removed from the cache, if
appropriate. That is handled with this patch.

Signed-off-by: Vivek Venkataraman <vivek@cumulusnetworks.com>
Reviewed-by:   Dinesh G Dutt <ddutt@cumulusnetworks.com>
Reviewed-by:   Donald Sharp <sharpd@cumulusnetworks.com>

diff --git a/bgpd/bgp_nht.c b/bgpd/bgp_nht.c
index 397b379fafa307171880234b322f29fd2ddc8eb6..ab4effcb1e0c26f70070081fbdf9b9efb8d3b361 100644 (file)
--- a/bgpd/bgp_nht.c
+++ b/bgpd/bgp_nht.c
@@ -206,8 +206,14 @@ bgp_find_or_add_nexthop (struct bgp *bgp, afi_t afi, struct bgp_info *ri,
   if (!CHECK_FLAG(bnc->flags, BGP_NEXTHOP_REGISTERED))
     register_zebra_rnh(bnc, is_bgp_static_route);
 
-  if (ri)
+  if (ri && ri->nexthop != bnc)
     {
+      /* Unlink from existing nexthop cache, if any. This will also free
+       * the nexthop cache entry, if appropriate.
+       */
+      bgp_unlink_nexthop (ri);
+
+      /* Link to new nexthop cache. */
       path_nh_map(ri, bnc, 1);
 
       if (CHECK_FLAG(bnc->flags, BGP_NEXTHOP_VALID) && bnc->metric)