Configuring BGP SR

Module Introduction

Before you start the hands-on part of this module, you should load the appropriate configuration and verify that the testbed is up and running by executing the corresponding robot file:

student@tour:~/trainings_resources/robot$ robot mpls_sr_bgp/mpls_sr_bgp_setup.robot

In order to get a better understanding, the lab setup is shown in the picture below.

mpls sr bgp lab
Figure 1. MPLS Segment Routing Lab Setup

Configuring Prefix Segments

When using BGP to distribute MPLS label bindings, labels must be encoded along with the associated prefixes. The original BGP specification only supports IPv4 unicast prefixes with IPv4 next hops, which are carried in the Network Layer Reachability Information (NLRI) field of standard BGP UPDATE messages.

To support labeled IPv4 prefixes, RFC 2858 introduces Multiprotocol Extensions for BGP-4, allowing BGP to carry routing information for multiple network layer protocols. These extensions define two new path attributes: Multiprotocol Reachable NLRI (MP_REACH_NLRI) and Multiprotocol Unreachable NLRI (MP_UNREACH_NLRI), which enable the advertisement and withdrawal of reachability information for various address families. BGP uses an Address Family Identifier (AFI) and a Subsequent Address Family Identifier (SAFI) to indicate the type of network layer protocol and the semantics of the NLRI. For labeled IPv4 unicast prefixes, the AFI is 1 (IPv4), and the SAFI is 4 (Labeled Unicast). Therefore, to exchange labeled IPv4 prefixes, BGP must carry MP_REACH_NLRI attributes with AFI/SAFI = 1/4.

Crucially, in BGP Labeled Unicast as defined in RFC 3107, the MPLS label is encoded as part of the NLRI, not the next-hop field. The label appears in a 3-octet field prepended to the prefix inside the NLRI, allowing each prefix to be associated with one or more labels, i.e., supporting label stacking. The next-hop field, on the other hand, contains only the IP address of the BGP next hop and is not involved in label encoding. This allows BGP to carry multiple labels in a stack, should the network require it (e.g., for VPNs or segment routing).

Exercise 1: Configuring BGP Labeled Unicast

On router R1, configure two external BGP peerings to neighbor R2 (IP address: 172.16.0.2, ASN: 64502) and R3 (IP address: 172.16.0.6, ASN: 64503) with support for IPv4 labeled-unicast address family only. The local ASN is 64501.

Click to reveal the answer
cfg> set instance default protocol bgp hostname R1
cfg> set instance default protocol bgp local-as 64501
cfg> set instance default protocol bgp address-family ipv4 labeled-unicast
cfg> set instance default protocol bgp peer-group AS64502 remote-as 64502
cfg> set instance default protocol bgp peer-group AS64502 address-family ipv4 labeled-unicast nexthop-self true
cfg> set instance default protocol bgp peer-group AS64503 remote-as 64503
cfg> set instance default protocol bgp peer-group AS64503 address-family ipv4 labeled-unicast nexthop-self true
cfg> set instance default protocol bgp peer ipv4 172.16.0.2 172.16.0.1 peer-group AS64502
cfg> set instance default protocol bgp peer ipv4 172.16.0.6 172.16.0.5 peer-group AS64503
cfg> commit

Once the configuration is activated, we can see that BGP sessions to both peers R2 and R3 are established.

cfg> show bgp peer
Instance: default
  Peer                                     Remote AS    State         Up/Down Time               PfxRcvd              PfxSent
  R2                                       64502        Established   0d:00h:02m:12s             3                    0
  R3                                       64503        Established   0d:00h:02m:10s             3                    0

We also notice that three prefixes have been received, but none have been advertised:

cfg> show bgp rib-in
Flags: & - Imported, ! - Error, N - RPKI Unknown, I - RPKI Invalid, V - RPKI Valid
Instance: default, AFI: ipv4, SAFI: labeled-unicast
  Hostname: R2, Peer IP: 172.16.0.2
  Source IP: 172.16.0.1, Total routes: 3
    Flags  Prefix                                       Next Hop                           MED         Lpref       AS Path
           192.168.0.2/32                               172.16.0.2                         0           -           64502
           192.168.0.3/32                               172.16.0.2                         0           -           64502, 64503
           192.168.0.4/32                               172.16.0.2                         0           -           64502, 64504
  Hostname: R3, Peer IP: 172.16.0.6
  Source IP: 172.16.0.5, Total routes: 3
    Flags  Prefix                                       Next Hop                           MED         Lpref       AS Path
           192.168.0.2/32                               172.16.0.6                         0           -           64503, 64502
           192.168.0.3/32                               172.16.0.6                         0           -           64503
           192.168.0.4/32                               172.16.0.6                         0           -           64503, 64504
