zebra: System routes sometimes can not be properly selected

System Routes if received over the netlink bus in a
specific pattern that causes an update operation for that
route in zebra can leave the dest->selected_fib pointer NULL,
while having the ZEBRA_FLAG_SELECTED flag set. Specifically
one way to achieve this is to do this:

`ip addr del 4.5.6.7/32 dev swp1 ; ip addr add 4.5.6.7/32 dev swp1 metric 9`

Why is this a big deal?
Because nexthop tracking is looking at ZEBRA_FLAG_SELECTED to
know if we can use a route, while nexthop active checking uses
dest->selected_fib.

So imagine we have bgp registering a nexthop. nexthop tracking in
the above case will be able to choose the 4.5.6.7/32 route
if that is what the nexthop is, due to the ZEBRA_FLAG_SELECTED being
properly set. BGP then allows the peers connection to come up and we
install routes with a 4.5.6.7 nexthop. The rib processing for route
installation will then look at the 4.5.6.7 route see no
dest->selected_fib and then start walking up the tree to resolve
the route. In our case we could easily hit the default route and be
unable to resolve the route. Which then becomes inactive in the
rib so we never attempt to install it.

This commit fixes this problem because when the rib_process decides
that we need to update the fib( ie replace old w/ new ), the
replacement with new was not setting the `dest->selected_fib` pointer
to the new route_entry, when the route was a system route.

Ticket: CM-24203
Signed-off-by: Donald Sharp <sharpd@cumulusnetworkscom>

1 files changed, 1 insertions, 1 deletions

diff --git a/zebra/zebra_rib.c b/zebra/zebra_rib.c
index 2014aa3be..5fa51ada4 100644
--- a/zebra/zebra_rib.c
+++ b/zebra/zebra_rib.c
@@ -1405,7 +1405,7 @@ static void rib_process_update_fib(struct zebra_vrf *zvrf,
 				 * from ourselves we don't
 				 * over write this pointer
 				 */
-				dest->selected_fib = NULL;
+				dest->selected_fib = new;
 			}
 			/* If install succeeded or system route, cleanup flags
 			 * for prior route. */