Category: traffic engineering
After covering the basics of MPLS, the discussion I had with Seamus Gilchrist turned to the basics of MPLS Traffic Engineering.
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.
SearchTelecom has invited me to a new project: Ask the Expert. Anyone can send me service provider-related questions through their web page ... and I’ll do my best to find a reasonable answer (curveball questions trying to trip me are not considered fair ;).
One of the first questions was quite interesting: Can I use MPLS traffic engineering in an IPv6 backbone? As the participants of my last week’s Building IPv6 Service Provider core webinar have learned, you can use MPLS TE (today) only if you transport IPv6 across MPLS-enabled IPv4 backbone. You’ll find a few more details in my answer and I’ve documented a particularly nasty border case a while ago; for even more details, there’s always the next iteration of my webinar.
The information in this article applies only to single-topology IS-IS setup. Multi-topology IS-IS works correctly.
It’s a shame but it looks like IPv6 and MPLS TE don’t work together in current IOS releases. The standards are there, but Cisco didn’t find the motivation to implement them yet. The situation is particularly grave if you happen to:
- run IS-IS as your routing protocol (many large Service Provider networks do);
- use IS-IS for both IPv4 and IPv6 (makes perfect sense) in single-topology mode (not the best idea);
- use MPLS TE for traffic engineering and/or fast reroute (not uncommon);
- use autoroute on MPLS TE tunnels (most people do);
- run IPv6 natively (without end-to-end MPLS LSP and 6PE).
In this scenario, IS-IS will install autoroute-enabled MPLS TE tunnels in the SPF tree (see autoroute basics for more details) but as IPv6 and MPLS TE tunnels don’t mix, the IPv6 destinations behind the MPLS TE tunnels will not be reachable at all.
A few days ago I had an interesting discussion about the need for bidirectional MPLS TE tunnels when using MPLS TE forwarding adjacency. Although I’d always thought I knew how MPLS TE FA works, it took me a while to figure out all the details, so I decided to write an in-depth description of this interesting feature ... and realized after a few botched attempts it would be better to start with the fundamentals.
If you want to understand the benefits of MPLS TE FA, you need to know how MPLS TE autoroute works (and what its limitations are), so we’ll start with the MPLS TE autoroute basics.
If you’ve ever tried to design QoS in a large Service Provider network, you’ve probably realized that QoS is a zero-sum game: you can give some traffic preferential treatment only if you decide to drop or delay some other traffic. Furthermore, QoS is not linked to IP routing; interface queues cannot apply backpressure to IP routing tables or influence load sharing ratios.
The only technology that can shift the excess traffic in high-speed IP-only networks from congested links to underutilized alternate paths is MPLS traffic engineering. The “Using MPLS TE to avoid core network congestion” article I’ve written for SearchTelecom describes the basic interactions of MPLS TE and QoS and introduces autotunnel and autobandwidth concepts.
When configuring MPLS Traffic Engineering in your network, you have to specify the amount of bandwidth that the MPLS TE tunnels can request on each MPLS TE-enabled interface with the ip rsvp bandwidth command.
Until recently, this command accepted only fixed bandwidth (in kilobits), which could be pretty inconvenient if you wanted to use common interface templates or deployed MPLS TE on links with varying bandwidth (for example, Multilink PPP bundles). IOS release 12.2SRC introduced a variant of the same command (ip rsvp bandwidth percentage) that allows you to specify reservable bandwidth as percentage of the current interface bandwidth. Unfortunately this feature didn’t make it into 12.4(20)T.
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.” The detailed rules and undesired side effects if you ignore them are summarized in the MPLS Traffic Engineering in MPLS VPN environment article.
In a comment to my post describing the role of implicit NULL in LDP, an anonymous commenter complained about lack of Cisco’s standard compliance in MPLS TE tunnel setup process. Time for packet capture and Wireshark :). The tests were performed on the MPLS TE network I’ve used to illustrate MPLS troubleshooting with LSP ping; packets were captured on the link between C4 and C2 (the penultimate hop and the tunnel tail-end) at the time when the MPLS TE tunnel was established from C1 to C2. In all tests, an ICMP Echo Request packet was sent over the tunnel to verify whether C4 performed PHP or used an MPLS shim header on the last hop of the tunnel.
The Building Core Networks with BGP, OSPF and MPLS (NIL_BCMPL) course focuses on MPLS applications such as MPLS VPN (with special attention to Internet access from a VPN), Any Transport over MPLS (AToM), Carrier Supporting Carrier (CsC) and MPLS Traffic Engineering (MPLS TE). As a prerequisite for MPLS deployment the routing protocols are explained as well - the Open Shortest Path First (OSPF) and Border Gateway Protocol (BGP). The scalability issues of the protocols as well as multiprotocol BGP are addressed as well. Several practice labs enable you to gain the necessary experience in deploying the MPLS-based core networks.
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).
The major problem of MPLS TE is that it's complex and that networking engineers usually lack the hands-on skills, and this is where we can help you: we've just rolled out the revised MPLS TE lab exercises. Compared to remote lab offerings from other sources, these lab exercises are very focused: you get step-by-step instructions (but no recipes, that would spoil the learning process), preconfigured equipment (so you don't have to configure IP addresses or IP routing protocols to get the job done) and detailed solutions explaining which task is achieved using a specific set of configuration commands.
I was able to get a discount for my readers: if you click this link and type in the promotion code 42B078 (expires on January 15th, 2008), you'll get a one week subscription to the MPLS TE remote lab bundle for €56. As this is a subscription offering, you can run the lab exercises as often as you like within a week of the purchasing date. And if you need one more argument to be persuaded, check the lab topology; you can experiment in a preconfigured nine router network :)