Troubleshooting the Network

The easiest way to troubleshoot an MPLS or tag switching network is to do a ping across the service provider network. Let’s do a ping from Peer 1 to the loopback address (192.168.2.1) of Peer 2. Here are the results:

Peer1#ping 192.168.2.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 116/118/120 ms

Everything works, right? Right! What if you do the ping from the Atlanta POP router? The answer is as follows, with a ping as executed on the Atlanta POP router:

Atlanta#ping 192.168.2.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

As you can see from the ping output from the Atlanta POP to the loopback of Peer 2, the ping command does not work. You might be asking yourself, “Why doesn’t this command work?” The answer has to do with routing protocols and what routes are known by each network device.

76 Chapter 2 Frame-Mode MPLS

To start with, let’s look at Peer 1’s routing table:

Peer1#show ip route

.

. output omitted

.

Gateway of last resort is not set

192.168.1.0 255.255.255.255 is subnetted, 1 subnets C 192.168.1.1 is directly connected, Loopback0

192.168.2.0 255.255.255.255 is subnetted, 1 subnets

B192.168.2.1 [20/0] via 192.168.3.6, 00:37:21 192.168.3.0 255.255.255.252 is subnetted, 2 subnets

B192.168.3.8 [20/0] via 192.168.3.6, 00:37:21

C192.168.3.4 is directly connected, Serial0

When a ping is done from Peer 1 to the loopback of Peer 2 (192.168.2.1), is there a route to get to the destination network? Yes. There’s a BGP route with a next hop address of 192.168.3.6.

The packet is sent to 192.168.3.6, which is the Atlanta POP router. The Atlanta POP router’s routing table is as follows:

Atlanta#show ip route

.

. output omitted

.

Gateway of last resort is not set

204.134.83.0 255.255.255.0 is variably subnetted, 5 subnets, 2 masks

R204.134.83.8 255.255.255.252

[120/1] via 204.134.83.6, 00:00:05, Serial0/0 C 204.134.83.1 255.255.255.255 is directly

connected, Loopback0

R204.134.83.3 255.255.255.255

[120/2] via 204.134.83.6, 00:00:05, Serial0/0

R204.134.83.2 255.255.255.255

[120/1] via 204.134.83.6, 00:00:05, Serial0/0

Troubleshooting and Verification 77

C 204.134.83.4 255.255.255.252 is directly connected, Serial0/0

192.168.1.0 255.255.255.255 is subnetted, 1 subnets

B192.168.1.1 [20/0] via 192.168.3.5, 14:12:49 192.168.2.0 255.255.255.255 is subnetted, 1 subnets

B192.168.2.1 [200/0] via 204.134.83.3, 00:41:22 192.168.3.0 255.255.255.252 is subnetted, 2 subnets

B192.168.3.8 [200/0] via 204.134.83.3, 00:41:23 C 192.168.3.4 is directly connected, Serial0/1

The packet destined from Peer 1 to Peer 2 arrives at the Atlanta POP router. Does the Atlanta POP router have a path to get to the loopback of Peer 2 (192.168.2.1)? Yes. There’s a BGP route to 192.168.2.1 with a next hop address of 204.134.83.3 (Raleigh). How does the Atlanta POP router get the packet to the Raleigh POP router? It sends it as a labeled, or in this case, a tagged packet, as you can see in the following output:

By observing the output of the show tag-switching forwardingtable command on the Atlanta POP, you can see that the packet is sent as a labeled, or in this case, a tagged packet. What is the outbound label? 27. What is the outbound interface? Serial 0/0. What is the neighboring device connected via Serial 0/0 (look back at Figure 2.7)? The Core router.

Let’s look at the Core router’s routing table:

Core#show ip route

.

. output omitted

.

Gateway of last resort is not set

204.134.83.0 255.255.255.0 is variably subnetted, 5 subnets, 2 masks

78 Chapter 2 Frame-Mode MPLS

C 204.134.83.8 255.255.255.252 is directly connected, Serial0/0

R204.134.83.1 255.255.255.255

[120/1] via 204.134.83.5, 00:00:18, Serial0/1

R204.134.83.3 255.255.255.255

[120/1] via 204.134.83.10, 00:00:01, Serial0/0

C204.134.83.2 255.255.255.255 is directly connected, Loopback0

C204.134.83.4 255.255.255.252 is directly connected, Serial0/1

Does the Core router have a route in its routing table to forward a packet to Peer 2 (192.168.2.1)? No. Without MPLS, or tag switching, the packet would be dropped right here. The Core router only knows about the IGP (RIP in this example) routes. The Core router does not forward the packet, but instead it does tag switching. The output of the show tag-switching forwarding-table command as executed on the Core router is as follows:

What happens to the packet? Well, from the Atlanta POP router, the packet is sent with a tag of 27. By observing the output of the show tagswitching forwarding-table command on the Core router, you can see that an inbound tagged packet of 27 arriving at the Core router has its tag popped and is forwarded as untagged IP out interface Serial 0/0. So here at the Core router, there is no routing, only switching of labeled, or in this case, tagged packets.

Now let’s move on to the Raleigh POP router. An unlabeled IP packet arrives destined for network 192.168.2.1. The Raleigh POP router’s routing table is as follows:

