On both providers, the LSPs end at the edge of the provider’s IGP: SP-A builds them with LDP, RSVP-TE and SR, and SP-B with SR only. BGP labelled unicast advertises an IPv4 prefix together with an MPLS label, and it lets an LSP run PE to PE from one provider into the other.
In this stage, the PEs and the ASBR of each provider advertise their Loopback0 with a label to their own route reflector, which passes them on to the other clients. B-PE1 has the three SP-B loopbacks with labels: its own and the two it learned through B-RR:
! trimmed to the timestamp and the label table
RP/0/RP0/CPU0:B-PE1#show bgp ipv4 labeled-unicast labels
Mon Jul 27 13:31:59.744 UTC
Network Next Hop Rcvd Label Local Label
*> 10.2.0.5/32 0.0.0.0 nolabel 3
*>i10.2.0.6/32 10.2.0.6 3 24015
*>i10.2.0.8/32 10.2.0.8 3 24016
Processed 3 prefixes, 3 pathsTopology file: topology.clab.yml · Addressing: ipam.md · Stage configs, 8 nodes (A-PE1, A-PE2, A-ASBR, A-RR, B-PE1, B-PE2, B-ASBR, B-RR): stage_configs/lab04-s1-bgp-lu/
The Configuration
The iBGP sessions to A-RR and B-RR exist from the BGP control-plane post, so this stage adds only address-family lines.
On the IOS-XE nodes, network puts the loopback into BGP and send-label makes the session to the route reflector carry labels. A-PE1:
router bgp 64501
!
address-family ipv4
network 10.1.0.5 mask 255.255.255.255
neighbor 10.1.0.7 activate
neighbor 10.1.0.7 send-label
exit-address-familyA-PE2, A-ASBR, and B-ASBR (but to its local RR) have the same lines for their own loopbacks.
IOS-XE negotiates labels as a capability of the IPv4 unicast session. show bgp ipv4 unicast neighbors shows it on A-PE1:
A-PE1#show bgp ipv4 unicast neigh 10.1.0.7 | i ^BGP|MPLS_Label
BGP neighbor is 10.1.0.7, remote AS 64501, internal link
ipv4 MPLS Label capability: advertised and receivedOn the IOS-XR PEs, network and allocate-label all go under the global address-family ipv4 unicast, and the neighbour gets address-family ipv4 labeled-unicast. B-PE1:
router bgp 64502
!
address-family ipv4 unicast
network 10.2.0.5/32
allocate-label all
!
neighbor 10.2.0.7
address-family ipv4 labeled-unicastB-PE2 has the same lines for its own loopback. IOS-XR sends a prefix as labelled unicast only when the prefix has a local label, and allocate-label all gives one to every prefix the router originates or learns over labelled unicast.
A-RR and B-RR also run IOS-XR, and each client gets address-family ipv4 labeled-unicast with route-reflector-client:
router bgp 64501
address-family ipv4 unicast
allocate-label all
!
neighbor 10.1.0.5
address-family ipv4 labeled-unicast
route-reflector-client
!
neighbor 10.1.0.6
address-family ipv4 labeled-unicast
route-reflector-client
!
neighbor 10.1.0.8
address-family ipv4 labeled-unicast
route-reflector-clientB-RR has the same configuration under router bgp 64502 for 10.2.0.5, 10.2.0.6, and 10.2.0.8. The route reflectors originate no prefixes of their own in this stage.
The Labels
Label 3 is the implicit-null label. Each PE and ASBR advertises it for its own loopback, since the LSP to that loopback ends on the router itself. A router that receives implicit-null for a prefix removes the top label before it sends the packet on, instead of swapping it for a new one.
B-PE1’s table from the first output shows the IOS-XR columns: the received label first, then the local label. Local Label 3 is the label B-PE1 advertises for its own 10.2.0.5, and allocate-label all gave the two learned loopbacks the local labels 24015 and 24016:
! trimmed to the timestamp and the label table
RP/0/RP0/CPU0:B-PE1#show bgp ipv4 labeled-unicast labels
Mon Jul 27 13:31:59.744 UTC
Network Next Hop Rcvd Label Local Label
*> 10.2.0.5/32 0.0.0.0 nolabel 3
*>i10.2.0.6/32 10.2.0.6 3 24015
*>i10.2.0.8/32 10.2.0.8 3 24016
Processed 3 prefixes, 3 pathsOn IOS-XE, the In label column is the label the router advertises, and the Out label column is the label it received from the next hop. Out label nolabel means no label was assigned:
A-PE1#show bgp ipv4 unicast labels
Network Next Hop In label/Out label
10.1.0.5/32 0.0.0.0 imp-null/nolabel
10.1.0.6/32 10.1.0.6 nolabel/imp-null
10.1.0.8/32 10.1.0.8 nolabel/imp-nullWhen a route reflector passes a route on with its next hop unchanged, it has to leave the label unchanged as well, so the clients receive the originator’s label. In A-PE1’s table above, the Out label for A-PE2’s loopback, 10.1.0.6, and for A-ASBR’s loopback, 10.1.0.8, is imp-null, the label each of them advertised for itself. B-PE2 received B-PE1’s loopback, 10.2.0.5, from B-RR, 10.2.0.7, with Received Label 3, the label B-PE1 advertised:
! trimmed to the path
RP/0/RP0/CPU0:B-PE2#show bgp ipv4 labeled-unicast 10.2.0.5/32
Mon Jul 27 13:36:47.854 UTC
BGP routing table entry for 10.2.0.5/32
Local
10.2.0.5 (metric 30) from 10.2.0.7 (10.2.0.5)
Received Label 3
Origin IGP, metric 0, localpref 100, valid, internal, best, group-best, labeled-unicast
Received Path ID 0, Local Path ID 1, version 4
Originator: 10.2.0.5, Cluster list: 10.2.0.7
The Session Restart
BGP peers exchange their capabilities in the OPEN message when the session comes up, and in this lab all address families of a neighbour share that session. Adding labelled unicast to an established session restarts it, so that the peers can open it again with the new capability.
On A-RR, the sessions to all three clients restarted in all four address families:
! trimmed to the timestamps and the neighbour tables
RP/0/RP0/CPU0:A-RR#show bgp ipv4 labeled-unicast summary
Mon Jul 27 13:23:24.242 UTC
Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd
10.1.0.5 0 64501 18023 16567 4 0 0 00:22:28 1
10.1.0.6 0 64501 18047 16566 4 0 0 00:22:29 1
10.1.0.8 0 64501 18048 16456 4 0 0 00:22:28 1
RP/0/RP0/CPU0:A-RR#show bgp vpnv4 unicast sum
Mon Jul 27 13:23:31.677 UTC
Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd
10.1.0.5 0 64501 18023 16567 114 0 0 00:22:36 2
10.1.0.6 0 64501 18047 16566 114 0 0 00:22:36 3
10.1.0.8 0 64501 18048 16456 114 0 0 00:22:36 4
RP/0/RP0/CPU0:A-RR#show bgp vpnv6 unicast sum
Mon Jul 27 13:23:36.524 UTC
Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd
10.1.0.5 0 64501 18023 16567 80 0 0 00:22:40 1
10.1.0.6 0 64501 18047 16566 80 0 0 00:22:41 2
10.1.0.8 0 64501 18048 16456 80 0 0 00:22:40 4
RP/0/RP0/CPU0:A-RR#show bgp ipv4 mvpn sum
Mon Jul 27 13:23:42.709 UTC
Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd
10.1.0.5 0 64501 18023 16567 72 0 0 00:22:47 1
10.1.0.6 0 64501 18047 16566 72 0 0 00:22:47 3In A-ASBR’s VPNv4 summary, only the session to A-RR restarted. The two eBGP sessions to B-ASBR, 10.255.0.2 for Option B and 10.255.0.6 for Option A, stayed up:
! trimmed to the neighbour table
A-ASBR#show bgp vpnv4 unicast all sum
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.1.0.7 4 64501 58 50 119 0 0 00:05:00 5
10.255.0.2 4 64502 11669 11706 119 0 0 1w0d 2
10.255.0.6 4 64502 17989 17971 119 0 0 1w4d 2On SP-B, B-PE1’s session to B-RR restarted as well:
! trimmed to the timestamp and the neighbour table
RP/0/RP0/CPU0:B-PE1#show bgp ipv4 labeled-unicast sum
Mon Jul 27 13:28:23.410 UTC
Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd
10.2.0.7 0 64502 16444 16500 4 0 0 00:23:51 2B-PE1’s colour-128 policy is an on-demand policy from the SR-TE post: B-PE1 builds it when a BGP route with colour 128 arrives, so it came up again with the session. The explicit colour-200 policy stayed up:
! trimmed to the status of the two policies
RP/0/RP0/CPU0:B-PE1#show segment-routing traffic-eng policy
Mon Jul 27 13:40:32.645 UTC
SR-TE policy database
---------------------
Color: 200, End-point: 10.2.0.6
Name: srte_c_200_ep_10.2.0.6
Status:
Admin: up Operational: up for 1w4d (since Jul 16 05:43:44.543)
Color: 128, End-point: 10.2.0.6
Name: srte_c_128_ep_10.2.0.6
Status:
Admin: up Operational: up for 00:35:55 (since Jul 27 13:04:37.453)CustA-HQ’s ping to CustA-Br2, over the path from the Option B post, got 5 of 5 replies in both address families after the restart:
CustA-HQ#ping 10.10.0.3 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.0.3, timeout is 2 seconds:
Packet sent with a source address of 10.10.0.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms
CustA-HQ#ping 2001:db8:10::3 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:10::3, timeout is 2 seconds:
Packet sent with a source address of 2001:DB8:10::1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/4/7 ms
CustA-HQ#The Routes That Forward
Each PE and ASBR now also learns the other loopbacks of its provider from BGP, with a label. The routing table installs only the route with the lowest administrative distance, and an iBGP route has 200, against 1 for a static route, 110 for OSPF, and 115 for IS-IS:
Since the BGP route is not installed, its label is not used for forwarding, and traffic to these loopbacks takes the same path as before this stage. A labelled unicast route is installed only when no route with a lower distance exists for the loopback.
A-PE2 marks its labelled unicast path to 10.1.0.5 RIB-failure, because the routing table already has 10.1.0.5/32 from a source with a lower distance:
A-PE2#show bgp ipv4 unicast 10.1.0.5/32
BGP routing table entry for 10.1.0.5/32, version 5
Paths: (1 available, best #1, table default, RIB-failure(17))
Not advertised to any peer
Refresh Epoch 1
Local
10.1.0.5 from 10.1.0.7 (10.1.0.7)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 10.1.0.5, Cluster list: 10.1.0.7
mpls labels in/out nolabel/imp-null
rx pathid: 0, tx pathid: 0x0That source is the static route that autoroute destination installs for Tunnel20, A-PE2’s RSVP-TE tunnel to A-PE1, from the MPLS-TE post, and its forwarding entry points into the same tunnel:
A-PE2#show ip route 10.1.0.5
Routing entry for 10.1.0.5/32
Known via "static", distance 1, metric 0 (connected)
Routing Descriptor Blocks:
* directly connected, via Tunnel20
Route metric is 0, traffic share count is 1
A-PE2#show mpls forward 10.1.0.5 32
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
1606 [T] Pop Label 10.1.0.5/32 0 Tu20 point2pointA-ASBR has no TE tunnel, and its route to 10.1.0.5 is OSPF, distance 110:
A-ASBR#show ip route 10.1.0.5
Routing entry for 10.1.0.5/32
Known via "ospf 1", distance 110, metric 3, type inter area
Last update from 10.1.1.41 on GigabitEthernet2, 1w4d ago
Routing Descriptor Blocks:
* 10.1.1.41, from 10.1.0.1, 1w4d ago, via GigabitEthernet2
Route metric is 3, traffic share count is 1
Repair Path: 10.1.1.45, via GigabitEthernet3On SP-B, B-PE1’s route to 10.2.0.6 is IS-IS, distance 115, with an SR label. It was installed before the iBGP sessions restarted:
RP/0/RP0/CPU0:B-PE1#show route 10.2.0.6/32 detail
Mon Jul 27 13:39:36.268 UTC
Routing entry for 10.2.0.6/32
Known via "isis 1", distance 115, metric 30, labeled SR, type level-2
Installed Jul 27 05:43:03.978 for 07:56:32What’s Next
This stage prepares the foundation for Inter-AS Option C. In the next post, the ASBRs exchange these labelled loopbacks over eBGP.
Leave a Reply