Hello,
and welcome to Pluralsight in this deep dive into Address Resolution Protocol,
or ARP.
My name is Jim Rizzo.
I am a network engineer and a security leader with over 20 years of LAN,
WAN, wireless, and security network engineering experience.
In this course,
we will be covering significant territory on one of the
most fundamental protocols in networking.
A deep understanding of ARP is necessary for anyone looking to have strong
working knowledge of how network systems communicate and be able to
effectively troubleshoot local area network problems.
In this module,
we will cover the fundamentals of Address Resolution Protocol
starting with its purpose and function in the LAN.
This will include the standard ARP messages used in
communicating with things both on the same LAN,
as well as with remote systems not on the LAN.
By the end,
you'll be able to view ARP caches in both Linux and Windows host systems,
as well as in Cisco routers.
In our demonstrations, you'll see live captures of ARP protocol,
as well as how to manage the cache configurations,
this will include knowing how and when to clear an ARP cache,
add or delete static ARP entries, and even where appropriate,
how to change the ARP timers.
Finally,
we'll show you how you can use ARP for
troubleshooting common problems in your LAN,
this will include showing you how to localize systems in
complex networks and how to spot and fix host or
default-gateway connectivity issues.
ARP's most basic purpose is to provide a way to map logical IP addressing of
other LAN systems to their physical hardware MAC addressing.
To understand why we need this,
we should take a look at some message from System A to System B.
In computer communication,
the IP address is a logical end-to-end addressing system,
which delivers packets from their source to
destination wherever they are in the world.
Now as in this case,
it could be on the same network or the two systems could be on
remote networks much like you could go from your house to your
neighbors or to some building in a faraway city.
Just as building addresses do not tell you much about the
roads you need to traverse to get you there,
IP addresses are useful for getting data from end-to-end,
but do not help with forwarding data over various different physical links
with different types of addressing such as your local LAN,
cell, satellite, frame relay, and serial networks,
for example.
Remember that address resolution protocol provides a method for mapping
known logical IP addresses to an unknown physical address.
To do this, physical hardware addressing needs to be appended to our IP datagram.
On our ethernet networks, this addressing is,
of course, our well-known MAC addresses.
In this example, System A would know its own MAC address.
The problem is, however, that System A may not know System B's MAC address.
There is no guarantee that any IP addresses at any given MAC address.
The IP to Mac parings will also change over time as your
system gets new IP addressing through DHCP.
It is also important to note that since our data may be going beyond our LAN
and over various networks possibly with different paths,
it is impossible to know what every physical address will be.
This is just like leaving your home on a trip,
you most likely do not know every street name in your path.
Since our system cannot know in advance what MAC
address is appropriate for any given IP,
a process was needed to allow a dynamic mapping to occur,
which would take any given IP address to which our computer wants to
send data and return a physical useful address,
a MAC address.
Address Resolution Protocol comes into play to map the target IP
address to a useful physical address for your LAN.
Once this is done,
destination MAC addressing can be added to our data
to get it across a physical link.
Let's review ARP's function and process.
A system requires sending data to another system somewhere in the world,
this could be email, web browsing, a phone call,
or just a simple ping.
The system process that requested the communication will have
to supply a known source IP address from your systems
configuration and a destination IP, for example,
from a DNS query result or a ping input.
Regardless of whether that target IP is on your LAN
or remotely out on the internet,
the data will require some additional physical link information be
appended before it can be shipped out your network card.
This is where ARP will perform its functions to
learn and cache that information.
Your system will naturally look in its memory location called
the ARP cache for an IP to MAC mapping.
If there is one there, the listed MAC address can be used.
If not,
address resolution protocol provides dynamic processes for
learning and caching the correct physical hardware addressing
to use for that target IP address.
Before we get into live captures,
let's take a look at a typical LAN to see just how ARP
dynamically learns and caches information.
Here, you see the Globomantics satellite office local area network.
There are three example hosts, each with its IP and MAC addresses,
and the default-gateway router at 10.
5.
1.
In this case, we will examine how the host at 10.
5.
101 uses ARP to resolve the MAC address of 10.
5.
102 on the same LAN.
Let's just keep it simple and assume our user there pinged the IP address 10.
5.
102.
To be able to send the ping, the system 10.
5.
101 will put on the source and destination IP addresses which it has from
the local configuration and the user's ping command.
Then to send the ping,
the system will need the source and destination MAC addresses.
Assuming these computers have never communicated before,
it will check its ARP cache and find no entry there for 10.
5.
102.
This will initiate the first ARP message.
ARP first sends a request message.
We'll take a look at more of ARP's detail later in
our live capture demonstration.
This ARP request has an option code of 1,
which marks it as a request and has a really simple message,
who has IP address equal to 10.
5.
102.
To the ARP request,
an ARP type field is added so the receiver knows an ARP message is contained.
Then a source Mac from its own NIC is added in a destination
broadcast MAC address of all Fs is added.
Since this is a Mac broadcast, when sent on the LAN,
it arrives at all interfaces.
Once the ARP request contents are examined, only 10.
5.
102 is going to process this and respond.
10.
5.
102 goes ahead and places an entry for 10.
5.
101 with a MAC address 01:01:01:AA:AA:AA in its ARP cache,
then it can formulate an ARP reply.
Here you can see the option code 2 marking this an ARP reply
with a response message that IP address 10.
5.
102 is at MAC address 02:02:02:BB:BB:BB.
Notice the header difference from the ARP request though,
it is still marked as an ARP packet,
but the source and destination MAC addresses are specific,
this means it is a unicast and it will be delivered
directly to the requesting system.
Once delivered in process,
the original requestor can add an ARP cache entry and complete its ping
packet with the necessary destination MAC address for 10.
5.
102.
Here,
we're going to take a quick look at how it differs when
data is leaving our local area network.
In this case,
our user is going to be opening their home page to go
do some studying at Pluralsight.
com.
When they open their browser,
it's going to create a GET request for the web page.
Of course, DNS is probably going to turn that name, Pluralsight.
com, into its associated IP address so those headers can be put on.
We have a source and destination IP, and again,
our machine is going to have to have a set of MAC addresses to put on.
It puts on the source MAC address of the local card,
but the routing function that determines that Pluralsight.
com's IP address is not on the same local area network is going to need to use
the default-gateway to send data off the local area network.
This is where things start to differ.
An ARP request is going to need to be built so that we can have the MAC
address of the default-gateway within our ARP cache.
Here,
you can see the ARP request again option code 1 now
with a message who has the IP 10.
5.
1.
Now the local system has that IP address in its TCP/IP configurations either
from DHCP giving it to it or from a static configuration.
Either way,
we still need to resolve the MAC address of the default-gateway so
this ARP request will have a source MAC address of,
of course, the network card on the local machine,
and again, it's going to be a broadcast to go out on a local area network.
Since it's a broadcast, again, it arrives at all interfaces on the network,
and again,
only the system for which that message was intended is going to process it.
What this means is the router is going to build an ARP cache entry for 10.
5.
101 with that same MAC address.
But now, the router can build an ARP reply,
and again, this ARP reply has an option code of 2,
it'll report that 10.
5.
1 is at the MAC address 04:04:04:DD:DD:DD.
An ARP header is going to put on to let us know that ARP is the
contained message and the source will be the router's MAC address and
the destination will be our originating machine.
Now since that's a unicast,
it should be delivered back to our originating machine only and
that entry can be added into its local ARP cache.
At that point,
the system can then build the message with the
destination MAC address of the router,
which means the local LAN can deliver to the router.
From there, the router is going to have to strip off the Mac addressing,
look at the destination IP of 54.
218.
36.
2, make a routing function look up,
and build new physical link headers to go out onto the wide area network.
So let's take a look at that cache.
Every active ethernet card in a system will have its own ARP cache.
The ARP cache is a memory location on a local system storing the IP to MAC
address mappings used for sending data to other systems.
Note that this does not store the local system's IP and MAC address.
Here, you can see the host IP address of 10.
2.
34 and the arp -a command which displays the IP to MAC mappings.
Notice the first two our dynamic types.
These both represent other systems on the LAN and are
learned and forgotten on an as needed basis.
There are three static mappings which the host itself programmed.
The first, 10.
2.
255 represents the broadcast address for the local network.
The last two, starting with 224,
are both multicast IP addresses and are mapped to their
associated multicast map address.
The 224.
0.
22 is the Internet Group Management Protocol,
IGMP,
and allows the host to report their IP multicast group
memberships to neighboring multicast routers.
224.
0.
252 is the Link Local Multicast Name Resolution Protocol,
LLMNR,
enabling name resolution in some cases where normal
DNS name resolution is not possible.
Before we begin our demonstration,
I'd like to take a moment to review some of the details
regarding those ARP cache entries.
Every host has a set of mappings for every active interface,
every cache can and probably does include both static and dynamic entries.
The dynamic entries were learned from the ARP request
reply process you just learned, but the entries have timers associated with them.
What this means is if two systems do not
communicate for a certain amount of time,
the ARP entry for that host will be removed.
Now it is important to note that in general every operating system
stack is different in what that time will be.
Not only that,
but there is a randomization factor which allows that time to
vary within a certain timeframe window.
For most host OSs, that window ranges from about 15 seconds up to 10 minutes.
It is possible in some operating systems to alter that window,
however,
changing this may result in more unnecessary ARP traffic or
stale entries lasting too long in the cache.
In general, it's not necessary.
In routers and in some network equipment,
however, this entry can be hours,
this can lead to issues where an ARP cache in the router has stale information,
especially if your LAN has a lot of changes.
Therefore,
we're going to show you in the demonstration how to
alter this on a Cisco router.
Another more common technique to handle possible stale entries in an
ARP cache is just to clear the dynamic entries.
Since most entries are learned dynamically and our LANs are
generally pretty consistent with IP and MAC addresses,
clearing a host or a router's ARP cache may be all that's
necessary to solve the issue of stale information.
As I showed you before,
there are static entries prebuilt by the OS for common
functions such as multicasting and broadcasting.
Although it is rare, as a system administrator,
you can also add or delete static entries.
You might want to do this if there are two systems on the LAN which
constantly communicate and you want to reduce the amount of ARP broadcast
traffic or make sure their ARP caches are more stable.
However, the overhead for doing this and managing changes in a network,
not to mention increasing the complexity when troubleshooting,
usually do not outweigh the very low overhead caused by the ARP dynamic process, therefore, static ARP entries are rarely used.