Table of Contents

Troubleshooting Tag and MPLS Switching Connections

This chapter provides troubleshooting information for connectivity and performance problems in tag switching and MPLS Label Distribution Protocol (LDP) environments. For more information on tag switching and MPLS, refer to the "Configuring Tag Switching and MPLS" chapter in the ATM Switch Router Software Configuration Guide.

Before you begin, make sure that all physical port connections are working correctly. See "Troubleshooting Switch Router ATM Interface Connections."

This chapter contains the following sections:

Tag Switching Overview

Tag switching is a high-performance packet-forwarding technology that assigns tags to multiprotocol frames for transport across packet-based or cell-based networks.

In conventional Layer 3 forwarding, as a packet traverses the network, each router extracts forwarding information from the Layer 3 header. Header analysis is repeated at each router (hop) through which the packet passes.

In a tag switching network, the Layer 3 header is analyzed just once. It is then mapped into a short, fixed-length tag. At each hop, the forwarding decision is made by looking at the value of the tag only; there is no need to reanalyze the Layer 3 header. Because the tag is a fixed-length, unstructured value, looking it up is fast and simple.

A tag switching network consists of tag edge routers and tag switch routers, as shown in Figure 8-1. Tag edge routers are located at the edge of a tag switching network. They use standard routing protocols—such as Open Shortest Path First (OSPF)—to create routing tables that identify routes through the network. Based on the routing tables, tag edge routers use the Tag Distribution Protocol (TDP) to apply and distribute tags to other tag edge routers or tag switch routers. Tag switch routers are located at the core of a tag switching network. They receive TDP information from the tag edge routers and build their own forwarding database. Tag switch routers then switch the packets based on the tags only (without looking at the Layer 3 header).

How Tag Switching Works

When a tag edge router at the entry point of a tag switching network receives a packet for forwarding the following occurs:

1. The router analyzes the network layer header and performs any applicable network layer services such as security, accounting, or quality of service (QoS) classification.

2. The router chooses a route for the packet based on the information in its routing table, applies a tag, and forwards the packet to the next-hop tag switch router.

3. The tag switch router receives the tagged packet and switches the packet from switch router to switch router based on the tag only. The switch routers do not reanalyze the network layer header; they look only at the short, fixed-length tag.

4. The packet reaches the tag edge router at the exit point of the tag switched network, where the tag is removed and the packet is delivered.

Troubleshooting Tag Switching Example

In the example network in Figure 8-1, the primary campus network backbone is made up of two ATM switch routers connected to two Cisco routers:

This network example is used to describe the troubleshooting examples in the rest of this chapter.

For detailed configuration information about tag switching, refer to the "Configuring Tag Switching" chapter in the ATM Switch Router Software Configuration Guide .

Initial Troubleshooting of Tag Switching

This section describes initial troubleshooting steps that you should perform when beginning to troubleshoot a tag switching connection.

At the switch router, use the following commands to check the tag switching configuration:

Follow these steps to confirm the TDP identifier for the routers or tag switching switch routers that might be malfunctioning:

Step 2   Check the Local TDP Identifier field. This field indicates the TDP identifier for the local tag switching switch router or router for this session.

Step 3   Check the Interfaces field. This field displays the interfaces engaging in TDP discovery activity:

If either xmit or recv do not appear, refer to the "Configuring Tag Switching" chapter in the
ATM Switch Router Software Configuration Guide .

Follow these steps to ping each tag switching switch router or router. This process confirms that each can connect to the TDP identifier of the neighbor:

Step 2   Check the Success rate field. This field should read "100 percent". If it does not, continue with the following troubleshooting steps.

Follow these steps to confirm that tag switching is configured on the switch router and its interfaces:

Step 2   Check the tag switching switch router interface to confirm that tag switching is enabled on the connections.

For detailed interface configuration information about tag switching, refer to the "Configuring Tag Switching" chapter in the ATM Switch Router Software Configuration Guide .

