bgpd: don't nexthop-track twice-leaked routes that came from zebra

Issue 2381: interface based routes not marked "up" when they originate
in zebra, redistributed to bgp vrf, then imported to vpn and then
imported by another vrf.

Routes that are redistributed into BGP from zebra should not get
nexthop tracking (the assumption is that the originating protocol
is responsible to export or withdraw the route according to its own
notion of nexthop status).

The vpn-vrf route-leaking code checks the source route sub_type to
decide whether to use nexthop tracking on the resulting leaked route.

A route that is redistributed from zebra into bgp will have
sub_type==BGP_ROUTE_REDISTRIBUTE. If it is leaked to the vpn RIB,
the resulting vpn RIB route will have sub_type==BGP_ROUTE_IMPORTED.
If THAT vpn route is leaked to another vrf, the original code will
examine only the leak-source route sub_type and, since it is
not BGP_ROUTE_REDISTRIBUTE, will wrongly try to use nexthop tracking
on the new route in the final vrf.

This change modifies the leak function to track back up the
parent links to the ultimate parent of the leak source route
and look at that route's sub_type instead.

Signed-off-by: G. Paul Ziemba <paulz@labn.net>

diff --git a/bgpd/bgp_mplsvpn.c b/bgpd/bgp_mplsvpn.c
index 64d12cf6078540c26bbc42938d60a5bde3a10d6b..710807156af5148ca34c7852cc059cf8d9d5e25b 100644 (file)
--- a/bgpd/bgp_mplsvpn.c
+++ b/bgpd/bgp_mplsvpn.c
@@ -466,6 +466,7 @@ leak_update(
 {
        struct prefix *p = &bn->p;
        struct bgp_info *bi;
+       struct bgp_info *bi_ultimate;
        struct bgp_info *new;
        char buf_prefix[PREFIX_STRLEN];
 
@@ -476,6 +477,26 @@ leak_update(
                        source_bi->type, source_bi->sub_type);
        }
 
+       /*
+        * Routes that are redistributed into BGP from zebra do not get
+        * nexthop tracking. However, if those routes are subsequently
+        * imported to other RIBs within BGP, the leaked routes do not
+        * carry the original BGP_ROUTE_REDISTRIBUTE sub_type. Therefore,
+        * in order to determine if the route we are currently leaking
+        * should have nexthop tracking, we must find the ultimate
+        * parent so we can check its sub_type.
+        *
+        * As of now, source_bi may at most be a second-generation route
+        * (only one hop back to ultimate parent for vrf-vpn-vrf scheme).
+        * Using a loop here supports more complex intra-bgp import-export
+        * schemes that could be implemented in the future.
+        * 
+        */
+       for (bi_ultimate = source_bi;
+               bi_ultimate->extra && bi_ultimate->extra->parent;
+               bi_ultimate = bi_ultimate->extra->parent)
+                       ;
+
        /*
         * match parent
         */
@@ -528,7 +549,7 @@ leak_update(
                        bgp_nexthop = bi->extra->bgp_orig;
 
                /* No nexthop tracking for redistributed routes */
-               if (source_bi->sub_type == BGP_ROUTE_REDISTRIBUTE)
+               if (bi_ultimate->sub_type == BGP_ROUTE_REDISTRIBUTE)
                        nh_valid = 1;
                else
                        /*
@@ -590,7 +611,7 @@ leak_update(
         * their originating protocols will do the tracking and
         * withdraw those routes if the nexthops become unreachable
         */
-       if (source_bi->sub_type == BGP_ROUTE_REDISTRIBUTE)
+       if (bi_ultimate->sub_type == BGP_ROUTE_REDISTRIBUTE)
                nh_valid = 1;
        else
                /*