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>

0 files changed, 0 insertions, 0 deletions