LSP Ping
Last updated
Last updated
Before we explore LSP ping, also called MPLS ping, we will first briefly examine the drawbacks of regular ICMP ping. Then we will see how LSP ping improves on the shortcomings with ICMP ping in an MPLS network. LSP ping uses its own protocol, not ICMP, although the concept of Ping request and Ping responses is similar.
We’ll re-use our topology from the previous article. The startup configs are the same. I have re-enabled IP to MPLS TTL propagation on the PEs.
Let’s disable LDP on the P4-PE2 link.
P4 now has an Unlabelled entry for PE2’s loopback:
If we try to ping from PE1 to PE2, the path from PE1 through P4 is label switched, but P4 must deliver the packets unlabelled to PE2. The problem with regular ping is that there is no way to determine whether or not the LSP is broken, because the routers can fallback to IP forwarding.
Additionally, we cannot tell from the traceroute whether P4 simply popped the label, or whether P4 had to deliver the packet to PE2 unlabelled because LDP is broken.
Let’s first run an LSP ping and then examine it in wireshark to understand how it works. In order to run an LSP ping, or “mpls ping,” we must turn on mpls oam. LSP ping uses its own UDP port, so routers must have mpls oam configured in order to generate and process LSP ping messages. This is already on by default on IOS-XE, so we’ll configure this on the XR routers.
To run an LSP ping, we need to understand one major difference between the LSP ping and ICMP ping. ICMP ping uses an ip destination address. LSP ping, in contrast, uses a FEC. This can be an IP prefix (address/mask), a pseudowire, or you can use no FEC but specify your own label stack (nil-fec):
This means that even if you want to run an LSP ping on a /32, you still need to specify the mask. This is because the LSP ping needs to match a FEC, not a specific IP. Let’s run the LSP ping for 2.2.2.2/32 on PE1:
LSP ping sends out 5 requests, similar to ICMP ping. We can see that the pings did not succeed. We got back a ‘B’ which indicates an unlabeled output interface. However this doesn’t tell us which router along the path has an unlabeled output interface.
First we’ll examine the LSP pings by capturing on the PE1-P3 link:
Layer 3 details:
The destination address is 127.0.0.1. This ensures that the LSP ping cannot fallback on IP routing like ICMP ping can.
The TTL is set to 1, further ensuring the IP packet cannot be routed.
The Router Alert option is set, to ensure the local router processes the packet in software.
Layer 4 details:
The source and destination port is well-known UDP port 3503, which is reserved for LSP ping
Layer 2.5 details:
The message type is MPLS Echo Request
The MPLS TTL is set to 255
The reply mode is “via an IPv4/IPv6 UDP packet” which tells the egress LSR to return a normal IP packet as a reply, instead of an LPS ping. This means that the LSP ping is unidirectional only, as the return traffic can fallback on IP forwarding.
The target FEC stack shows 2.2.2.2/32
There is a timestack field to calculate RTT
The LSP Reply is sourced from P4, because as we know, it has an Unlabeled entry for 2.2.2.2/32 pointing to PE2. It cannot deliver it to PE2, because if it tries to IP forward the packet, the destination is 127.0.0.1 which points to P4 itself.
Let’s bring LDP back up between P4 and PE2 and test the LSP ping again:
The ping now succeeds. To prove that the return traffic is IP routed instead of being an LSP ping, let’s filter the advertisement of label 1.1.1.1/32 from P3 to P4. This is also good practice for LDP conditional advertising.
An LSP ping from PE2 to PE1 will not work:
However, the LSP ping in the reverse direction, from PE1 to PE2 works. This is because the MPLS Echo Reply can be IP forwarded.
Here is a packet capture at the P3-P4 link. The Echo replies have no MPLS label:
Let’s remove the LDP conditional advertisement on P3:
Confirm that the LSP ping from PE2 to PE1 works again:
LSP ping is a verification tool that improves upon ICMP ping for testing LSPs. LSRs can fallback on IP forwarding ICMP packets, meaning that if an ICMP ping succeeds in an MPLS network, you can never know if the LSP is broken or not.
LSP ping uses the style of ICMP ping, but with more options to tailor it to testing MPLS LSPs. The LSP ping uses 127.0.0.1 in the destination to prevent it from being IP forwarded. The LSP ping has several different return codes to assist with troubleshooting. In the lab above, we saw B which indicated that an LSR had an unlabeled entry for the interface it must deliver the packet out. Additionally, we saw that the LSP ping is unidirectional only, as the return traffic is by default a normal IPv4 packet and can fallback on IP forwarding.
The problem with LSP ping was that we did not see which router along the path generated the error code. In the next article, we will explore LSP Traceroute.
https://www.youtube.com/watch?v=WZ72zKgw8V8&ab_channel=iblacula
