Category: MPLS

MPLS Traffic Engineer is sometimes promoted as a QoS solution (it seems bandwidth calendaring is a permanent obsession of some networking engineers, and OpenFlow is no more a solution than MPLS-TE was ;), but in reality it’s pretty hard to make the two work together seamlessly (just ask anyone who had to implement auto-bandwidth MPLS-TE in a large network).

Not surprisingly, we addressed the topic during our MPLS Tech Talk (now part of MPLS Essentials webinar).

After discussing the basics of MPLS, MPLS-TE and LDP, and the relationship between FECs, LDP and BGP, Seamus and myself focused on another interesting topic: how MPLS protocol stack uses RSVP to implement traffic engineering.

One of my readers is struggling with the aftermath of marketing gimmicks:

We will implement a new network soon, and we're discussing P-routers versus regular routers versus switches. I'm looking for arguments to go one way or the other.

TL&DR: there’s no difference between router and L3 switch.

MPLS bottom-of-stack bit confused one of my readers. In particular, he had a problem with the part where the egress MPLS Label Switch Router (LSR) should go from labeled (MPLS) to unlabeled (IPv4, IPv6) packets and had to figure out what was in the packet.

In the third part of MPLS Tech Talks, we focused on the role of label distribution protocol (LDP) and its operation in frame-mode MPLS.

After covering the basics of MPLS, my discussion with Seamus Gilchrist turned to the basics of MPLS Traffic Engineering.

The video of that discussion is available in the MPLS Essentials webinar.

Seamus Gilchrist sent me a fantastic list of MPLS- and MPLS-TE-related questions. Instead of starting an email exchange we agreed on something that should benefit a wider community: a lengthy whiteboard session discussing the basics of MPLS, MPLS-TE, load balancing and QoS in MPLS networks…

The first part of our conversation is already online: The Essence of MPLS.

In a previous blog post I explained how load sharing across LDP-controlled MPLS core works. Now let’s focus on another detail: how are the packets assigned to individual paths across the core?

2014-08-14: Additional information was added to the blog post based on comments from Nischal Sheth, Frederic Cuiller and Tiziano Tofoni. Thank you!

Here’s a question that bothered me for years till I finally gave up and labbed it: does ECMP load sharing work in an MPLS core? More specifically, will an LSP split into multiple LSPs?

I heard the following pretty bold statement while listening to an episode of my favorite podcast: “Bringing MPLS into the data center is impractical because MPLS requires custom silicon.” Really? How about checking the Intel FM 6000 product brief first?

Broadcom Trident chipset supposedly also supports MPLS. I couldn’t verify that because Broadcom considers the capabilities of their hardware highly confidential (but if you know more, do write a comment). Absolutely refreshing for a chipset that you get in almost every ToR switch you buy.

A group of researches presented an “interesting” result @ IETF 87: migrating from IBGP full mesh to IBGP reflectors can introduce temporary forwarding loops. OMG, really?

Don’t panic, the world is not about to become a Vogon hyperspace bypass. Let’s put their results in perspective.

One of the holy grails of data center SDN evangelists is controller-driven traffic engineering (throwing more leaf-and-spine bandwidth at the problem might be cheaper, but definitely not sexier). Obviously they don’t call it traffic engineering as they don’t want to scare their audience with MPLS TE nightmares, but the idea is the same.

Interestingly, you don’t need new technologies to get as close to that holy grail as you wish; Petr Lapukhov got there with a 20 year old technology – BGP.

TL&DR Summary: Yes (if you’re clumsy enough).

A while ago I read Impact of Graceful IGP Operations on BGP – an article that described how changes in IGP topology result in temporary (or sometimes even permanent) forwarding loops in networks using BGP route reflectors.

Is the problem real? Yes, it is. Could you generate a BGP RR topology that results in a permanent forwarding loop? Yes. It’s not that hard.

One of my readers sent me a surprising question: “We run only LDP in our MPLS network and need to run RSVP for TE and then phase out LDP. How could we do it?”

My first reaction was “Why would you ever want to do that” and I got no reasonable answer (suggestions, anyone?) but let’s focus on “Could you do it?”

TL&DR summary: You could, but that doesn’t mean you should.

I asked Martin Casado to check whether I correctly described his HotSDN’12 paper in my Edge and Core OpenFlow post, and he replied with another interesting observation:

The (somewhat nuanced) issue I would raise is that [...] decoupling [also] allows evolving the edge and core separately. Today, changing the edge addressing scheme requires a wholesale upgrade to the core.

The 6PE architecture (IPv6 on the edge, MPLS in the core) is a perfect example of this concept.