Brocade Multi-Service IronWare Multiprotocol Label Switch (MPLS) Configuration Guide (Supporting R05.6.00) - Manual (Page 230)

206 Multi-Service IronWare Multiprotocol Label Switch (MPLS) Configuration Guide
53-1003031-02
IP Traceroute over MPLS
1
Traceroute in an MPLS-enabled network
The standard traceroute implementation is insufficient for diagnosing Layer 3 routing problems in
an MPLS environment, such as a provider network configured to tunnel a customer’s Virtual Private
Network (VPN) traffic through a public backbone.
Standard traceroute relies on IP forwarding based on routing table lookup. It requires that the IP
addresses of the source and the destination are transparent to the transit Label Switch Routers
(LSRs) so they can route ICMP error responses back to the source. When traffic is tunneled through
an MPLS domain, IP addresses outside the MPLS domain may not be available to provider transit
nodes. In a typical Layer 3 VPN, only the Provider Edge (PE) routers have IP routes to Customer
Edge (CE) devices and can use IP addresses to send traffic to and from the MPLS domain. Once a
packet enters the MPLS domain, transit LSRs must rely on label information to move traffic along
pre-configured Label-Switched Paths (LSPs).
Because of its dependence on IP routing protocols, the user cannot use the standard traceroute
command to troubleshoot and identify problems within an MPLS domain, such as a faulty LSP.
Enhanced traceroute using ICMP label extensions
To troubleshoot MPLS-based routing problems, the user can configure traceroute to use LSP
forwarding when sending ICMP packets through an MPLS domain and to report MPLS label
information. The user controls the traceroute configuration with the ip icmp mpls-response
command.
The IP traceroute over MPLS enhancement implements extensions to ICMP error control messages
as described in RFC 4884 and RFC 4950. The basic idea is to allow the label stack of an expired IP
packet to be appended to the ICMP ttl-exceeded message that is generated when a router drops a
traceroute packet due to TTL expiration. Recall that for any transit LSR, the source and destination
IP addresses embedded in the IP packet header may have no meaning, and the LSR may find itself
in a situation where it is unable to route the ICMP message back to the source.
When the user configures traceroute to use ICMP message extensions, an LSR copies the label
stack that encapsulated the original datagram when it arrived at the LSR to the ICMP ttl-exceeded
message generated by that LSR when it drops a packet due to TTL expiration. Before discarding an
expired packet, the LSR strips the label stack from the datagram and attaches it to the ICMP
message. The extended message contains the label stack—an inner VPN label identifying the
outgoing VRF interface and an outer label that specifies the next hop, each one with its embedded
TTL value—plus the IP addresses of the packet source and destination (embedded in the IP header
attached to the ICMP message).
With the label stack of the discarded datagram appended to the ICMP message, the forwarding
LSR has two options, depending on the MPLS response configuration:
• When a Layer 3 VPN is used to tunnel customer traffic through the MPLS domain, the transit
LSRs have no knowledge of the source and destination IP addresses of the traceroute probe.
In this case, the user has the option to configure the LSRs so they route the ICMP messages in
the direction of the traceroute destination and back to the source using label switching along
predetermined LSPs.
• When IP forwarding is enabled in the MPLS core, the user can configure the LSRs to use IP
forwarding to route the ICMP ttl-exceeded messages back to the source. The enhanced
traceroute command offers the added benefit of reporting MPLS label stack information for
each hop along with the traceroute output in addition to the IP source addresses of the transit
LSRs.