MPLS ping returns 'Q' - request not sent.

[jkeeffe]

What would cause the code 'Q' when doing an MPLS ping?

I'm doing a pilot project in our enterprise, using mBGP and MPLS, to segment/isolate a small portion of our network.  All seems to be working well, except that I get intermittant pings in the vrf.  Even when the pings do work, I can't get an MPLS ping to work.  Here are the outputs of both ping and mpls ping:

SRC-RT3845-MDF#ping vrf VRF-test 10.40.5.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.40.5.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

SRC-RT3845-MDF#ping mpls ipv4 10.40.5.1 255.255.255.255
Sending 5, 100-byte MPLS Echos to 10.40.5.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 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.
QQQQQ
Success rate is 0 percent (0/5)
SRC-RT3845-MDF#

Also, here is the output of traceroute:

SRC-RT3845-MDF#trace vrf VRF-test 10.40.5.1           

Type escape sequence to abort.

Tracing the route to 10.40.5.1

VRF info: (vrf in name/id, vrf out name/id)

  1 10.40.1.14 [MPLS: Label 806 Exp 0] 0 msec

    10.40.1.6 [MPLS: Label 806 Exp 0] 0 msec

    10.40.1.14 [MPLS: Label 806 Exp 0] 4 msec

  2 10.40.1.5 4 msec *  0 msec

SRC-RT3845-MDF# SRC-RT3845-MDF#

I don't know if there is a broken LSP, but I was hoping the the mpls ping would help.

What would cause the 'Q' when doing the MPLS ping?

[Harold Ritter · Accepted solution]

Hi,

The command "ping mpls ipv4" is used to test the LSP tail-end reachability. The destination ipv4 address you use should be reachable via the global routint table (GRT) rather than through a VRF. In your case, the destination address is not reachable via the GRT, hence the Q being seen in the ping command.

Here's an excerpt from the Cisco IOS documentation:

Determining Why a Packet Could Not Be Sent

The Q return code means that the packet could not be sent. The problem  can be caused by insufficient processing memory, but it probably results  because an LSP could not be found that matches the FEC information that  was entered on the command line.

You need to determine the reason why the packet was not forwarded so  that you can fix the problem in the path of the LSP. To do so, look at  the Routing Information Base (RIB), the Forwarding Information Base  (FIB), the Label Information Base (LIB), and the MPLS LFIB. If there is  no entry for the FEC in any of these routing or forwarding bases, there  is a Q return code.

http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/ht_lspng.html

Regards

[Mohammed Imran Khan · Accepted solution]

Hi,

Just adding to Harold's response, this is what I see:

SRC-RT3845-MDF#ping mpls ipv4 10.40.5.1 255.255.255.255

SRC-RT3845-MDF#ping vrf VRF-test 10.40.5.1  >>>

Both, LSP far end IP and vrf IP is same???? The IP that should be used in the LSP should be the remote end loopback IP. As per my understanding, this should not ping.

Regards,

Imran

[Harold Ritter · Accepted solution]

Mohammed,

From what I understand, it is not that the LSP tail-end ip address and the VRF ip address are the same but rather that the original poster is trying to use the MPLS ping against the VRF ip address when he should be using the remote PE ip address.

Regards