Welcome to the demonstration on inverse ARP.
We'll be using Cisco's iOS configured with frame
relay to see inverse ARP in action.
First,
I will show you the specifics of how frame relay's Layer-2
virtual circuit identifiers called DLCI,
or Data Link Connection Identifier numbers,
are mapped to IP addresses.
You will see the commands necessary to configure inverse ARP,
and along with Cisco's debug functions,
you will see how inverse ARP traffic does the job of dynamically taking that
DLCI number and translating it into an associated IP address.
I will show you how and why you can shut off the dynamic mappings
and what the consequences are for doing so.
Finally,
you'll see how to replace inARP dynamic mappings with static frame relay maps.
Let's start by taking a look at our frame relay configuration.
We'll be working with LabRouter3, it has a serial 0/0/0 IP address set to 192.
168.
10.
3.
Its Layer-2 identifier called the DLCI number,
or Data Link Connection Identifier, is set to 301.
Now I want you to think of that a lot like the MAC addresses in ethernet,
however, unlike ethernet, we're not sharing a broadcast LAN here.
Our LabRouter3 is connected into a frame relay cloud.
That frame relay cloud is maintained by the internet service
provider and is a circuit switch technology.
What that means is, within the frame relay cloud,
the internet service provider is going to use that Layer-2 DLCI number as the
way to circuit switch our packets over to our other end,
in this case, it'll be LabRouter1.
So we're going to take a look at how our DLCI numbers are
mapped to the IP addresses at the other end.
Let's bring up our LabRouter3 interface.
Alright, to get started, let's log into my LabRouter3,
issue the enable and my password,
and the first thing I want to do is I want to take a look at the
configuration on my interface serial 0/0/0,
which is facing the frame relay cloud.
So let's take a look at what's configured there.
First, of course, you've got our IP address 192.
168.
10.
3 with the mask, and of course, I've got encapsulation frame relay on.
Now currently, I have my interface in shutdown,
which means it's not participating and it's inactive,
but I do have frame relay inverse ARP automatically turned on.
Now that's the default on frame relay interfaces.
The other commands I have there, frame relay interface DLCI 301,
defines that actual Layer-2 address for the frame relay interface.
Now that 301 DLCI number is used by the frame relay cloud
to packet switch to my other LabRouter1.
The frame relay service provider has a switch path that's predefined,
that defined switch path can either be what's called a PVC,
a Permanent Virtual Circuit, or a switch virtual circuit.
Either way,
they know that this end point 301 has to pass traffic
out to the other end point 103.
The problem is when my router needs to encapsulate data,
it needs not only the DLCI number, but of course,
the IP address to be mapped to each other and this is
where inverse ARP comes into play.
It's going to do that mapping of DLCI number 301 to
the other end point's IP address.
Just like regular ARP would map an IP address to an unknown MAC address Layer-2,
inverse ARP will do the inverse, it'll take a Layer-2 address,
our DLCI 301, and map it to the IP address at the other end on LabRouter1.
Now my last command there,
frame relay inverse ARP interval 15 shortens our window for frame relay
inverse ARP messages so that we can pick them up sooner.
Here, I'm also going to add three debug commands.
These debug commands are going to add some ability to
see the frame relay inARP in action,
as well as how frame relay is going to use those
mappings for sending and receiving data.
So I've got debug frame relay adjacency PVCs so I can
see the adjacencies come up and down,
I'm also going to see any frame relay events,
and my last one is to look for packets being sent and received.
Now that we've got our debugging on, let's go and correct that shutdown command,
bring our interface on,
and see inARP do its job to map that DLCI 301 to
the other end points IP address.
Configure terminal will bring me up to the global configuration mode.
Interface serial 0/0/0 is going to allow me to
configure my frame relay interface.
Now as I said, inverse ARP is on my default on my frame relay interface.
This allows for dynamic mapping of those Layer-2
addresses to the Layer-3 IP addresses.
Even though it's on by default,
the command you want to use to turn on inverse ARP
on our frame relay interfaces, frame-relay inverse-ARP.
Of course,
nothing is going to happen until I issue the no shutdown
command to bring that interface alive.
It should come alive, it did, change date to up,
that's good, and momentarily, we should get some inverse ARP traffic,
there it is.
My serial 0/0/0 is preparing IP inARP on our DLCI 301.
It actually sent that inverse ARP request out and it's already
received a frame relay ARP input back in.
Now I want you to notice that the inverse ARP,
the inARP was received on 301 on that Layer-2 interface,
and immediately following that,
a frame relay adjacency was made on DLCI mapping to 192.
168.
10.
1.
Right there is the Layer-2 to Layer-3 mapping happening by inverse ARP.
So now what we're going to do is we're going to drop back down to privilege
exec mode and we're going to show you the frame relay map.
This shows us the result of inverse ARP having mapped DLCI 301
to the IP address of our LabRouter1 192.
168.
10.
1.
Take a look at the word dynamic there,
that tells us again that inverse ARP is dynamically doing this for us,
and as proof that our data can now be encapsulated,
we'll send a ping across, ping 192.
168.
10.
1,
and what we're going to see here is our frame relay
encapsulation on the outbound and inbound traffic on that
DLCI 301 for each 1 of our ping packets,
and those are, of course, being encapsulated with our DLCI number 301.
Now inverse ARP has dynamically mapped those DLCI numbers to IP addresses,
but in certain cases,
it might be better to shut that off and create a static mapping.
For example,
if you only have a few frame relay end points or if you've got a
complex point to multipoint frame relay cloud,
but you want to control which end points are statically mapped to which others.
So let's show you how to shut off inverse ARP and create that static mapping.
Move up to global configuration mode, interface 0/0/0,
and now to shut off the inverse ARP on that interface,
I use no frame-relay inverse-arp.
Now inverse ARP is off, however, my mapping still exists,
so I'm going to clear my cached dynamic ARP,
to do that, I'll issue clear frame-relay inarp,
and immediately, the frame relay adjacency is gone.
I'll show my frame relay map, and at this point,
my router has no way to encapsulate data to 192.
168.
10.
1.
So I'm going to have to go back to my interface and create a static
mapping because inARP is no longer doing its job.
To create the static mapping,
I'll issue frame-relay map ip and then the destination IP 192.
168.
10.
1 to the DLCI number of my interface, 301.
Now I have a mapping and an adjacency comes back up for frame relay,
this is going to allow encapsulation.
Now when I look at my show frame-relay map,
we can see that the mapping is now static,
no longer done by dynamic ARP.
And now that I have a way to encapsulate at Layer-2 and Layer-3,
my pings can go through.
Once again, inverse ARP is on by default on frame relay physical interfaces.
We can choose to shut it off, but if we do shut it off,
we're going to have to create the static mappings to be able to
encapsulate data across the frame relay cloud to a IP end point.
Now to close out,
I'm going to make sure I shut off all my debugging and I'm going to
go back and I'm going to erase my frame relay map and replace it with
my dynamic inverse ARP configuration.
Go back to global configuration mode, go back to my interface 0/0/0,
take off the frame relay mapping with the no frame-relay map ip
command reversing the IP address and DLCI number,
and to turn inverse ARP back on, issue frame-relay inverse-arp.
Show frame-relay map, again,
will show us that we've used inverse ARP as a dynamic mapping
between our Layer-2 and Layer-3 address.
Pinging the other end point shows that encapsulation is happening and inverse ARP is on the job.