cfg> show bgp rib-out
cfg> show bgp fib
cfg>

Although three prefixes were received, none of these were installed into the BGP routing table.

The reason for this is that we have enabled BGP-LU, but the neighbors do not use the standard labeled-unicast mechanism to advertise the prefixes. Instead, they use segment routing extension according to RFC 8669. This introduces an optional transitive attribute called the Prefix-SID TLV (type code 40) which carries the label index and the SRGB.

A prefix segment is a global segment that is associated with an IPv4 or IPv6 prefix and represented by the Prefix-SID. The corresponding index can be set at the set instance <instance> protocol bgp address-family ipv4|ipv6 labeled-unicast level.

Prefix-SIDs must be unique in the SR domain.

In addition, a segment routing global block (SRGB) must be defined. The SRGB consists of a base value and a range which defines how many prefix-SIDs the block contains.

For sake of simplicity and troubleshooting, it is strongly recommended to use identical SRGBs on all nodes within the SR domain.
Exercise 2: Enabling BGP Segment Routing

On router R1, configure a prefix node SID with index 1 and a SRGB with base value of 8000 and range of 100.

Click to reveal the answer
cfg> set instance default protocol bgp address-family ipv4 labeled-unicast srgb base 8000
cfg> set instance default protocol bgp address-family ipv4 labeled-unicast srgb range 100
cfg> set instance default protocol bgp address-family ipv4 labeled-unicast srgb index 1
cfg> commit

After configuring the SRGB and the prefix index on R1, we should be able to see IPv4 labeled-unicast routes in the routing table. Let’s check:

cfg> show bgp fib
Instance: default, AFI: ipv4, SAFI: labeled-unicast, Total routes: 3
  Prefix                                        Preference      Out Label            Next Hop
  192.168.0.2/32                                20              -                    172.16.0.2
  192.168.0.3/32                                20              -                    172.16.0.6
  192.168.0.4/32                                20              8004                 172.16.0.2
cfg> show bgp fib 192.168.0.4/32 detail
Instance: default, AFI: ipv4, SAFI: labeled-unicast, Total routes: 1
  Prefix: 192.168.0.4/32
    Next hop key: c86231da242e19b6ab1f354606647197cf8b00588652efdd
    Route source: bgp, Send path ID: 130982003, Received path ID: None
    AS path: [64502, 64504], Originator ID: None, Origin: Incomplete
    Community: None
    Extended community: None
    Large community: None
    Cluster list: None
    IGP metric: 4294967295, Local preference: None, Multi exit discriminator: 0
    Preference: 20, External route: None, Readvertised route: None
    Route up: None
    SRGB base: 8000, SRGB range: 100                       (1)
    SID index: 4                                           (2)
    Next hop: 172.16.0.2, Label: 8004                      (3)
cfg> show route ipv4 labeled-unicast prefix 192.168.0.4/32 detail
Instance: default, AFI: ipv4, SAFI: labeled-unicast
  Prefix: 192.168.0.4/32
    Source: bgp, Preference: 20
      Next Hop: 172.16.0.2
      Covering prefix: 172.16.0.2/32
      Next Hop type: mpls ingress, Next Hop action: mpls label push
      Resolved in: default-ipv4-labeled-unicast(Primary)
      Outgoing Interface: hostif-0/0/1/0, NextHop MAC: 7a:fc:da:c0:00:01
      MPLS-Label: 8004
1 Segment Routing Global Block advertised by router R4.
2 Prefix node SID advertised by router R4.
3 Label calculated using the prefix node SID and the SRGB of the nexthop router.

In addition, we now re-advertise the prefixes learned from one external neighbor to another external neighbor.