The neighbor information branch can have information about all TDP neighbors or can be limited to the neighbor with a specific IP address, or TDP identifier, or to TDP neighbors known to be accessible over a specific interface.

Follow these steps to display the status of TDP sessions:

Step 2   Check the Peer TDP Ident field. This field indicates the TDP identifier of the neighbor (peer device) for this session.

Step 3   Check the Local TDP Ident field. This field indicates the TDP identifier for the local tag switching switch router or router for this session.

Step 4   Check the TCP connection field. This field indicates the TCP connection used to support the TDP session. The format for displaying the TCP connection is peer IP address.peer port local IP address.local port.

Step 5   Check the PIEs sent/rcvd (Protocol Information Element sent or received) field. This field indicates the number of TDP PIEs sent to and received from the session peer device. The count includes the transmission and receipt of periodic keepalive PIEs, which are required for maintenance of the TDP session.

Step 6   Check the Up time field. This field indicates the length of time the TDP session has existed.

Follow these steps to confirm the tag switching interface configuration on the switch router:

Step 2   Check the IP field. This field indicates whether the interface is configured to tag IP packets.

Step 3   Check the Operational field. This field shows whether the packets are being tagged.

Step 4   Enter the show tag-switching interfaces detail command to confirm the tag switching VPI range on an interface.

Step 5   Check the IP tagging enabled field. This field indicates whether tag switching is enabled on this interface.

Step 6   Check the ATM tagging field. This field indicates the VPI range of the interface.

For detailed interface configuration information about tag switching, refer to the "Configuring Tag Switching" chapter in the ATM Switch Router Software Configuration Guide .

Follow these steps to confirm the loopback interface 0 configuration on the switch router:

Step 2   Check the Loopback 0 status field. It should be up.

Step 3   Check the line protocol field. It should be up.

Step 4   Check the Internet address field. It should display the IP address of the loopback interface on this switch router.

For detailed information, refer to the "Configuring Tag Switching" chapter in the
ATM Switch Router Software Configuration Guide .

Follow these steps to confirm the OSPF configuration on the switch router:

Step 2   Check the Routing Process field. The ospf field and ID fields should match the configured numbers. If they do not, refer to the "Configuring Tag Switching" chapter in the
ATM Switch Router Software Configuration Guide .

Troubleshooting TDP Neighbors

This section describes how to troubleshoot TDP control channel VPI and virtual channel identifier (VCI).

Although not necessary for most configurations, you can change the default VPI and VCI of the TDP control channel if you want to use a nondefault value.

Note   The default TDP control channel is on VPI 0 and VCI 32. TDP control channels exchange TDP hellos and PIEs to establish two-way TDP sessions. Tag virtual channels (TVCs) are created by the exchange of PIEs through TDP control circuit.

Use the following command to check the tag switching TDP neighbor connections:

Follow these steps to check the tag switching TDP neighbor connections:

Step 2   Check the peer TDP identifier field. This field indicates the TDP identifier of the neighbor (peer device) for this session.

Step 3   Check the local TDP identifier field. This field indicates the TDP identifier for the local tag switching switch router or router for this session.

Step 4   Check the TCP connection field. This field indicates the TCP connection used to support the TDP session. The format for displaying the TCP connection is peer IP address.peer port local IP address.

Step 5   Check the PIEs sent/rcvd (sent or received) field. This field indicates the number of TDP PIEs sent to and received from the session peer device. The count includes the transmission and receipt of periodic keepalive PIEs, which are required for maintenance of the TDP session.

Step 6   Check the Up time field. This field indicates the length of time the TDP session has existed.

Follow these steps to confirm the VPI and VCI configuration of the tag switching interface on the switch router interface:

Step 2   Check the IP tagging field. This field shows whether the interface is configured to tag IP packets.

Step 3   Check the Tagging operational field. This field shows whether the packets are being tagged.

Step 4   Check the ATM tagging field. This field indicates the VPI range of the interface.

For detailed information, refer to the "Configuring Tag Switching" chapter in the
ATM Switch Router Software Configuration Guide .

