In this section,
we will be covering how dynamic ARP behaviors work to keep entries current,
thankfully, this makes ARP issues rare.
However, due to differences in vendor implementations,
problems can and do occur.
You will see how Windows 10 successfully mitigates false
ARP entries and how Cisco routers do not.
I will show you how default dynamic ARP combined with certain types of IP to
MAC changes can lead to false information and stale ARP cache entries
resulting in loss data and loss of communication.
Of course,
you'll learn the most direct fixes for these issues including
how clearing the ARP cache can be a quick fix and how changing
ARP timers can alleviate problems, at least in the short and the medium term,
but because this may create more overhead in the network,
you'll see that more permanent fixes may need to be
applied to end stations in the network.
Before we see how ARP can fail due to stale or static entries,
we should review exactly what keeps ARP dynamic entries accurate.
There are three rules or behaviors which ARP uses to do this.
Once we know these, it will make sense why and when they can fail.
When your machine sends a packet,
it needs to be able to add both IP and MAC destination addresses.
The first rule is that if your machine looks in the ARP cache and does
not have a MAC address entry for the destination IP,
then send an ARP request and expect a reply from the owner.
ARP cache entry timers,
four systems to either proactively send ARP requests to keep caches
updated or if the timer for an entry expires,
the OS stack can mark it stale or invalid or erase the entry
which leads us back to our first rule.
Cleared and invalid entries must then renew through
normal ARP request and replies.
Either way, both of these make sure ARP information in a host cache is accurate.
Lastly,
when signature changes occur on a network card such as
changing the state to up or setting an IP,
a gratuitous ARP is generally sent to update the
network and keep everything accurate.
However, there are some gaps in the rules which lead to problems.
Let's see how stale,
false ARP cache entries can occur and negatively affect the network.
Since this will be our demonstration network,
I want to take a minute to talk about the setup.
I have a Windows 10 host at 20.
1.
15 on which I have set a uniquely obvious MAC address mimicking the
IP address in that it ends similarly with 2001.
0115.
Likewise, I have set up an Ubuntu host at 20.
1.
16 and made its MAC address end with 2001.
0116 there on a LAN connected to their Cisco default-gateway.
As you previously have seen,
gratuitous ARP and ARP cache timers limit the freshness of ARP information.
When timers exhaust depending on the OS implementation,
entries are automatically updated, marked as invalid,
or erased forcing requests for new information.
However,
what happens if network systems are updated with new IP to Mac bindings
which are not properly propagated to the network.
Some changes to network cards do not force gratuitous ARPs.
Why would this occur?
Depending on your OS protocol stack, the software controlling the cards,
or how a user makes a change to the system,
there may be no update.
In demonstration,
I will make a command-line change at the Ubuntu Mac address
which will not force any update to the network.
Other server and redundancy failover scenarios
allow MAC to IP changes to happen,
but they also do not proactively send gratuitous ARPs.
This seems to most often happen because there is no formal
state change for involved network cards and the vendor's
coding did not account for this.
At that point,
any systems holding old information prior to the change would have a false
entry in its ARP cache and will not properly encapsulate data.
This will lead to communication errors.
Short timers on most host operating systems like those on our Windows 10
host prevent this from being a common or lasting issue and you will see how
Windows 10 will correct for this exact problem.
However,
this issue can easily worsen with any systems which have very
long timers associated with ARP cache entries.
For example,
Cisco routers and Layer-3 switches have default ARP cache timers of 4 hours.
As a default-gateway with a false ARP cache entry,
critical data will not reach its destination.
This problem does not occur often, and although rare,
it is important to be able to recognize and know how to handle it.
Therefore,
I will show you how it occurs and describe your options in the upcoming live demonstration.