[Music]
before we get started let's take another
look at Paul's ticket as you may
remember paul's computer is ipv4 only
now nothing about Paul's ticket flat-out
screams that there's a network latency
problem in fact it looks a lot like the
other tickets we've looked at but
remember what we said earlier don't get
into the habit of assuming that two
different problems are similar just
because they look the same on the
surface sometimes Network latency can
present as a network failure if the
network is slow enough it can cause some
applications to timeout and just stop
trying so they fail to the end-user this
looks like something is just broken and
in fact even if we ask really good
questions we usually cannot determine
whether there's a network latency issue
or just an outright failure just by
talking to the end user we have to
actually get on Paul's computer to find
out what's really going on so let's do
that right now here we can see the page
can't be displayed here that Paul
reported but notice also that the status
icon on the tab is spinning indicating
that Internet Explorer is still trying
to load the page up to this point we've
been using the Windows command prompt to
diagnose and troubleshoot but I want to
show you another alternative the windows
powershell it's available on all windows
7 and later operating systems and you
can get to it by going to the Start menu
and just searching for power show the
commands we're going to use are exactly
the same as we would use at the windows
command prompt in fact all of the
commands we're using are part of the
Windows operating system and are not
tied to either the command prompt or
power show let's start out by pinging
and our ping the default gateway will do
a ping 10 10 1.2 54 and that looks good
ARP dash a shows the correct dynamic ARP
entry for the Gateway so we know that
layers 1 & 2 are good now let's ping the
intranet site ping Internet net Lexia
comm and we get a response initially
followed by a request timed out another
response and then another request timed
out if you look at the ping statistics
you'll see that it reports a 50 percent
packet loss now this is just over 4
pings this could just be a temporary
blip in the network or it could be part
of a larger pattern but we can't tell
which it is with just 4 pings so what do
we do well we could set the ping command
to ping over and over again but then
we'd have to sit there and constantly
watch it which would take us away from
other things we could be doing to
troubleshoot the issue instead there's
another program I want to show you
called coalesce off to ping tool this is
a third-party program that is not part
of Windows so you will need to download
it and I'll give you the link in a
moment ping tool gives you a visual
representation of ping response times
over time so you can easily spot
patterns without having to wait a long
time you can also leave it running in
the background while you do other
troubleshooting and then come back to it
later to review the results you can see
that we're getting the same 50% packet
loss and it's very consistent what do we
make of consistent 50% packet loss well
we can make several guesses and there's
nothing wrong with guessing but we still
have another tool at our disposal we
clearly have a layer 3 issue on our
hands so we'll use traceroute to try to
find out where the packets are getting
dropped
okay now what's going on here it goes
from switch 1 to R 2 to R 3 to switch 4
and you don't have to take my word for
it we'll look at the topology diagram in
a minute
so why does the internet IP address 10
that 11.0 11 show up four different
times well this has to do with the way
traceroute works I wish I could tell you
that traceroute actually just traces an
individual packet from its source to its
destination but that's not actually how
it works
traceroute sends a series of packets and
under normal circumstances all of those
packets will get a response but in this
case because we have 50% packet loss not
all of those packets are getting a
response the asterisks you see scattered
around here indicate a response that
went unanswered in other words a packet
that was lost now if you count the
number of asterisks or lost packets
there are eight but in total there are
twelve requests now this is more than
50% loss it's actually about 67% why is
this well remember we're still running a
continuous ping in the background using
the kola soft pink tool so that's going
to skew the results a little bit and
that's okay but we still don't know
what's causing the intermittent packet
loss so what do we do well we're gonna
run another trace route now why are we
doing this well the first trace route
gave us some pretty strange results by
running a second one we can compare the
two to see what if anything is different
remember there's no magic bullet when it
comes to network troubleshooting in
other words there's no defined set of
commands to run that will always tell
you the cause of the problem or even
where it's located now that the second
trace route is done let's go through and
compare it line by line with the first
one we have switch 1 followed by our two
followed by our three but look at the
fourth hop on the first trace route it
switched four but on the second it
switched three it looks as if the
packets are taking two different paths
let's take a look at the topology
diagram to get a better view of what's
going on
the packet goes from Paul's computer to
switch one from there it goes to R 2 and
then 2 R 3 on the first trace route the
next hop was switch 4 but on the
subsequent trace route it was switched 3
so it appears based on our trace route
output that the packet is taking two
different paths sometimes it takes the
path through switch 3 and sometimes it
takes the path through switch 4 assuming
that one of these two paths is not
working that would explain why we're
getting 50% packet loss so we've
definitely isolated the problem to a
layer 3 issue but as yet we don't know
the cause but before we get too far
ahead let's take a step back and review
what we've done so far with Paul's
problem initially we observed that Paul
was experiencing 50% packet loss while
pinging the intranet site we use the
kola soft ping tool to visualize the
packet loss and ping response times from
Paul's computer to the intranet site
ping tool is a great tool for when
you're dealing with a network latency
issue or when you just want to monitor
performance over a period of time after
we discovered the 50% packet loss using
ping tool we ran a trace route which
showed us that the packet was taking two
different paths but it didn't tell us
which path was failing I'm not going to
get into the technical details of how
trace route works but suffice it to say
that the trace route does not always
tell the whole story what this means is
that you cannot always use a trace route
output alone to conclusively determine
the cause of a problem this is one of
those cases where we have to be very
wary of what trace route is telling us