Troubleshooting Tag Switching on VP Tunnels

This section describes how to troubleshoot a tag switching connection configured on a VP tunnel.

For detailed information, refer to the "Configuring Tag Switching" chapter in the
ATM Switch Router Software Configuration Guide .

To confirm VP tunnel configuration of tag switching, perform the following tasks in EXEC mode:

Follow these steps to confirm the VP tunnel configuration of tag switching:

Step 2   Check the Status field. The PVP status should be UP. If it is not, check the VP tunnel configuration. Refer to "Configuring Tag Switching" chapter in the ATM  Switch Router Software Configuration Guide.

Follow these steps to confirm the tag switching VP tunnel configuration:

Step 2   Enter the show tag-switching tsp-tunnels command to confirm VP tunnel configuration at the middle switch routers or routers:

Step 3   Enter the show tag-switching tsp-tunnels command to confirm VP tunnel configuration at the tail-end switch router or router:

Step 4   Check whether the TSP Tunnels Process is running. If it is not, enter the tag-switching tsp-tunnels command to enable the process globally on the switch router or router.

Step 5   Check whether the RSVP Process is running. If it is not, enter the tag-switching tsp-tunnels command on the interfaces used by the tunnel to enable the process on the interface.

Step 6   If this is a router connection, check whether Forwarding is enabled on the router. If it is not, enter the ip cef distributed switch command or ip cef switch command to enable IP Cisco Express Forwarding (CEF) globally on the router.

Step 7   Enter the show tag-switching interfaces command to check the VP tunnel interface configuration at each switch router or router in the tunnel. The following example starts at the head end:

Step 8   Enter the show tag-switching interfaces command to check the VP tunnel interface configuration at the middle switch router or routers:

Step 9   Enter the show tag-switching interfaces command to confirm VP tunnel configuration at the tail end switch router or router:

Step 10   Check whether the interfaces used by the tunnel have "Yes" in the Tunnel column. If they do not, use the tag-switching tsp-tunnels command on the interfaces used by the tunnel to enable TSP tunnels, and refer to the "Configuring Tag Switching" chapter in the ATM Switch Router Software Configuration Guide. Verify that the interfaces used by the tunnel are operational. The interfaces should have "Yes" in the Operational column.

If they do not, check the interface configuration and refer to the "Configuring Tag Switching" chapter in the ATM Switch Router Software Configuration Guide .

Troubleshooting Tag Switching Using debug Commands

This section describes debug commands that you can use to troubleshoot tag switching connections on a switch router.

Use the following commands to debug tag switching connections on a switch router:

For detailed interface configuration information, refer to the "Configuring Tag Switching" chapter in the ATM Switch Router Software Configuration Guide .

MPLS Overview

MPLS Label Distribution Protocol (LDP), as standardized by the Internet Engineering Task Force (IETF), and as enabled by Cisco IOS software, allows the construction of highly scalable and flexible IP Virtual Private Networks (VPNs) that support multiple levels of service.

This section includes the following:

From an historical and functional standpoint, LDP is a superset of Cisco's prestandard Tag Distribution Protocol (TDP), which also supports MPLS forwarding along normally routed paths. For those features supported by both LDP and TDP the pattern of protocol exchanges between network routing platforms is identical. The differences between LDP and TDP for those features supported by both protocols are largely embedded in their respective implementation details, such as the encoding of protocol messages.

Table 8-1 provides a conversion from the tag switching designations to the equivalent MPLS designations.

How MPLS Works

As a packet traverses the network in conventional Layer 3 forwarding mechanisms, each router extracts from the Layer 3 header all the information needed to forward the packet. This information is then used as an index for a routing table lookup to determine the next hop for the packet.

In the most common case, the only needed field in the header is the destination address. But, in some cases, other fields might also be needed. This means at each router, as the packet traverses the network, all the header analysis must be independently completed. Additionally, a complicated table lookup must be done at each router.

