Category: MPLS

Something didn’t feel right as I tried to check whether the IPv4 ECMP I observed in the latest version of Arista cEOS containers works with my MPLS/anycast scenario. The forwarding tables seemed OK, but I wasn’t getting MPLS labels in the ICMP replies (see RFC 4950 for details), even though I know Arista EOS can generate them.

I decided to go down that rabbit hole and built the simplest possible BGP-free core (the addition of BGP will become evident in a few seconds) to investigate PE/P-router behavior:

I decided it was high time to create EVPN/MPLS netlab integration tests and wanted to use the same approach I used for the EVPN/VXLAN ones:

• One of the PE-devices is the device we want to test
• The other PE-device is a device that is known to work (ideally, an FRRouting container).
• Bonus points if the other PE-device can generate operational data in JSON format. Using a device for which we already have a validation plugin is close to perfection.
• Add a P-router in the middle because MPLS.
• Attach some hosts to the two PE-devices (we’re testing two MAC-VRFs in the final version of the test)
• After validating everything that can reasonably be validated (OSPF session, IBGP session, EVPN AF on IBGP session), do the end-to-end pings and hope for the best.

This is the graph netlab created from the lab topology:

Whenever I claim that the initial use case for MPLS was improved forwarding performance (using the RFC that matches the IETF MPLS BoF slides as supporting evidence), someone inevitably comes up with a source claiming something along these lines:

The idea of speeding up the lookup operation on an IP datagram turned out to have little practical impact.

That might be true¹, although I do remember how hard it was for Cisco to build the first IP forwarding hardware in the AGS+ CBUS controller. Switching labels would be much faster (or at least cheaper), but the time it takes to do a forwarding table lookup was never the main consideration. It was all about the aggregate forwarding performance of core devices.

Anyhow, Duty Calls. It’s time for another archeology dig. Unfortunately, most of the primary sources irrecoverably went to /dev/null, and personal memories are never reliable; comments are most welcome.

One of my readers attempted to implement a multi-vendor multicast VPN over MPLS but failed. As a good network engineer, he tried various duct tapes but found that the only working one was a GRE tunnel within a VRF, resulting in considerable frustration. In his own words:

How is a GRE tunnel different compared to an MPLS LSP? I feel like conceptually, they kind of do the same thing. They just tunnel traffic by wrapping it with another header (one being IP/GRE, the other being MPLS).

Instead of going down the “how many angels are dancing on this pin” rabbit hole (also known as “Is MPLS tunneling?”), let’s focus on the fundamental differences between GRE/IPsec/VXLAN tunnels and MPLS paths.

You can use SR-MPLS, MPLS-TE, or an SDN controller to build virtual circuits (label-switched paths) across the network core. The controller can push the LSPs into network devices with PCEP, BGP-LU, or some sort of NETCONF/RESTCONF trickery.

Unfortunately, you’re only half done once you have installed the LSPs. You still have to persuade the network devices to use them. Welcome to the confusing world of traffic steering explored in the Loopback as a Service blog post by Dmytro Shypovalov.

This blog post discusses an old arcane question that has been nagging me from the bottom of my Inbox for almost exactly four years. Please skip it if it sounds like Latin to you, but if you happen to be one of those readers who know what I’m talking about, I’d appreciate your comments.

Terminology first:

• Prefix Independent Convergence allows entries in the forwarding table to point to shared next hops (or next-hop groups), reducing the FIB update bottleneck when changing the next hop for a large number of prefixes (for example, when dealing with a core link failure). More details in the initial blog post and PIC applicability to fast reroute.
• PIC Edge (as defined by vendor marketing) is the ability to switch to a backup CE route advertised to a backup PE router before the network convergence is complete.

Here’s (in a nutshell) how PIC Edge is supposed to work:

Urs Baumann brought me a nice surprise last weekend. He opened a GitHub issue saying, “MPLS works on Arista cEOS containers in release 4.31.2F” and asking whether we could enable netlab to configure MPLS on cEOS containers.

After a few configuration tweaks and a batch of integration tests later, I had the results: everything worked. You can use MPLS on Arista cEOS with netlab release 1.9.0 (right now @ 1.9.0-dev2), and I’ll be able to create MPLS labs running in GitHub Codespaces in the not-too-distant future.

Dmytro Shypovalov wrote a fantastic article explaining the basics of MPLS-based Segment Routing. It’s pretty much equivalent to everything I ever wrote about SR-MPLS but in a much nicer package. Definitely a must-read.

Brad Casemore published an interesting analysis explaining why Cisco should accept being a mature company with mature products (yeah, you have to subscribe to view it). I always loved reading his articles, but unfortunately, this time, he briefly ventured into the “I don’t think this word means what you think it means” territory:

MPLS worked – and it still works – but it provided optimal value in an earlier time when the center of gravity was not the cloud. The cloud challenged the efficacy of MPLS, and it wasn’t long before SD-WAN, cloud connects, and interconnects […] represented an implacable threat to a status quo that had once seemed unassailable.

The second part of the paragraph is (almost) true, but it had nothing to do with MPLS.

A long-time friend sent me this question:

I would like your advice or a reference to a security framework I must consider when building a green field backbone in SR/MPLS.

Before going into the details, keep in mind that the core SR/MPLS functionality is not much different than the traditional MPLS: