Now ping is great for testing as an example
if I ping 10.1.1.2 the ping succeeds
the reason the first ping failed is due to ARP
the router needs to ARP for the MAC address of router 2
but notice if I ping 10.1.2.2 which is the IP address of router 3
the pings fail because that route is not in the routing table.
10.1.2.0 is not in the local router's routing table.
10.1.1.0 is in the local routing table.
so the router can route appropriately
now debugs are very useful for testing and troubleshooting
and in this example, I’m gonna use a command debug ip icmp
on both router 2 and router 3 just to prove that traffic is arriving
as expected on the correct routers.
so ping 10.1.1.2 this IP address
notice we see the ICMP echo replies sent back to 10.1.1.1
let's do that so 10.1.2.2 the traffic doesn’t reach this router
we don’t see any outputs on the screen of router 3
where’s just to do it again to 10.1.1.2
we see the debugs because the traffic is being sent from router 1 to router 2
and is being received by router 2 which in turn is replying back.
So on router 1, we can use the command debug ip packet
be careful with this command in a live environment.
In a live environment, you want to use an access control list
to limit the traffic that you are debugging in a production
or live environment, you can kill your router if you run this command.
But in this live environment, it’s ok to do it.
so from a testing and troubleshooting point of view
lets work through logic
on router 1, we try to ping 10.1.2.2
we're not getting a reply we run a debug IP ICMP
on router 3 to see if the traffic is actually arriving at router 3
and it's not, that’s useful because pings send traffic
and then expect to respond
and this would allows to check whether the problem is on the path R1 to R3
or whether the problem is on the return R3 to R1
so this is a great command for testing
so ping 10.1.2.2 notice in the output we're getting unroutable
the local router is telling us that the source IP address 10.1.1.1
going to the destination 10.1.2.2 is unroutable
so it doesn’t know where to forward the traffic.
another great thing in the output here
is that we know which interface the router is using for sending packets
typically a router uses the outgoing interface
as the source in packets and you can see that here.
so the source of the ping is 10.1.1.1
because that’s the outgoing interface to get to a destination
such as 10.1.2.2
as an example, if we ping 10.1.1.2 the ping succeed
we get quite a lot of output
so scrolling back, there’s the ping, they are the success messages
we can see that the source IP address is 10.1.1.1
destination is 10.1.1.2 this IP address
and this was routed via the Forwarding Information Base or FIB out of F0/0
so the packet was sent
and then we received a reply from 10.1.1.2 going to 10.1.1.1
so here we can see that the packet was forwarded out of the router
or sent by the router and here we can see a replied back from router 2.
so a very useful command but once again be careful using it in production
sh ip route
shows me that I don’t have a route in the routing table for 10.1.2.0
and I also don’t have a gateway of last resort
in other words, I don’t have a default gateway
or default route configured on this router.
So the router doesn’t know what to do with the traffic
and hence when we ping the router tells us that the traffic is unroutable.
The router doesn’t know where to forward the traffic
so we need to configure static routes.