zebra: send ipv4 singlepath delete messages to kernel without nexthop

Problem reported was stale routes left in the kernel in certain cases
when overlapping static routes were used and links were bounced.  The
problem was determined to be an issue where the nexthop was changed
due to recursion as the link is going down, and the next-hop at the
time of deletion doesn't match what was previously installed by the
kernel.  This caused the kernel to reject the deletion and the route
stuck around.

It was pointed out that the kernel doesn't actually require a next-hop
value on the netlink deletion call.  In this fix, we are eliminating
the nexthop for RTM_DELROUTE messages to the kernel in the ipv4 singlepath
case.  This approach could also be valid for other cases but the fix
as is resolved the reported failure case.  More testing should be
performed before similar changes are made for other cases.

Testing included manual testing for the failure condition as well as
complete bgp-smoke and ospf-smoke tests with no new failures.

Ticket: CM-13328
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: CCR-5562

diff --git a/zebra/rt_netlink.c b/zebra/rt_netlink.c
index 01922e1ad59032fa145e7c4f3b2fc72eea4a9045..5d1ef2648753536ba3f5dedbb5e48ca30a3173ca 100644 (file)
--- a/zebra/rt_netlink.c
+++ b/zebra/rt_netlink.c
@@ -777,8 +777,10 @@ _netlink_route_build_singlepath(
   if (nexthop->type == NEXTHOP_TYPE_IPV4
       || nexthop->type == NEXTHOP_TYPE_IPV4_IFINDEX)
     {
-      _netlink_route_nl_add_gateway_info (rtmsg->rtm_family, AF_INET, nlmsg,
-                                          req_size, bytelen, nexthop);
+      /* Send deletes to the kernel without specifying the next-hop */
+      if (cmd != RTM_DELROUTE)
+        _netlink_route_nl_add_gateway_info (rtmsg->rtm_family, AF_INET, nlmsg,
+                                            req_size, bytelen, nexthop);
 
       if (cmd == RTM_NEWROUTE)
        {