Segment Routing using BGP is quite straightforward. It uses BGP-LU with an additional attribute called BGP Prefix-SID which signals the index value.
If you aren’t familiar with BGP-LU, it is a separate address family (ipv4 labeled-unicast) which adds a label to an ipv4 advertisement in the NLRI. When a router advertises a BGP-LU route, it adds its local label so that the peer knows what label to push onto traffic that matches that route. This is very similar to LDP advertising its local label bindings for prefixes to directly connected neighbors.
Here’s a pcap of the advertisement of the prefix SID for 2.2.2.2/32. This was advertised by R2 itself, so it advertises label 3 (implicit null) for its local label binding.
As you can see above, the label advertisement is still present in the NLRI as in regular BGP-LU. BGP for SR simply adds the path attribute called BGP Prefix-SID. This means that BGP for SR is fully interoperable with regular BGP-LU. If a BGP peer does not understand the optional, transitive PA called BGP Prefix-SID, it simply ignores this and allocates a random dynamic label. The BGP Prefix-SID value is simply a “hint” to install a local label with the value of SRGB+index. However if the peer is not running SRGB, it can simply allocate a dynamic label instead.
When using BGP for SR, you give up features such as FRR because you do not have adjacency information like you do with SR for intra-area IGP.
To use SR for BGP you must define the SRGB globally. BGP will not use the IGP’s SRGB reservation. However the global SRGB can overlap with the IGP SRGB if you are also using SR with an IGP. Defining the SRGB globally is necessary for BGP to map the label index value of a received route to a local label that will be installed in the LFIB.
To advertise an SR /32 prefix SID into BGP, you simply apply a route policy to the BGP network statement that sets the label-index value in IOS-XR. In IOS-XE you add the command segment-routing mpls under BGP, and BGP will automatically associate /32 network statements with the index value found under the connected-prefix-sid-map.
SR for BGP can be a great way for an organization to achieve an end-to-end LSP with a consistent label value across multiple IGP domains, such as in a Unified MPLS design.
Lab
In this lab we’ll configure Inter-Area L3VPN Option C using segment routing. This is slightly more complex than Unified MPLS and allows us to practice this design again.
We’ll re-use the topology from the Option C article:
SP1 runs OSPF internally, and SP2 runs ISIS internally. Router R2 at both SPs is the route-reflector for both ipv4 labeled-unicast and vpnv4 unicast. We’ll imagine that SP1 and SP2 are merging and wish to combine their SR domains into one. Both SPs will use the default SRGB. SP1 indexes will be 10X and SP2 indexes will be 20X, where X is the router number.
Here are the startup configs. Only the SR-enabled IGP is configured for each SP so far.
Each SP needs to advertise the RR loopback and PE loopback. The RRs peer with each other to exchange vpnv4 routes, and the PEs must have reachability to each other for the end-to-end LSP. Each router will advertise its loopback into BGP-LU with the prefix-SID index set.
Let’s analyze this SR BGP advertisement process. We’ll use SP1_R2 specifically to look at the process in-depth.
First SP1_R2 advertises its own loopback into BGP-LU. By activiating segment-routing mpls under the ipv4 address-family, SP1_R2 will add the prefix-SID index of 102 to the BGP advertisement. The prefix-SID index is found under the segment-routing mpls connected-prefix-sid-map stanza.
SP1_R2 advertises the prefix with an implicit-null value (3). This is received at SP1_R3. SP1_R3 sees the prefix-SID index value, and because the SRGB is defined globally, the BGP process on SP1_R3 allocates label 16102. This is the same as the label it has allocated using the IGP. However, it is necessary for BGP to allocate the same label so that when SP1_R3 advertises the route to SP2_XR1, it advertises with label 16102. If the SRGB was not defined globally, the BGP process on SP1_R3 would allocate a random dynamic label in addition to the SR label that is already allocated for this prefix.
SP1_R3#show bgp ipv4 unicast 10.2.2.2/32
BGP routing table entry for 10.2.2.2/32, version 2
Paths: (1 available, best #1, table default, RIB-failure(17))
Net local label from RIB
Advertised to update-groups:
3
Refresh Epoch 1
Local
10.2.2.2 (metric 2) from 10.2.2.2 (10.2.2.2)
Origin IGP, metric 0, localpref 100, valid, internal, best
sr-labelindex 0x66
mpls labels in/out 16102/imp-null
rx pathid: 0, tx pathid: 0x0
Updated on Aug 24 2022 03:02:45 UTC
The label allocated by SP1_R3 is 16102.
SP1_R3 advertises 10.2.2.2/32 to SP2_XR1 with the label value as 16102 and the label index value as 102. The label value and label index value are completely separate. The label value is the label the local router expects to receive. It is the advertising router’s local label binding for that prefix. It does not have to be a label in the SRGB, but in this case, because SP1_R3 is running SR, it did allocate an SRGB label. The label index value is simply an attribute is that is passed along with the route. It does not change from when SP1_R2 advertised the route. If SP1_R3 allocated label 24018, this would be the label present in the NLRI, and the prefix-SID index value would still be 102.
Here is a pcap of the advertisement to SP2_XR1:
SP2_XR1 receives this route and also allocates label 16102 for 10.2.2.2/32. Because SP2_XR1 has the SRGB defined globally, it “honors” to label index present on the route and allocates its local label from its own SRGB.
RP/0/0/CPU0:SP2_XR1#show mpls forwarding
Wed Aug 24 13:17:01.855 UTC
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
16101 16101 SR Pfx (idx 101) Gi0/0/0/0 100.1.1.1 1688
16102 16102 SR Pfx (idx 102) Gi0/0/0/0 100.1.1.1 6914000
16202 Pop SR Pfx (idx 202) Gi0/0/0/1 10.1.2.2 123719
16203 16203 SR Pfx (idx 203) Gi0/0/0/1 10.1.2.2 1430
24000 Pop SR Adj (idx 1) Gi0/0/0/1 10.1.2.2 0
24001 Pop SR Adj (idx 3) Gi0/0/0/1 10.1.2.2 0
24002 Pop 100.1.1.1/32 Gi0/0/0/0 100.1.1.1 12860100
SP2_XR1 advertises this to SP2_R2 via iBGP. SP2_XR1 includes its own local label of 16102 and keeps the prefix-SID index value unchanged. SP2_XR1 also sets the next-hop to itself because the gi0/0/0/0 link is not participating or redistributed into the IGP.
SP2_R2 also allocates the same local label of 16102 for 10.2.2.2/32 by looking at the prefix-SID index value on the route. BGP is able to reserve 16102 because the SRGB is defined globally on the router.
SP2_R2#show mpls forwarding-table
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
16 Pop Label 10.2.3.3-A 0 Gi2 10.2.3.3
17 Pop Label 10.1.2.1-A 0 Gi1 10.1.2.1
16101 16101 10.1.1.1/32 0 Gi1 10.1.2.1
16102 16102 10.2.2.2/32 0 Gi1 10.1.2.1
16201 Pop Label 20.1.1.1/32 1856 Gi1 10.1.2.1
16203 Pop Label 20.3.3.3/32 1486 Gi2 10.2.3.3
A - Adjacency SID
Conclusion
SR for BGP simply uses BGP-LU with an additional optional, transitive Path Attribute called BGP Prefix-SID
The BGP Prefix-SID is a hint for the peer to locally allocate a label of SRGB+index. For this to work, the SRGB has to be defined globally, as BGP won’t use the IGP’s SRGB block.
The label value in the BGP-LU NLRI is no different from how it usually works. It is the advertising router’s local label binding for that prefix.
To inject a BGP-LU route with the BGP Prefix-SID attribute set, you use a route-policy on the network statement on IOS-XR, and the keyword segment-routing mpls under the BGP ipv4 address-family on IOS-XE.
#SP1_R2
segment-routing mpls
global-block 16000 23999
!
connected-prefix-sid-map
address-family ipv4
10.2.2.2/32 index 102 range 1
exit-address-family
!
!
router bgp 100
address-family ipv4
network 10.2.2.2 mask 255.255.255.255
segment-routing mpls
SP1_R2#show bgp ipv4 unicast 10.2.2.2/32
BGP routing table entry for 10.2.2.2/32, version 2
Paths: (1 available, best #1, table default)
Advertised to update-groups:
1 2
Refresh Epoch 1
Local
0.0.0.0 from 0.0.0.0 (10.2.2.2)
Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced, local, best
mpls labels in/out imp-null/nolabel
rx pathid: 0, tx pathid: 0x0
Updated on Aug 24 2022 03:01:13 UTC
