The long awaited LTS Release of VyOS 1.4.0 is steadily approaching. Some of the biggest additions to 1.4.0 are the inclusion of numerous MPLS related features. While 1.3.x had MPLS, these were largely for serving the role as Provider (P) routers, which are used to forward labels between routers. 1.4.0 adds numerous features that allow VyOS to serve the roll as Provider Edge (PE) routers, which are used to route overlay services over an MPLS environment.

I figured this would be a good time to help familiarize people with MPLS Basics as it relates to VyOS.

What is MPLS

MPLS has now been around for over 3 decades, and has seen a lot of development over that period. At a basic level, MPLS is the forwarding of packets using labels instead of IPs. This provides efficiencies in the forwarding of the packet, as these lookup processes were optimized over the lookup of an IP header. The major benefit of MPLS was that dedicated P routers could be deployed that didn’t need to know about any of the IPv4 customer prefixes, only a small number of labels. Holding large routing tables with modern hardware is somewhat trivial, but 3 decades ago, routers that could hold large routing tables were the biggest and baddest routers on the market, which came with a heavy price point.

Modern MPLS more revolves around the extensibility of overlay services, as it provides a transparent underlay for traffic to traverse.

Operation of MPLS

Just like with a normal IP network, when a packet is about to be put on an MPLS network, a route lookup is performed. This time, a lookup is performed against a table holding labels, typically referred to as the Label Forwarding Information Base (LFIB). The lookup is performed against the next-hop for the destination in the routing table, not necessarily the destination in the packet..

MPLS will follow a Push, Swap, Pop process when traversing Label Switched Paths (LSPs)

  • Push:
    • A push action occurs when a label is “shimmed” between the L2 and L3 headers, which is why MPLS Labels will sometimes be referred to as Shim Headers.
  • Swap:
    • A swap action will occur as that packet traverses the LSP, swapping out labels to continue on to the destination.
  • Pop:
    • A pop action occurs when the destination MPLS Router is reached so the packet can be forwarded via IP to the IP destination.

Let’s build a quick lab see this.

Topology

Our topology will have 3 devices connected in a row.

IP Addressing:

All devices are interconnected using IPs based on their device number (e.g. P1 and P2 are connected with the 10.1.2.0/24 network; P2 and P3 will connect using the 10.2.3.0/24 network)

  • Loopbacks:
    • P1 – 10.0.0.1/32
    • P2 – 10.0.0.2/32
    • P3 – 10.0.0.3/32

Each device will run OSPF between each other to share routes.

P1:
set interfaces dummy dum0 address '10.0.0.1/32'
set interfaces ethernet eth0 address '10.1.2.1/24'

set protocols ospf interface dum0 area '0'
set protocols ospf interface eth0 area '0'
set protocols ospf interface eth0 network 'point-to-point'

P2:
set interfaces dummy dum0 address '10.0.0.2/32'
set interfaces ethernet eth0 address '10.1.2.2/24'
set interfaces ethernet eth1 address '10.2.3.2/24'

set protocols ospf interface dum0 area '0'
set protocols ospf interface eth0 area '0'
set protocols ospf interface eth0 network 'point-to-point'
set protocols ospf interface eth1 area '0'
set protocols ospf interface eth1 network 'point-to-point'

P3:
set interfaces dummy dum0 address '10.0.0.3/32'
set interfaces ethernet eth1 address '10.2.3.3/24'

set protocols ospf interface dum0 area '0'
set protocols ospf interface eth1 area '0'
set protocols ospf interface eth1 network 'point-to-point'

Label Imposition

We need some way to attach labels to prefixes in our devices. The most common methods are Static Binding, Label Distribution Protocol, and BGP Labeled Unicast. In this lab, we’re going to use LDP, which is typically run along side a IGP like OSPF. This will allow us to build our LFIB.

LDP Configuration

P1:
set protocols mpls interface 'eth0'
set protocols mpls ldp discovery transport-ipv4-address '10.0.0.1'
set protocols mpls ldp interface 'eth0'
set protocols mpls ldp router-id '10.0.0.1'

P2:
set protocols mpls interface 'eth0'
set protocols mpls interface 'eth1'
set protocols mpls ldp discovery transport-ipv4-address '10.0.0.2'
set protocols mpls ldp interface 'eth0'
set protocols mpls ldp interface 'eth1'

P3:
set protocols mpls interface 'eth1'
set protocols mpls ldp discovery transport-ipv4-address '10.0.0.3'
set protocols mpls ldp interface 'eth1'
set protocols mpls ldp router-id '10.0.0.3'

LDP will negotiate on the multicast address of 224.0.0.2. We should see neighbors built between our devices now.