Raleigh#show ip route

.

. output omitted

.

R204.134.83.1 255.255.255.255

[120/2] via 204.134.83.9, 00:00:10, Serial0/3 C 204.134.83.3 255.255.255.255 is directly

connected, Loopback0

R204.134.83.2 255.255.255.255

[120/1] via 204.134.83.9, 00:00:10, Serial0/3

R204.134.83.4 255.255.255.252

[120/1] via 204.134.83.9, 00:00:10, Serial0/3 192.168.1.0 255.255.255.255 is subnetted, 1 subnets

B192.168.1.1 [200/0] via 204.134.83.1, 01:03:10 192.168.2.0 255.255.255.255 is subnetted, 1 subnets

B192.168.2.1 [20/0] via 192.168.3.10, 01:03:01 192.168.3.0 255.255.255.252 is subnetted, 2 subnets

C192.168.3.8 is directly connected, Serial0/1

B192.168.3.4 [200/0] via 204.134.83.1, 01:03:12

Does the Raleigh POP router have a path to get to the loopback (192.168.2.1) of Peer 1? Yes, there’s a BGP route to 192.168.2.1. What is the outbound interface? Serial 0/1.

The packet arrives on Peer 2. Peer 2 needs to send a response to the ping. The routing table of Peer 2 is as follows:

Peer2#show ip route

.

. output omitted

.

Gateway of last resort is not set

192.168.1.0 255.255.255.255 is subnetted, 1 subnets B 192.168.1.1 [20/0] via 192.168.3.9, 01:06:37

192.168.2.0 255.255.255.255 is subnetted, 1 subnets

C192.168.2.1 is directly connected, Loopback0

80 Chapter 2 Frame-Mode MPLS

192.168.3.0 255.255.255.252 is subnetted, 2 subnets C 192.168.3.8 is directly connected, Serial0

B192.168.3.4 [20/0] via 192.168.3.9, 01:06:37

Does the Peer 2 router have a path to get back to Peer 1? Yes. The entire process you just observed will now be repeated in reverse.

What if you are on the Atlanta POP router and you try a ping to Peer 2 (192.168.2.1)? It fails, as you can see in the following output:

Atlanta#ping 192.168.2.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

Why does this ping fail? Because the source address (204.134.83.5) is unknown to Peer 2. Observe the traceroute command as executed on the Atlanta POP router:

Atlanta#traceroute 192.168.2.1

Type escape sequence to abort.

Tracing the route to 192.168.2.1

How far does the traceroute command get? Only to the Raleigh POP router. Peer 2 has no way to respond to the source.

Let’s illustrate by changing how the ping command is used. This time I’m going to source the ping from an interface that Peer 2 knows about:

Atlanta#ping

Protocol [ip]:

Target IP address: 192.168.2.1

Repeat count [5]:

Datagram size [100]:

Timeout in seconds [2]:

Troubleshooting and Verification 81

Extended commands [n]: y

Source address or interface: 192.168.3.6 Type of service [0]:

Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]:

Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 88/88/88 ms

Peer 2 knows about the 192.168.3.4 network. Take a look at Peer 2’s routing table:

Peer2#show ip route

.

. output omitted

.

Gateway of last resort is not set

192.168.1.0 255.255.255.255 is subnetted, 1 subnets B 192.168.1.1 [20/0] via 192.168.3.9, 01:06:37

192.168.2.0 255.255.255.255 is subnetted, 1 subnets

C192.168.2.1 is directly connected, Loopback0 192.168.3.0 255.255.255.252 is subnetted, 2 subnets

C192.168.3.8 is directly connected, Serial0

B192.168.3.4 [20/0] via 192.168.3.9, 01:06:37

Confused yet? The best way to test to make sure that everything works is to do a ping from one CE device to another CE device. If it works, then MPLS or tag switching is enabled and working properly. If the ping fails, you don’t have a complete LSP through the service provider network.

Let me show you what a failure looks like. I’ve disabled tag switching on the Core router, which means that there isn’t a complete LSP between the Atlanta and Raleigh POP routers.

82 Chapter 2 Frame-Mode MPLS

Let’s ping from Peer 1 to the loopback (192.168.2.1) of Peer 2. The ping command as executed on Peer 1 is as follows:

Peer1#ping 192.168.2.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

It fails, right? Right! There is no LSP between the Atlanta and Raleigh POP routers. Notice the following output from the traceroute command:

Peer1#traceroute 192.168.2.1

Type escape sequence to abort.

Tracing the route to 192.168.2.1

1 192.168.3.6 16 msec 16 msec 16 msec

2 * * *

How far does the packet get? Only to the Atlanta POP router. Let’s enable tag switching on the Core router and try the ping command again from Peer 1 to the loopback (192.168.2.1) of Peer 2. The output of the ping command is as follows:

Peer1#ping 192.168.2.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 116/117/120 ms

Now that tag switching has been enabled again on the Core router, everything works because there is an end-to-end LSP between the Atlanta and Raleigh POP routers. In the following output from the traceroute command, the packet makes it all the way through the service provider network:

Peer1#traceroute 192.168.2.1