


	More Testimonials >

Visit my blog for free daily Cisco CCNA and CCNP certification questions, my latest free articles and tutorials, and more!

CCNP TSHOOT Tutorial:

"The Mystery Of The Unroutable Packet"

By Chris Bryant, CCIE #12933

Having been a pretty fair network troubleshooter for over a decade now, I can tell you from experience that there are two keys to being an efficient t-shooter....

1. A solid knowledge of network fundamentals

2. A structured plan for starting your t-shooting procedures

The same could be said of success on the CCNP TShoot exam.

With both real-world and exam room success in mind, et's tackle one of those fundamentals right now - with ping!

Whether you're on a PC or a Cisco router, ping is generally the first troubleshooting tool you'll use. Ping is a basic IP connectivity test where five Internet Control Message Protocol (ICMP) packets to the destination we specify in the command, and hopefully we get five packets back!

We're first going to concentrate on a typical LAN scenario where two hosts are connected to two Cisco switches, as shown below.

Here's what we want to see:

R2#ping 172.23.23.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.23.23.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms

Five exclamation points = good.

Here's what we don't want to see:

R2#ping 172.12.23.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.12.23.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Five periods, dots, whatever you want to call them = bad.

Now we need a plan, a structured approach, to troubleshooting. Let's say you just walked into a client site and they report this kind of issue. Where to start?

When troubleshooting, always start at the physical layer.

You'll be surprised how often the problem is simply a loose cable or another physical problem. A great place to start troubleshooting a Cisco router is show interface, so let's run that on the ethernet interface and see what we can see.

R2#show interface ethernet0
Ethernet0 is administratively down, line protocol is down
Hardware is Lance, address is 00e0.1e68.91f0 (bia 00e0.1e68.91f0)

Well, that was easy! The interface is administratively down. Remember, Cisco router interfaces are shut down by default. Let's open the interface and see what happens.

R2(config)#inter ethernet0
R2(config-if)#no shutdown
R2(config-if)#^Z

02:26:13: %SYS-5-CONFIG_I: Configured from console by console
02:26:14: %LINK-3-UPDOWN: Interface Ethernet0, changed state to up
02:26:16: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0, changed state to up

The line protocol comes up, and running show interface verifies that the interface is up.

R2#show interface ether0
Ethernet0 is up, line protocol is up
Hardware is Lance, address is 00e0.1e68.91f0 (bia 00e0.1e68.91f0)

Let's try that ping again.

R2#ping 172.23.23.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.23.23.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R2#

The ping still isn't working. We know the cable isn't the problem, since show interface told us that the physical interface and line protocol are both up.

You may have already spotted the reason, but let's run debug ip packet and see what's going on. Remember, do not run a debug on a production network unless you are sure of the result - this debug in particular can quickly overwhelm a router's available CPU resources.

R2#debug ip packet
IP packet debugging is on
R2#ping 172.23.23.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.23.23.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R2#
02:29:28: IP: s=2.2.2.2 (local), d=172.23.23.3, len 100, unroutable
02:29:30: IP: s=2.2.2.2 (local), d=172.23.23.3, len 100, unroutable
02:29:32: IP: s=2.2.2.2 (local), d=172.23.23.3, len 100, unroutable
02:29:34: IP: s=2.2.2.2 (local), d=172.23.23.3, len 100, unroutable
02:29:36: IP: s=2.2.2.2 (local), d=172.23.23.3, len 100, unroutable

How can that address be unroutable when they're on the same subnet? Take a look at the configuration, apply your troubleshooting skills, and check out the answer further down the page!

____________________________________________________

My Bulldog Boot Camp DVDs Are Ready To Help Get Your CCNP --

-- And For A Limited Time, They're $97 Each!

CCNP SWITCH DVD CCNP ROUTE DVD CCNP TSHOOT DVD

Get Over $100 Of Free Ebooks And Receive Free Worldwide Shipping With My CCNP Video Boot Camp Bundle!

_____________________________________________

Let's revisit the topology and figure out how and why the packet could be unroutable.

Network Troubleshooting Exercise

There's no router involved, and the two hosts are on the same subnet, so routing shouldn't be a problem. Unless.....

R2#show interface ethernet0
Ethernet0 is up, line protocol is up
Hardware is Lance, address is 00e0.1e68.91f0 (bia 00e0.1e68.91f0)
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255

The MAC address is shown, but not the IP address. The problem is that there is no IP address configured on the ethernet interface!

R2(config)#int e0
R2(config-if)#ip address 172.23.23.2 255.255.255.0

The interface is already open, and there's no need to close and reopen it after assigning an IP address. Let's send that ping again.

R2#ping 172.23.23.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.23.23.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms

Success!

If we were still not able to ping between those two hosts, I would check the VLAN port membership on the switches with show vlan brief. You'll see more of this in your CCNA studies, but remember - if hosts are in different VLANs, they will not be able to send IP packets to each other without a Layer 3 device being involved.

Just with that simple network, we ran into quite a few things that could have been the cause of the issue: