Category: MPLS

I wanted to get in-depth details on how various MTU parameters interact in GRE/IPSec/MPLS environment. Before going into router configuration details, I wanted to have a tool that would reliably measure actual path MTU between the endpoints. After a while, Google gave me a usable link: supposedly the tracepath program on Linux does what I needed. As I'm a purely Windows user (for me, PCs are just a tool), I needed a Windows equivalent … and found mturoute, the utility that does exactly what I was looking for.

Most MPLS books (mine included) and courses tell you that you have to manually enable MPLS on each interface where you want to run it with the mpls ip interface configuration command. However, this task was significantly simplified in IOS release 12.3(14)T with the introduction of MPLS LDP autoconfiguration. If you use OSPF as the routing protocol in your network, you can use the mpls autoconfig ldp [area number] router configuration command to enable LDP on all interfaces running OSPF (optionally limited to an OSPF area).

As the careful readers of my MPLS books know, it’s dangerous to run LDP with your customers; the moment you run LDP with them (Carrier’s carrier model is an exception), they can insert any labeled packet into your network, bypassing inbound access lists and sending traffic where it’s not supposed to go (even into another VPN). It’s vital that you consider security implications before deploying MPLS LDP autoconfiguration.

Using this feature on P routers is absolutely safe, as they have no customer links. You have to be more careful on the PE routers, more so if you run routing protocols with your customers. The safest configuration method would be to configure LDP autoconfiguration inside a single OSPF area, but even then, a configuration error (placing a PE-CE interface in a wrong area) could open your network to MPLS-based attacks.

One of the hardest troubleshooting problems within an MPLS VPN network has always been finding a broken LSP. While you could (in theory) use the IP ping or traceroute (assuming all hops support ICMP extensions for MPLS), the results are not always reliable… and interpreting them is not so easy. For example, after I've disabled LDP on an interface with the no mpls ip configuration command, the routers in the LSP path still reported outgoing MPLS labels in ICMP replies for a few seconds (until the LDP holddown timer expired on both ends of the link).

As a side note, would you deduce from the printout that the break in the LSP path happened on the router with the IP address 192.168.201.1?

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.

The MPLS Label Stack Encoding (RFC 3032) specifies two reserved values (among others) that are useful in the last hop of a Label Switched Path (LSP):

• 0: explicit NULL. Can be used in signaling protocols as well as label headers.
• 3: implicit NULL. Used in signaling protocols only. It should never appear in the label stack. Its use in a signaling protocol indicates that the upstream router should perform penultimate hop popping (PHP; remove the top label on the stack).

The implicit NULL should be used whenever possible, as the PHP reduces the amount of lookup required on the last hop of an LSP (sometimes that could mean the difference between hardware and software lookup).

With implicit NULL, the penultimate router performs a simple label lookup, pops the label, and sends an IP packet to the egress router. The egress router performs a simple IP lookup.

When using the implicit NULL, there is no label on the last link in the MPLS network. QoS actions on that link are thus based on the IP packet DSCP value.

With explicit NULL, the penultimate router swaps an MPLS label with a NULL label, and sends a labeled packet to the egress router. The egress router performs an MPLS label lookup and finds a NULL label which triggers another lookup in IP routing table.

Explicit NULL could be used in environments where you want to use MPLS QoS values that are different from IP DSCP/IP Precedence values.

When the egress router signals an explicit NULL, a packet traversing the last link in the MPLS network carries a NULL label, the EXP bits in the label stack are preserved throughout the MPLS network, and the QoS actions performed by the penultimate router can be based on MPLS EXP bits.

By default, Cisco IOS routers advertise implicit NULL with LDP. To change this behavior, use the mpls ldp explicit-null global configuration command.