In label switching, the analysis of the Layer 3 header is done only once, when the packet enters the network at the ingress LSR (label switching router). This LSR reads the Layer 3 header and inserts a small fixed-format label in front of each data packet. For ATM MPLS connections the label used is the VPI/VCI of the virtual circuit.

Many different headers can map to the same label, as long as those headers always result in the same choice of the next hop. A label represents an FEC (forwarding equivalence class) or a set of packets which might be of different types, but are the same with respect to the forwarding function.

The selection of the label to be inserted is not based exclusively on the contents of the Layer 3 packet header. Forwarding decisions might be based on routing policy.

Once a label is assigned, and added at the front of the Layer 3 packet, it is carried across the network as part of the packet. The labels are swapped at each LSR and forwarding decisions are made using the LFIB (label forwarding information base).

The 32-bit MPLS label is located after the Layer 2, header and before the IP header. The MPLS label contains the following fields:

This entire MPLS label is also called a "Shim" header.

Distribution of Label Bindings

Each label switching router (LSR) in the network makes an independent, local decision as to which label value to use to represent an FEC. This association is known as a label binding. Each LSR informs its neighbors of the label bindings it has made. This awareness of label bindings by neighboring routers and switches facilitates the following protocols:

The MPLS LDP (label distribution protocol) provides a standard methodology for hop-by-hop, or dynamic label, distribution in an MPLS network by assigning labels to routes that have been chosen by the underlying Interior Gateway Protocol (IGP) routing protocols. The resulting labeled paths, called label switch paths or LSPs, forward label traffic across an MPLS backbone to particular destinations. These capabilities enable service providers to implement Cisco MPLS-based IP VPNs and IP+ATM services across multivendor MPLS networks.

LDP allows label switching routers (LSRs) to request, distribute, and release label prefix binding information to peer routers in a network. LDP enables LSRs to discover potential peers, and to establish LDP sessions with those peers to order to exchange label binding information.

An LDP label binding is an association between a destination prefix and a label. The label used in a label binding is allocated from a set of possible labels called a label space.

LDP supports two types of label spaces:

Figure 8-2 shows the summary route propagation between four LSRs in an MPLS network.

Figure 8-2 shows the LDP discover mechanism used to periodically transmit LDP Hello messages, and to signal it is ready to advertise label bindings. The LSR sends the LDP Hello messages as UDP packets to the well known LDP port (646).

The Hello messages carry the LDP identifier, or "ID", of the label space that the sending LSR wants to advertise, as well as other information. In Figure 8-2, SalesLSR4 sends a hello packet with the VPI and VCI used to connect to FEC 172.68.0.0. Each LSR then propagates that FEC, replacing the VPI and VCI used to connect to its ingress interface.

When a labeled packet is being sent from an LSR to its neighbor LSR, the label value carried by the packet is the label value that the egress LSR assigned to represent the FEC of the packet. This causes the label value (VPI/VCI) to be swapped as the packet traverses the network.

Figure 8-3 shows the packet transmission and LFIB table look up process used between a source and destination over an ATM MPLS network.

In Figure 8-3, AdminLSR1 is the ingress point for packets from the router AdminRt1. When the LSR receives the packet, it determines the FEC and determines the LSP to use by looking in the LFIB table.

Note   The LFIB table is propagated using the LDP discover mechanism shown in Figure 8-2.

AdminLSR1 then adds the label (VPI/VCI) 65,180 to the packet, and forwards the packet out ATM interface 0/1/0.

The intermediate LSR (NetLSR2) takes the labeled packet, and pairs the incoming interface and label, using a lookup table to determine the outgoing interface and label. After swapping the incoming label with the new outgoing label, the packet is forwarded out to the next LSR.

The label swapping process is continued at each LSR, up to the last LSR. The egress LSR performs the same look up as the intermediate LSRs, but the outgoing label is stripped off and the packet is either routed, or switched using a Layer 3 protocol to its destination.

MPLS Example

This section provides a description of a packet being transmitted across an MLPS enabled network, and of the process used to switch the packets.

