Unified MPLS
Last updated
Last updated
Unified MPLS, also called Seamless MPLS, was defined in draft-ietf-mpls-seamless-mpls-07. This is not really a new technology, but a combination of tools to allow for multiple IGP islands within a single AS. This allows you to form end-to-end LSPs even though you don’t have a single IGP. (An end-to-end LSP is an LSP in which the bottom service label never changes).
This is sort of like Inter-AS VPNs, but you could call it “Inter-Domain IGP / Intra-Domain AS”. The service provider has multiple, separate IGP processes for scalability, but a single BGP AS.
Imagine the following topology, which we will use for our lab:
For scalability, the service provider has created a single OSPF process for each agg router and all access routers that connect to that agg router. For brevity only a single access router connects to each agg in our lab. The core, comprising of all agg and core routers, runs ISIS.
What happens if we want to have an LSP from Access1 to Access2? By default, this will not work, as Access1 does not know Access2’s loopback and vice versa. You could redistribute all loopbacks into every IGP process, but this kind of defeats the purpose of having multiple IGPs. If you have thousands of routers in each IGP process, you don’t want to flood the IGP with thousands of external /32s.
The Unified MPLS solution uses BGP-LU (Labeled Unicast) to exchange the /32 loopbacks of access routers in the topology. BGP is much better equiped to handle a large number of routes than IGP is.
The agg routers are ASBRs, because they participate in both the ISIS core and the OSPF processes. The access routers will run BGP-LU with the Agg router in their area. The agg routers will also run BGP-LU between each other. The core can stay “BGP-Free” as no CEs or services connect directly to the core.
The potential problem with this is that, by default, when an iBGP route is reflected to another iBGP router, you cannot alter the next-hop. Access1 will get a /32 route for Access2 but pointing to Access2. Obviously this cannot work. Agg1 needs to insert itself into the path by setting the next-hop of the /32 for Access2 to itself when it advertises the route to Access1. In order to change the next-hop on iBGP learned routes that are advertised to iBGP peers you have to use a special command:
IOS-XE: next-hop-self all on the neighbor statement
IOS-XR: ibgp policy out enforce-modifications globally + next-hop-self on the neighbor’s AFI/SAFI
Let’s set this up in our lab so you can get a better understanding of how this works.
First we’ll configure standard IGP/LDP on all routers. Remember there is no redistribution between the IGP processes. On the agg routers we’ll advertise the loopback into both IGPs.
Now we’ll configure BGP-LU on the access and agg routers. Each access router advertises its own loopback. The agg routers treat access routers as RR clients and each other as RR clients.
We now have an LSP between Access1 and Access2:
Let’s go hop-by-hop and understand where each label came from.
Label 22 is imposed because this is the label that Agg1 advertised to Access1 for 6.6.6.6/32 via BGP-LU.
Agg1 swaps label 22 for label 24005, because this is the label that Agg2 advertised to Agg1 via BGP-LU.
Agg1 also needs to push the transport label representing Agg2’s loopback, as Core1 and Core2 are BGP-free. This is very similar to vpnv4, where the top label seen in the core is the label representing the remote PE’s loopback.
Core1 swaps 19 for 24003. This is a normal LDP operation.
Core2 pops label 24003 and delivers to Agg2. This is another normal LDP operation.
Agg2 pops the BGP-LU label that it advertised to Agg1 and delivers to Access2
The labels that Agg1 and Agg2 advertised to each other over BGP-LU are actually just the LDP labels allocated for the prefixes 1.1.1.1/32 and 6.6.6.6/32 that were already allocated.
Let’s test the end-to-end LSP by adding an L2VPN service between Access1 and Access2. If you would like to follow along, you will need to swap Access2 XRv for a XRv9000.
CE1 connects to Access1 on Gi2:
CE2 connects to Access2 on Gi0/0/0/1:
Question: How many labels are seen on the link between Agg1 and Core1 when CE1 pings CE2?
Answer: Three. The top label is the transport label which represents Agg2. The middle label is the BGP label that Agg2 advertised for 6.6.6.6/32. The bottom label is the service label which Access2 advertised to Access1 for this L2VPN.
19 is the transport label, 24005 is the BGP label, and 24000 is the service label.
Question: Why didn’t we need to run BGP between Access1 and Access2 for this L2VPN to work?
Answer: The xconnect is a Martini circuit. This uses targeted LDP to exchange the service label. See the section “IOS-XE Ethernet Services/E-Line” for more information or practice.
What is interesting is that because Access1 and Access2 only know each other via a labeled path, the targeted LDP Hellos are actually MPLS-encapsulated!
