Welcome to this demonstration on proxy ARP.
In this demonstration,
we'll be looking at how hosts use routing and the default-gateway as
their normal LAN function for forwarding data.
Then I will show you how proxy ARP functions by using Cisco's default proxy ARP
configuration to compare against the normal LAN functions.
I'll cover the reasons for and against using proxy ARP and
why it might be better to shut it off.
And finally, I'll show you how to disable proxy ARP on Cisco devices.
To begin with, let's take a look at our network diagram.
On the left, we have the network 20.
1.
0/24 and within our host 20.
1.
13 with the same mask separated by the router,
and on the right, we have our network 20.
2.
0/24 and the host 20.
2.
2 with the same mask.
I'll use this configuration to show you how normal routing occurs and
use that to compare against how proxy ARP functions.
To start, I'll confirm the Windows IP addressing with ipconfig.
There we can see its IP address 20.
1.
13 with that /24 mask and the default-gateway set to 20.
1.
Within the ARP cache, we can see the default-gateway 20.
1.
1 with the MAC address 00:23:5e:e2:5f:ee.
As I would expect,
there are no other dynamic entries besides IP addresses from the local LAN.
Moving over to the router,
I'll use show ip arp to look at the router's ARP cache and confirm
that the FastEthernet 0/0 interface is set to 20.
1.
1 with the MAC address ending in 5fee and the
FastEthernet 0/1 interface is set to 20.
2.
1 with the MAC address ending in 5fef.
We can also see our host at 20.
2.
2 with the MAC address 00:50:b6:15:b1:ca.
To be able to view ARP traffic on our router, I'm going to turn on debug arp.
To confirm connectivity across the inner network,
I'm going to return to Windows and ping 20.
2.
Because 20.
2.
2 is on another network from our host perspective,
our host is going to route traffic through the default-gateway at 20.
1.
Now even though we've seen a couple of ARP messages in our Cisco command prompt,
let's take a look at them and see what's really happening.
The first is an IP ARP request from the source of 20.
2.
2 looking for 20.
2.
1.
In other words, our host on the 20.
2.
0 network is looking for its default-gateway.
The default-gateway sends an ARP reply sourced at 20.
2.
1 back to our host at 20.
2.
This is normal LAN behavior.
The second pair of ARPs is essentially the same thing.
Our host at 20.
1.
13 sent an ARP request to find the default-gateway at 20.
1.
1 and our default-gateway sent an ARP reply sourced at 20.
1.
1 back to our host at 20.
1.
13.
Both hosts are doing their normal behavior to ARP for their
default-gateway within their local area network.
Now let's take a look at a proxy ARP configuration and turn this
into a transparent gateway bridging scenario.
Take a look at our host at 20.
1.
13 in the diagram.
In this case, we're going to change its mask to /8 or 255.
0.
This way,
the host will believe that anything that starts with 20
is within its local area network.
Because of this,
it'll generate ARPs for anything that I want to reach that starts
with 20 and this will include any hosts on the 20.
2.
0 network.
To make this configuration change,
I'm going to bring up my Ethernet0 and I'm going to change the
TCPIP property so that the mask reads 255.
0.
In this way,
it's going to believe that everything starting with
20 is on its local area network.
I'm going to close out and return to my Windows command prompt.
Back in my host command prompt,
I'm going to clear the screen and I'm going to check its ARP cache.
Now still, there is nothing for the 20.
2.
0 network, so I'm going to ping 20.
2.
2, and in this case,
our host is going to believe that's on the same network and generate ARPs.
Here, we can see proxy ARP in action.
We can see the host 20.
1.
13 sending an ARP request for the destination of 20.
2.
The router then sends an ARP reply that 20.
2.
2 is at the MAC address 00:23:5e:e2:5f:ee.
That's its own FastEthernet 0/0 MAC address.
That's exactly the behavior of proxy ARP.
Of course,
we still see a pair of ARP request and replies for both
hosts looking for their default-gateway.
The 20.
1.
13 host is looking for 20.
1.
1, it's default-gateway, and our 20.
2.
2 host is looking for its default-gateway at 20.
2.
1.
If I check my ARP cache on my host again, now I can see that entry, 20.
2.
2 is at the MAC address of my router.
Notice that the MAC address matches my default-gateway.
This is a key indicator that proxy ARP is functioning when a remote host IP
address is at the MAC address of something local on my LAN.
Let's do that again by clearing my screen,
deleting my ARP cache with arp -d and an asterisk to clear it all out,
check my ARP cache with arp -a and we can see that there is nothing in there,
not even the default-gateway.
So I'm going to ping 20.
2.
2 and my host, assuming that that's on my local area network,
is going to send an ARP request and reply and my router is
going to answer it with the proxy ARP.
Right here,
we can see that ARP request and the router's proxy ARP reply saying that 20.
2.
2 is at the router's MAC address on FastEthernet 0/0.
Again, if I check my ARP cache within my host, I can see that the host 20.
2.
2 appears local but is really at my router's MAC address.
Now in most modern networks, we shouldn't need proxy ARP.
The normal routing function of hosts and routers should make
the determination of what's local and what's remote and ARP
should be able to resolve anything on the local area network
including the default-gateway.
In some cases,
you may actually want proxy ARP to solve some problems of host to host
connectivity through transparent gateway bridging.
It may be useful if you're migrating hosts from a larger subnet into
smaller ones and you want to maintain connectivity while the IP
conversions and mask conversions are being done.
It might also be useful in some inter VLAN routing
scenarios where you need to maintain connectivity between
hosts that really should be remote, but need to appear local to each other.
One of the problems we can see here from proxy ARP is that hosts with
misconfigured masks are going to generate more ARPs on the network.
Our host at 20.
1.
13/8 is going to generate ARPs for anything that starts
with 20 and that would include up to 16.
7 million different IP addresses.
Not only that,
the router generating proxy ARP replies will add still more ARPs to the network.
Besides the increase in ARPs and the larger ARP cache on our host at 20.
1.
13, there are some significant security issues to consider.
If our router is providing proxy ARP services,
it might actually provide connectivity between hosts
whose data should really be routed.
Another situation can come in the form of a denial of service attack where an
attacker can overwhelm the router's resources by forcing a proxy ARP router
to handle too much ARP traffic or my spoofing the proxy ARP router cause
hosts to forward traffic to a blackhole.
Now even though proxy ARP is on by default on our router and may seem helpful,
in general, because of its overhead on the network and its security issues,
I'm going to teach you how to shut it off.
Let's return to my router interface, go to global configuration mode,
and to the interface FastEthernet 0/0.
To shut off proxy ARP on any Cisco device,
at the interface configuration, use the no ip proxy-arp command.
I'll also move to my interface FastEthernet 0/1 and shut it off there.
Now even though I've shut off proxy ARP,
what's interesting is my misconfigured host at 20.
1.
13/8 will still have connectivity across the router to 20.
2.
2, but instead of using proxy ARP, it will go back to routing that traffic.
Let's return to my host, clear the screen, and I'll check my ARP cache.
We can still see that it has the remote host 20.
2.
2 listed with the MAC address of my router.
So I'm going to delete that with arp -d 20.
2.
2, check my ARP cache to make sure it's gone.
Now when I ping 20.
2.
2, my misconfigured host will still send an ARP to the router.
We will see this in the debugs, but since proxy ARP is turned off,
my router will not reply.
At that point, my host will make a routing decision to route the traffic to 20.
2.
2 through its default-gateway.
Let's take a look.
Here, we see the ARP request for 20.
2.
2, but notice my router is not responding.
We do see the return to normal behavior where the host 20.
2.
2 is ARP-ing for its default-gateway and 20.
1.
13 has ARP'd for its default-gateway.
However, no matter how hard my host at 20.
1.
13 tries to ARP for 20.
2.
2 now that proxy ARP is shut off, my router won't reply.
When we check our pings,
we see that the first one was a response of destination host
unreachable because there was no ARP reply to 20.
2.
At that point, our host shifted over to using the default-gateway at 20.
1.
1 to forward its traffic and the last 3 pings succeeded.
Now what we should do to finally correct the situation is return to my
host's IP address configurations and reset the IP address and mask to
match the addressing scheme for the network.
So I'm going to set its mask to 255.
255.
0, which will allow it to stop ARP-ing for things off of the local area network.
Let's close out of the configuration so we can see what's been happening.
Turning to my command prompts,
I can see in the Cisco router debug that having set the IP address
on the interface has forced my client to do its duplicate IP address
detection with the three packets here,
and not having heard any conflict response,
of course, my client is going to send out a gratuitous ARP right there,
and after it's updated the network with the gratuitous ARP,
it checks its default-gateway with an ARP request
and a reply back from my router.
Finally, what I want you to remember is that proxy ARP has its place.
It automatically handles connecting local network hosts to remote VPN,
serial,
and modem hosts to bridge virtual machine guest networks
to the real world and to help forward traffic to IP
addresses hidden behind NAT agents.
In these applications,
configuring the specific management interfaces is
what determines the proxy needs.
As for the transparent gateway bridging I just demonstrated here,
it can be convenient,
but unless you have specific well-defined and design needs to use it,
proxy ARP may be on by default and can create overhead
and security risks in the network.
Therefore, it would be better to move to a more solid design and disable proxy ARP.