When a packet is received at an MPLS ingress interface, the interface driver uses the IDB (interface descriptor block) to start the following MPLS processes on the packet:

Figure 8-4 shows a packet as it traverses a network from its source on network 130.0.0.0 to its destination on network 180.0.0.0.

The packet from network 130.0.0.0 enters router AdminRt1 at Ethernet interface 2/3 with a destination IP address on network 180.0.0.0. The router performs a standard routing table lookup and determines the packet should be routed out ATM interface 0/0 to the next hop interface 140.0.0.1 on interface ATM 1/0/0. By using CEF (Cisco Express Forwarding) the Layer 3 switched packet interface FIB (Forwarding Information Base) is queried and the next hop is determined to be reached through ATM MPLS interface 3/0/0. Prior to transmission to the next LSR, an MPLS label (or VPI/VCI) is appended to the packet just before the destination IP address.

From this point on, through the MPLS network, the only information that is checked by the successive LSRs is the label information in the packet. When the packet reaches the edge LSR, the MPLS label is "popped off" (deleted) the stack and subsequent switching is completed using Layer 3 protocols and standard routing practices.

Troubleshooting MPLS Connections

This section describes troubleshooting MPLS connections, and uses an OSPF sample configuration.

Before you start troubleshooting the MPLS connection, confirm that you have configured the following:

Troubleshooting MPLS interface connections is described in the following sections:

To troubleshoot MPLS interface configurations, use the following commands:

Figure 8-5 shows a customer VPN connection over an MPLS Fast Ethernet backbone connection.

In Figure 8-5, all of the routers and ATM switch routers have loopback 0 interfaces configured with an IP address. Each LSR uses these interfaces as the LDP router ID and LSR LDP ID. The display representation for an LDP ID uses the following form:

[LDP router ID] : [Local label space ID]

The LDP ID "222.2.1.1/32" is an example of a "ProvEdge1" loopback 0 interface. In this example, 111.0.1.1/30 is the IP address of the "ProvEdge1" interface to "8540-P" the provider switch router.

The MPLS example network shown in Figure 8-5 is used in the following examples of troubleshooting MPLS network connections.

Verifying CEF Switching

Follow these steps to troubleshoot CEF on the MPLS interface connections:

Step 2   Check the Routing for Networks field to verify the correct networks are configured and present. If they are not, reconfigure the network protocol.

Step 3   Check the Routing Information Sources field to see whether the correct neighbors are present in the table. The neighbors are the routing sources the Cisco IOS software uses to build its routing table. If the correct neighbor is not included, verify the interfaces are up and configured correctly.

Step 4   Enter the show ip route command to confirm the IP route addresses are in the routing table.

Step 5   Verify the router(s) or route(s) are listed in the display. If they are not, check the routing protocol configuration.

Step 6   Enter the show ip cef summary command to display specific entries in the Forwarding Information Base (FIB), based on IP address information.

Verify the show ip cef command output does not display "%CEF not running" as shown in the following example.

If the CEF is not running, re-enable Cisco Express Forwarding using the ip cef global configuration command.

Enter the show ip cef command to display Prefix and Next Hop information.

The information displayed by entering the show ip cef command is built from the IP routing table, and resides on the route processor.

The following is an explanation of the information in the Next Hop column:

Verifying MPLS

Follow these steps to verify the MPLS interface connections:

Step 2   Verify the contents of the following fields:

Pinging Neighbors

Follow these steps to verify the neighbor MPLS interface connections:

This ping command example provides verification of the connections shown in Figure 8-5.

Step 2   Enter the debug mpls packet command or the MPLS-aware traceroute vrf command to verify the MPLS labels are set.

Verify that the interfaces that appear in the traceroute command output display are the correct cross-connect addresses. This traceroute vrf command example shows verification of the connections, shown in Figure 8-5.

Verifying Label Distribution

Follow these steps to verify the label distribution between MPLS interface connections:

The Local tag field displays the label assigned by this switch router.

