Hello, and welcome to this Protocol Deep Dive on ARP.
In this module, we will be covering several ARP variations.
After getting to see the basic function of address
resolution protocol in the previous module,
you'll see now how ARP is used in some pretty surprising and
creative ways with the networks that solve problems.
We're going to start with inverse ARP,
this is an excellent chance to see how ARP is used differently
from our common LAN ethernet to solve the problem of Layer-2
to Layer-3 address resolution.
In this section,
we'll use frame relay as a basis for understanding how the
inverse ARP packet and process works.
In my demo,
you will get the chance to see how this is applied in frame relay to
create dynamic mappings and I will show you how and why you might
deactivate inverse ARP to instead make static mappings.
Although obsoleted by more current methods,
I think it is important to take a quick look into an
old method of IP address assignment, reverse ARP.
From here,
I will show you how gratuitous ARP functions to update
systems and synchronize the network.
This becomes especially important for redundancy protocols which
handle failover of network links with servers,
and when using first hop default-gateway redundancy scenarios,
you'll see how this is configured and functions with
Cisco's Hot Standby Router Protocol, or HSRP.
One special variation on ARP is its use and
duplicate IP address conflict detection.
I'll show you how this works both without conflicts and when
duplicate IP addresses exist on the network.
Finally, with proxy ARP,
you'll learn how one system on the LAN can act and respond for other
devices to help forward traffic to remote systems.
Before you see how inverse ARP functions,
let's take a look at what we saw in the previous module with
basic ARP and compare it with inverse ARP,
also known as inARP.
First, let's remember that ARP stands for Address Resolution Protocol,
it's primary function is to resolve addresses.
With basic ARP, that means mapping a known Layer-3 IP address,
which identifies logical end points of network
communication to the Layer-2 data link MAC address,
which can be used to reach that IP.
What's important here for ARP is that it is used on a
shared access broadcast network.
This means ARP requests and replies can use a broadcast call
and response process to do the resolution.
Now let's compare that to the inverse ARP.
Inverse ARP functions, as the name says,
in the inverse by resolving a Layer-2 identifier to the OSI Layer-3 IP address,
it operates in basically the same fashion as ARP with one notable
exception to the broadcasting for responses.
In inverse ARP,
it's used on frame-relay and ATM networks primarily where routers know
the Layer-2 address associated with the connection.
These Layer-2 identifiers are associated with a virtual circuit,
which are used to switch and direct traffic over the networks to a specific
endpoint without the use of the Layer-3 IP addresses.
This removes the need for broadcast so there is no
reliance on IP for this process.
Inverse ARP serves the end stations to map the circuit
IDs to those associated IP addresses.
ARP and inverse ARP both allow static and dynamic mappings.
In my demonstration,
I will show you how inverse ARP functions to dynamically make the mapping,
then we'll take a look at why and how you can disable the
dynamic inverse ARP process to create static maps.
Let's take a look at a concrete example here by using a frame relay cloud.
This is set up by the service provider, again,
to switch frames at Layer-2 from end point to end point.
Our company's routers are the end points and are defined using a
Layer-2 frame relay ID called a DLCI number,
or D-L-C-I, which is for Data Link Connection Identifier.
The service provider is contracted to pass traffic from one DLCI to
another through their cloud over these virtual circuits.
What the company routers need is a way to map their known DLCI
numbers to the appropriate IP at the other end.
To make the mapping, inverse ARP sends a packet from the source DLCI,
which naturally gets switched to the cloud to the receiver's end point.
Please note that as we are concentrating on the function here,
I've simplified the packet details.
One item I left in was the option code.
The option codes are 8 and 9 for the request and response respectively.
Otherwise,
specifications for inverse ARPs packet details are essentially the
same as the standard ethernet ARP just that ATM,
or in this case, frame relay circuit identifiers,
those DLCIs, will take the place of the MAC addresses used on our ethernet LAN.
The inARP receiver, in this case,
the one at DLCI 302 will reply delivering the IP address as
part of the packet using its DLCI number,
that will be received back at DLCI 301 through the frame switch cloud,
and the inARP initiator can update its frame relay map and start encapsulating data to the other end point.