Situation: The Globomantics clients cannot access the
new Wired Brain Coffee servers.
Before we show up with both guns blazing, let's stop and think.
Here is what I would suggest as a strategy for isolating a network fault.
First, try to ping the target server using the IP address shown.
If it works, great, there's no problem.
Let's rule that out right away so we don't spend all
day pinging every hop along the path.
Next, ping from the client to your local default gateway,
which is the first router in the network.
Most networks issues happen towards the network's edges,
so it makes sense to rule out issues at the edge before digging into the core.
If this ping fails, the issue is with your client's connectivity to the network.
If it passes, I suggest pinging the remote server's default gateway.
This helps determine if the remote server has a default gateway issue.
If the ping succeeds after the ping to the server itself failed,
then it is likely a remote server default gateway issue.
If it fails, it's likely a core network issue.
Bouncing back to the left,
next we ping the WAN interface of the local Globomantics
router to see if the interface is up.
If it fails, the interface is likely in a down state and should be investigated.
If it succeeds,
ping the Wired Brain Coffee WAN interface at the other
end of the link to see if it works.
I think you're getting the point now.
The general strategy is to work from the outside in,
starting at both sides and moving ever inward from both sides.
This strategy has served me well for years.
Let's see how it works with a live demonstration.
Previously,
I explained our high‑level strategy for isolating the network outage between
the Globomantics client and the Wired Brain Coffee server.
Such outages, whether they are link failures,
router failures, security policies, or misconfigurations,
are very common during networking mergers and acquisitions.
The fault usually lies at the interconnection point of the two networks.
In keeping with our strategy,
let's ping from the client to the server and see what happens.
We should always start with this step since if it succeeds,
there isn't a reachability problem, and we can't stop here.
The IP address of the remote Wired Brain Coffee server is 10.2.5.5,
as seen previously.
Clearly, the ping is failing here, so we should move on to the next step.
I recommend pinging from the client to its local default gateway,
which is 10.1.4.1,
just to rule out any client misconfigurations before digging deeper.
As I said earlier,
it's much more likely to have problems at the edge of the network than the core
since problems in the core tend to affect multiple services,
and your phone would be ringing off the hook if that were the case.
But since we don't have a phone, we wouldn't know.
Okay, looks like this ping succeeded.
That's great.
I suggest we ping the default gateway of the remote server now,
which is 10.2.5.2.
To reiterate,
this is a powerful technique as it validates the IP
routing to the remote server LAN segment even if the
target server itself is unreachable.
The ping fails here,
so I'll wager that the problem is somewhere in the core network. Next,
let's ping the R1 router WAN link towards R2. That has an IP address of
10.1. 2.1 and is one of the links in our core network. It appears to be
working, so let's test the other end of the link, which is R2 at IP
address 10.1.2.2. This ping fails.
We can stop our ping testing at this point.
What conclusions can we draw from these results?
If you need some time to collect your thoughts, pause the video here.
The problem appears to be with R2, the Wired Brain Coffee
router, which has some interfaces shut down.
I will bring these interfaces back up, and if you
aren't strong with Cisco IOS commands,
all I did was enable the shutdown interface towards R1. These
commands are outside the scope of a deep dive into ICMP, so
don't worry too much about it.
Let's move back to our client machine and try to ping the
server, which has IP address of 10.2.5.5 now that we've
repaired the fault in the core network.
This looks good.
I hope this demonstration provided a useful example of using ICMP to zero in on
the problems in the network using a logical thought process.
This concludes our discussion of ICMP ping for IPv4. Let's
briefly review what we covered in this module before moving
on to more advanced topics.
ICMP ping is a basic and common tool used to test
connectivity between endpoints on an IP network.
Identifier and sequence numbers are used for packet
accounting during ping tests. Work from the outside in
when using ping to isolate faults.
Ping should be your number one troubleshooting tool,
especially if you have a suspect routing or connectivity issue in the network.
If ping comes back successful and you still have issues,
what next? Stick around because I'll cover your number two troubleshooting tool, traceroute