The Outgoing tag or VC field displays the label assigned by the next hop, or VPI/VCI used to get to the next hop.

Step 2   Check the Prefix or Tunnel Id field. It should displays the address (Loopback 0 interface IP address) or tunnel to which packets with this label are going. If it does not, check the interface configuration.

The Bytes tag switched field displays the number of bytes switched with this incoming label.

Step 3   Check the Outgoing interface field. It should display the correct interface configured to the next hop on either side of the switch router.

Step 4   Check the Next Hop field. It should display the correct IP address to the next hop interface.

Verifying Label Bindings

Follow these steps to verify the label bindings on MPLS interface connections:

This display contains label bindings for 111.0.1.X/30 networks that are the interfaces for each Label Switch Router (LSR). Notice there are multiple labels for each LSR. Each label corresponds to a different path. For example, the connection to the Loopback 0 interface 222.2.1.1/32 on the 8540-PE1 switch router uses the following labels:

Troubleshooting MPLS VPN

This section provides troubleshooting steps for MPLS Virtual Private Networks (VPNs) over ATM connections.

When used with MPLS, the VPN allows several sites to interconnect transparently through a service provider network. One service provider network can support several different IP VPNs. Each of these appears to its users as a private network, separate from all other networks. Within a VPN, each site can send IP packets to any other site in the same VPN.

Each VPN is associated with one or more VPN routing or forwarding instances (VRFs). A VRF consists of an IP routing table, a derived Cisco Express Forwarding (CEF) table, and a set of interfaces that use this forwarding table.

The ATM switch router maintains a separate routing and CEF table for each VRF. This prevents information from being sent outside the VPN, and allows the same subnet to be used in several VPNs without causing duplicate IP address problems.

The ATM switch router distributes the VPN routing information using the MP-BGP extended communities.

Troubleshooting MPLS VPN Fast Ethernet Example

Figure 8-5 shows a customer VPN connection over a Fast Ethernet MPLS backbone connection, and is used in the following examples of troubleshooting MPLS VPN network connections.

To troubleshoot an MPLS Ethernet configuration, use the following commands:

Verifying VRF Configurations

Follow these steps to verify the VRF on MPLS VPN interface connections:

Step 2   Verify existence of the VRFs and their names are valid.

Step 3   Verify that each Default RD (route-indicator) field is the same at each provider edge ATM switch router. If it is not, check the configuration of the interfaces.

Step 4   Enter the show ip vrf detail command to check the VRFs more closely.

Note   Remember that VPN routing/forwarding instance (VRF) names are case sensitive: "Red" is not the same as "red".

Step 5   Enter the show ip vrf interface command to check the VRFs for a specific interface.

Step 6   Verify the Interface field matches the configuration of the target interface.

Step 7   Verify the VRF names and routing attributes.

Step 8   Verify the Protocol field is up.

Verifying Routing Information

Follow these steps to verify the routing tables for MPLS VPN interface connections:

Step 2   Check the destination for a particular address by using the show ip route vrf command with the VRF-name and IP-address variables.

Border Gateway Protocol (BGP) is used between the PE routers and is necessary for inter-site connectivity. In the following example, we use internal BGP (iBGP). You can also use external BGP (eBGP) as an external routing protocol for Provider Edge-to-Customer Equipment route propagation.

You can use the following commands to troubleshoot BGP:

Step 3   Check the destination for a BGP address by entering the show ip bgp vpnv4 vrf command with the VRF-name.

Step 4   Check the destination for a BGP address by using the show ip bgp vpnv4 vrf command with the VRF-name and IP-address.

Step 5   If the routing protocol used on the customer side does not use BGP, you can use traditional show commands, and apply them to the correct VRF.

For example, if your network is using the Routing Information Protocol (RIP), enter the show ip rip database vrf command.

Step 6   If you are using OSPF, you must enter the show ip ospf [process-id area-id] database command, and specify the correct process number. For example:

Step 7   Verify:

Verifying Labels

