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 18.104.22.168/32 Sending 5, 100-byte MPLS Echos to 22.214.171.124/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 126.96.36.199/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 188.8.131.52 which has loopback 184.108.40.206/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 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 220.127.116.11/32 Tracing MPLS Label Switched Path to 18.104.22.168/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 22.214.171.124 MRU 1500 [Labels: 207 Exp: 0] L 1 126.96.36.199 MRU 1500 [Labels: 312 Exp: 0] 12 ms L 2 188.8.131.52 MRU 1500 [Labels: 510 Exp: 0] 40 ms L 3 184.108.40.206 MRU 1504 [Labels: implicit-null Exp: 0] 24 ms ! 4 220.127.116.11 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, 18.104.22.168. 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 22.214.171.124—> 126.96.36.199—–>188.8.131.52—–>184.108.40.206.
We will see some downstream mappings to understand it better. Let’s take an example of the 1st echo sent by 220.127.116.11 and check its downstream mapping. Here notice that the router connected to PE1 over Gi2/0 has IP 18.104.22.168 and assigns label 203 to the prefix 22.214.171.124/32. So in the MPLS echo for the Mpls traceroute the sender router will have to include the next-hop it knows to reach 126.96.36.199/32 and the label associated with it. This operation will be done by the responding router as well. Like the next-hop 188.8.131.52 now will respond with the downstream interface IP and label which it has learned from its neighbor to reach 184.108.40.206/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 220.127.116.11 YES NVRAM up up Loopback0 18.104.22.168 YES NVRAM up up Loopback1 192.168.1.1 YES NVRAM up up PE1#show mpls forwarding-table 22.214.171.124 Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or VC or Tunnel Id Switched interface 20 207 126.96.36.199/32 0 Gi2/0 188.8.131.52
Let’s see another downstream mapping, this time from 184.108.40.206 node’s echo reply packet. Here we have two downstream mappings. Which means the router 220.127.116.11 has two paths to reach to 18.104.22.168/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 22.214.171.124/32 Starting LSP Multipath Traceroute for 126.96.36.199/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 188.8.131.52 source 184.108.40.206 destination 127.0.0.1 LL! Path 1 found, output interface Gi2/0 nexthop 220.127.116.11 source 18.104.22.168 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
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.