With Multiprotocol Label Switching (MPLS) as popular as it is in the provider space and private MPLS clouds for larger enterprise, we needed some tools to help troubleshoot and maintain these networks. With the providers in mind, the normal ping or traceroute may not be enough. In fact, within the provider space, many don’t want their core routers (P routers) visible to the customer when they perform a traceroute (either for security or to reduce the potential for confusion since most providers use private IP addressing internally). Providers today typically disable TTL propagation, which forces the edge router of the MPLS cloud NOT to copy the IP TTL to the MPLS header. This makes it so that the traceroute from the customer will not “see” the intermediate routers in the label switch path (LSP) within the provider’s cloud.
In addition, a standard ping or traceroute won’t really show the provider whether the LSP is working correctly. Since they both use IP addressing as the target, we may assume that the success of the ping or traceroute is due to MPLS and the LSP, but if there is an issue in the LSP and all labels are popped, there is a chance the core routers simply just route the packets normally, without using MPLS. There is no indication as to how the success happened. Other tools are need for the provider to help support their MPLS clouds: MPLS Ping and MPLS Traceroute!
MPLS Ping and Traceroute
The MPLS LSP Ping/Traceroute for LDP and LSP Ping for VCCV feature is well suited for identifying LSP breakages for the following reasons:
- An MPLS echo request packet cannot be forwarded via IP, because IP TTL is set to 1 and the IP destination address field is set to a 127/8 address.
- The FEC being checked is not stored in the IP destination address field (as is the case of ICMP).
MPLS echo request and reply packets test LSPs. There are two methods by which a downstream router can receive packets: the Cisco implementation of MPLS echo request and echo reply that was previously based on the Internet Engineering Task Force (IETF) Internet Draft “Detecting MPLS Data Plane Failures” or based on the IETF RFC 4379 “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures.”
By default, these features are available on the routers running MPLS. The source router will look up the label needed to reach the target. These features are accessed from an MPLS router either by using the ping mpls ipv4 or the traceroute mpls ipv4 commands. Notice in the following examples that the target is a route, not a host address:
R1#ping mpls ipv4 4.4.4.0/24
Sending 5, 100-byte MPLS Echos to 4.4.4.0/24,
timeout is 2 seconds, send interval is 0 msec:
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'l' - Label switched with FEC change, 'd' - see DDMAP for return code,
'X' - unknown return code, 'x' - return code 0
Type escape sequence to abort.
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 740/816/868 ms
Total Time Elapsed 4160 ms
R1#traceroute mpls ipv4 4.4.4.0/24
Tracing MPLS Label Switched Path to 4.4.4.0/24, timeout is 2 seconds
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'l' - Label switched with FEC change, 'd' - see DDMAP for return code,
'X' - unknown return code, 'x' - return code 0
Type escape sequence to abort.
0 10.0.12.1 MRU 1500 [Labels: 16 Exp: 0]
L 1 10.0.12.2 MRU 1500 [Labels: 16 Exp: 0] 348 ms
L 2 10.0.13.3 MRU 1504 [Labels: implicit-null Exp: 0] 360 ms
! 3 10.0.14.4 384 ms
These tools are a basic test to see if the label switch path can actually pass traffic to a given destination, where just simply looking at the routing table (RIB), label table (LIB) or label forwarding information table (LFIB) may not be good enough. For Layer 3 VPN, you could get all the labels you need and all the routes look good, but no traffic flows. The MPLS Ping and MPLS Traceroute can help determine if the path is good and, if it’s not, where the problem may lie.
Related Courses
MPLS — Implementing Cisco MPLS v2.3