|
|
Troubleshooting AToMThe AToM troubleshooting process consists of troubleshooting the PE to PE router tunnel label switch path (LSP) and the exchange of VC labels between the peer PE routers. The flowchart in Figure 7-13 describes the troubleshooting process used with AToM. You can use this flowchart to quickly access the section of the chapter relevant to problems you are experiencing on your network. Figure 7-13. AToM Troubleshooting Flowchart The reference topology shown in Figure 7-14 is used throughout this section. In Figure 7-14, three virtual circuits (pseudowires) are carried over the MPLS backbone between London_PE and Paris_PE:
Note that the LDP ID on each of the P and PE routers shown in Figure 7-14 corresponds to the IP addresses configured on their respective loopback 0 interfaces. The sections that follow cover troubleshooting of both the tunnel LSPs and VC label exchange between PE routers. Verifying and Troubleshooting the Tunnel LSPIf the tunnel LSP between peer PE routers is not operational, one of the following reasons might be to blame:
Use an extended ping to test IP connectivity between the loopback interfaces (LDP IDs) on peer PE routers. If the ping does not succeed, begin regular IP troubleshooting. The other issues in the preceding list are discussed in the sections that follow. When troubleshooting the tunnel LSP, the first step is to locate the issue. Locating the Tunnel LSP IssueOne command that is very useful in locating a tunnel LSP issue is traceroute, which can be used to display the label stack hop-by-hop across the MPLS backbone from PE router to PE router. In Example 7-28, the LSP is traced from London_PE to Paris_PE (interface loopback 0). Example 7-28. Tracing the LSP from PE Router to PE RouterLondon_PE#traceroute 172.16.1.4 Type escape sequence to abort. Tracing the route to 172.16.1.4 1 172.16.2.2 [MPLS: Label 22 Exp 0] 92 msec 92 msec 88 msec 2 172.16.3.2 [MPLS: Label 17 Exp 0] 80 msec 76 msec 76 msec 3 172.16.4.2 32 msec 28 msec * London_PE# In highlighted line 1, London_PE imposes tunnel label 22 on the packet and forwards it to next-hop router 172.16.2.2 (London_P). In highlighted line 2, London_P swaps tunnel label 22 for label 17 and forwards the packet to next-hop router 172.16.3.2 (Paris_P). Finally, in highlighted line 3, Paris_P pops the tunnel label and forwards the packet to router 172.16.4.2 (Paris_PE). If the command no mpls ip propagate-ttl is configured on the PE routers, the MPLS backbone is represented as one hop. Use the mpls ip propagate-ttl local command to allow TTL to be propagated in traceroute on PE routers. If traceroute is not successful from PE router to PE router, you should begin regular IP troubleshooting. If no label stack or only a partial label stack is displayed when using traceroute, you should verify CEF, MPLS, and LDP operation. CEF, MPLS, and LDP must be correctly configured and operational on all routers in the path from PE router to PE router for the tunnel LSP to be established. The sections that follow examine CEF, MPLS, and LDP. Note that if you are using IOS 12.0(27)S or above, you can use the ping mpls and trace mpls MPLS Embedded Management feature commands to verify tunnel LSP connectivity and trace tunnel LSPs respectively. You can also use the ping mpls command to verify AToM pseudowires between peer PE routers Verifying and Troubleshooting CEFIf CEF is not enabled, label switching will not operate. Use the show ip cef command to verify that CEF is globally enabled, as shown in Example 7-29. Example 7-29. CEF Is DisabledLondon_P#show ip cef %CEF not running Prefix Next Hop Interface London_P# As you can see, CEF is disabled on London_P. CEF is then enabled on London_P using the ip cef [distributed] command, as shown in Example 7-30. Note that the distributed keyword can be used to enable distributed CEF (dCEF) on high-end platforms, such as the 7500 and 12000 series. Example 7-30. CEF Is Enabled on London_PLondon_P#conf t Enter configuration commands, one per line. End with CNTL/Z. London_P(config)#ip cef London_P(config)#exit London_P# CEF is then verified again using the show ip cef command, as shown in Example 7-31. Example 7-31. CEF Is Enabled
London_P#show ip cef
Prefix Next Hop Interface
0.0.0.0/0 drop Null0 (default route handler entry)
0.0.0.0/32 receive
172.16.1.1/32 172.16.2.1 FastEthernet0/0
172.16.1.2/32 receive
172.16.1.3/32 172.16.3.2 Serial1/0
172.16.1.4/32 172.16.3.2 Serial1/0
172.16.2.0/24 attached FastEthernet0/0
172.16.2.0/32 receive
172.16.2.1/32 172.16.2.1 FastEthernet0/0
172.16.2.2/32 receive
172.16.2.255/32 receive
172.16.3.0/24 attached Serial1/0
172.16.3.0/32 receive
172.16.3.1/32 receive
172.16.3.2/32 attached Serial1/0
172.16.3.255/32 receive
172.16.4.0/24 172.16.3.2 Serial1/0
172.16.4.1/32 172.16.3.2 Serial1/0
172.16.4.2/32 172.16.3.2 Serial1/0
224.0.0.0/4 drop
224.0.0.0/24 receive
255.255.255.255/32 receive
London_P#
CEF is now enabled, and the show ip cef command displays a summary of the CEF forwarding information base (FIB). Verifying and Troubleshooting MPLSMPLS must be enabled globally and on core interfaces of PE and P routers. If it is not enabled, label switching will not function. The following two sections discuss how to verify whether MPLS is disabled globally or on an interface. MPLS Has Been Globally DisabledLabel switching will not function on any interface if MPLS has been globally disabled. Use the show mpls interfaces or show mpls forwarding-table commands to verify that MPLS is enabled. Example 7-32 shows the output of the show mpls interfaces command. Example 7-32. MPLS Is Globally DisabledLondon_PE#show mpls interfaces IP MPLS forwarding is globally disabled on this router. Individual interface configuration is as follows: Interface IP Tunnel Operational London_PE# As you can see, MPLS has been globally disabled on London_PE. Example 7-33 shows the output of the show mpls forwarding-table command. Example 7-33. MPLS Has Been Disabled and an LFIB Has Not Been AllocatedLondon_PE#show mpls forwarding-table Tag switching is not operational. CEF or tag switching has not been enabled. No TFIB currently allocated. London_PE# In Example 7-33, you can see that MPLS has been disabled, and no Label Forwarding Information Base (LFIB, shown as TFIB) has been allocated. Use the mpls ip command to globally re-enable MPLS, as shown in Example 7-34. Example 7-34. Globally Enabling MPLS on the RouterLondon_PE#conf t Enter configuration commands, one per line. End with CNTL/Z. London_PE(config)#mpls ip London_PE(config)#end London_PE# In Example 7-34, MPLS is re-enabled using the mpls ip command. MPLS Is Disabled on an InterfaceIf MPLS is disabled on a core interface, MPLS will not function on that interface. Use the show mpls interfaces command to verify that MPLS is enabled on an interface, as shown in Example 7-35. Example 7-35. MPLS Is Disabled on Core Interfaces
London_PE#show mpls interfaces
Interface IP Tunnel Operational
London_PE#
As you can see, MPLS is not enabled on any interfaces on London_PE. In fact, it should be enabled on core interface fast Ethernet 2/0. Use the mpls ip command to enable MPLS on core interfaces as shown in Example 7-36. Example 7-36. Enabling MPLS on Core InterfacesLondon_PE#conf t Enter configuration commands, one per line. End with CNTL/Z. London_PE(config)#interface fastethernet 2/0 London_PE(config-if)#mpls ip London_PE(config-if)#exit London_PE# In Example 7-36, MPLS is enabled on core interface Fast Ethernet 2/0. The show mpls interfaces command is then used to verify that MPLS is operational on the core interfaces, as demonstrated in Example 7-37. Example 7-37. MPLS Is Enabled on Core InterfacesLondon_PE#show mpls interfaces Interface IP Tunnel Operational FastEthernet2/0 Yes (ldp) No Yes London_PE# As you can see, MPLS is now enabled on core interface fast Ethernet 2/0. Troubleshooting LDP for Tunnel LSP EstablishmentLDP is used between adjacent LSRs in the path between the PE routers to exchange tunnel label bindings. If LDP discovery or session establishment fails, label bindings will not be exchanged, and label switching will not function. The sections that follow discuss issues with LDP discovery, session establishment, and advertisement of label bindings. LDP Neighbor Discovery Fails Between Directly Connected LSRsAs previously mentioned, if LDP neighbor discovery fails, session establishment will not take place, and label bindings will not be exchanged. Figure 7-15 illustrates the LDP neighbor discovery process between directly connected peers in the MPLS backbone. Figure 7-15. LDP Discovery Between Directly Connected Peers Use the show mpls ldp discovery command to verify successful LDP discovery, as shown in Example 7-38. Example 7-38. Successful LDP DiscoveryLondon_PE#show mpls ldp discovery Local LDP Identifier: 172.16.1.1:0 Discovery Sources: Interfaces: FastEthernet2/0 (ldp): xmit/recv LDP Id: 172.16.1.2:0 Targeted Hellos: 172.16.1.1 -> 172.16.1.4 (ldp): active, xmit/recv LDP Id: 172.16.1.4:0 London_PE# Highlighted line 1 shows the local LDP ID (172.16.1.1:0). In highlighted line 2, you can see that you can see that LDP packets are being transmitted (xmit) and received (recv) on core interface fast Ethernet 2/0. LDP discovery between directly connected LSRs can fail for a number of reasons, including the following:
The sections that follow examine these issues in more detail. Label Protocol MismatchIf label protocols are mismatched between peer LSRs, neighbor discovery will fail. Use the show mpls ldp discovery command to verify neighbor discovery between peer LSRs, as shown in Example 7-39. Example 7-39. LDP Neighbor Discovery FailsLondon_PE#show mpls ldp discovery Local LDP Identifier: 172.16.1.1:0 Discovery Sources: Interfaces: FastEthernet2/0 (ldp): xmit Targeted Hellos: 172.16.1.1 -> 172.16.1.4 (ldp): active, xmit/recv LDP Id: 172.16.1.4:0 London_PE# As you can see, London_PE is transmitting (xmit) but not receiving (recv) LDP hello messages on interface fast Ethernet 2/0. This may indicate a label distribution protocol mismatch with the peer LSR. Use the show mpls interfaces command to verify the label protocol used on the peer LSR (London_P), as demonstrated in Example 7-40. Example 7-40. Verifying the Label ProtocolLondon_P#show mpls interfaces Interface IP Tunnel Operational FastEthernet0/0 Yes (tdp) No Yes Serial1/0 Yes (ldp) No Yes London_P# The highlighted line indicates that TDP is configured on interface fast Ethernet 0/0, which is connected to London_PE. This clearly indicates a label protocol mismatch. The label protocol is then configured as LDP on interface fast Ethernet 0/0 using the mpls label protocol ldp command, as shown in Example 7-41. Example 7-41. LDP Is Configured on Interface Fast Ethernet 0/0London_P#conf t Enter configuration commands, one per line. End with CNTL/Z. London_P(config)#interface fastethernet 0/0 London_P(config-if)#mpls label protocol ldp London_P(config-if)#exit London_PE# Once the label protocol has been modified, LDP neighbor discovery is verified again using the show mpls ldp discovery command, as demonstrated in Example 7-42. Example 7-42. LDP Neighbor Discovery SucceedsLondon_PE#show mpls ldp discovery Local LDP Identifier: 172.16.1.1:0 Discovery Sources: Interfaces: FastEthernet2/0 (ldp): xmit/recv LDP Id: 172.16.1.2:0 Targeted Hellos: 172.16.1.1 -> 172.16.1.4 (ldp): active, xmit/recv LDP Id: 172.16.1.4:0 London_PE# Highlighted line 1 shows that LDP hello messages are now being both transmitted (xmit) and received (recv) on interface fast Ethernet 2/0. In highlighted line 2, you can see that the LDP ID of the peer LSR (London_P) is 172.16.1.2:0. Access List Blocks LDP DiscoveryLDP discovery between directly connected neighbors uses UDP port 646 and all routers multicast address 224.0.0.2. Ensure that neither UDP port 646 nor multicast address 224.0.0.2 is blocked by an access list. Similarly, LDP discovery between non-directly connected neighbors (PE routers) uses UDP port 646 and unicast communication between LDP router IDs (loopback IP addresses). Remember that PE routers must perform LDP discovery and establish an LDP session before exchanging VC labels. Ensure that unicast communication on UDP port 646 between PE router LDP ID addresses is not blocked by an access list. Use the show mpls ldp discovery command to verify LDP discovery, as shown in Example 7-43. Example 7-43. LDP Discovery FailsLondon_PE#show mpls ldp discovery Local LDP Identifier: 172.16.1.1:0 Discovery Sources: Interfaces: FastEthernet2/0 (ldp): xmit Targeted Hellos: 172.16.1.1 -> 172.16.1.4 (ldp): active, xmit London_PE# In highlighted line 1, you can see that London_PE is transmitting (xmit) but not receiving hello messages on interface Fast Ethernet 2/0 from the directly connected LSR London_P. Highlighted line 2 shows that London_PE is also transmitting (xmit) but not receiving (recv) targeted hello messages from peer PE router Paris_PE. This may be because of the presence of an access list. Verify the presence of an access list using the show ip interface [interface_name] command. This is shown in Example 7-44. Example 7-44. Verifying the Presence of an Access ListLondon_PE#show ip interface fastethernet 2/0 FastEthernet2/0 is up, line protocol is up Internet address is 172.16.2.1/24 Broadcast address is 255.255.255.255 Address determined by non-volatile memory MTU is 1500 bytes Helper address is not set Directed broadcast forwarding is disabled Multicast reserved groups joined: 224.0.0.2 Outgoing access list is not set Inbound access list is 101 Proxy ARP is disabled Security level is default Split horizon is enabled As you can see, access list 101 is configured in an inbound direction on interface fast Ethernet 2/0. The composition of the access list is then examined using the show ip access-lists command, as shown in Example 7-45. Example 7-45. Verifying the Contents of an Access List
London_PE#show ip access-lists 101
Extended IP access list 101
permit tcp any any eq www
permit tcp any any eq telnet
permit tcp any any eq ftp
permit tcp any any eq ftp-data
permit udp any any eq tftp
permit udp any any eq ntp
permit udp any any eq snmp
permit udp any any eq snmptrap
London_PE#
As you can see, access list 101 does not explicitly permit UDP port 646, and so it is blocked by the implicit deny any at the end of the access list. In this case, it is decided that access list 101 is not required, so it is removed, as shown in Example 7-46. Example 7-46. Access List 101 Is Removed from Interface Fast Ethernet 2/0London_PE#conf t Enter configuration commands, one per line. End with CNTL/Z. London_PE(config)#interface fastethernet 2/0 London_PE(config-if)#no ip access-group 101 in London_PE(config-if)#end London_PE# Once access list 101 has been removed, LDP discovery succeeds. This is verified using the show mpls ldp discovery command, as shown in Example 7-47. Example 7-47. LDP Discovery SucceedsLondon_PE#show mpls ldp discovery Local LDP Identifier: 172.16.1.1:0 Discovery Sources: Interfaces: FastEthernet2/0 (ldp): xmit/recv LDP Id: 172.16.1.2:0 Targeted Hellos: 172.16.1.1 -> 172.16.1.4 (ldp): active, xmit/recv LDP Id: 172.16.1.4:0 London_PE# Highlighted line 1 shows that LDP hello messages are now being transmitted (xmit) and received (recv) on interface fast Ethernet 2/0. Highlighted line 2 shows the LDP ID of the peer LSR (172.16.1.2:0, London_P). In highlighted line 3, you can see that targeted hello messages are now being transmitted (xmit) and received (recv) to and from Paris_PE. The LDP ID of Paris_PE (172.16.1.4:0) is shown in highlighted line 4. Control VC Is Mismatched Between LDP PeersIf the control VC is mismatched on LC-ATM interfaces between peer LSRs, LDP discovery will fail. Use the show mpls ldp discovery command to verify LDP discovery, as shown in Example 7-48. Example 7-48. LDP Discovery FailsLondon_PE#show mpls ldp discovery Local LDP Identifier: 172.16.1.1:0 Discovery Sources: Interfaces: ATM3/0.1 (ldp): xmit Targeted Hellos: 172.16.1.1 -> 172.16.1.4 (ldp): active, xmit/recv LDP Id: 172.16.1.4:0; no route London_PE# The highlighted line indicates that LDP hello messages are being transmitted (xmit) but not received (recv) on interface ATM 3/0.1. This may indicate that there is a control VC mismatch. Use the show mpls interfaces atm interface detail command to verify the control VC, as shown in Example 7-49. Example 7-49. Verifying the Control VC on London_PELondon_PE#show mpls interfaces atm 3/0.1 detail Interface ATM3/0.1: IP labeling enabled (ldp) LSP Tunnel labeling not enabled BGP labeling not enabled MPLS not operational Optimum Switching Vectors: IP to MPLS Turbo Vector MPLS Turbo Vector Fast Switching Vectors: IP to MPLS Fast Switching Vector MPLS Turbo Vector MTU = 4470 ATM labels: Label VPI = 1, Control VC = 0/32 London_PE# As you can see, the control VC on interface atm 3/0.1 on London_PE uses VPI/VCI 0/32 (the default). The control VC is then verified on London_P, as shown in Example 7-50. Example 7-50. Verifying the Control VC on London_PLondon_P#show mpls interfaces atm 2/0.1 detail Interface ATM2/0.1: IP labeling enabled (ldp) LSP Tunnel labeling not enabled BGP labeling not enabled MPLS not operational Optimum Switching Vectors: IP to MPLS Turbo Vector MPLS Turbo Vector Fast Switching Vectors: IP to MPLS Fast Switching Vector MPLS Turbo Vector MTU = 4470 ATM labels: Label VPI = 1, Control VC = 0/55 London_P# The highlighted line indicates that the control VC on interface atm 2/0.1 on London_P is 0/55 (VPI/VCI). Clearly, there is a mismatch between London_PE and London_P. The control VC must then be modified on either London_PE or London_P so that there is no longer a mismatch. In Example 7-51, the control VC is modified on London_P so that it is the same as that on the connected interface on London_PE (interface atm 2/0.1). Example 7-51. Control VC Is Modified on London_PLondon_P#conf t Enter configuration commands, one per line. End with CNTL/Z. London_P(config)#interface atm 2/0.1 London_P(config-subif)#mpls atm control-vc 0 32 London_P(config-subif)#end London_P# In Example 7-51, the control VC is modified so that it is 0/32 (VPI/VCI) on interface atm 2/0.1 on London_P. LDP discovery now succeeds between London_PE and London_P. This is verified using the show mpls ldp discovery command, as shown in Example 7-52. Example 7-52. LDP Discovery SucceedsLondon_PE#show mpls ldp discovery Local LDP Identifier: 172.16.1.1:0 Discovery Sources: Interfaces: ATM3/0.1 (ldp): xmit/recv LDP Id: 172.16.1.2:1; IP addr: 172.16.7.2 Targeted Hellos: 172.16.1.1 -> 172.16.1.4 (ldp): active, xmit London_PE# In highlighted line 1, you can see that LDP hello messages are now being transmitted (xmit) and received (recv) on interface atm 3/0.1. Highlighted line 2 shows the LDP ID of London_P (172.16.2.1:1), as well as the IP address on interface atm 2/0.1 on London_P. LDP Session Establishment Fails Between Directly Connected LSRsIf LDP session establishment fails between directly connected LSRs, tunnel label bindings will not be exchanged. Figure 7-16 illustrates LDP sessions between directly connected LSRs on the path between the PE routers. Figure 7-16. LDP Sessions Between Directly Connected LSRs Use the show mpls ldp neighbor command to verify LDP session establishment, as shown in Example 7-53. Example 7-53. LDP Session Establishment Succeeds Between Directly Connected NeighborsLondon_PE#show mpls ldp neighbor Peer LDP Ident: 172.16.1.2:0; Local LDP Ident 172.16.1.1:0 TCP connection: 172.16.1.2.11052 - 172.16.1.1.646 State: Oper; Msgs sent/rcvd: 199/196; Downstream Up time: 02:41:28 LDP discovery sources: FastEthernet2/0, Src IP addr: 172.16.2.2 Addresses bound to peer LDP Ident: 172.16.1.2 172.16.3.1 172.16.2.2 Peer LDP Ident: 172.16.1.4:0; Local LDP Ident 172.16.1.1:0 TCP connection: 172.16.1.4.11056 - 172.16.1.1.646 State: Oper; Msgs sent/rcvd: 200/196; Downstream Up time: 02:41:29 LDP discovery sources: Targeted Hello 172.16.1.1 -> 172.16.1.4, active Addresses bound to peer LDP Ident: 172.16.1.4 172.16.4.2 London_PE# In highlighted line 1, you can see the peer and local LDP IDs (172.16.1.2:0 and 172.16.1.1:0, respectively). Highlighted line 2 shows that peer and local LSRs have opened TCP ports 11052 and 646 for LDP session establishment. Highlighted line 3 shows that the session state is operational (established), the number of messages sent and received (199 and 196), and the method of label distribution (unsolicited downstream). The local interface (Fast Ethernet 2/0) and peer LSR (source) IP address used for LDP discovery are shown in highlighted line 4. The peer LSR's interface IP addresses are shown in highlighted line 5. LDP session establishment between directly connected neighbors can fail for a number of reasons, including the following:
These issues are examined in the following few sections. Peer LDP ID Is UnreachableIf the peer's LDP ID is unreachable, session establishment will fail. Use the show mpls ldp discovery command to troubleshoot this issue, as shown in Example 7-54. Example 7-54. Peer's LDP ID Is UnreachableLondon_PE#show mpls ldp discovery Local LDP Identifier: 172.16.1.1:0 Discovery Sources: Interfaces: FastEthernet2/0 (ldp): xmit/recv LDP Id: 172.16.1.2:0; no route Targeted Hellos: 172.16.1.1 -> 172.16.1.4 (ldp): active, xmit/recv LDP Id: 172.16.1.4:0 London_PE# The highlighted line shows that London_PE does not have a route to peer (LDP ID) 172.16.1.2. This is confirmed using the show ip route command, as shown in Example 7-55. Example 7-55. London_PE Has No Route to Peer 172.16.1.2London_PE#show ip route 172.16.1.2 % Subnet not in table London_PE# As you can see, there is definitely no route to peer (LDP ID) 172.16.1.2. When the configuration of the peer router is examined using the show running-config command, the problem is revealed. Example 7-56 shows the configuration of the peer router. Example 7-56. Configuration of London_PLondon_P#show running-config Building configuration... ! tag-switching tdp router-id Loopback0 force ! ! interface Loopback0 ip address 172.16.1.2 255.255.255.255 no ip directed-broadcast ! ! router isis net 49.0001.0000.0000.0002.00 is-type level-2-only metric-style wide ! In highlighted line 1, the command tag-switching tdp router-id (mpls ldp router-id) is used to configure the LDP router ID. The LDP router ID itself is shown in highlighted line 2 (172.16.1.2). Finally, the configuration of the IGP (in this example, IS-IS) is shown in highlighted line 3. The problem is that interface loopback 0 (the LDP ID) is not enabled for IS-IS. Interface loopback 0 is then enabled for IS-IS using the passive-interface interface_name command, as shown in Example 7-57. Some versions of IOS also require you to configure the ip router isis command on the loopback interface in addition to specifying the passive interface command. Example 7-57. Enabling the Loopback Interface for IS-ISLondon_P#conf t Enter configuration commands, one per line. End with CNTL/Z. London_P(config)#router isis London_P(config-router)#passive-interface loopback0 London_P(config-router)#end London_P# Once the loopback interface has been enabled for IS-IS, LDP session establishment is successful. This is verified using the show mpls ldp neighbor command, as shown in Example 7-58. Example 7-58. LDP Session Establishment SucceedsLondon_PE#show mpls ldp neighbor Peer LDP Ident: 172.16.1.4:0; Local LDP Ident 172.16.1.1:0 TCP connection: 172.16.1.4.11056 - 172.16.1.1.646 State: Oper; Msgs sent/rcvd: 223/218; Downstream Up time: 02:58:30 LDP discovery sources: Targeted Hello 172.16.1.1 -> 172.16.1.4, active Addresses bound to peer LDP Ident: 172.16.1.4 172.16.4.2 Peer LDP Ident: 172.16.1.2:0; Local LDP Ident 172.16.1.1:0 TCP connection: 172.16.1.2.11058 - 172.16.1.1.646 State: Oper; Msgs sent/rcvd: 17/16; Downstream Up time: 00:02:50 LDP discovery sources: FastEthernet2/0, Src IP addr: 172.16.2.2 Addresses bound to peer LDP Ident: 172.16.1.2 172.16.3.1 172.16.2.2 London_PE# Highlighted line 1 shows the peer and local LDP IDs (172.16.1.2:0 and 172.16.1.1:0, respectively). In highlighted line 2, you can see that the session state is operational (established). In highlighted line 3, you can see that the session has been established for 2 minutes and 50 seconds. Access List Blocks LDP Session EstablishmentLDP sessions are established between peer LSRs over a unicast connection on TCP port 646. The unicast connection is between the peer LSRs' LDP ID addresses. Ensure that an access list is not blocking either TCP port 646 or the LDP ID addresses. When configuring an access list on an LSR, consider that the passive peer (the peer with the lower LDP ID) opens TCP port 646, and the active peer (the peer with the higher LDP ID) opens an ephemeral port for LDP session establishment. Use the show ip interface [interface_name] command to verify the presence of an access list, as shown in Example 7-59. Example 7-59. Verifying the Presence of an Access ListLondon_PE#show ip interface fastethernet 2/0 FastEthernet2/0 is up, line protocol is up Internet address is 172.16.2.1/24 Broadcast address is 255.255.255.255 Address determined by non-volatile memory MTU is 1500 bytes Helper address is not set Directed broadcast forwarding is disabled Multicast reserved groups joined: 224.0.0.2 Outgoing access list is not set Inbound access list is 101 Proxy ARP is disabled Security level is default Split horizon is enabled As you can see, access list 101 is configured in an inbound direction on interface fast Ethernet 2/0. The contents of the access list are then verified using the show ip access-lists command, as demonstrated in Example 7-60. Example 7-60. Verifying the Contents of the Access List
London_PE#show ip access-lists 101
Extended IP access list 101
permit tcp any any eq ftp
permit tcp any any eq ftp-data
permit tcp any any eq telnet
permit tcp any any eq www
permit tcp any any eq smtp
permit udp any any eq tftp
permit udp any any eq ntp
permit udp any any eq snmp
permit udp any any eq snmptrap
London_PE#
As you can see, TCP port 646 is not explicitly permitted and is, therefore, blocked by the implicit deny any at the end of the access list. Because London_PE is the passive peer (in this example), LDP session establishment fails. Access list 101 is unnecessary in this case and is removed, as shown in Example 7-61. Example 7-61. Access List Is Removed from the InterfaceLondon_PE#conf t Enter configuration commands, one per line. End with CNTL/Z. London_PE(config)#interface fastethernet 2/0 London_PE(config-if)#no ip access-group 101 in London_PE(config-if)#end London_PE# Once the access list has been removed, LDP session establishment is successful. This is verified using the show mpls ldp neighbor command, as shown in Example 7-62. Example 7-62. LDP Session Establishment Is SuccessfulLondon_PE#show mpls ldp neighbor Peer LDP Ident: 172.16.1.4:0; Local LDP Ident 172.16.1.1:0 TCP connection: 172.16.1.4.11170 - 172.16.1.1.646 State: Oper; Msgs sent/rcvd: 16/15; Downstream Up time: 00:00:49 LDP discovery sources: Targeted Hello 172.16.1.1 -> 172.16.1.4, active Addresses bound to peer LDP Ident: 172.16.1.4 172.16.4.2 Peer LDP Ident: 172.16.1.2:0; Local LDP Ident 172.16.1.1:0 TCP connection: 172.16.1.2.11173 - 172.16.1.1.646 State: Oper; Msgs sent/rcvd: 14/14; Downstream Up time: 00:00:47 LDP discovery sources: FastEthernet2/0, Src IP addr: 172.16.2.2 Addresses bound to peer LDP Ident: 172.16.1.2 172.16.3.1 172.16.2.2 London_PE# Highlighted lines 1 to 4 show that LDP session establishment has now been successful with peers 172.16.1.4 (peer PE router, Paris_PE) and 172.16.1.2 (directly connected LSR, London_P). LDP Authentication FailureIf there is a TCP MD5 authentication password mismatch between peer LSRs, or one peer is configured for authentication but the other is not, session establishment will fail. In this example, there is an authentication password mismatch between peer LSRs. The message shown in Example 7-63 is logged. Example 7-63. Authentication Password Mismatch
*Apr 18 17:43:38.335 UTC: %TCP-6-BADAUTH: Invalid MD5 digest from 172.16.1.2
(11187) to 172.16.1.1(646)
The authentication password is reconfigured on the peer LSRs, as shown in Example 7-64. Example 7-64. Reconfiguration of Authentication Password on Peer LSRsLondon_PE#conf t Enter configuration commands, one per line. End with CNTL/Z. London_PE(config)#mpls ldp neighbor 172.16.1.2 password mjlnet London_PE(config)#end London_PE# ________________________________________________________________ London_P#conf t Enter configuration commands, one per line. End with CNTL/Z. London_P(config)#mpls ldp neighbor 172.16.1.1 password mjlnet London_P(config)#end London_P# After the authentication password has been reconfigured, LDP session establishment is successful, as shown in Example 7-65. Example 7-65. LDP Session Is SuccessfulLondon_PE#show mpls ldp neighbor Peer LDP Ident: 172.16.1.4:0; Local LDP Ident 172.16.1.1:0 TCP connection: 172.16.1.4.11172 - 172.16.1.1.646 State: Oper; Msgs sent/rcvd: 32/30; Downstream Up time: 00:14:47 LDP discovery sources: Targeted Hello 172.16.1.1 -> 172.16.1.4, active Addresses bound to peer LDP Ident: 172.16.1.4 172.16.4.2 Peer LDP Ident: 172.16.1.2:0; Local LDP Ident 172.16.1.1:0 TCP connection: 172.16.1.2.11193 - 172.16.1.1.646 State: Oper; Msgs sent/rcvd: 14/13; Downstream Up time: 00:00:08 LDP discovery sources: FastEthernet2/0, Src IP addr: 172.16.2.2 Addresses bound to peer LDP Ident: 172.16.1.2 172.16.3.1 172.16.2.2 London_PE# Highlighted line 1 shows the peer and local LDP IDs (172.16.1.2:0 and 172.16.1.1:0, respectively). In highlighted line 2, you can see that the session state is operational (established). Note that if the local peer has been configured with authentication, but the remote peer has not, the message shown in Example 7-66 is logged. Example 7-66. Remote Peer Is Not Configured with LDP Authentication.
*Apr 20 20:54:24.027 UTC: %TCP-6-BADAUTH: No MD5 digest from 172.16.1.4(11004) to
172.16.1.1(646)
To resolve this issue, authentication should be configured on the peer LSR. VPI Ranges Do Not Overlap Between Peers' LC-ATM InterfacesDuring LDP session initialization, various parameters are negotiated between peers. If the peers are connected via LC-ATM interfaces, VPI/VCI ranges used for label switching are negotiated. If there is no overlap between the VPI ranges configured for label switching on peer LSRs, session initialization will fail, and the message shown in Example 7-67 is logged. Example 7-67. VPI Ranges Do Not Overlap*Apr 18 18:29:33.399 UTC: %TDP-3-TAGATM_BAD_RANGE: Interface ATM3/0.1, Bad VPI range. Can't start a TDP session You can obtain more information using the debug mpls atm-ldp api command, as shown in Example 7-68. Example 7-68. Peer VPI RangesLondon_PE#debug mpls atm-ldp api LC-ATM API debugging is on London_PE# *Apr 18 18:35:30.923 UTC: TAGATM_API: Disjoint VPI local[1-1], peer[3-6] London_PE# The highlighted line indicates that the local LSR is configured to use VPI range 1-1 (the default), and the remote (peer) LSR is configured to use VPI range 36. The VPI range on one of the LSRs must be configured to overlap with the other. In this example, the VPI range on London_P is reconfigured to overlap with the range on London_PE, as shown in Example 7-69. Example 7-69. VPI Range Is ReconfiguredLondon_P#conf t Enter configuration commands, one per line. End with CNTL/Z. London_P(config)#interface atm 2/0.1 London_P(config-subif)#no mpls atm vpi 3-6 London_P(config-subif)#end London_P# In the highlighted line, the VPI range 36 is removed. This resets the VPI range to the default range (11). Once the VPI range has been reconfigured on London_P, session establishment succeeds, as confirmed in Example 7-70. Example 7-70. LDP Session Establishment SucceedsLondon_PE#show mpls ldp neighbor Peer LDP Ident: 172.16.1.4:0; Local LDP Ident 172.16.1.1:0 TCP connection: 172.16.1.4.11175 - 172.16.1.1.646 State: Oper; Msgs sent/rcvd: 47/41; Downstream Up time: 00:19:31 LDP discovery sources: Targeted Hello 172.16.1.1 -> 172.16.1.4, active Addresses bound to peer LDP Ident: 172.16.1.4 172.16.4.2 Peer LDP Ident: 172.16.1.2:1; Local LDP Ident 172.16.1.1:1 TCP connection: 172.16.7.2.11211 - 172.16.7.1.646 State: Oper; Msgs sent/rcvd: 12/12; Downstream on demand Up time: 00:00:09 LDP discovery sources: ATM3/0.1, Src IP addr: 172.16.7.2 London_PE# Highlighted line 1 shows the peer and local LDP IDs (172.16.1.2:1 and 172.16.1.1:1, respectively). In highlighted line 2, you can see that the LDP session is operational (established). Tunnel Label Bindings Are Not AdvertisedIf label bindings are not advertised for the tunnel LSP, label switching across the MPLS backbone will fail. Use the show mpls ldp bindings command to verify the advertisement of label bindings, as shown in Example 7-71. This command displays the contents of the Label Information Base (LIB). Example 7-71. Verifying Label Bindings for the Tunnel LSPLondon_PE#show mpls ldp bindings tib entry: 172.16.1.1/32, rev 4 local binding: tag: imp-null remote binding: tsr: 172.16.1.2:0, tag: 16 remote binding: tsr: 172.16.1.4:0, tag: 24 tib entry: 172.16.1.2/32, rev 6 local binding: tag: 18 remote binding: tsr: 172.16.1.2:0, tag: imp-null remote binding: tsr: 172.16.1.4:0, tag: 23 tib entry: 172.16.1.3/32, rev 18 local binding: tag: 24 remote binding: tsr: 172.16.1.2:0, tag: 20 remote binding: tsr: 172.16.1.4:0, tag: 19 tib entry: 172.16.1.4/32, rev 22 local binding: tag: 26 remote binding: tsr: 172.16.1.4:0, tag: imp-null remote binding: tsr: 172.16.1.2:0, tag: 22 tib entry: 172.16.2.0/24, rev 2 local binding: tag: imp-null remote binding: tsr: 172.16.1.2:0, tag: imp-null remote binding: tsr: 172.16.1.4:0, tag: 22 tib entry: 172.16.3.0/24, rev 10 local binding: tag: 20 remote binding: tsr: 172.16.1.2:0, tag: imp-null remote binding: tsr: 172.16.1.4:0, tag: 20 tib entry: 172.16.3.1/32, rev 16 local binding: tag: 23 remote binding: tsr: 172.16.1.4:0, tag: 18 tib entry: 172.16.3.2/32, rev 9 local binding: tag: 19 remote binding: tsr: 172.16.1.2:0, tag: 17 remote binding: tsr: 172.16.1.4:0, tag: 21 tib entry: 172.16.4.0/24, rev 12 local binding: tag: 21 remote binding: tsr: 172.16.1.2:0, tag: 18 remote binding: tsr: 172.16.1.4:0, tag: imp-null tib entry: 172.16.4.1/32, rev 20 local binding: tag: 25 remote binding: tsr: 172.16.1.4:0, tag: 16 remote binding: tsr: 172.16.1.2:0, tag: 21 tib entry: 172.16.4.2/32, rev 14 local binding: tag: 22 remote binding: tsr: 172.16.1.2:0, tag: 19 London_PE# As you can see, label bindings are being received from LSRs 172.16.1.2:0 (London_P) and 172.16.1.4:0 (Paris_PE). Note, in particular, the entry for 172.16.1.4/32 (highlighted line 1). The label advertised by London_P for this entry is 22. This label corresponds to the egress PE router's (Paris_PE in this example) LDP ID, and it is the tunnel label used by London_PE to forward AToM Layer 2 PDUs across the MPLS backbone. Label bindings that correspond to the best IGP routes can also be seen in the Label Forwarding Information Base (LFIB). The contents of the LFIB can be examined using the show mpls forwarding-table command, as shown in Example 7-72. Example 7-72. Examining the LFIBLondon_PE#show mpls forwarding-table Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 16 Untagged l2ckt(121) 71416 Fa1/0.1 point2point 18 Pop tag 172.16.1.2/32 0 Fa2/0 172.16.2.2 19 17 172.16.3.2/32 0 Fa2/0 172.16.2.2 20 Pop tag 172.16.3.0/24 0 Fa2/0 172.16.2.2 21 18 172.16.4.0/24 0 Fa2/0 172.16.2.2 22 19 172.16.4.2/32 0 Fa2/0 172.16.2.2 23 Untagged 172.16.3.1/32 0 Fa2/0 172.16.2.2 24 20 172.16.1.3/32 0 Fa2/0 172.16.2.2 25 21 172.16.4.1/32 0 Fa2/0 172.16.2.2 26 22 172.16.1.4/32 0 Fa2/0 172.16.2.2 27 Untagged l2ckt(123) 132 Se4/0 point2point 30 Untagged l2ckt(124) 6775 Se4/1 point2point London_PE# As you can see, the LFIB contains both the locally assigned and outgoing (advertised by the peer LSR) labels for each prefix, as well as local VC labels. Also shown are the number of bytes switched, together with the outgoing interface and next-hop associated with the LFIB entry. In the highlighted line, you can see that the outgoing label for entry 172.16.1.4/32 is again 22, the number of bytes switched is 0, and the outgoing interface and next-hop are fast Ethernet 2/0 and 172.16.2.2 (Paris_P), respectively. Advertisement of tunnel label bindings can fail for a number of reasons, including the following:
The sections that follow discuss these issues in greater detail. Peer LSR Is Configured Not to Advertise Label BindingsIf no label bindings are being received from the peer LSR, this might indicate that the peer is configured not to advertise label bindings. Use the show mpls ldp bindings command to verify advertisement of label bindings from the peer LSR, as shown in Example 7-73. Example 7-73. Label Bindings Are Not Advertised by the Peer LSRLondon_PE#show mpls ldp bindings tib entry: 172.16.1.1/32, rev 4 local binding: tag: imp-null remote binding: tsr: 172.16.1.4:0, tag: 24 tib entry: 172.16.1.2/32, rev 6 local binding: tag: 18 remote binding: tsr: 172.16.1.4:0, tag: 23 tib entry: 172.16.1.3/32, rev 18 local binding: tag: 24 remote binding: tsr: 172.16.1.4:0, tag: 19 tib entry: 172.16.1.4/32, rev 22 local binding: tag: 26 remote binding: tsr: 172.16.1.4:0, tag: imp-null tib entry: 172.16.2.0/24, rev 2 local binding: tag: imp-null remote binding: tsr: 172.16.1.4:0, tag: 22 tib entry: 172.16.3.0/24, rev 10 local binding: tag: 20 remote binding: tsr: 172.16.1.4:0, tag: 20 tib entry: 172.16.3.1/32, rev 16 local binding: tag: 23 remote binding: tsr: 172.16.1.4:0, tag: 18 tib entry: 172.16.3.2/32, rev 9 local binding: tag: 19 remote binding: tsr: 172.16.1.4:0, tag: 21 tib entry: 172.16.4.0/24, rev 12 local binding: tag: 21 remote binding: tsr: 172.16.1.4:0, tag: imp-null tib entry: 172.16.4.1/32, rev 20 local binding: tag: 25 remote binding: tsr: 172.16.1.4:0, tag: 16 tib entry: 172.16.4.2/32, rev 14 local binding: tag: 22 London_PE# Highlighted line 1 shows the entry for 172.16.1.4/32. The local and remote (from peer 172.16.1.4:0, Paris_PE) bindings for this prefix are shown in highlighted lines 2 and 3. One thing is missing, however. There is no remote binding for peer 172.16.1.2:0 (London_P). If you examine all the other entries in the LIB, you notice that there are no bindings from London_P. When the configuration of London_P is examined using the show running-config command, the problem is revealed. This is shown in Example 7-74. Note that only the relevant portion of the output is shown. Example 7-74. Configuration of London_PLondon_P#show running-config Building configuration... ! no tag-switching advertise-tags tag-switching tdp router-id Loopback0 force ! The highlighted line shows that the command no mpls ldp advertise-labels command (shown as no tag-switching advertise-tags) is configured on London_P. This is preventing London_P from advertising any labels to London_PE or other peer LSRs. Label bindings advertisement is then enabled using the mpls ldp advertise-labels command, as shown in Example 7-75. Example 7-75. Label Bindings Advertisement Is EnabledLondon_P#conf t Enter configuration commands, one per line. End with CNTL/Z. London_P(config)#mpls ldp advertise-labels London_P(config)#end London_P# Label bindings are now received on London_PE. This is verified using the show mpls ldp bindings command, as shown in Example 7-76. Example 7-76. Label Bindings Are Received from London_PLondon_PE#show mpls ldp bindings tib entry: 172.16.1.1/32, rev 4 local binding: tag: imp-null remote binding: tsr: 172.16.1.4:0, tag: 24 remote binding: tsr: 172.16.1.2:0, tag: 16 tib entry: 172.16.1.2/32, rev 6 local binding: tag: 18 remote binding: tsr: 172.16.1.4:0, tag: 23 remote binding: tsr: 172.16.1.2:0, tag: imp-null tib entry: 172.16.1.3/32, rev 18 local binding: tag: 24 remote binding: tsr: 172.16.1.4:0, tag: 19 remote binding: tsr: 172.16.1.2:0, tag: 20 tib entry: 172.16.1.4/32, rev 22 local binding: tag: 26 remote binding: tsr: 172.16.1.4:0, tag: imp-null remote binding: tsr: 172.16.1.2:0, tag: 22 tib entry: 172.16.2.0/24, rev 2 local binding: tag: imp-null remote binding: tsr: 172.16.1.4:0, tag: 22 remote binding: tsr: 172.16.1.2:0, tag: imp-null tib entry: 172.16.3.0/24, rev 10 local binding: tag: 20 remote binding: tsr: 172.16.1.4:0, tag: 20 remote binding: tsr: 172.16.1.2:0, tag: imp-null tib entry: 172.16.3.1/32, rev 16 local binding: tag: 23 remote binding: tsr: 172.16.1.4:0, tag: 18 tib entry: 172.16.3.2/32, rev 9 local binding: tag: 19 remote binding: tsr: 172.16.1.4:0, tag: 21 remote binding: tsr: 172.16.1.2:0, tag: 17 tib entry: 172.16.4.0/24, rev 12 local binding: tag: 21 remote binding: tsr: 172.16.1.4:0, tag: imp-null remote binding: tsr: 172.16.1.2:0, tag: 18 tib entry: 172.16.4.1/32, rev 20 local binding: tag: 25 remote binding: tsr: 172.16.1.4:0, tag: 16 remote binding: tsr: 172.16.1.2:0, tag: 21 tib entry: 172.16.4.2/32, rev 14 local binding: tag: 22 remote binding: tsr: 172.16.1.2:0, tag: 19 London_PE# As you can see in highlighted lines 1 and 2, a label binding for prefix 172.16.1.4/32 has now been received from London_P (172.16.1.2:0). Conditional Label Advertisement Blocks Label BindingsIf conditional label advertisement is configured on a peer LSR, then some, but not all, label bindings may be received. Use the show mpls ldp bindings command to verify label bindings received from peer LSRs, as demonstrated in Example 7-77. Example 7-77. Not All Label Bindings Are Received from London_PLondon_PE#show mpls ldp bindings tib entry: 172.16.1.1/32, rev 4 local binding: tag: imp-null remote binding: tsr: 172.16.1.4:0, tag: 24 remote binding: tsr: 172.16.1.2:0, tag: 22 tib entry: 172.16.1.2/32, rev 10 local binding: tag: 22 remote binding: tsr: 172.16.1.4:0, tag: 23 remote binding: tsr: 172.16.1.2:0, tag: imp-null tib entry: 172.16.1.3/32, rev 18 local binding: tag: 26 remote binding: tsr: 172.16.1.4:0, tag: 19 remote binding: tsr: 172.16.1.2:0, tag: 19 tib entry: 172.16.1.4/32, rev 22 local binding: tag: 28 remote binding: tsr: 172.16.1.4:0, tag: imp-null tib entry: 172.16.2.0/24, rev 2 local binding: tag: imp-null remote binding: tsr: 172.16.1.4:0, tag: 22 remote binding: tsr: 172.16.1.2:0, tag: imp-null tib entry: 172.16.3.0/24, rev 8 local binding: tag: 21 remote binding: tsr: 172.16.1.4:0, tag: 20 remote binding: tsr: 172.16.1.2:0, tag: imp-null tib entry: 172.16.3.1/32, rev 16 local binding: tag: 25 remote binding: tsr: 172.16.1.4:0, tag: 18 tib entry: 172.16.3.2/32, rev 6 local binding: tag: 20 remote binding: tsr: 172.16.1.4:0, tag: 21 remote binding: tsr: 172.16.1.2:0, tag: 16 tib entry: 172.16.4.0/24, rev 12 local binding: tag: 23 remote binding: tsr: 172.16.1.4:0, tag: imp-null remote binding: tsr: 172.16.1.2:0, tag: 17 tib entry: 172.16.4.1/32, rev 20 local binding: tag: 27 remote binding: tsr: 172.16.1.4:0, tag: 16 remote binding: tsr: 172.16.1.2:0, tag: 20 tib entry: 172.16.4.2/32, rev 14 local binding: tag: 24 remote binding: tsr: 172.16.1.2:0, tag: 18 London_PE# Highlighted line 1 shows the LIB entry for prefix 172.16.1.4/32. Highlighted lines 2 and 3 show a local label binding, together with a remote binding from peer 172.16.1.4:0 (Paris_PE) for this prefix. You will notice, however, that there is no binding from peer 172.16.1.2:0 (London_P). A close examination of other entries in the LIB shows that other bindings are being received from London_P. This might indicate that conditional label advertisement is configured on London_P. The configuration of London_P is then examined using the show running-config command, as shown in Example 7-78. Note that only the relevant portion of the output is shown. Example 7-78. Configuration of London_PLondon_P#show running-config Building configuration... ! no tag-switching advertise-tags tag-switching advertise-tags for 1 ! ! access-list 1 permit 172.16.1.1 access-list 1 permit 172.16.1.3 access-list 1 permit 172.16.1.2 access-list 1 permit 172.16.2.0 0.0.0.255 access-list 1 permit 172.16.3.0 0.0.0.255 access-list 1 permit 172.16.4.0 0.0.0.255 ! Highlighted lines 1 and 2 show that London_P is configured to advertise only those label bindings permitted in access list 1. Access list 1 is shown in highlighted lines 3 to 8. As you can see, prefix 172.16.1.4/32 is not permitted. To correct this problem, either access list 1 can be modified or conditional label advertisement can be removed. The configuration in Example 7-79 removes conditional label advertisement. Example 7-79. Conditional Label Advertisement Is RemovedLondon_P#conf t Enter configuration commands, one per line. End with CNTL/Z. London_P(config)#mpls ldp advertise-labels London_P(config)#no mpls ldp advertise-labels for 1 London_P(config)#exit London_P# Once conditional label advertisement has been removed, London_P advertises the label binding for prefix 172.16.1.4/32. This is verified using the show mpls ldp bindings [prefix] [mask_length] command, as shown in Example 7-80. Example 7-80. Label Binding for 172.16.1.4/32 Is Received from London_PLondon_PE#show mpls ldp bindings 172.16.1.4 32 tib entry: 172.16.1.4/32, rev 22 local binding: tag: 28 remote binding: tsr: 172.16.1.4:0, tag: imp-null remote binding: tsr: 172.16.1.2:0, tag: 21 London_PE# As you can see, a label binding has now been received from 172.16.1.2:0 (London_P) for prefix 172.16.1.4/32. It is also possible to filter label bindings as they are received on an LSR using the mpls ldp neighbor [vrf vpn-name] neighbor-address labels accept acl command. Only labels corresponding to prefixes permitted in a standard access list are accepted from the specified neighbor. You can use the show mpls ldp neighbor neighbor-address detail command to verify the presence of this command. CEF Is DisabledIf no tunnel label bindings are locally assigned to prefixes, this may indicate that CEF is globally disabled on the LSR. Verify local label assignment using the show mpls ldp bindings command, as shown in Example 7-81. Example 7-81. No Labels Are Locally Assigned
London_P#show mpls ldp bindings
tib entry: 172.16.1.1/32, rev 5
remote binding: tsr: 172.16.1.1:0, tag: imp-null
remote binding: tsr: 172.16.1.3:0, tag: 21
tib entry: 172.16.1.2/32, rev 2
remote binding: tsr: 172.16.1.1:0, tag: 22
remote binding: tsr: 172.16.1.3:0, tag: 20
tib entry: 172.16.1.3/32, rev 8
remote binding: tsr: 172.16.1.1:0, tag: 26
remote binding: tsr: 172.16.1.3:0, tag: imp-null
tib entry: 172.16.1.4/32, rev 10
remote binding: tsr: 172.16.1.1:0, tag: 28
remote binding: tsr: 172.16.1.3:0, tag: 18
tib entry: 172.16.2.0/24, rev 1
remote binding: tsr: 172.16.1.1:0, tag: imp-null
remote binding: tsr: 172.16.1.3:0, tag: 19
tib entry: 172.16.3.0/24, rev 4
remote binding: tsr: 172.16.1.1:0, tag: 21
remote binding: tsr: 172.16.1.3:0, tag: imp-null
tib entry: 172.16.3.1/32, rev 11
remote binding: tsr: 172.16.1.1:0, tag: 25
remote binding: tsr: 172.16.1.3:0, tag: 17
tib entry: 172.16.3.2/32, rev 3
remote binding: tsr: 172.16.1.1:0, tag: 20
tib entry: 172.16.4.0/24, rev 6
remote binding: tsr: 172.16.1.1:0, tag: 23
remote binding: tsr: 172.16.1.3:0, tag: imp-null
tib entry: 172.16.4.1/32, rev 9
remote binding: tsr: 172.16.1.1:0, tag: 27
tib entry: 172.16.4.2/32, rev 7
remote binding: tsr: 172.16.1.1:0, tag: 24
remote binding: tsr: 172.16.1.3:0, tag: 16
London_P#
An examination of the output shown in Example 7-81 shows that no labels are locally assigned to prefixes on London_P (there are no local bindings). CEF is then verified using the show ip cef summary command, as demonstrated in Example 7-82. Example 7-82. CEF Is DisabledLondon_P#show ip cef summary IP CEF without switching (Table Version 4), flags=0x0, bits=8 4 routes, 0 reresolve, 0 unresolved (0 old, 0 new), peak 0 4 leaves, 8 nodes, 8912 bytes, 4 inserts, 0 invalidations 0 load sharing elements, 0 bytes, 0 references universal per-destination load sharing algorithm, id A189DD49 1(0) CEF resets, 0 revisions of existing leaves 0 in-place/0 aborted modifications Resolution Timer: Exponential (currently 0s, peak 0s) refcounts: 2308 leaf, 2304 node Table epoch: 0 (4 entries at this epoch) %CEF not running London_P# As you can see, CEF is disabled on London_P. The ip cef command is then used to enable CEF, as shown in Example 7-83. Example 7-83. CEF Is Enabled on London_PLondon_P#conf t Enter configuration commands, one per line. End with CNTL/Z. London_P(config)#ip cef London_P(config)#exit London_P# After CEF has been enabled, the LIB is re-examined using the show mpls ldp bindings command, as shown in Example 7-84. Example 7-84. Labels Are Locally Assigned
London_P#show mpls ldp bindings
tib entry: 172.16.1.1/32, rev 16
local binding: tag: 20
remote binding: tsr: 172.16.1.1:0, tag: imp-null
remote binding: tsr: 172.16.1.3:0, tag: 21
tib entry: 172.16.1.2/32, rev 21
local binding: tag: imp-null
remote binding: tsr: 172.16.1.1:0, tag: 22
remote binding: tsr: 172.16.1.3:0, tag: 20
tib entry: 172.16.1.3/32, rev 19
local binding: tag: 22
remote binding: tsr: 172.16.1.1:0, tag: 26
remote binding: tsr: 172.16.1.3:0, tag: imp-null
tib entry: 172.16.1.4/32, rev 14
local binding: tag: 18
remote binding: tsr: 172.16.1.1:0, tag: 28
remote binding: tsr: 172.16.1.3:0, tag: 18
tib entry: 172.16.2.0/24, rev 18
local binding: tag: imp-null
remote binding: tsr: 172.16.1.1:0, tag: imp-null
remote binding: tsr: 172.16.1.3:0, tag: 19
tib entry: 172.16.3.0/24, rev 20
local binding: tag: imp-null
remote binding: tsr: 172.16.1.1:0, tag: 21
remote binding: tsr: 172.16.1.3:0, tag: imp-null
tib entry: 172.16.3.1/32, rev 11
remote binding: tsr: 172.16.1.1:0, tag: 25
remote binding: tsr: 172.16.1.3:0, tag: 17
tib entry: 172.16.3.2/32, rev 17
local binding: tag: 21
remote binding: tsr: 172.16.1.1:0, tag: 20
tib entry: 172.16.4.0/24, rev 12
local binding: tag: 16
remote binding: tsr: 172.16.1.1:0, tag: 23
remote binding: tsr: 172.16.1.3:0, tag: imp-null
tib entry: 172.16.4.1/32, rev 13
local binding: tag: 17
remote binding: tsr: 172.16.1.1:0, tag: 27
tib entry: 172.16.4.2/32, rev 15
local binding: tag: 19
remote binding: tsr: 172.16.1.1:0, tag: 24
remote binding: tsr: 172.16.1.3:0, tag: 16
London_P#
As you can see, labels are now locally assigned to prefixes. Verifying and Troubleshooting VC Label ExchangeIf VC labels are not successfully exchanged between peer PE routers, pseudowire setup will fail. Use the show mpls l2transport vc vcid detail command to verify VC label exchange, as shown in Example 7-85. Example 7-85. Verifying VC Label ExchangeLondon_PE#show mpls l2transport vc 124 detail Local interface: Se4/1 up, line protocol up, HDLC up Destination address: 172.16.1.4, VC ID: 124, VC status: up Preferred path: not configured Default path: active Tunnel label: 21, next hop 172.16.2.2 Output interface: Fa2/0, imposed label stack {21 17} Create time: 00:01:43, last status change time: 00:01:05 Signaling protocol: LDP, peer 172.16.1.4:0 up MPLS VC labels: local 16, remote 17 Group ID: local 0, remote 4 MTU: local 1500, remote 1500 Remote interface description: Sequencing: receive disabled, send disabled VC statistics: packet totals: receive 11, send 7 byte totals: receive 1662, send 210 packet drops: receive 0, send 0 London_PE# In the highlighted line, you can see local and remote (advertised by the remote PE router) VC labels for the pseudowire with VC ID 124. If VC labels are not successfully exchanged between peer PE routers, the cause may be one of the following:
Use the show interface [interface_name] command to verify that attachment circuits are correctly configured and in an up state. The sections that follow examine the other issues described in the preceding list. Note that if you are using IOS 12.0(27)S or above, you can use the ping mpls command to verify AToM pseudowires between peer PE routers. Peer PE routers advertise the capability to support the verification of pseudowires (called Virtual Circuit Connection Verification [VCCV]) to each other. Use the show mpls l2transport binding command to verify PE router VCCV capability. Troubleshooting LDP Between PE RoutersLDP is used between the PE routers to exchange VC label bindings. If LDP discovery or session establishment is not successful, label bindings will not be exchanged and pseudowire setup will fail. Note that it is only necessary for the IP address (LDP IDs) within a single xconnect command on peer PE routers to be correctly configured for LDP discovery and session establishment to succeed between those peers. Figure 7-17 illustrates VC label exchange. Figure 7-17. VC Label Exchange Issues with LDP discovery and session establishment are discussed in the following two sections. LDP Neighbor Discovery Fails Between Peer PE RoutersIf LDP neighbor discovery fails, session establishment will not take place, and VC label bindings will not be exchanged. Figure 7-18 illustrates LDP neighbor discovery between PE routers. Figure 7-18. LDP Discovery Between PE Routers Use the show mpls ldp discovery command to verify successful LDP discovery between peer PE routers, as shown in Example 7-86. Example 7-86. Successful LDP Discovery Between PE RoutersLondon_PE#show mpls ldp discovery Local LDP Identifier: 172.16.1.1:0 Discovery Sources: Interfaces: FastEthernet2/0 (ldp): xmit/recv LDP Id: 172.16.1.2:0 Targeted Hellos: 172.16.1.1 -> 172.16.1.4 (ldp): active, xmit/recv LDP Id: 172.16.1.4:0 London_PE# In highlighted line 1, you can see the local LDP ID (172.16.1.1:0). Highlighted line 2 shows that targeted hello messages are being transmitted (xmit) and received (recv) between the local (172.16.1.1) and remote (172.16.1.4) PE routers. The LDP ID of the remote PE router (172.16.1.4:0) is shown in highlighted line 3. LDP discovery between peer PE routers can fail for a number of reasons, including the following:
See the section entitled "Peer LDP ID Is Unreachable," earlier in the chapter (on page 620) for more information about verifying and troubleshooting peer LDP ID reachability. For more information about misconfiguration of the IP address of the peer PE router, see the section entitled "Peer PE Router's IP Address Is Misconfigured," later in this chapter (on page 644). See the section entitled "Access List Blocks LDP Discovery," earlier in this chapter (on page 614) for more information about troubleshooting access lists. LDP Session Establishment Fails Between PE RoutersIf an LDP session is not established between PE routers, VC labels will not be exchanged. Figure 7-19 illustrates an LDP session between peer PE routers. Figure 7-19. LDP Session Between PE Routers Use the show mpls ldp neighbor command to verify LDP session establishment, as shown in Example 7-87. Example 7-87. Verifying LDP Session Establishment Between PE RoutersLondon_PE#show mpls ldp neighbor Peer LDP Ident: 172.16.1.2:0; Local LDP Ident 172.16.1.1:0 TCP connection: 172.16.1.2.11181 - 172.16.1.1.646 State: Oper; Msgs sent/rcvd: 14/13; Downstream Up time: 00:00:19 LDP discovery sources: FastEthernet2/0, Src IP addr: 172.16.2.2 Addresses bound to peer LDP Ident: 172.16.1.2 172.16.3.1 172.16.2.2 Peer LDP Ident: 172.16.1.4:0; Local LDP Ident 172.16.1.1:0 TCP connection: 172.16.1.4.11172 - 172.16.1.1.646 State: Oper; Msgs sent/rcvd: 16/14; Downstream Up time: 00:00:05 LDP discovery sources: Targeted Hello 172.16.1.1 -> 172.16.1.4, active Addresses bound to peer LDP Ident: 172.16.1.4 172.16.4.2 London_PE# Highlighted line 1 shows the remote and local LSR LDP IDs (172.16.1.4:0 and 172.16.1.0:0, respectively). In highlighted line 2, you can see that the session state is operational (established), the number of messages sent and received are 16 and 14, respectively, and the method of label distribution is unsolicited downstream. Highlighted line 3 shows that the session has been established for 5 seconds. In highlighted line 4, you can see that targeted (unicast) hello messages are being sent from local address 172.16.1.1 to peer address 172.16.1.4. In highlighted line 5, you can see the peer's interface IP addresses. LDP session establishment between non-directly connected neighbors (PE routers) can fail for a number of reasons, including the following:
See the section, "Access List Blocks LDP Session Establishment," earlier in this chapter (on page 622) for more information about issues with access lists. See the section "LDP Authentication Failure," earlier in this chapter (on page 624) for more information about issues with LDP authentication. VC Type MismatchIf VC types are mismatched on peer PE routers, circuit setup will fail. Use the debug mpls l2transport vc event command to troubleshoot this issue, as shown in Example 7-88. Example 7-88. VC Type MismatchLondon_PE#debug mpls l2transport vc event AToM vc event debugging is on London_PE# *Apr 19 16:12:42.275 UTC: AToM MGR [172.16.1.4, 123]: Local end up *Apr 19 16:12:42.275 UTC: AToM MGR [172.16.1.4, 123]: Mismatch vc type in remote label binding, local 1, remote 6 *Apr 19 16:12:43.275 UTC: AToM MGR [172.16.1.4, 123]: Withdraw local vc label binding London_PE# As you can see, there is a VC mismatch between the local VC type and the remote VC type for VC ID 123 to PE router 172.16.1.4 (Paris_PE). The VC type is then verified on London_PE and Paris_PE using the show mpls l2transport vc command, as shown in Example 7-89. Example 7-89. VC Types on London_PE and Paris_PELondon_PE#show mpls l2transport vc 123 Local intf Local circuit Dest address VC ID Status ------------- -------------------- --------------- ---------- ---------- Se4/0 FR DLCI 50 172.16.1.4 123 DOWN London_PE# ________________________________________________________________ Paris_PE#show mpls l2transport vc 123 Local intf Local circuit Dest address VC ID Status ------------- -------------------- --------------- ---------- ---------- Se2/0 HDLC 172.16.1.1 123 DOWN Paris_PE# As you can see, VC ID 123 on London_PE corresponds to a Frame Relay DLCI-to-DLCI connection (highlighted line 1), and on Paris_PE to a HDLC connection (highlighted line 2)clearly a mismatch. In fact, VC ID 123 (on interface serial 2/0) should correspond to a Frame Relay DLCI-to-DLCI connection on Paris_PE. Paris_PE is, therefore, reconfigured, as shown in Example 7-90. Example 7-90. Paris_PE Is ReconfiguredParis_PE#conf t Enter configuration commands, one per line. End with CNTL/Z. Paris_PE(config)#int s2/0 Paris_PE(config-if)#encapsulation frame-relay Paris_PE(config-if)#frame-relay intf-type dce Paris_PE(config-if)#exit Paris_PE(config)# Paris_PE(config)#connect PVCtoLondon serial 2/0 60 l2transport Paris_PE(config-fr-pw-switching)#xconnect 172.16.1.1 123 encapsulation mpls Paris_PE(config-fr-pw-switching)#end Paris_PE# In highlighted lines 1 to 4, a Frame Relay DLCI-to-DLCI connection for DLCI 60 is configured with VC ID 123 to peer 172.16.1.1 (London_PE). Once the circuit type has been reconfigured on Paris_PE, the circuit changes state to UP. This is verified using the show mpls l2transport vc command, as shown in Example 7-91. Example 7-91. Circuit Changes State to UPLondon_PE#show mpls l2transport vc 123 Local intf Local circuit Dest address VC ID Status ------------- -------------------- --------------- ---------- ---------- Se4/0 FR DLCI 50 172.16.1.4 123 UP London_PE# Note that Cisco routers now support interworking between circuit types such Frame Relay and Ethernet VLAN. This feature is available with Cisco IOS Software Release 12.0(26)S and later and is called L2VPN Interworking. See Cisco.com for more details. VC ID MismatchIf there is a VC ID mismatch for a circuit between peer PE routers, circuit setup will fail. Use the show mpls l2transport vc command to verify VC IDs on peer PE routers, as shown in Example 7-92. Example 7-92. VC IDs Are MismatchedLondon_PE#show mpls l2transport vc Local intf Local circuit Dest address VC ID Status ------------- -------------------- --------------- ---------- ---------- Fa1/0.1 Eth VLAN 10 172.16.1.4 121 UP Se4/0 FR DLCI 50 172.16.1.4 123 DOWN Se4/1 HDLC 172.16.1.4 124 UP London_PE# ________________________________________________________________ Paris_PE#show mpls l2transport vc Local intf Local circuit Dest address VC ID Status ------------- -------------------- --------------- ---------- ---------- Fa0/0.1 Eth VLAN 10 172.16.1.1 121 UP Se2/2 HDLC 172.16.1.1 124 UP Se2/0 FR DLCI 60 172.16.1.1 128 DOWN Paris_PE# A Frame Relay DLCI-to-DLCI connection should be established between interface serial 4/0 on London_PE (172.16.1.1) and interface serial 2/0 on Paris_PE (172.16.1.4). As you can see in highlighted lines 1 and 2, however, the VC IDs on London_PE and Paris_PE are mismatched (123 and 128). The VC ID for this circuit should, in fact, be 123 on both PE routers. The VC ID for the circuit is, therefore, reconfigured on Paris_PE, as shown in Example 7-93. Example 7-93. VC ID Is Reconfigured on Paris_PEParis_PE#conf t Enter configuration commands, one per line. End with CNTL/Z. Paris_PE(config)#connect PVCtoLondon Serial2/0 60 l2transport Paris_PE(config-fr-pw-switching)#xconnect 172.16.1.1 123 encapsulation mpls Paris_PE(config-fr-pw-switching)#end Paris_PE# Once the VC ID has been reconfigured on Paris_PE, the circuit state changes to UP, verified using the show mpls l2transport vc command, as shown in Example 7-94. Example 7-94. Circuit State Has Changed to UPLondon_PE#show mpls l2transport vc 123 Local intf Local circuit Dest address VC ID Status ------------- -------------------- --------------- ---------- ---------- Se4/0 FR DLCI 50 172.16.1.4 123 UP London_PE# The highlighted line indicates that the circuit has now changed state to UP. MTU MismatchIf there is an MTU size mismatch between attachment circuits on peer PE routers, VC setup will fail. Use the debug mpls l2transport vc event or show mpls l2transport vc VCID detail commands to troubleshoot this issue. Example 7-95 shows the output of the debug mpls l2transport vc event command. Example 7-95. MTU MismatchLondon_PE#debug mpls l2transport vc event AToM vc event debugging is on London_PE# *Apr 24 21:10:18.615 UTC: AToM MGR [172.16.1.4, 123]: Local end up *Apr 24 21:10:18.615 UTC: AToM MGR [172.16.1.4, 123]: Mismatch MTU in remote label binding, local 1450, remote 1500 *Apr 24 21:10:19.615 UTC: AToM MGR [172.16.1.4, 123]: Withdraw local vc label binding London_PE# The highlighted line indicates that there is an MTU mismatch between the local and remote attachment circuits for VC ID 123 to peer 172.16.1.4 (Paris_PE). The local MTU size is 1450, and the remote MTU is 1500. This is confirmed using the show mpls l2transport vc VCID detail command, as shown in Example 7-96. Example 7-96. Verifying MTU SizesLondon_PE#show mpls l2transport vc 123 detail Local interface: Se4/0 up, line protocol up, FR DLCI 50 down Destination address: 172.16.1.4, VC ID: 123, VC status: down Tunnel label: not ready Output interface: unknown, imposed label stack {} Create time: 00:04:34, last status change time: never Signaling protocol: LDP, peer 172.16.1.4:0 up MPLS VC labels: local 27, remote 18 Group ID: local 0, remote 2 MTU: local 1450, remote 1500 Remote interface description: Sequencing: receive disabled, send disabled VC statistics: packet totals: receive 0, send 0 byte totals: receive 0, send 0 packet drops: receive 0, send 0 London_PE# The solution is to reconfigure either London_PE or Paris_PE so that their attachment circuit MTU sizes match. In this case, the MTU size on London_PE is reconfigured using the mtu bytes command, as shown in Example 7-97. Example 7-97. Reconfiguration of the MTU Size on London_PELondon_PE#conf t Enter configuration commands, one per line. End with CNTL/Z. London_PE(config)#interface serial 4/0 London_PE(config-if)#mtu 1500 London_PE(config-if)#end London_PE# Once the MTU size has been reconfigured on London_PE, the VC changes state to UP. This is verified using the show mpls l2transport vc vcid command, as shown in Example 7-98. Example 7-98. VC State Has Changed to UPLondon_PE#show mpls l2transport vc 123 Local intf Local circuit Dest address VC ID Status ------------- -------------------- --------------- ---------- ---------- Se4/0 FR DLCI 50 172.16.1.4 123 UP London_PE# Peer PE Router's IP Address Is MisconfiguredIf the peer PE router's IP address (LDP ID) is misconfigured in an xconnect peer_LDP_router_id VCID encapsulation mpls command, circuit setup will fail. Use the show mpls l2transport vc command to troubleshoot this issue, as shown in Example 7-99. Example 7-99. Peer IP Address Is Misconfigured on Paris_PELondon_PE#show mpls l2transport vc 123 Local intf Local circuit Dest address VC ID Status ------------- -------------------- --------------- ---------- ---------- Se4/0 FR DLCI 50 172.16.1.4 123 DOWN London_PE# ________________________________________________________________ Paris_PE#show mpls l2transport vc 123 Local intf Local circuit Dest address VC ID Status ------------- -------------------- --------------- ---------- ---------- Se2/0 FR DLCI 60 172.16.1.11 123 DOWN Paris_PE# A careful examination of the destination (peer PE router) IP addresses configured for the circuit with VC ID 123 reveals that the address is correctly configured on London_PE (to 172.16.1.4, Paris_PE) but incorrectly configured on Paris_PE (to 172.16.1.11). The destination address for the circuit on Paris_PE should, in fact, be 172.16.1.1 (London_PE). The destination IP address is then reconfigured on Paris_PE with the xconnect peer_LDP_router_id VCID encapsulation mpls command, as shown in Example 7-100. Example 7-100. Destination IP Address Is Reconfigured on Paris_PEParis_PE#conf t Enter configuration commands, one per line. End with CNTL/Z. Paris_PE(config)#connect PVCtoBank Serial2/0 60 l2transport Paris_PE(config-fr-pw-switching)#xconnect 172.16.1.1 123 encapsulation mpls Paris_PE(config-fr-pw-switching)#end Paris_PE# Once the destination IP address for the circuit has been reconfigured on Paris_PE, the circuit changes state to UP. This is verified using the show mpls l2transport vc [vcid] command, as shown in Example 7-101. Example 7-101. Circuit State Is UPLondon_PE#show mpls l2transport vc 123 Local intf Local circuit Dest address VC ID Status ------------- -------------------- --------------- ---------- ---------- Se4/0 FR DLCI 50 172.16.1.4 123 UP London_PE#  |
|
|