MPLS PART6 - TROUBLESHOOTING MPLS

Troubleshooting MPLS

• Is Cisco Express Forwarding (CEF) enabled?

• Is MPLS enabled on all routers?

• Is MPLS disabled on any of the interfaces?

• Is a TDP or an LDP session established between adjacent devices and are labels exchanged between them?

• Are labeled packets propagated across the MPLS network?

Detailed troubleshooting steps

• Is Cisco Express Forwarding (CEF) enabled?

-          Check show ip cef summary

• Is MPLS enabled on all routers?

-          Check show mpls forwarding-table

• Is MPLS disabled on any of the interfaces?

-          Check show mpls interfaces output indicates whether MPLS is configured on an interface

• Is a TDP or an LDP session established between adjacent devices and are labels exchanged between them?

-          Verify Local LDP Parameters

1.       show mpls ldp parameters (for LDP) commands to verify the LDP settings of the local router

-          Verify Correct Operation of TDP/LDP Hello Protocol

1.       show mpls ldp discovery commands to check the correct operation of the LDP hello protocol. These commands display all MPLS-enabled interfaces and the neighbors present on them. The command output also displays only the keyword xmit next to interfaces with no MPLS neighbors

o    A protocol mismatch exists between adjacent LSRs. For example, one of them might support only TDP, whereas the other supports only LDP An access list is blocking incoming UDP packets from adjacent LSRs. Use the show ip interface command to check for the presence of access lists, and use the show access-list command to verify the content of access lists.

o    LSR detects the adjacent LSR but claims that there is no route to the adjacent LSR , output of show mpls ldp discovery shows

Serial0/0.5: xmit/recv

TDP Id: 192.168.3.2:0; no route

LDP sessions run between TDP identifiers

of the adjacent LSRs (usually the IP addresses of the loopback interfaces). These IP addresses need to be reachable from the adjacent LSRs; otherwise, the TCP session cannot be established. To fix this error, inspect your routing protocol configurations and ensure that the IP addresses used for TDP identifiers are announced to adjacent LSRs.

-          Check TDP/LDP Sessions

1.    With the adjacent LSRs successfully exchanging the TDP/LDP hello packets, the LDP session should start immediately.

Verify the state of LDP using command show mpls ldp neighbor

This command displays the details of the TCP connection between the adjacent LSRs, the status of the LDP session (established session is indicated in the State: Oper section of the output), the interfaces through which the adjacent LSR is reachable (displayed in the TDP discovery sources section of the output), and the IP addresses configured on the

adjacent LSR (shown in the Addresses bound to peer TDP Ident section).

The TDP or LDP session between adjacent LSRs might not start after the neighbor is discovered through the TDP or LDP hello protocol for the following two reasons:

• No route exists to the TDP/LDP identifier of the adjacent LSR.

• An incoming access list is blocking TCP packets.

-          Check the Label Exchange

1.    After you verify that the TDP or LDP sessions exist between adjacent LSRs, you need to determine whether the LSRs have assigned labels to the IP prefixes under consideration. To display the Label Information Base (LIB), use the show mpls ldp bindings command.These commands display the labels assigned to a specified IP prefix (or all IP prefixes) by the local LSR and by all the adjacent LSRs

LSRs assign labels to prefixes in only their IP routing table. When your nexthop LSR has not assigned a label to a prefix in your IP routing table, the nexthop LSR might have a different prefix in its IP routing table (for example, because of route summarization).Label distribution is further filtered when an access list is specified with the tag-switching advertise-tag command. If the downstream LSR is using a misconfigured label advertising the access list, the LSR under inspection does not receive a label, although it was assigned (but not distributed) by the downstream LSR

Monitoring End-to-end MPLS Path

One of the most common reasons for end-to-end MPLS connectivity problems is a broken Label Switched Paths (LSP). In many applications, for example, MPLS VPN or BGP running only on-edge routers, an LSP should span the entire MPLS network, from ingress LSR to egress LSR. In these cases, the LSRs in the middle of the network usually cannot propagate unlabeled packets sent from ingress to egress LSR. A break in the LSP, therefore, results in loss of connectivity. A break in an end-to-end LSP commonly occurs for the following two reasons:

• An LSR in the path performs address summarization.

• An IP router in the path does not support MPLS.

To test an end-to-end LSP, perform these steps:

Step 1. Use the mpls ip propagate-ttl local command to enable TTL

propagation for local packets on the ingress LSR. Perform the trace from the ingress LSR toward the egress LSR. You should see all LSRs in the forwarding path with MPLS labels displayed at every hop but the last one

Step 2. Use the no mpls ip propagate-ttl local command to disable the

TTL propagation for local packets on the ingress LSR, and perform the same

trace command. Now, you should see only the last LSR in the forwarding

path

If, however, a device in the forwarding path breaks the LSP (for example,

because of route summarization), the trace command shows more than one

122

hop but probably less than the entire forwarding path (as displayed by the

trace command with TTL propagation enabled). Output indicating a broken

LSP

Oversized Packet Issues

symptom—end-to-end ping works, but the applications

cannot pass any useful data. To test for the presence of this symptom, perform the

extended ping from ingress to egress router with varying packet sizes. If the ping

command displays packet loss with large packet sizes, the LSR probably does not

support full-size IP packets with imposed labels, or a Layer-2 device probably does

not support giant frames in the forwarding path.