One of the frequent questions I hear regarding L3VPNs, is regarding the bottom VPN label. In this article, we will focus on the control plane that provides both the VPN and transit labels, and then look at the data plane that results because of those labels.
In the topology, there are 2 customer sites (bottom right, and bottom left). The BGP, VRFs, Redistribution, etc are all configured to allow us to focus on the control and data plane. Lets begin by verifying that R1 is sourcing the network, 1.1.1.1/32.
A debug verifies that R1 is sending the updates for 1.1.1.1 to R2.
R2 has learned the route from R1, has assigned a VPN label for it, and has exported it from the VRF into BGP. This lucky route was assigned the local label of 16 by R2.
We can also look at the MPLS forwarding table on R2 to see the same tag information.
This prefix, as a VPNV4 route, is sent as an update to the iBGP peer R4. We can force an update with refresh.
The update can be seen on the wire between R2 and R3, (on its way to R4) using a protocol analyzer. You may also notice that R2 uses outgoing label 19 for forwarding this update to 4.4.4.4 The label can be seen in the MPLS forwarding output above.
The VPN label being advertised in the update is Label 16, which is R2′s local label for the 1.1.1.1 network.
On R4, which will be the ingress PE for transit traffic destined for 1.1.1.1, we can see that the VPN label of 16 is associated with destination network of 1.1.1.1 The next hop of 2.2.2.2 to reach the 1.1.1.1 network, is due to R2 assigning next-hop-self for updates it sends to R4.
We can also see the outgoing MPLS label that R4 will use to reach the next hop of 2.2.2.2. The label of 18 below, was advertised by R3, as the label to use to reach 2.2.2.2
We can also verify that the route (1.1.1.1) has been imported by R4 into the customer vrf.
So when a transit packet is sent from R5 to 1.1.1.1, R4 should impose 2 labels. The bottom label will be 16 (the VPN label) for the 1.1.1.1 network (R2 told us about that via the iBGP update), and the top label should be 18 (advertised via LDP from R3), to reach the next hop of 2.2.2.2
On R4 a quick check of the CEF table for the vrf can verify both labels.
A simple trace from R5, to the destination network of 1.1.1.1 should prove all the labels in the path.
The top label of 18 is used to reach the next hop of 2.2.2.2, and the bottom label of 16, which is meaningful to R2, because he sourced it, will be used by R2 in forwarding the transit traffic destined to 1.1.1.1 to the next hop, which is R1.
R3 will pop the transit label off, due to R2 advertising implicit-null for the network 2.2.2.2 (itself).
In the topology, there are 2 customer sites (bottom right, and bottom left). The BGP, VRFs, Redistribution, etc are all configured to allow us to focus on the control and data plane. Lets begin by verifying that R1 is sourcing the network, 1.1.1.1/32.
A debug verifies that R1 is sending the updates for 1.1.1.1 to R2.
R2 has learned the route from R1, has assigned a VPN label for it, and has exported it from the VRF into BGP. This lucky route was assigned the local label of 16 by R2.
We can also look at the MPLS forwarding table on R2 to see the same tag information.
This prefix, as a VPNV4 route, is sent as an update to the iBGP peer R4. We can force an update with refresh.
The update can be seen on the wire between R2 and R3, (on its way to R4) using a protocol analyzer. You may also notice that R2 uses outgoing label 19 for forwarding this update to 4.4.4.4 The label can be seen in the MPLS forwarding output above.
The VPN label being advertised in the update is Label 16, which is R2′s local label for the 1.1.1.1 network.
On R4, which will be the ingress PE for transit traffic destined for 1.1.1.1, we can see that the VPN label of 16 is associated with destination network of 1.1.1.1 The next hop of 2.2.2.2 to reach the 1.1.1.1 network, is due to R2 assigning next-hop-self for updates it sends to R4.
We can also see the outgoing MPLS label that R4 will use to reach the next hop of 2.2.2.2. The label of 18 below, was advertised by R3, as the label to use to reach 2.2.2.2
We can also verify that the route (1.1.1.1) has been imported by R4 into the customer vrf.
So when a transit packet is sent from R5 to 1.1.1.1, R4 should impose 2 labels. The bottom label will be 16 (the VPN label) for the 1.1.1.1 network (R2 told us about that via the iBGP update), and the top label should be 18 (advertised via LDP from R3), to reach the next hop of 2.2.2.2
On R4 a quick check of the CEF table for the vrf can verify both labels.
A simple trace from R5, to the destination network of 1.1.1.1 should prove all the labels in the path.
The top label of 18 is used to reach the next hop of 2.2.2.2, and the bottom label of 16, which is meaningful to R2, because he sourced it, will be used by R2 in forwarding the transit traffic destined to 1.1.1.1 to the next hop, which is R1.
R3 will pop the transit label off, due to R2 advertising implicit-null for the network 2.2.2.2 (itself).
