[Autogenerated] Now we're over on
Gabriella's computer. We know the DNS
server for N S primary is down. We'll
start a fresh pea cap so we can see it
from Gabrielle is perspective. Her
configuration is a bit different from
Jayden's. Instead of the stub server in
the New York office, she's configured to
use the primary and secondary servers in
Atlanta. Let's see what happens when she
tries to browse out to w w dot
Globomantics dot com. Well, that seemed to
load up. Okay, It's always good to
capture, to see it from the user's point
of view. Since they're the ones who
registered the complaint, we'll check
another site just to be sure. A. That one
takes a bit longer. See how it's happening
before the page even tries to load again.
Big clue for DNS. But the pages do load
and the sales page loaded the fastest,
just like it did for Jayden. But remember
that address will always be in the local
DNA servers cache because it's part of our
zone. Let's load a few more that I know
are not in any of our DNA servers cache.
I'll go to Cisco. Let's see how it does
loaded Great. Now we'll be able to search
for that when we look at the peak app. But
before we do, let's stop the service on
the secondary DNA server and see how that
affect S3 users. Now we're getting some
red errors of port unreachable. Gabriella
wants to check her cache, and sure enough,
both Cisco and the sales server are in her
cache. Let's flush her DNA's cache so that
she has to go ahead and make those DNS
queries. Now we can go back to the browser
and refresh the page is suddenly sales
want to load, and we've lost our
connection to Cisco Notice. Even the
browser tells us the issue is name
resolution. It's not that the connection
is a problem. When we look at the packets
notice, there's our query for Cisco. Com
we can put in a filter for DNA's matches.
Cisco to focus on just those DNA's
requests. Right off the top, we see
Gabriella go to the secondary server for a
standard query for cisco dot com. She
doesn't get a reply, so the next packet
219 milliseconds later, she sends a
request to the primary server for 0.5,
remember 0.5 doesn't have a firewall for
its ICMP, so it sends a response of port
unreachable 0.6. Just ignores her. Either
way, she's not getting a response. If we
know the box is up, silence means firewall
and an ICMP port. Unreachable means an
explicit no. So, of course, what does any
good client do? They ask again, this time
waiting a second. No reply. Ask again,
waiting two seconds so you can see if we
can't get to DNS how long it takes before
the browser gives up between the query
that I have highlighted and the response
that actually took 3.345 seconds. That's
how long Gabriella looked at her browser
with nothing happening to make it a little
easier to follow the flow. I'm going to
right-click on the addresses and change
the resolved name. That way, it's easier
for me to tell that 0.6 is the secondary,
and Docker five is the primary notice how
long it takes for the client to send the
DNAs retransmission, asking again to the
secondary and then to the primary and then
back to the secondary. That time of
silence just keeps adding up. No wonder
the users were complaining. Let's start in
a secondary backup now if we reload the
page on Gabrielle is computer sales a
loads with no problem. And now that our
stub server can do get answers from the
primary and secondary, Jayden will be
able to browse again as well. When we look
at the packets on the stub server in New
York, we can see all of the errors where
the stub server try to request an S O a
record from the primary only to receive an
ICMP airport unreachable in reply. The
candy striping pattern that we see along
the right next to the scroll bar is
something we never want to see. That's a
request with a reply of no pattern.
Stripes are not a good look in wire shark.
The big clues in this outage scenario is
that some of the requests were slow and
yet others weren't. If we have eliminated
a network issue, that clue usually means
that some of the requests are in cache and
some are not. Jayden was getting responses
from cache from the stub server and
Gabriella was getting responses from the
secondary server. That was up. No one was
getting responses from the primary. That's
why we look to it. First we could ping it,
but we couldn't get DNA SAP. Watching
everything in the packets is one way to
see exactly what's going on. We also could
have gone immediately to the servers to make sure that the service was up.