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>

2 files changed, 33 insertions, 10 deletions

diff --git a/bgpd/bgp_mplsvpn.c b/bgpd/bgp_mplsvpn.c
index dfa275036..a409dcefd 100644
--- 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 f3d9bd1a8..a91711137 100644
--- 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