vyos@P1# run show mpls ldp neighbor 
AF ID State Remote Address Uptime
ipv4 10.0.0.2 OPERATIONAL 10.0.0.2 00:33:40

Let’s look at our labels. We have a few places where we can look at labels.

MPLS Table

The VyOS MPLS table shows labels that we are both sending and receiving. While this is nice to see, it doesn’t really help because we need to know what prefixes are attached to that label.

vyos@P1# run show mpls table 
Inbound Label Type Nexthop Outbound Label
-----------------------------------------------
17 LDP 10.1.2.2 17

We can get a little more by looking at LDP bindings.

NOTE: You can also see labels attached to prefixes with “show ip route forward”

vyos@P1# run show mpls ldp binding 10.0.0.3/32
AF Destination Nexthop Local Label Remote Label In Use
ipv4 10.0.0.3/32 10.0.0.2 17 17 yes

Now we can see that that label 17 was attached to the 10.0.0.3/32 IP, which is the loopback of P3.

  • Local Label:
    • This is the label we will advertise to peers to reach 10.0.0.3/32 through us (P1). If we advertised this to another router, and received a packet with label 17 from them, we would know that we need to keep forwarding to 10.0.0.3/32 (by swapping labels) without needing to do an IP lookup.
  • Remote Label
    • This is the label we received from the peer advertising the 10.0.0.3/32 prefix to us (P2). This means that when we send to 10.0.0.3/32, we will swap label 17 into our packet, so that P2 knows how to continue on forwarding.

NOTE: You can see that the label is identical. In normal routing, this could be an issue and cause an IP conflict. In traditional MPLS, labels are locally significant. Each device could use label 17 for different IPs and it wouldn’t cause an issue, since it is able to look at the label coming in on a specific interface.

Let’s see this in action. We’ll start with pinging P3 from P1:

vyos@P1# run ping 10.0.0.3 source-address 10.0.0.1 count 1
64 bytes from 10.0.0.3: icmp_seq=1 ttl=63 time=5.33 ms

Let’s look at the packet captures between our devices:

P1 to P2

We can see that predictably, our packet has label 17 in it. Let’s look at the LDP Binding Table on P2 to see how it’ll forward to P3.

vyos@P2# run show mpls ldp binding 10.0.0.3/32
AF Destination Nexthop Local Label Remote Label In Use
ipv4 10.0.0.3/32 10.0.0.3 17 imp-null yes

We can see our local label is 17, and we receive the packet with a label of 17 (from P1). This let’s us lookup where to send this packet; again without needing to do an IP lookup. You may see something unfamiliar under the Remote Label. Let’s see the packet capture between P2 and P3 before we go into what imp-null means.

P2 to P3

We can see we don’t have a label in this packet. That may not seem right, but this is perfectly expected behavior with that “imp-null” value.

Implicit Null

What is imp-null? It is short for Implicit Null, which is an enhancement to MPLS. The opposite of this is predictably called Explicit Null. Prior to implicit null, all traffic was explicit null. What this means is that there’s a label when we go from P1 to P2, then a new label when we go to P2 and P3. When P3 receives the packet, it then sees that it owns 10.0.0.3/32, and would pop that label it received in the packet from P2 before doing the IP lookup. This isn’t efficient because it needs to do a label lookup, followed by an IP lookup.

This is what implicit null solved. If a router owns a prefix, it will advertise a reserved label (label 3) to its peers, indicating implicit null. This triggers a process called Penultimate Hop Popping (PHP). PHP will tell the penultimate (meaning next to last; P2 in this case) router that it can pop the transport label before sending to P3. This allows the destination router to only need to do that single IP lookup.

Let’s look at the return path:

P3 to P2

vyos@P3# run show mpls ldp binding 10.0.0.1/32
AF Destination Nexthop Local Label Remote Label In Use
ipv4 10.0.0.1/32 10.0.0.2 16 16 yes

Here we use label 16. P3 will add that label in the packet so P2 can do a lookup.

P2 to P1

vyos@P2# run show mpls ldp binding 10.0.0.1/32
AF Destination Nexthop Local Label Remote Label In Use
ipv4 10.0.0.1/32 10.0.0.1 16 imp-null yes

We can see that implicit null triggered PHP again, allowing for P1 to do a simple IP lookup on 10.0.0.1.

Conclusion

That’s the basic building blocks for all MPLS traffic and how it is forwarded across LSPs. In Part 2 of this series, we’re going to go over some of those Provider Edge features I hinted at.

Leave a Reply

Trending

Discover more from Level Zero Networking

Subscribe now to keep reading and get access to the full archive.

Continue reading