In this section, we will be covering static ARP use cases.
I will cover the pros and cons and compare static ARP against dynamic.
Then, you'll see how static ARP problems stack up against its benefits.
By the end,
I am pretty sure I will have you convinced to make sure that any
static entries in your network are eliminated.
In both the presentation and demonstration,
I will show you how to identify the symptoms of static ARP problems,
and in the demonstration, I will show you how to remove them from Linux,
Windows, and Cisco systems to correct any problems.
Static ARP is simply where one or more permanent entries
are added to a system's ARP cache, they can be made anywhere in the LAN,
but should only be made pointing to systems with static IP
addresses like a server or the gateway as their IP to MAC
address mappings rarely change.
Once configured,
a system's static ARP entry will never time out and does not get
updated through any dynamic ARP processes.
In the case of our example LAN,
we might see static entries configured on hosts pointing at the default-gateway,
a system with, we hope, a very stable IP and MAC address.
As hosts and servers have fairly short ARP cache timers,
the thought is that static entries would reduce the need to send ARP requests to
the router and the router would never have to send replies.
The idea is to reduce ARP request and reply traffic in the
network leaving more space for other traffic.
My own analysis on both the large LAN network over 500 hosts and small
under 50 has shown that ARP traffic only accounts for about 2 to 3% of the
overall bytes sent to and from a normal host.
As I will show,
compared to the management overhead of static ARP entries
along with some of the problems they create,
dynamic ARPs traffic is little to worry about.
Another place static ARP entries could be configured is on the
gateway and perhaps end stations pointing at servers with
which they communicate regularly,
this would alleviate the need to Exchange ARP messages with common and
static network resources like our example web server.
As well,
static ARP cache entries like these are purported to be a form of security.
Because they do not allow dynamic updates to the systems,
the static entries would prevent an attacker poisoning host and gateway
ARP caches which would allow redirection of traffic to the attacker and
some spoofing in man-in-the-middle attacks.
As you will see in the upcoming demonstration on static ARP,
the overhead and problems caused are usually not
worth the improvements to security.
Furthermore, in the module on ARP related security issues,
you will see better forms of security than static ARP entries can provide.
For these reasons along with others I will describe in coming videos,
static ARP entries should generally not be used.
A common problem we can see from static entries is during
normal LAN maintenance upgrading and repair.
For example, for some reason,
the network team needs to take down the primary gateway to do an upgrade,
a migration, or some service.
They'll stand up a new router to take its place.
This will be at the gateway's IP address so that there
will be no interruption in service, but it will have a different MAC address.
As soon as this happens,
all static entries will have the right IP for the gateway,
but the wrong MAC.
No data will flow off the local area network.
One solution is that you can accept this and if you have
tight control over network change, you may wish to adjust static entries.
In my opinion, timing this with other network changes,
administrative overhead of change and verification,
and finally keeping static entry documentation up to date
is not at all worth the management overhead or any
security and traffic efficiencies.
Of course, the same issues can occur with servers in the network.
Problems may be just like the gateway due to a simple hardware migration.
As well, server teams naturally want redundancies in their servers.
These can take the form of multiple network cards in
one server or multi server clusters.
The same IP on the servers will be set up to load balance traffic across hosts.
Using various network cards, and depending on the vendors implementations,
different MAC addresses.
In the case of load balancing,
symptoms on systems with static entries will probably vary,
it will appear somewhat random and sporadic depending on which
host is being serviced by which server card.
Along with the load balancing routing, some hosts will have no loss,
some may flip flop in connectivity, and some will lose connectivity altogether.
This can be very frustrating.
Due to the reasons already shared and the increased
complexity during troubleshooting,
I will show you how to remove static entries in our demonstration.
If there are changes to systems IP to MAC address
combinations such as when a network card is changed,
a system is swapped out for another using the same IP or in
redundancy and clustering technologies,
then static mappings must be manually updated to reflect.
If static entries are not removed or updated with network changes,
problems will occur.
Symptoms are generally a loss of connectivity,
they can seem intermittent as some systems using dynamic ARP function
fine and systems with incorrect static entries do not.
Symptoms can be even more sporadic if load balancing technologies allow some
connectivity and some loss making troubleshooting painful.
In summary,
static ARP management creates overhead in setup
whenever there are network changes, in verification and validation steps,
in documentation efforts, and in network troubleshooting.
This completely outweighs any benefits associated with
miniscule improvements static entries might give in
dynamic ARP processing or security.
Acceptance of very rare cases of stale false cache entries, dynamic ARP gracefully handles almost every problem.