cfg> show bgp rib-out
Instance: default, AFI: ipv4, SAFI: labeled-unicast
  Peer-group: AS64502, Sent routes: 3
    Prefix                                        MED     Lpref      Origin          Next Hop                                 AS Path
    192.168.0.2/32                                0       -          Incomplete      -                                        64501, 64502
    192.168.0.3/32                                0       -          Incomplete      -                                        64501, 64503
    192.168.0.4/32                                0       -          Incomplete      -                                        64501, 64502, 64504
  Peer-group: AS64503, Sent routes: 3
    Prefix                                        MED     Lpref      Origin          Next Hop                                 AS Path
    192.168.0.2/32                                0       -          Incomplete      -                                        64501, 64502
    192.168.0.3/32                                0       -          Incomplete      -                                        64501, 64503
    192.168.0.4/32                                0       -          Incomplete      -                                        64501, 64502, 64504

However, we still do not advertise a prefix with a node SID of 1 ourselves. In IGPs like OSPF and IS-IS, interfaces are tightly linked with the routing protocol, and the loopback interface is typically used to bind the prefix SID. In contrast, BGP does not directly associate interfaces with the routing process. As a result, we need to explicitly redistribute routes, such as interface routes, into BGP.

Exercise 3: Redistributing Loopback Interface into BGP

Configure a simple policy that matches only on the IPv4 address of interface lo-0/0/0. Redistribute direct routes into BGP address-family ipv4 labeled-unicast using the previously defined policy.

Click to reveal the answer
cfg> set policy statement LOOPBACK ordinal 10 match rule 1 type ipv4-prefix
cfg> set policy statement LOOPBACK ordinal 10 match rule 1 value-type discrete
cfg> set policy statement LOOPBACK ordinal 10 match rule 1 match-type exact
cfg> set policy statement LOOPBACK ordinal 10 match rule 1 value 192.168.0.1/32
cfg> set policy statement LOOPBACK ordinal 10 action rule 99 operation return-permit
cfg> set policy statement LOOPBACK ordinal 20 action rule 99 operation return-deny
cfg> set instance default protocol bgp address-family ipv4 labeled-unicast redistribute direct policy LOOPBACK
cfg> commit

After redistributing the prefix corresponding to the loopback interface into BGP, we can verify that this IPv4 prefix is advertised with the correct SRGB and index:

cfg> show bgp rib-out 192.168.0.1/32 detail
Instance: default, AFI: ipv4, SAFI: labeled-unicast
  Peer-group: AS64502, Sent routes: 1
    Prefix: 192.168.0.1/32, RD: None, Send path ID: 0, Next hop: None
      Route source: -, Received path ID: None, Path hash: 89b252a9244b13e6e18fd6d7a4372eeee816fc98115cee82
      AS path: [64501], Originator ID: None, Origin: Incomplete
      Community: None
      Extended community: None
      Large community: None
      Cluster list: None
      IGP metric: None, Local preference: None, Multi exit discriminator: 0
      Preference: None, External route: None, Readvertised route: None
      SRGB base: 8000, SRGB range: 100
      SID index: 1
      Label: 3, Last update: 0d:00h:00m:15s

Note, that the label which is encoded in the NLRI is not 8001 but 3. This is the implicit null label used to signal to the BGP neighbor that it should use penultimate hop popping. In return, BGP neighbor R2 also sent an implicit null label. For all transit packets traversing R1, this results in R1 removing label 8002 from the label stack, i.e., R1 performs PHP for R2.

cfg> show route mpls unicast
Flags: & - Imported
Instance: default, AFI: mpls, SAFI: unicast
Flags  Prefix/Label                                Source            Pref    Next Hop                                    Outgoing Interface
       8002                                        bgp               170     172.16.0.2                                  hostif-0/0/1/0
       8003                                        bgp               170     172.16.0.6                                  hostif-0/0/2/0
       8004                                        bgp               170     172.16.0.2                                  hostif-0/0/1/0
cfg> show route mpls unicast label 8002 detail
Instance: default, AFI: mpls, SAFI: unicast
  Label: 8002
    Source: bgp, Preference: 170
      Next Hop: 172.16.0.2
      Covering prefix: 172.16.0.2/32
      Next Hop type: mpls php, Next Hop action: mpls label pop - next protocol ipv4
      Resolved in: default-ipv4-labeled-unicast(Primary)
      Outgoing Interface: hostif-0/0/1/0, NextHop MAC: 7a:fc:da:c0:00:01

Module Summary

This module outlined how to configure MPLS SR using extensions of BGP.

If you have completed the exercise, you can check the results by executing

student@tour:~/trainings_resources/robot$ robot mpls_sr_bgp/mpls_sr_bgp_verify.robot