MPLS ping is a utility just like our old ipv4 ping in the hop to hop ip routing scenarios. The only difference is that it tells you that everything is fine in MPLS label switch path. In mpls label switch path you cannot rely on normal ping as it is possible that normal ping is working but still the label switch path(LSP) is broken. To identify if the LSP path, as well as the underlying IP path is fine we can use the MPLS ping. Below is an example of a successful MPLS ping.
For this blog I am going to use following topology and the red highlighted path is the MPLS path that I am focusing.
PE1#ping mpls ipv4 8.8.8.8/32
Sending 5, 100-byte MPLS Echos to 8.8.8.8/32,
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,
'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 = 76/80/84 ms
PE1#
Keep in mind that it should be performed from the router where MPLS is enabled, if there is no MPLS configured on the router the output will look like following.
CE1#ping mpls ipv4 8.8.8.8/32 % MPLS forwarding or IP CEF is not enabled on this router CE1#
Wireshark Capture and explanation.
Now let’s see how MPLS ping looks on the wire. The whole notion of ping works on echo request and reply theory and comes from SONAR world so wherever you see ping you should expect that there will be echo and reply in the communication. Likewise in MPLS as well we have MPLS echo requests and MPLS echo replies. See captures below…
Notice that we are sending MPLS ping to IP 127.0.0.1 which is not a routable IP range. Now it may confuse some but if you think about it, this seems very obvious. We do not need any routable IP here as we do not want the packet to be forwarded after it reaches the last hop. Apart from this the IP header also has TTL of 1 which means it certainly not going anywhere once the MPLS label is removed. The MPLS ping is sent with UDP transport header with the source and destination port as 3503.
This is MPLS Echo request
This is MPLS Echo reply
Notice the red square in the below packet, this is called the sender’s handle. with “Sender’s handle” you can filter all the MPLS ping packets for a particular flow. Here is the Wireshark filter for that : mpls_echo.sender_handle == 0x7d9f7512
Here we are seeing a response is coming from router 50.50.50.2 which has loopback 8.8.8.8/32 we are pinging MPLSsly(:D).
Here is something noteworthy, try to find out the MPLS header in the echo-response packet. MPLS echo-response is directly sent to the requester with TTL 255 in the IP header. It will have MPLS label echo-response header but it will not be sent over LSP path, just plain IP routed path.
MPLS Traceroute:
MPLS traceroute is a very intelligently implemented tool to find issues in the MPLS path. Like a normal traceroute it relies on the hop by hop polling with the TTL of 1. Only in this case as this is MPLS network hence the TTL for the MPLS header will be 1. MPLS tracerote uses the same range of 127.0.0.0 IP addresses which means here also if we strip out the MPLS label then the packet will not be routable based on the destination IP address, also like the MPLS ping here the IP header will have the TTL 1. MPLS Traceroute like MPLS ping will be sent with UDP header with the source and destination port as 3503. The major difference between the MPLS trace and ping is downstream mapping information. Following is how MPLS trace looks like.
PE1#traceroute mpls ipv4 8.8.8.8/32 Tracing MPLS Label Switched Path to 8.8.8.8/32, 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, 'X' - unknown return code, 'x' - return code 0 Type escape sequence to abort. 0 20.20.20.1 MRU 1500 [Labels: 207 Exp: 0] L 1 20.20.20.2 MRU 1500 [Labels: 312 Exp: 0] 12 ms L 2 30.30.30.2 MRU 1500 [Labels: 510 Exp: 0] 40 ms L 3 40.40.40.2 MRU 1504 [Labels: implicit-null Exp: 0] 24 ms ! 4 50.50.50.2 64 ms
Downstream Mapping : This information is embedded into the MPLS label echo header and it keeps the information about the interface, label, and multipath information over which the IP we are tracing is reachable, in this case, 8.8.8.8. Multipath, is explained in the next section of this blog. This downstream information helps the sender to identify the subsequent nodes to send the packet. For example, in the below capture you can see that the trace is responded by 20.20.20.2—> 30.30.30.2—–>40.40.40.2—–>50.50.50.2.
We will see some downstream mappings to understand it better. Let’s take an example of the 1st echo sent by 20.20.20.1 and check its downstream mapping. Here notice that the router connected to PE1 over Gi2/0 has IP 20.20.20.2 and assigns label 203 to the prefix 8.8.8.8/32. So in the MPLS echo for the Mpls traceroute the sender router will have to include the next-hop it knows to reach 8.8.8.8/32 and the label associated with it. This operation will be done by the responding router as well. Like the next-hop 20.20.20.2 now will respond with the downstream interface IP and label which it has learned from its neighbor to reach 8.8.8.8/32. So now with this info, the originator node will know about the next-to-next hop where it needs to send the packet. I try to explain with an analogy, suppose StudentA gets a book from StudentB to read and likes it, now StudentA wants to buy this book so he asks StudentB to sell it to him. StudentB says that it is not mine to sell, I borrowed it from StudentC why dont you check with StudentC. Here StudentA is going hop by hop but the information to jump to hops is provided by StudentB(telling to go to StudentC). Just like this it happens in MPLS traceroute. Next hop tells me about the further next hop with the help of downstream mapping.
PE1#sh ip int bri | ex una Interface IP-Address OK? Method Status Protocol GigabitEthernet1/0 10.10.10.2 YES NVRAM up up GigabitEthernet2/0 20.20.20.1 YES NVRAM up up Loopback0 2.2.2.2 YES NVRAM up up Loopback1 192.168.1.1 YES NVRAM up up PE1#show mpls forwarding-table 8.8.8.8 Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or VC or Tunnel Id Switched interface 20 207 8.8.8.8/32 0 Gi2/0 20.20.20.2
Let’s see another downstream mapping, this time from 20.20.20.2 node’s echo reply packet. Here we have two downstream mappings. Which means the router 20.20.20.2 has two paths to reach to 8.8.8.8/32 .
How to know ECMP paths (Multipath) with MPLS Trace.
With the help of MPLS trace, you can also find out all the equal-cost Mpls path (lsp) to reach a particular prefix. Below is how we can do it. In the below example we can see two MPLS paths discovered and both are responding correctly.
PE1#traceroute mpls multipath ipv4 8.8.8.8/32 Starting LSP Multipath Traceroute for 8.8.8.8/32 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, 'X' - unknown return code, 'x' - return code 0 Type escape sequence to abort. LLL! Path 0 found, output interface Gi2/0 nexthop 20.20.20.2 source 20.20.20.1 destination 127.0.0.1 LL! Path 1 found, output interface Gi2/0 nexthop 20.20.20.2 source 20.20.20.1 destination 127.0.0.0 Paths (found/broken/unexplored) (2/0/0) Echo Request (sent/fail) (7/0) Echo Reply (received/timeout) (7/0) Total Time Elapsed 356 ms
Conclusion :
MPLS Ping and traceroute is probably the first thing you should check when troubleshooting MPLS. In most of the cases if the problem is MPLS related then it will be the quickest tool to guide you through the solution. There are other options available in mpls ping and trace which gives us a great deal of information about the path like you can check the behavior for dscp tagged packet, you can also see verbose information for the traceroute. I recommend exploring the MPLS ping and traceroute command more.
Following is the the complete set of packet capture that you can explore. It has MPLS ping, MPLS trace, MPLS trace with Multipath.
