Additional Troubleshooting Commands
This section introduces additional commands that might be useful in troubleshooting MPLS VPNs.
show ip cef vrf vrf_name detail
The show ip cef [vrf vrf_name] [prefix] detail command can be used to view detailed information about CEF FIB entries.
Example 6-177 shows the VRF mjlnet_VPN CEF FIB entry for prefix 172.16.5.0/24.
Example 6-177 show ip cef vrf vrf_name detail Command Output
Chengdu_PE#show ip cef vrf mjlnet_VPN 172.16.5.0 detail
172.16.5.0/24, version 52, epoch 0, cached adjacency 10.20.10.2
0 packets, 0 bytes
tag information set, all rewrites owned
local tag: VPN route head
fast tag rewrite with Fa1/0, 10.20.10.2, tags imposed {35 16}
via 10.1.1.4, 0 dependencies, recursive
next hop 10.20.10.2, FastEthernet1/0 via 10.1.1.4/32 (Default)
valid cached adjacency
tag rewrite with Fa1/0, 10.20.10.2, tags imposed {35 16}
Chengdu_PE#
Highlighted line 1 shows the prefix itself (172.16.5.0/24), the FIB version, the epoch, and the cached adjacency for next-hop 10.20.10.2.
The epoch indicates the number of times the CEF table has been rebuilt. The epoch number starts at 0 and increments with each rebuild to a maximum of 255, at which point it loops back to 0. The clear ip cef epoch command can be used to rebuild the CEF table. This command can be used if there are inconsistencies in the CEF table.
The next-hop (10.20.10.2) cached adjacency shows that a Layer 2 header has been built and stored in the adjacency table. Note that this next-hop is the resolved (physical Layer 3) next-hop and not necessarily the next-hop of the route shown in the routing table.
Highlighted line 2 shows the next-hop for the prefix. This next-hop is the one stored in the routing table. Because this is a VPN route, this is the BGP update source of the PE router that sent the route.
Finally, highlighted line 3 shows the outgoing interface (Fast Ethernet 1/0), the resolved next-hop, and the labels to be imposed on packets being forwarded to the prefix (destination).
In this case, there is a two-label stack, with an outer IGP label (35), and an inner VPN label (16). Note that CEF is responsible for imposing a label stack on IP packets as they enter the MPLS backbone.
show adjacency detail
You can use the show adjacency detail command to examine the contents of the CEF adjacency table.
Example 6-178 shows the CEF adjacency table for Chengdu_PE.
Example 6-178 show adjacency detail Command Output
Chengdu_PE#show adjacency detail
Protocol Interface Address
IP Serial4/1 point2point(20)
8138 packets, 630040 bytes
FF030021
CEF expires: 00:02:18
refresh: 00:00:18
Epoch: 0
TAG FastEthernet1/0 10.20.10.2(24)
6467 packets, 3867274 bytes
0006535AEFC0
00049BD60C1C8847
TFIB 02:27:03
Epoch: 0
IP FastEthernet1/0 10.20.10.2(68)
0 packets, 0 bytes
0006535AEFC0
00049BD60C1C0800
ARP 02:26:54
Epoch: 0
Chengdu_PE#
Highlighted line 1 shows the adjacency table entry used for label (tag) switching packets out of interface FastEthernet1/0. The IP address of the next-hop is also shown, together with (in brackets) the number of times that this adjacency table entry is referenced by CEF FIB table entries (seen with the show ip cef command).
Highlighted line 2 shows CEF accounting statistics, including the number of packets and bytes switched.
Highlighted lines 3 and 4 show the cached Layer 2 header to be used when label switching out of interface FastEthernet1/0. Note in particular the last four hexadecimal numerals (8847). This is the Ethertype for MPLS.
Highlighted line 5 indicates that source of the adjacency table entry. In this case, CEF is interfacing to the LFIB (shown as TFIB). The time until this entry expires is also shown.
Highlighted line 6 indicates the epoch of the adjacency table (0). In highlighted line 7, the adjacency table entry used for switching IP packets out of interface FastEthernet1/0 is shown.
Note highlighted line 8 and 9. These lines show the cached Layer 2 header used when switching IP packets out of the interface. You will notice that this is the same as that shown in highlighted lines 3 and 4. The one difference is the Ethertype shown in the last four numerals (0800) in highlighted line 9. This number (0800) is the Ethertype for IP.
show mpls ldp parameters
The show mpls ldp parameters command is used to examine LDP parameters as demonstrated in Example 6-179.
Example 6-179 show mpls ldp parameters Command Output
Chengdu_PE#show mpls ldp parameters Protocol version: 1 Downstream label generic region: min label: 16; max label: 100000 Session hold time: 180 sec; keep alive interval: 60 sec Discovery hello: holdtime: 15 sec; interval: 5 sec Discovery targeted hello: holdtime: 90 sec; interval: 10 sec Downstream on Demand max hop count: 255 TDP for targeted sessions LDP initial/maximum backoff: 15/120 sec LDP loop detection: off Chengdu_PE#
Highlighted line 1 shows the LDP version in use. Currently there is only one version. Highlighted line 2 shows the generic label range available for label assignment (16 to 100000). Labels 1 to 15 are reserved.
Label value 0 is "IPv4 Explicit Null," label value 1 is "Router Alert," label value 2 is "IPv6 Explicit Null," and label value 3 is "Implicit Null." Label values 4 to 15 are reserved for future use.
In highlighted line 3, the session holdtime (180 seconds) and keepalive interval (60 seconds) are shown. Note that one session is maintained between LSRs per label space. This means that one session is maintained for all the frame-mode interfaces that connect neighboring LSRs, and another session is maintained per LC-ATM interface that connect LSRs.
Highlighted line 4 shows the discovery holdtime and interval (15 and 5 seconds, respectively). These parameters are used for directly connected neighbors.
Highlighted line 5 shows the discovery parameters for neighbors that are not directly connected (90 seconds for holdtime, and 10 seconds for the hello interval).
Highlighted line 6 shows the maximum hop count for label request messages in a downstream-on-demand environment (255). If an ATM-LSR receives a label request message with this hop count, the message is dropped because it is assumed that the message is looping between adjacent LSRs. This hop count is configurable using the mpls ldp maxhops command.
Highlighted line 7 shows any configured parameters for targeted LDP sessions. Targeted sessions are those between non-directly connected neighbors.
Highlighted line 8 shows the backoff timers (initial and maximum). The backoff mechanism ensures that if two LSRs are configured with incompatible LDP parameters, they will not reattempt session establishment at a constant time interval. Instead, the time interval between session establishment attempts will gradually increase.
Finally, highlighted line 9 shows whether LDP loop detection is enabled.
show mpls atm-ldp capability
The show mpls atm-ldp capability command displays ATM (cell-mode) parameters negotiated during session initialization.
Example 6-180 shows the output of the show mpls atm-ldp capability command.
Example 6-180 show mpls atm-ldp capability Command Output
Chengdu_PE#show mpls atm-ldp capability
VPI VCI Alloc Odd/Even VC Merge
ATM3/0.1 Range Range Scheme Scheme IN OUT
Negotiated [1 - 1] [33 - 1018] UNIDIR - -
Local [1 - 1] [33 - 1018] UNIDIR NO NO
Peer [1 - 1] [33 - 1023] UNIDIR - -
Chengdu_PE#
Highlighted line 2 shows the VPI (1 to 1) and VCI (33 to 1018) ranges used for label switching by the local ATM-LSR. VPI/VCI ranges must overlap between adjacent ATM-LSRs, otherwise the session will not be established. The VPI range can be modified using the mpls atm vpi command.
Highlighted line 2 also shows that the allocation scheme is unidirectional for VCIs with the same VPI value. Highlighted line 2 also shows that VC-merge is not supported in either an inbound or an outbound direction on this ATM interface.
Highlighted line 3 shows the same information for the peer ATM-LSR. In this case, the peer is using the VPI range 1 to 1 and the VCI range 33 to 1023.
The VPI/VCI ranges negotiated between the local and peer ATM-LSRs during session initialization (1 to 1, and 33 to 1018) are shown in highlighted line 1.
show atm vc
The show atm vc command can be used to verify the control VC, together with any Label Virtual Circuits (LVCs) created on LC-ATM interfaces.
Example 6-181 shows the output of the show atm vc command.
Example 6-181 show atm vc Command Output
Chengdu_PE#show atm vc
VCD / Peak Avg/Min Burst
Interface Name VPI VCI Type Encaps SC Kbps Kbps Cells Sts
3/0.1 1 0 32 PVC SNAP UBR 155000 UP
3/0.1 2 1 33 TVC MUX UBR 155000 UP
3/0.1 3 1 34 TVC MUX UBR 155000 UP
3/0.1 4 1 35 TVC MUX UBR 155000 UP
3/0.1 5 1 36 TVC MUX UBR 155000 UP
3/0.1 6 1 37 TVC MUX UBR 155000 UP
Chengdu_PE#
The control VC is shown in highlighted line 1. It uses the default VPI/VCI of 0/32. Note additionally that it uses a SNAP encapsulation.
Highlighted line 2 shows a LVC (shown as a TVC) created on the LC-ATM interface. This LVC uses VPI/VCI 1/33.
Note the four other LVCs created on the interface, each with a unique VPI/VCI. These LVCs use MUX encapsulation because they will carry only MPLS datagrams. The control VC VPI/VCI can be modified using the mpls atm control-vc command. The LVC VPI range can be modified using the mpls atm vpi command.
show ip bgp vpnv4 vrf vrf_name labels
The show ip bgp vpnv4 vrf vrf_name labels command can be used to examine the VPN labels assigned to VRF prefixes.
Example 6-182 shows the output of the show ip bgp vpnv4 vrf vrf_name labels command.
Example 6-182 show ip bgp vpnv4 vrf vrf_name labels Command Output
HongKong_PE#show ip bgp vpnv4 vrf mjlnet_VPN labels Network Next Hop In label/Out label Route Distinguisher: 64512:100 (mjlnet_VPN) 172.16.1.0/24 10.1.1.1 nolabel/26 172.16.2.0/24 10.1.1.1 nolabel/27 172.16.3.0/24 10.1.1.1 nolabel/28 172.16.4.0/24 10.1.1.1 nolabel/29 172.16.4.2/32 10.1.1.1 nolabel/30 172.16.5.0/24 172.16.8.2 26/nolabel 172.16.6.0/24 172.16.8.2 27/nolabel 172.16.7.0/24 172.16.8.2 28/nolabel 172.16.8.0/24 0.0.0.0 29/aggregate(mjlnet_VPN) 172.16.8.2/32 0.0.0.0 30/nolabel HongKong_PE#
Highlighted lines 1 to 5 show the VPN labels assigned to remote VRF prefixes. Highlighted lines 6 to 10 show VPN labels assigned to local customer VPN routes.
debug mpls ldp transport events
The LDP peer discovery mechanism can be monitored using the debug mpls ldp transport events command.
Example 6-183 shows the output of the debug mpls ldp transport events command.
Example 6-183 debug mpls ldp transport events Command Output
Chengdu_PE#debug mpls ldp transport events LDP transport events debugging is on Chengdu_PE# *Jan 22 06:12:22.407 UTC: ldp: enabling ldp on Serial4/0 *Jan 22 06:12:22.407 UTC: ldp: Set intf id: intf 0x61F4BBA4, Serial4/0, not lc-atm, intf_id 0 *Jan 22 06:12:22.407 UTC: ldp: i/f status change: Serial4/0; cur/des flags 0x2/0x2mcast 1 *Jan 22 06:12:22.411 UTC: ldp: Send ldp hello; Serial4/0, src/dst 10.20.10.1/224.0.0.2, inst_id 0 *Jan 22 06:12:26.555 UTC: ldp: Send ldp hello; Serial4/0, src/dst 10.20.10.1/224.0.0.2, inst_id 0 *Jan 22 06:12:26.695 UTC: ldp: Rcvd ldp hello; Serial4/0, from 10.20.10.2 (10.1.1.2:0), intf_id 0, opt 0xC *Jan 22 06:12:26.695 UTC: ldp: ldp Hello from 10.20.10.2 (10.1.1.2:0) to 224.0.0.2, opt 0xC *Jan 22 06:12:26.695 UTC: ldp: New adj 0x622FFB10 for 10.1.1.2:0, Serial4/0 *Jan 22 06:12:26.695 UTC: ldp: adj_addr/xport_addr 10.20.10.2/10.1.1.2 *Jan 22 06:12:26.695 UTC: ldp: local idb = Serial4/0, holdtime = 15000, peer 10.20.10.2 holdtime = 15000 *Jan 22 06:12:26.695 UTC: ldp: Link intvl min cnt = 2, intvl = 5000, idb = Serial4/0 Chengdu_PE#
In highlighted line 1, LDP is enabled on interface serial 4/0. Highlighted line 2 shows that an interface ID has been set for the interface. Note that the interface ID is 0. This indicates that this is not an LC-ATM interface.
In highlighted line 3, the interface status changes, and then in highlighted lines 4 and 5, two LDP neighbor discovery messages are sent. Notice that these messages are sent to the all routers multicast address (224.0.0.2).
In highlighted line 6, a discovery (hello) message is received from the peer LSR. When a discovery message is received on an interface, initiation of a link adjacency is allowed. In highlighted line 7, the receipt of the discovery hello message is reported, and in highlighted lines 8 and 9, the LDP adjacency with the peer is confirmed.
debug mpls ldp messages
The debug mpls ldp messages command shows LDP messages sent and received by the LSR, as demonstrated in the sample output in Example 6-184.
Example 6-184 debug mpls ldp messages Command Output
Chengdu_PE#debug mpls ldp messages sent LDP sent PDUs, excluding periodic Keep Alives debugging is on Chengdu_PE# *Jan 22 06:07:06.079 UTC: ldp: Sent init msg to 10.1.1.2:0 (pp 0x0) *Jan 22 06:07:06.083 UTC: ldp: Sent keepalive msg to 10.1.1.2:0 (pp 0x0) *Jan 22 06:07:06.135 UTC: ldp: Sent address msg to 10.1.1.2:0 (pp 0x622AFBE0) *Jan 22 06:07:06.139 UTC: ldp: Sent label mapping msg to 10.1.1.2:0 (pp 0x622AFBE0) *Jan 22 06:07:06.139 UTC: ldp: Sent label mapping msg to 10.1.1.2:0 (pp 0x622AFB E0) *Jan 22 06:07:06.139 UTC: ldp: Sent label mapping msg to 10.1.1.2:0 (pp 0x622AFB E0) Chengdu_PE#
Highlighted line 1 shows an Initialization message being sent by the local LSR neighboring LSR 10.1.1.2:0. Initialization messages are sent during session establishment and are used to negotiate common parameters such as VPI/VCI range and VC-merge capability.
In highlighted line 2, a keepalive message is sent. This keepalive is used to monitor the underlying LDP session transport connection.
An Address message is sent to LSR 10.1.1.2:0 in highlighted line 3. The Address message is used by an LSR to advertise its interface addresses to a peer.
In highlighted line 4, a Label Mapping message is sent. This is used to advertise a label binding.
debug mpls ldp advertisements
The debug mpls ldp advertisements command is used to monitor address (interface) and label bindings advertisement to peer LSRs.
CAUTION
As with all debug commands, exercise extra caution when using this command because it can produce copious output and impact device performance.
Example 6-185 shows the output of the debug mpls ldp advertisements command.
Example 6-185 debug mpls ldp advertisements Command Output
Chengdu_PE#debug mpls ldp advertisements LDP label and address advertisements debugging is on Chengdu_PE# *Jan 22 06:01:53.347 UTC: tagcon: Assign peer id; 10.1.1.2:0: id 0 *Jan 22 06:01:53.347 UTC: tagcon: peer 10.1.1.2:0 (pp 0x622B0234): advertise 10.1.1.1 *Jan 22 06:01:53.347 UTC: tagcon: peer 10.1.1.2:0 (pp 0x622B0234): advertise 10. 20.10.1 *Jan 22 06:01:53.347 UTC: tagcon: peer 10.1.1.2:0 (pp 0x622B0234): advertise 10. 1.1.1/32, label 3 (imp-null) (#2) *Jan 22 06:01:53.351 UTC: tagcon: peer 10.1.1.2:0 (pp 0x622B0234): advertise 10.20.10.2/32, label 16 (#4) *Jan 22 06:01:53.351 UTC: tagcon: peer 10.1.1.2:0 (pp 0x622B0234): advertise 10.20.10.0/24, label 3 (imp-null) (#6) *Jan 22 06:01:53.351 UTC: tagcon: peer 10.1.1.2:0 (pp 0x622B0234): advertise 10.20.20.2/32, label 17 (#8) Chengdu_PE#
In highlighted line 1, Chengdu_PE advertises an interface address (10.1.1.1) to peer LSR 10.1.1.2:0.
In highlighted line 2, a binding for prefix 10.20.10.2/32 with label 16 is advertised to peer 10.1.1.2:0.
debug mpls ldp bindings
The debug mpls ldp bindings command can be used to examine addresses and bindings received from the peer LSR.
CAUTION
As with all debug commands, exercise extra caution when using this command because it can produce copious output and impact device performance.
Example 6-186 shows the output of the debug mpls ldp binding command.
Example 6-186 debug mpls ldp binding Command Output
Chengdu_PE#debug mpls ldp bindings
LDP Label Information Base (LIB) changes debugging is on
Chengdu_PE#
*Jan 22 06:16:33.571 UTC: tagcon: tibent(10.1.1.0/24): label 23 from 10.1.1.2:0
removed
*Jan 22 06:16:33.571 UTC: tagcon: tibent(10.1.1.1/32): label 21 from 10.1.1.2:0
removed
*Jan 22 06:16:33.571 UTC: tib: Not OK to announce label; nh 10.1.1.1 not bound
to 10.1.1.2:0
*Jan 22 06:16:33.571 UTC: tagcon: Omit route_tag_change for: 10.1.1.1/32
lsr 10.1.1.2:0: connected route
*Jan 22 06:16:33.571 UTC: tagcon: tibent(10.1.1.2/32): label imp-null from
10.1.1.2:0 removed
*Jan 22 06:16:33.571 UTC: tagcon: tibent(10.1.1.3/32): label 20 from 10.1.1.2:0
removed
*Jan 22 06:16:33.571 UTC: tagcon: tibent(10.20.10.0/24): label imp-null from
10.1.1.2:0 removed
*Jan 22 06:16:33.571 UTC: tagcon: tibent(10.20.10.1/32): label 16 from
10.1.1.2:0 removed
Chengdu_PE#
Highlighted lines 1 and 2 show label bindings for prefixes 10.1.1.0/24 and 10.1.1.1/32 being removed from the LIB (shown as TIB).