MPLS VPN uses a two-level label stack. One of the labels is used to identify the VRF, and is set up between the two provider edge ATM switch routers. The other label (on the top of the stack) is the "backbone" label, and is set up by the standard MPLS network.

Follow these steps to verify the labels on MPLS VPN interface connections:

Note   This command only works with an MPLS-aware traceroute, and only if the backbone ATM switch routers are configured to propagate and generate IP Time to Live (TTL) information.

Note   More precise outputs, such as the table of the labels for a particular VRF, can be seen by entering the show ip bgp vpnv4 all tags command.

Step 2   Enter the show ip bgp vpnv4 all command to display a more precise output of the table of the labels for a particular VRF.

Step 3   Enter the show ip cef vrf command with the VRF name and summary keyword to display a summary of the CEF table associated with a VRF.

Step 4   Enter the show ip cef vrf command with the VRF name and detail keyword to display greater detail of the CEF table associated with a VRF.

Step 5   Verify:

Pinging VPN Connection Neighbors

Follow these steps to verify the MPLS VPN connections:

Note   Before establishing an MPLS VPN, you must be able to ping, for example, the "8540-PE1" ATM switch router (111.0.1.18) from "8540-PE2" (111.0.1.1), and vice-versa. (See Figure 8-5.)

To see if the VRF works, use the ping command.

Note   If you are checking a provider edge ATM switch router, you must add the specific VRF name.

Follow these steps to verify the neighbor MPLS interface connections:

This ping command example confirms the connections, shown in Figure 8-5.

Step 2   Enter the debug mpls packet command or the MPLS-aware traceroute vrf command to verify the MPLS labels are set.

Step 3   Verify that the interfaces that appear in the traceroute command output displays the correct cross-connect addresses. This traceroute vrf command example shows verification of the connections, shown in Figure 8-5.

Troubleshooting MPLS ATM Connections

This section provides steps used to troubleshoot and verify MPLS over ATM routing and interface connections.

Troubleshooting MPLS VPN ATM Example

Figure 8-6 shows customer VPN connections over ATM MPLS backbone connections, and is used in the following examples of troubleshooting MPLS VPN ATM network connections.

In Figure 8-6, all of the routers and ATM switch routers have loopback 0 interfaces configured with an IP address. Each LSR uses these interfaces as the LDP router ID and LSR LDP ID. The display representation for an LDP ID uses the following form:

[LDP router ID] : [Local label space ID]

The LDP ID "102.0.0.0/32" is an example of an "8540-ATM-PE1" loopback 0 interface. In this example, 2.0.0.1/8 is the IP address of the "8540-ATM-PE1" interface to "8540-ATM-P", the provider switch router.

The ATM MPLS interfaces are configured from the PE (provider edge) ATM switch router (8540-ATM-PE1) through the provider core ATM switch router (8540-ATM-P) to the PE (provider edge) ATM switch router (8540-ATM-PE2). The CE (customer edge) routers use these connections to communicate between IP networks 11.1.0.0 and 14.0.0.0.

The MPLS example network shown in Figure 8-6 is used in the following examples of troubleshooting MPLS VPN ATM network connections.

Verifying ATM Interface VRF Configurations

This section describes troubleshooting and verifying the VRF (VPN routing and forwarding instance) over ATM interfaces on a ATM switch router.

To troubleshoot the VRF configuration, use the following commands:

Follow these steps to verify the VRF on MPLS VPN ATM interface connections:

Step 2   Verify that the neighbor attached to the MPLS interface is configured as (tdp) and the Operational field indicates Yes. If it does not, check the interface MPLS configuration.

Step 3   Verify the Interface field matches the configuration of the target interface.

Step 4   Verify the VRF names routing attributes.

Step 5   Verify the Protocol field is up.

Step 6   Enter the show mpls ldp discovery command to verify the interface is sending TDP Hello messages.

The Local LDP Identifier should display the Loopback 0 IP address.

Step 7   Enter the show ip vrf command to verify the VRFs are present on the ATM switch routers and on their associated route-indicators and interface(s).

