Hello,
and welcome to this demonstration on losses of connectivity to hosts in the LAN,
as well as the default-gateway.
To understand what's going to happen in the demonstration,
let's take a look at the lab diagram.
I have a Windows 10 host at 20.
1.
15 and an Ubuntu Linux host at 20.
1.
16.
We'll take a look at what will happen in the network when there
is a loss of connectivity to the host 20.
1.
89.
When a system becomes unavailable on the LAN,
the symptom is that all of its services will,
of course, be unavailable.
Any machine trying to contact it will have some
failure within the user's software.
For example, if using web browser or email client,
you would see some sort of failure message to the user,
such as web page not found errors or the email server could not be contacted.
In my demonstration, I will simply ping from the Windows and Linux hosts.
As you'll see,
the ping response will vary based on the vendor's operating system,
but will usually be either destination host unreachable or timeout messages.
What we will see in Wireshark's sniffs on the Linux and
Windows hosts will also be a bit different,
but in general, and most importantly,
all attempts to contact the unreachable host through
ARP requests will remain unanswered.
This behavior of ARP is not really a failure, but a success.
If you have access to a protocol analyzer,
it lets you know that systems are broadcasting ARP requests for
that system and either the target is not on,
it is disconnected,
or something like a firewall is not allowing the ARP
request and response process to complete.
The solution is to fix the disconnected host if its services are
required or to make sure that any host or network firewalls can
allow necessary ARP and user traffic.
When a loss of the default-gateway occurs,
anything outside the LAN will be unreachable.
In most networks,
a significant amount of services such as email and web
are outside the local area network.
All users would be complaining that they can't get to anything,
and depending on the criticality of the LAN and the
state of mind of the end users,
panic might ensue and pitchforks could be brandished.
If we look at a network protocol analyzer like Wireshark,
this case will differ from the previous one.
You will see that all hosts trying to get to anything beyond the
gateway will be sending ARP broadcast requests for the gateway
and all ARPs will remain unanswered.
Since in most networks there is a large number of hosts using
services outside the local area network,
this will generate a significant amount of ARP traffic.
Of course,
the solution is to get the default-gateway back online and
servicing hosts as quickly as possible.
Let's move over to our Ubuntu host to check that one out first.
Alright, let's take a look at what happens when our Ubuntu Linux host at 20.
1.
16 tries to ping a system that's gone off the network at 20.
1.
89.
To see what's happening, I'll bring up my Wireshark,
and with an ARP display filter already ready,
I'll start my capture.
I'll bring up my command-line and I'll ping 20.
1.
89.
The Ubuntu Linux host is responding to my ping command by
telling me from my own network card at 20.
1.
16 that that host is unreachable.
Let's go take a look at Wireshark to see what's happening in the network.
In Wireshark,
what we're seeing is a series of broadcast ARPs that are who has for 20.
1.
89 tell 20.
1.
16.
Now that we've had this running for a while,
I'm going to stop my pings with a Ctrl+C,
we'll go back to Wireshark and take a look at all the traffic.
We can see that right away, my card at 20.
1.
16 was sending who has messages for 20.
1.
89.
We can see some normal traffic from hosts in the network looking for the
default-gateway and the default-gateway responding.
But since my card can't encapsulate data until it has an ARP cache entry for 20.
1.
89, it will continue to send broadcast ARPs looking for 20.
1.
89.
This is extremely common behavior.
When we try to contact hosts in the network that have
gone off or are no longer available,
we'll see broadcast who has messages and no data will be encapsulated or sent.
Now let's take a look at how Windows 10 handles things a little bit differently.
Within the Windows Wireshark,
I'll add an ARP filter and start my capture on Ethernet 0,
then I'll switch over to my command prompt and I'll ping 20.
1.
89.
Now although the host 20.
1.
89 is off, Windows will behave very differently than our Ubuntu Linux host.
In this case, we're seeing request timed out for all of our pings.
What that's telling me is Windows is actually trying to send 20.
1.
89.
Switching over to Wireshark, we'll see just what's happening.
We can see some normal ARP requests and reply for the default-gateway.
Then we can see our default-gateway asking who has 20.
1.
89, this is because Windows not having found an ARP cache entry for 20.
1.
89 is trying to facilitate communication by sending
its traffic to the default-gateway.
The default-gateway also doesn't have an ARP cache entry for 20.
1.
89 and is having to broadcast for it.
Then we can also see my Windows 10 host at 20.
1.
15 send a who has message for 20.
1.
89.
Next, my host sends an ARP request and reply for the default-gateway,
and again, the default-gateway is broadcasting ARPs to find 20.
1.
89, another ARP request and response for the gateway from 20.
1.
6, and then we're back to the gateway looking for 20.
1.
89.
No matter who sends an ARP broadcast request for 20.
1.
89, there is no response.
To really understand what's going on here,
I'm going to change my filter to display only traffic from my MAC address.
Notice that the first packet is an echo ping request from my card to 20.
1.
89; however, if we look at the ethernet header,
it's coming from my MAC address, but the destination is the Cisco router.
When my Windows 10 system didn't find an ARP cache entry,
it elected to try to send the ping through the default-gateway,
that's why our default-gateway was trying to send ARPs for 20.
1.
89.
Now we can see my own card sending a broadcast for 20.
1.
89 and a normal ARP request and reply for my router.
Again, my card is sending 3 more pings to 20.
1.
89, but the MAC addresses again show it's trying to use the router,
then a browser announcement from Windows 10,
and finally, a broadcast ARP from my card to 20.
1.
89.
Now although Windows 10 shows a different methodology than the
Ubuntu Linux host for trying to find 20.
1.
89, we can still see the same general behavior that all ARPs for 20.
1.
89 remain unanswered.
Next,
let's take a look at how a default-gateway failure affects hosts in the LAN.
I'm going to start a new capture and I'm going to put a
new ARP filter in my visual filter line,
and to create a default-gateway loss, I'm just going to go to my router,
I'll log in, I'll move to global configuration mode,
I'll move to the interface servicing my LAN,
and I'll tell it to shut down.
Now that this interface is down,
it'll become unavailable for all hosts on the LAN.
So let's go back to Wireshark and see what's happening.
When we lose our default-gateway, all connectivity to the outside world stops.
At that point,
every host since it's using the default-gateway is going to be
continually ARP-ing for that default-gateway.
So here we can see pretty much every station in my LAN that's
awake sending who has broadcast messages for 20.
1.
This is classic behavior when the default-gateway is down.
Of course, all the users are complaining that they don't have web access,
they can't get their email, they can't do any of their work,
but if you have a sniffer running within your network,
you're going to see ARP traffic from every host that's on
looking for the default-gateway IP address,
of course, since these are broadcasts, they reach every host on the network.
This should immediately tell you,
you better hustle to get that default-gateway router
back up or notify the people who can.
Of course, looking in your application responses for failures,
testing with pings is useful, but if you also have sniffer traffic,
you can easily tell when a host is not responding to ARP broadcasts
and you can clearly tell when the default-gateway is down because all
hosts are going to be ARP-ing for that.
As a bonus,
I want to take a look at what happens when you've got a host
either plugged into the wrong VLAN or given the wrong IP
addressing scheme on its network card.
Take a look at our Wireshark and here you can see
scrolling through a host at 20.
2.
17 is continually ARPing for 20.
2.
75.
Any time you see ARPs that don't match your IP addressing scheme,
either that host is misconfigured for the wrong IP address or it's
potentially plugged into ports in the wrong VLAN.
In the case that its imports in the wrong VLAN,
we really need to either reassign the port to the right VLAN or change
the cable connection to a port in the correct VLAN.
And of course, if it's an IP addressing problem,
you need to find that host and change its IP address to meet the scheme of the local area network.