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.
Lab
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.
The problem with normal ping and traceroute
Let’s disable LDP on the P4-PE2 link.
#P4
mpls ldp
no int gi0/0/0/1
#PE2
mpls ldp
no int gi0/0/0/1
P4 now has an Unlabelled entry for PE2’s loopback:
RP/0/0/CPU0:P4#show mpls forwarding
Tue Aug 30 18:29:38.685 UTC
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
24000 16 1.1.1.1/32 Gi0/0/0/0 10.3.4.3 40478
24001 Pop 3.3.3.3/32 Gi0/0/0/0 10.3.4.3 36062
24002 Pop 10.1.3.0/24 Gi0/0/0/0 10.3.4.3 0
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.
PE1#ping 2.2.2.2 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 5/7/10 ms
PE1#traceroute 2.2.2.2 source lo0 probe 1
Type escape sequence to abort.
Tracing the route to 2.2.2.2
VRF info: (vrf in name/id, vrf out name/id)
1 10.1.3.3 [MPLS: Label 19 Exp 0] 7 msec
2 10.3.4.4 [MPLS: Label 24003 Exp 0] 6 msec
3 10.2.4.2 7 msec
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.
LSP Ping
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.
#P4, PE2
mpls oam
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):
PE1#ping mpls ?
ipv4 Target specified as an IPv4 address
mldp Multicast LDP
nil-fec Nil FEC with fixed labels and outgoing information
pseudowire Target VC specified as an IPv4 address and VC ID
tp Target specified as Transport Profile tunnel interface
traffic-eng Target (P2P or P2MP) specified as TE tunnel interface
<cr> <cr>
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:
PE1#ping mpls ipv4 2.2.2.2/32 source 1.1.1.1
Sending 5, 72-byte MPLS Echos to 2.2.2.2/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,
'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.
BBBBB
Success rate is 0 percent (0/5)
Total Time Elapsed 56 ms
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:
Echo Request
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
Echo Reply
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:
#P4, PE2
mpls ldp
int Gi0/0/0/1
PE1#ping mpls ipv4 2.2.2.2/32 source 1.1.1.1
Sending 5, 72-byte MPLS Echos to 2.2.2.2/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,
'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 = 7/9/17 ms
Total Time Elapsed 64 ms
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.
#P3
ip access-list standard PE1
deny host 1.1.1.1
permit any
!
ip access-list standard NEIGHBORS
permit any
!
mpls ldp advertise-labels for PE1 to NEIGHBORS
no mpls ldp advertise-labels
#P4
RP/0/0/CPU0:P4#show mpls forwarding
Tue Aug 30 19:10:01.939 UTC
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
An LSP ping from PE2 to PE1 will not work:
RP/0/0/CPU0:PE2#ping mpls ipv4 1.1.1.1/32 source 2.2.2.2
Tue Aug 30 19:10:49.077 UTC
Sending 5, 100-byte MPLS Echos to 1.1.1.1/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 rx label,
'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.
BBBBB
Success rate is 0 percent (0/5)
However, the LSP ping in the reverse direction, from PE1 to PE2 works. This is because the MPLS Echo Reply can be IP forwarded.
PE1#ping mpls ipv4 2.2.2.2/32 source 1.1.1.1
Sending 5, 72-byte MPLS Echos to 2.2.2.2/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,
'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 = 7/8/10 ms
Total Time Elapsed 57 ms
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:
#P3
mpls ldp advertise-labels
no mpls ldp advertise-labels for PE1 to NEIGHBORS
Confirm that the LSP ping from PE2 to PE1 works again:
RP/0/0/CPU0:PE2#ping mpls ipv4 1.1.1.1/32 source 2.2.2.2
Tue Aug 30 19:13:46.275 UTC
Sending 5, 100-byte MPLS Echos to 1.1.1.1/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 rx label,
'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 = 1/8/10 ms
Conclusion
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.
