zebra: relax mpls entries installation with labeled unicast entries

Until now, when a FEC entry is added in zebra, driven by the
reception of a BGP labeled unicast update, an LSP entry is
created. That LSP entry is resolved by using the route entry
which is also installed by BGP labeled unicast.

This route entry is not available when we face with i-bgp
peering session. I-BGP labeled sessions are used to establish
IP connectivity across separate IGPs.

The below dumps illustrate a 3 IGP topology. An attempt to create
connectivity between the north and the south machines is done.

The 3 separate IGPs are configured in Segment routing:
- north-east
- east-west
- west-south

We create BGP peerings between each endpoint of each IGP:
- iBGP between (north) and (east)
- iBGP between (east) and (west)
- iBGP between (west) and (south)

Before that patch, the FEC entries could not be resolved on the
east machine:

Before:
east-vm# show mpls fec
192.0.2.1/32
  Label: 18
  Client list: bgp(fd 48)
192.0.2.5/32
  Label: 17
  Client list: bgp(fd 48)
192.0.2.7/32
  Label: 19
  Client list: bgp(fd 48)

east-vm# show mpls table
 Inbound Label  Type        Nexthop      Outbound Label
 --------------------------------------------------------
 1011           SR (OSPF)   192.168.2.2  1011
 1022           SR (OSPF)   192.168.2.2  implicit-null
 11044          SR (IS-IS)  192.168.3.4  implicit-null
 11055          SR (IS-IS)  192.168.3.4  11055
 30000          SR (OSPF)   192.168.2.2  implicit-null
 30001          SR (OSPF)   192.168.2.2  implicit-null
 36000          SR (IS-IS)  192.168.3.4  implicit-null

east-vm# show ip route
[..]
B   192.0.2.1/32 [200/0] via 192.0.2.1 inactive, label implicit-null, weight 1, 00:17:45
O>* 192.0.2.1/32 [110/20] via 192.168.2.2, r3-eth0, label 1011, weight 1, 00:17:47
O>* 192.0.2.2/32 [110/10] via 192.168.2.2, r3-eth0, label implicit-null, weight 1, 00:17:47
O   192.0.2.3/32 [110/0] is directly connected, lo, weight 1, 00:17:57
C>* 192.0.2.3/32 is directly connected, lo, 00:18:03
I>* 192.0.2.4/32 [115/20] via 192.168.3.4, r3-eth1, label implicit-null, weight 1, 00:17:59
B   192.0.2.5/32 [200/0] via 192.0.2.5 inactive, label implicit-null, weight 1, 00:17:56
I>* 192.0.2.5/32 [115/30] via 192.168.3.4, r3-eth1, label 11055, weight 1, 00:17:58
B>  192.0.2.7/32 [200/0] via 192.0.2.5 (recursive), label 19, weight 1, 00:17:45
  *                        via 192.168.3.4, r3-eth1, label 11055/19, weight 1, 00:17:45
[..]

After command "mpls fec nexthop-resolution" was applied, the FEC
entries will resolve over any non BGP route that has a labeled path
selected.

east-vm# show mpls table
 Inbound Label  Type        Nexthop      Outbound Label
 --------------------------------------------------------
 17             SR (IS-IS)  192.168.3.4  11055
 18             SR (OSPF)   192.168.2.2  1011
 19             BGP         192.168.3.4  11055/19
 1011           SR (OSPF)   192.168.2.2  1011
 1022           SR (OSPF)   192.168.2.2  implicit-null
 11044          SR (IS-IS)  192.168.3.4  implicit-null
 11055          SR (IS-IS)  192.168.3.4  11055
 30000          SR (OSPF)   192.168.2.2  implicit-null
 30001          SR (OSPF)   192.168.2.2  implicit-null
 36000          SR (IS-IS)  192.168.3.4  implicit-null

Co-developed-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
Signed-off-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This commit is contained in:
Philippe Guibert 2022-11-07 18:29:07 +01:00 committed by Dmytro Shytyi
parent 110cb369a3
commit 9f88ed98a4

View File

@ -651,8 +651,10 @@ struct route_entry *rib_lookup_ipv4(struct prefix_ipv4 *p, vrf_id_t vrf_id)
int zebra_rib_labeled_unicast(struct route_entry *re)
{
struct nexthop *nexthop = NULL;
struct zebra_vrf *zvrf = vrf_info_lookup(re->vrf_id);
if (re->type != ZEBRA_ROUTE_BGP)
if ((re->type != ZEBRA_ROUTE_BGP) &&
!zvrf->zebra_mpls_fec_nexthop_resolution)
return 0;
for (ALL_NEXTHOPS(re->nhe->nhg, nexthop))