Troubleshooting Basic Routing using Pings & Traceroutes

This is a basic practical to understand the ping & traceroute outputs to troubleshoot the basic routing / connectivity issues. If you need a reference for the output characters you will encounter when using ping & traceroute in Cisco IOS, please go through this.

Only the IP addresses are configured, no routing is placed..
Windows PC has it's gateway configured..
Obviously the PC can ping 10.1.10.1 (gateway) unless there is a physical link failure.

What happens when the PC pings & traceroutes to 10.1.12.1 ??

It works.. PC can ping any interface on R1 without any routing in place because it sends everything it does not know to 10.1.10.1  and R1 knows about the subnet of PC as it is directly connected..

Note that replying host is 10.1.12.1 for the traceroute; not 10.1.10.1



What happens when the PC pings & traceroutes to 10.1.12.2 ??

Result is a
"Request timed out"..

Request timed out comes from the R1's PC connected side interface..




We know PC can reach R1. Let's see from R1's CLI whether it can reach R2's interface..

Obviously R1 can reach the 10.1.12.2 interface of R2 because it is directly connected.
(1st ping is dropped because of the ARP process) Now let's see R2's routing table..

It knows about 10.1.12.0 subnet so it can reply R1's pings & traceroutes.
But it has no route to the subnet which the PC is in (10.1.10.0/24).

So what happened here is that the packets were routed by the PC to R1, R1 routed it to R2 but R2 does not know how to send reply packets to 10.1.10.0 subnet.. So the replies never come back; timed out..

I am adding a static route to 10.1.10.0 on R2 to fix this..
R2(config)#ip route 10.1.10.0 255.255.255.0 10.1.12.1

Now the replies comes in..

Note that the 1st reply is coming from the PC side interface of R1 and the last one comes from the destination itself..

What happens when the PC pings & traceroutes to 10.1.23.2 ??

Result is a 
"Destination unreachable" message comes from 10.1.10.1..

Here you can see the PC routes the packets to 10.1.10.1 of R1 but R1 is reporting the destination host is unreachable..

Even though we put a static route on R2 to 10.1.10.0/24 subnet, routing seems to be not working for the interfaces of R2 except the interface which the R1 connects.
We know PC can reach R1. 

Let's see from R1's CLI to findout whether it can reach R2's interface or not..

You can see that R1 cannot ping 10.1.23.2 and the traceroute has not even a one hop listed. Therefore you can figureout that R1 has no route the 10.1.23.0/24 subnet.. Let's analyze the routing table..

I am putting a static route on R1 to 10.1.23.0/24 subnet..
R1(config)#ip route 10.1.23.0 255.255.255.0 10.1.12.2

Now the pings and traceroutes works..
Note that the traceroute reply comes from the R1's side interface which is 10.1.12.2 not from the destination..

Now let's see from PC..

Note that the final traceroute reply comes from the destination not from the PC's side interface of R2 like in Cisco IOS..


What happens when the PC pings & traceroutes to 10.1.23.3 ??

Request timed out & now you know the reason.. It is what happened in the 1st case too.. Routing is OK for the forward direction but not OK for the reply traffic...

Let's add a route on R3 to 10.1.10.0/24 subnet..
R3(config)#ip route 10.1.10.0 255.255.255.0 10.1.23.2

Now it is working fine..

Note:-

Though the routing is working fine from PC to R3, pings from R1 will not get replies as it is sending packets from R1's e0/0 interface (10.1.12.1).. Reason is R3 has no route to 10.1.12.0/24 subnet..

But you will be able to successfully ping and traceroute to 10.1.23.3 from R1 if you sourced it from the e0/1 interface of R1 because it is in the 10.1.10.0/24 subnet which R3 now has a route intsalled..

What happens when the PC pings & traceroutes to 3.3.3.3 ??

Destination host unreachable from 10.1.10.1 (R1) which means there is no route to the destination from R1..

Let's add a route on R1 to 3.3.3.0/24 subenet..
R1(config)#ip route 3.3.3.0 255.255.255.0 10.1.12.2

Now let's see what happens..

Now again a destination host unreachable from 10.1.12.2 (R2) which means there is no route to the destination from R2..

Before adding a route on R2, let's see what will be the output of pings & traceroutes from R1 to 3.3.3.3

"U" in ping means Unreachable in IOS while "H" in traceroute means Host Unreachable in IOS..



Let's add a route on R1 to 3.3.3.0/24 subenet..
R2(config)#ip route 3.3.3.0 255.255.255.0 10.1.23.3

Now routing is OK from PC to R3's all the interfaces..

Let's see from R1;

Request timed out.. Now you know why.. There is no route on destination to 10.1.12.0/24 subnet..

Let's add a route on R3 to 10.1.12.0/24 subenet..
R3(config)#ip route 10.1.12.0 255.255.255.0 10.1.23.2

Now R1 also can ping R3's any interface successfully..

Note that the traceroute reply comes from the R1's side interface which is 10.1.12.2 not from the destination like in Windows command prompt..

Conclusions:

In Windows command prompt;
(1) "Destination host unreachable" in ping or in tracert indicates that there is no route to the destination from the reporting router..
(2) "Request timed out" in ping or in tracert indicates that there is no route to the source from the destination for the reply traffic..
(3) Traceroute replies always come from the source's side interfaces of the routing path.. Except the final destination..

In Cisco IOS;
(1) "U" in ping or "H" in traceroute indicates (unreachable) that there is no route to the destination from the reporting router..
(2) "." in ping or "*" in tracert indicates (request timeout) that there is no route to the source from the destination for the reply traffic..
(3) Traceroute replies always come from the source's side interfaces of the routing path.