bgpd: export redistributed routes with label allocation per nexthop

The label allocation per nexthop mode requires to use a nexthop
tracking context. For redistributed routes, a nexthop tracking
context is created, and the resolution helps to know the real
nexthop ip address used. The below configuration example has
been used:

 > vrf vrf1
 >  ip route 172.31.0.14/32 192.0.2.14
 >  ip route 172.31.0.15/32 192.0.2.12
 >  ip route 172.31.0.30/32 192.0.2.30
 > exit
 > router bgp 65500 vrf vrf1
 >  address-family ipv4 unicast
 >   redistribute static
 >   label vpn export per-nexthop
 > [..]

The static routes are correctly imported in the BGP IPv4 RIB.
Contrary to label allocation per vrf mode, some nexthop tracking
are created/or reused:

 > # show bgp vrf vrf1 nexthop
 > 192.0.2.12 valid [IGP metric 0], #paths 3, peer 192.0.2.12
 >  if r1-eth1
 >  Last update: Fri Jan 13 15:49:42 2023
 > 192.0.2.14 valid [IGP metric 0], #paths 1
 >  if r1-eth1
 >  Last update: Fri Jan 13 15:49:42 2023
 > 192.0.2.30 valid [IGP metric 0], #paths 1
 >  if r1-eth1
 >  Last update: Fri Jan 13 15:49:51 2023
 > [..]

This results in having a BGP VPN route for each of the static
routes:

 > # show bgp ipv4 vpn
 > [..]
 > Route Distinguisher: 444:1
 >  *> 172.31.0.14/32   192.0.2.14@9<            0         32768 ?
 >  *> 172.31.0.15/32   192.0.2.12@9<            0         32768 ?
 >  *> 172.31.0.30/32   192.0.2.30@9<            0         32768 ?
 > [..]

Without that patch, only the redistributed routes that rely on a
pre-existing nexthop tracking context could be exported.

Also, a command in the code about redistributed routes is modified
accordingly, to explain that redistribute routes may be submitted
to nexthop tracking in the case label allocation per next-hop is
used.

note:
VNC routes have been removed from the redistribution,
because of a test failure in the bgp_l3vpn_to_bgp_direct test.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

diff --git a/bgpd/bgp_mplsvpn.c b/bgpd/bgp_mplsvpn.c
index 951dbd1efc3d19ed1bee862c0c7e3c6f0886629a..9e75261a5cc7d6b2275a4a6c876096a49faa5ae5 100644 (file)
--- a/bgpd/bgp_mplsvpn.c
+++ b/bgpd/bgp_mplsvpn.c
@@ -1116,12 +1116,14 @@ leak_update(struct bgp *to_bgp, struct bgp_dest *bn,
 
        /*
         * 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.
+        * nexthop tracking, unless MPLS allocation per nexthop is
+        * performed. In the default case nexthop tracking does not apply,
+        * 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_bpi may at most be a second-generation route
         * (only one hop back to ultimate parent for vrf-vpn-vrf scheme).

diff --git a/bgpd/bgp_nht.c b/bgpd/bgp_nht.c
index 39aff8d500d9b070ce653c1a8b0e5ffb80ccd047..bda163d7a50943d9260973a18fb86868437d6ed2 100644 (file)
--- a/bgpd/bgp_nht.c
+++ b/bgpd/bgp_nht.c
@@ -1137,10 +1137,21 @@ void evaluate_paths(struct bgp_nexthop_cache *bnc)
        }
 
        LIST_FOREACH (path, &(bnc->paths), nh_thread) {
-               if (!(path->type == ZEBRA_ROUTE_BGP
-                     && ((path->sub_type == BGP_ROUTE_NORMAL)
-                         || (path->sub_type == BGP_ROUTE_STATIC)
-                         || (path->sub_type == BGP_ROUTE_IMPORTED))))
+               if (path->type == ZEBRA_ROUTE_BGP &&
+                   (path->sub_type == BGP_ROUTE_NORMAL ||
+                    path->sub_type == BGP_ROUTE_STATIC ||
+                    path->sub_type == BGP_ROUTE_IMPORTED))
+                       /* evaluate the path */
+                       ;
+               else if (path->sub_type == BGP_ROUTE_REDISTRIBUTE) {
+                       /* evaluate the path for redistributed routes
+                        * except those from VNC
+                        */
+                       if ((path->type == ZEBRA_ROUTE_VNC) ||
+                           (path->type == ZEBRA_ROUTE_VNC_DIRECT))
+                               continue;
+               } else
+                       /* don't evaluate the path */
                        continue;
 
                dest = path->net;
@@ -1242,6 +1253,16 @@ void evaluate_paths(struct bgp_nexthop_cache *bnc)
                         */
                        vpn_leak_from_vrf_update(bgp_get_default(), bgp_path,
                                                 path);
+               else if (path->sub_type == BGP_ROUTE_REDISTRIBUTE &&
+                        safi == SAFI_UNICAST &&
+                        (bgp_path->inst_type == BGP_INSTANCE_TYPE_VRF ||
+                         bgp_path->inst_type == BGP_INSTANCE_TYPE_DEFAULT))
+                       /* redistribute routes are always valid
+                        * if nht is called with redistribute routes, the vpn
+                        * exportation needs to be triggered
+                        */
+                       vpn_leak_from_vrf_update(bgp_get_default(), bgp_path,
+                                                path);
                else if (path_valid != bnc_is_valid_nexthop) {
                        if (path_valid) {
                                /* No longer valid, clear flag; also for EVPN