07-30-2013 01:20 PM
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?
Solved! Go to Solution.
07-30-2013 02:30 PM
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:
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
07-30-2013 03:54 PM
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
07-30-2013 04:58 PM
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
07-30-2013 02:30 PM
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:
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
07-30-2013 03:54 PM
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
07-30-2013 04:58 PM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide