# LSP Ping

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 <a href="#id-72b23fcb-101b-46d6-89ab-0466d5cce600" id="id-72b23fcb-101b-46d6-89ab-0466d5cce600"></a>

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.

<figure><img src="https://1203572585-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgAMH3CMtmYTBkob03NUj%2Fuploads%2FTBH9Q9iTIrtLPw7Q65ID%2Fimage.png?alt=media&#x26;token=013b3a4e-f415-490a-a599-7de0e9ba74af" alt=""><figcaption></figcaption></figure>

### 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:

<pre><code>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           
<a data-footnote-ref href="#user-content-fn-1">24003    Unlabelled        2.2.2.2/32                       Gi0/0/0/1            10.2.4.2                     101</a>
</code></pre>



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

<figure><img src="https://1203572585-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgAMH3CMtmYTBkob03NUj%2Fuploads%2FMbujznTzuELsHBfF8V0j%2FUntitled%201.png?alt=media&#x26;token=b1ec50fd-541b-4e26-a460-44aa275be8fd" alt=""><figcaption></figcaption></figure>

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

<figure><img src="https://1203572585-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgAMH3CMtmYTBkob03NUj%2Fuploads%2FwWBtHraBveK8T3qQk2sb%2FUntitled%202.png?alt=media&#x26;token=14fbbe0e-740e-490f-884a-5a31e478dc42" alt=""><figcaption></figcaption></figure>

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.

<pre><code>#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    
------ ----------- ------------------ ------------ --------------- ------------
<a data-footnote-ref href="#user-content-fn-2">24000    Unlabelled        1.1.1.1/32                          Gi0/0/0/0            10.3.4.3                     0</a>
</code></pre>



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:

<figure><img src="https://1203572585-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgAMH3CMtmYTBkob03NUj%2Fuploads%2FMfyXcOHRIJSIE9QZK7gT%2FUntitled%203.png?alt=media&#x26;token=e19f350f-eeb0-45ab-9a33-de3d6317ecf7" alt=""><figcaption></figcaption></figure>



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 <a href="#id-98ab73e7-c7ec-44d8-9fe7-6505132d150c" id="id-98ab73e7-c7ec-44d8-9fe7-6505132d150c"></a>

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.



### Further Watching <a href="#id-60356cad-5ee2-4333-9b18-8ff429b97fdd" id="id-60356cad-5ee2-4333-9b18-8ff429b97fdd"></a>

[https://www.youtube.com/watch?v=WZ72zKgw8V8\&ab\_channel=iblacula](https://www.youtube.com/watch?v=WZ72zKgw8V8\&ab_channel=iblacula)

[^1]: This entry is unlabelled because P4 has no LDP session with the nexthop, PE2

[^2]: 1.1.1.1/32 now has an unlabelled entry for the outgoing label, resulting in an inability to label switch return traffic
