Hello, and welcome to this demonstration on proxy ARP overhead.
You are going to see how using proxy ARP can decrease your router or other
proxy devices performance while dealing with more ARP traffic,
how it can increase unnecessary bandwidth utilization
for ARP traffic in the network, and force LAN hosts to have larger ARP caches.
Finally,
we will see how to remove the proxy function and force our
end stations to use routing instead.
Let's get started by looking at the configuration
I'll use during the demonstration.
We'll use our Windows host at 20.
1.
15 configured with a /8 subnet mask.
It will be receiving proxy ARP responses from our default-gateway at 20.
1.
1/24, and on our gateway router, I'll configure a variety of remote subnets.
There will be a physical network off of
FastEthernet 0/1 using the IP address 20.
2.
0/24, and to simulate some large LAN networks,
I'll add three loopback interfaces, Loopback 37 at 20.
4.
37.
0/24, Loopback 123 at 20.
88.
123.
0/24, and for good measure, Loopback 96 covering the 20.
5.
96.
0/19 network.
Because our sender has a /8 mask,
it's going to assume that all of these remote subnets are
local to it forcing it to send ARP requests.
Our Cisco gateway router having the default configuration of proxy ARP
enabled is then going to have to respond to these ARPs.
Let's move over to our router's configuration.
I'll bring up my router's command prompt.
Let's first look at the already configured interfaces.
We've got our FastEthernet 0/0 serving our local host,
our FastEthernet 0/1 serving the 20.
2.
0 network, and now I'm going to simulate a variety of subnets,
which this router might support.
These could be connected at physical interfaces with actual live hosts,
but here, I'll simply create some loopback interfaces.
I'll move to global configuration mode and create interface Loopback 37.
I'll put an IP address on it of 20.
4.
37.
1 with the /24 mask.
I'll create interface Loopback 123, I'll put an IP address on this of 20.
88.
123.
1, also with a /24 mask.
And finally, I'll create interface loopback 96 with an IP address of 20.
5.
96.
1, and in this case, I'll set the mask to 255.
255.
224.
0.
Let's show our interfaces.
To be able to see how proxy ARP affects our router,
I'm going to turn on debugs for ARP.
Now this is not something I recommend on a production router as it can
create serious overhead on the router processing the debugs.
Now let's go over to our Windows command prompt.
Before I get started on the pings,
I'm also going to bring up a Wireshark capture to see the ARPs in the network.
I'll put an ARP filter in and start my capture on Ethernet 0.
Returning to my command prompt,
I'm going to ping 1 of the loopback interfaces 20.
88.
123.
1.
To verify the proxy ARP is handling the situation rather than routing,
I'll check my ARP cache.
Notice that our default-gateway, 20.
1.
1, is there with the MAC address 00-00-0c-07-ac-01.
Notice that we've got other dynamic entries for things beginning with 20,
all appearing at the same MAC address of our router.
If I check my IP address on my system, we see why.
The IP address is 20.
1.
15 with a /8 mask,
which makes this machine assume that everything that starts with 20 is
on the local area network and forces it to send ARPs.
Since my router has proxy ARP enabled, it then needs to respond.
Let's see that response inside the router.
Here, we see the Windows system sending an ARP request from 20.
1.
15 looking for 20.
88.
123.
1 being received on FastEthernet 0 and our router sent an ARP reply that 20.
88.
123.
1 is at the router's MAC address.
If we look in Wireshark, we'll see the exact same traffic.
An ARP broadcast who has message from my Windows machine looking for 20.
88.
123.
1, please tell 20.
1.
15.
And my Cisco router's response that IP is at the router's MAC address.
Now of course, this is just one ARP request and reply pair,
but let's multiply that by potentially thousands of
destinations over hundreds of hosts in our network.
I'm going to simulate that by using an IP scanner.
In my IP scanner, I'm going to add the network 20.
4.
37.
0/24 and I'm also going to add the network 20.
88.
123.
0/24.
This'll scan around 500 destination IP addresses.
I'm going to start my scan on those IP addresses and
let's take a look at what's happening.
While that's scanning,
I'm going to bring up the router's command prompt and we can see
it's going nuts with ARP request and reply traffic.
If I move over to my Wireshark, we can see the same thing,
pages and pages of ARP request and reply traffic.
This is hammering the router's resources and
hammering the network with ARP traffic.
Let's return to the IP scanner to see what's happening there.
If you take a look,
all those IP addresses being scanned are being replied
to by the Cisco router's MAC address.
Now let's check out what happened to the Windows ARP cache.
I'll use arp -a,
but I'll also put on the pipe to more so that we get a page at a time.
Let's scroll through the pages.
Oh man.
Hundreds of replies all coming from the router.
All that and I didn't even scan the over 8, 000 hosts on the third network.
Clearly, this could create some serious overhead on your router,
on your network traffic, and on the host ARP caches.
Our solution to this is to stop providing proxy ARP
services for something like this.
To shut this off, I'm going to return to my router,
I'll move to global configuration mode,
I'll move to the interface servicing my LAN,
FastEthernet 0/0, and I'll use the no ip proxy-arp command.
This will shut off proxy ARP on the interface.
I'll also need to return to my host IP
configuration and correct its mask errors.
To do this, I'll go to its TCP/IP Properties and I'll set that mask to 255.
255.
0 and close out.
Now my router is not providing proxy ARP and my hosts are going to use routing. This way will reduce the overhead that proxy ARP can create within our LAN.