Step 8   Verify the existence of the VRFs, and their names are valid.

Step 9   Verify that each Default RD (route-descriptor) field is the same at each provider edge ATM switch router. If not, check the configuration of the interfaces.

Step 10   Enter the show ip vrf detail command to examine the VRFs more closely.

Note   Remember that VPN routing/forwarding instance (VRF) names are case sensitive. For example, a VRF named "Red" is not the same as one named "red".

Verifying Routing Information

This section describes the process you can use to verify the routing configuration associated with an MPLS VPN.

To troubleshoot the MPLS VPN routing configuration, use the following commands:

Follow these steps to verify the routing tables for MPLS VPN interface connections:

Step 2   Check the destination for a particular address by entering the show ip route vrf command with the VRF-name and the bgp routing protocol keyword.

Border Gateway Protocol (BGP) is used between the PE routers and is necessary for inter-site connectivity. In the following example, we use internal BGP (iBGP). You can also use external BGP (eBGP) as an external routing protocol for Provider Edge-to-Customer Equipment route propagation.

Use the following commands to troubleshoot BGP:

Step 3   Check the destination for a BGP address by entering the show ip bgp vpnv4 vrf command with the VRF name.

Step 4   If the routing protocol used on the customer side does not use BGP, enter traditional show commands, and apply them to the correct VRF.

For example, if your network is using the Routing Information Protocol (RIP), enter the show ip rip database vrf command.

Step 5   If you are using OSPF, you must enter the show ip ospf [process-id area-id] database command and specify the correct process number. For example:

Step 6   Verify:

Verifying Labels

MPLS VPN uses a two-level label stack. One of the labels is used to identify the VRF, and is set up between the two provider edge ATM switch routers. The other label (on the top of the stack) is the "backbone" label, and is set up by the standard MPLS network.

To verify the MPLS VPN label configuration, use the following commands:

Follow these steps to verify the labels on MPLS VPN interface connections:

Note   More precise outputs like the table of the labels for a particular VRF can be seen using the show ip bgp vpnv4 all tags command.

Step 2   Enter the show ip bgp vpnv4 all command to display the next hop connections in the VPN.

Step 3   Check the Next Hop column. It should display the IP addresses of the directly connected CE node and the PE node of the VPN.

Step 4   Enter the show ip protocols vrf command to display the routing protocol information associated with a VRF.

Step 5   Check the Neighbor(s) field. It should display the IP address of the next node in the VPN.

Step 6   Check the Routing Information Sources field. It should display the interface IP addresses used to update the MPLS label binding information.

Step 7   Enter the show ip cef vrf command with the VRF name to display the entries in the FIB table based on the IP address, and to verify that the CEF table has the correct precedence value for the prefix.

Step 8   Enter the show ip cef vrf command with the VRF name and the detail keyword to display the entries in the FIB table in greater detail.

Step 9   Verify:

Step 10   Check the Adjacency Table fields. They should show connections to the IP address of the CE (customer equipment) router and the PE (provider edge) switch router. If they do not, check the MPLS connection configurations.

Pinging ATM VPN Connections

Follow these steps to verify the ATM MPLS VPN connections:

Note   Before establishing an MPLS VPN, you must be able to ping, for example, the "8540-ATM-PE1" ATM switch router (2.0.0.1) from "8540-ATM-PE2" (3.0.0.2), and vice-versa.

To see whether the VRF works, use the ping command.

Note   If you are checking a provider edge ATM switch router, you must add the specific VRF name.

This ping command example shows verification of the connections, shown in Figure 8-6.

Step 2   Enter the traceroute vrf command to verify the MPLS labels are set.

Step 3   Verify that the interfaces that appear in the traceroute command output display are the correct cross-connect addresses. This traceroute vrf command example shows verification of the connections shown in Figure 8-6.

Debugging MPLS

This section outlines the debug commands used to troubleshoot the MPLS interface configuration.

Use the following debug commands to check the MPLS configuration and setup processes: