Category: traffic engineering

Content providers were using centralized traffic flow optimization together with MPLS TE for at least 15 years (some of them immediately after Cisco launched the early MPLS-TE implementation in their 12.0(5)T release), but it was always hard to push the results into the network devices.

PCEP and BGP-LS all changed that – they give you a standard mechanism to extract network topology and install end-to-end paths across the network, as Julian Lucek of Juniper Networks explained in Episode 43 of Software Gone Wild.

Ethan Banks recently wrote a nice blog post detailing the benefits and drawbacks of traditional routing protocols and comparing them with their SD-WAN counterparts.

While I agree with everything he wrote, the comparison between the two isn’t exactly fair – it’s a bit like trying to cut the cheese with a chainsaw and complaining about the resulting waste.

In the final part of our MPLS-focused discussion (now part of MPLS Essentials webinar), Seamus wanted to know how one could combine MPLS/VPN, MPLS-TE and QoS (for example, sending VoIP traffic for one customer over a different path).

Short answer: don’t even think about doing that. The added complexity is not worth whatever extra money you’ll be charging the customer (or not).

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.

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.

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.

Ronald sent me an interesting question: What's the point of having a secondary path set up for a certain LSP, when this LSP also has fast-reroute enabled (for example, with the Junos fast-reroute command)?

The idea of having a pre-established secondary LSP backing up a traffic engineering tunnel was commonly discussed before FRR was widely adopted, but should have quietly faded away by now.

An MPLS Traffic Engineering (MPLS TE) tunnel is a unidirectional Label Switched Path (LSP) established between the tunnel head-end Label Switch Router (LSR) and tail-end LSR. Once the tunnel is established and operational, it’s ready to forward IPv4 data traffic. However, no traffic will enter the tunnel unless the IPv4 routing tables and CEF tables are modified. You can push the traffic into an MPLS TE tunnel with a static route or with policy-based routing (PBR) or modify the behavior of the link-state algorithm used to implement MPLS TE in your network.

The autoroute functionality configured with the tunnel mpls autoroute announce interface configuration command automatically inserts the MPLS TE tunnel in the SPF tree and ensures the tunnel is used to transport all the traffic from the head-end LSR to all destinations behind the tail-end LSR.

An anonymous commenter to my implicit NULL/PHP post made a very valid point:

Most Cisco documentation states that you must enable LDP before doing MPLS-TE, which is a complete fallacy.

If you're using MPLS TE simply to shift IP traffic around your network, he's absolutely right: there is no need to run LDP if you have an IP-only network. If you're running MPLS VPN or BGP on edges/MPLS in the core, the answer becomes “it depends.”

I documented the detailed rules and undesired side effects if you ignore them a long while ago, but that article disappeared into /dev/null. Fortunately archive.org caught a copy before that.

Would you like me to migrate that article to ipSpace.net? Send me a message and I just might do it...

You've probably heard the joke about the honest salesmen: it's not that they're lying, what they know isn't true. I had a similar problem recently: in the 10 MPLS traffic engineering myths and half truths I wrote “Half-truth: MPLS TE only works with OSPF and IS-IS routing protocols.” Ivan Kuchin understood that as “You can run MPLS TE without OSPF or IS-IS.” Although I haven't written that anywhere, I also thought that was the case … so let me try to weasel out of this mess.

I remember being involved in a situation years ago (around the 12.0T release) where someone wanted to use MPLS TE without IS-IS (which was the only supported protocol in those days) and somehow the solution was to set up tunnels using explicit paths, where you have to specify hop-by-hop IP addresses. When you think about it, it makes perfect sense: if you list every IP address in the path, there is no need for constraint-based path calculation (PCALC). However, as it turns out, the later additions to MPLS TE (loose source routing, address exclusion, inter-area MPLS TE, inter-AS MPLS TE) changed the IOS code sufficiently that even the hop-by-hop tunnels cannot be set up without operational OSPF or IS-IS:

• In order to have MPLS TE running on a router, you need an MPLS TE router-id, and you can only specify that in OSPF or IS-IS routing protocol.
• Even though the hop-by-hop explicit path is static, the router wants to run PCALC for every hop in the path. If the next-hop IP address is not in the OSPF topology database, the router will not even try to set up the tunnel.

If you want to run MPLS TE in your network, you thus need to run OSPF or IS-IS, even though you might not want to use them for IP packet forwarding. For example, you could enable one of them only on the links actually used for MPLS TE and set the distance to 255 to prevent their routes from getting into the IP routing table (and I've tested it in the lab before writing this post).

Did you believe MPLS TE was a quality-of-service feature? Did someone persuade you it’s mandatory to run OSPF or IS-IS if you want to deploy MPLS TE? I’ve collected a few more myths like these two and explained the actual facts behind them in 10 MPLS traffic engineering myths and half truths published by ComputerWeekly..

One of the most commonly asked load-sharing-related questions is “can I load-share traffic across unequal-cost links?”. In general, the answer is no. In order to load-share the traffic, you need more than one path to the destination and the only way to get multiple routes toward a destination in the IP routing table is to make them equal-cost (the only notable exception being EIGRP that supports unequal-cost load-sharing with the variance parameter).

There are, however, two cases where you can force unequal traffic split across equal-cost paths toward a destination: when using inter-AS BGP with the link bandwidth parameter, and when using unequal-bandwidth traffic-engineering tunnels.