Hello, and welcome to this demonstration on proxy ARP being unavailable.
In this section,
I'm going to show you what happens when we shut off
proxy ARP and hosts are relying on it.
We'll see how Windows 10 reacts and solves the problem gracefully.
We'll also see how Ubuntu Linux handles it not so gracefully.
Then we'll take a look at how we can fix the problem either through
returning proxy ARP to function or fixing the endpoints.
To get started, let's get grounded in our setup.
We have two hosts, a Windows host at 20.
1.
15 with a /8 mask or 255.
0.
0 and an Ubuntu Linux host at 20.
1.
60/8.
Their gateway is 20.
1.
1/24 and is providing proxy ARP.
We'll then use that proxy ARP to test connectivity to our remote target,
which is a fake Globomantics web server I've set up set to the IP address of 20.
2.
201.
Once we see that's working and we see proxy ARP is
functioning to provide connectivity,
I will shut off the proxy ARP on the gateway.
Then we'll see how Windows 10 handles it differently from Ubuntu Linux.
And finally, we'll correct the problem on our end stations.
Let's get started by verifying our setup and making
sure the proxy ARP is working.
Within the Windows command prompt, I'm going to check my ARP cache.
Here, we can see the gateway set at 20.
1.
1 with a MAC address 00-00-0c-07-ac-01.
To make sure proxy ARP is functioning, I'm going to ping 20.
2.
201 and see that I get a reply,
then check my ARP cache again and we can see that 20.
2.
201 also appears local to the LAN at my gateway's MAC address.
I'll also bring up the Globomantics fake web page I've created.
Let's switch over to the Ubuntu host and verify its connectivity.
First, I'll check its ARP cache and we can see its connected to the same gateway.
So that we can see the proxy ARP,
I'll start a Wireshark capture and I'll put it in an ARP filter.
Returning to my command prompt, I'll ping 20.
2.
201 and then check my ARP cache, and again, we can see 20.
2.
201 and our router's MAC address.
Checking Wireshark, I can see the ARP request for 20.
2.
201 and our proxy ARP reply from our router that 20.
2.
201 is at our router's MAC address.
Let's verify that the Globomantics web page is available and it is.
Now let's see what happens when we shut off proxy ARP.
I'll return to my Windows, I'll return to my router's command prompt,
move to global configuration mode,
and on interface FastEthernet 0/0 facing my LAN,
I'll issue the command no proxy arp.
This will shut off the proxy ARP function for our LAN host.
Now let's see how Ubuntu handles this.
First, I'll bring up the command prompt and I'll ping 20.
2.
201.
It's still working, let's see why.
If I check my ARP cache,
it still has the entry there that was provided by proxy ARP.
Now even though proxy ARP has been shut off,
I'll be able to use the gateway to ping 20.
2.
201.
However, just like every machine, that dynamic entry has a timer.
When that timer expires and the ARP cache entry is deleted,
things are going to change.
Instead of waiting for the timer,
I'm going to use the arp -d command to delete 20.
2.
201.
Now if we check the ARP cache,
we can see that that entry is listed as incomplete and
it won't be used for sending data.
Now I'll try pinging 20.
2.
201 and we'll see what happens.
Destination host unreachable.
Let's confirm that we've lost connectivity by
refreshing the Globomantics web page.
And it says unable to connect.
If we check the Wireshark, we'll see why.
It looks like my system is broadcasting who has messages for 20.
2.
201 and there is no response.
Because I've shut off proxy ARP on the router and my system still thinks 20.
2.
201 is on the local area network,
it's getting no response and won't encapsulate data.
Now let's see how Windows handles the situation.
Within Windows,
I'm going to start a Wireshark capture and I'll put
it in a display filter for ARP.
Then we'll bring up the command prompt and we'll check our ARP cache
and see that it's still got an entry there for 20.
2.
201.
So I should be able to ping it, and I can,
but I'm going to delete that entry just like I did on
the Linux system with arp -d 20.
2.
201.
Now I'll check my ARP cache again and we'll see that it's gone.
Now let's see what happens when I ping 20.
2.
201.
I got a destination host unreachable, but now I'm getting responses.
Let's check what happens with the web page.
I refresh it and it still comes up.
Let's check out Wireshark to see what happened.
It looks like my Windows host is sending directed ARP requests for 20.
2.
201 and not getting an answer.
Then its shifted over to sending our broadcast for 20.
2.
201 and still not getting an answer.
Clearly, proxy ARP has been shut off.
Let's verify that by looking at the Windows ARP cache.
Arp -a and I see that there are no entries for 20.
2.
anything.
What this means is even though proxy ARP has been shut off on my
router and my Windows host still believes that 20.
2.
201 is local to the LAN,
it doesn't let a lack of ARP replies stop it from
contacting the remote Globomantics web server.
Windows has shifted over to using routing and the
default-gateway to pass that traffic.
Looks like another win for Windows.
Although Windows has solved the problem and Linux has not,
the best thing is to not rely on the proxy ARP in the first place.
Of course,
we could return to our router and on the FastEthernet
0/0 interface servicing our LAN, we could reenable proxy ARP.
However,
a better solution is to fix our endpoint stations and leave proxy ARP shut off.
Within Windows,
I'm going to change the TCP/IP configuration so that it
no longer relies on the proxy ARP.
Our problem is our /8 mask, which I'll go ahead and change to 255.
255.
0 and save that configuration.
Returning to my command prompt,
ipconfig will show us we've got our /24 mask and things of course still work.
I could ping 20.
2.
201 and even though it never really stopped,
our Globomantics web page will still load.
Now let's verify that fix works on Ubuntu Linux.
In Linux, I'll bring up the Network Configuration page,
I'll shut off my network card, change the options,
and in the IPv4 settings, change the mask to a 24-bit mask.
I'll save my configuration and reenable my card.
Now let's check out the web page and see if that loads and it does.
Return to my command prompt, ifconfig shows us that our IP address is set,
and based on that broadcast and mask,
we have a proper configuration for the network.
I'll ping 20.
2.
201 and now that we're routing, we no longer need the proxy ARP.
Before disabling proxy ARP in your network,
I would highly recommend determining what your host needs are for proxy
ARP and making sure that when you decide to shut it off,
they're all properly configured and can function.
In the same way,
you can use captures and testing to find out how they're going
to function within an isolated lab before you shut off proxy ARP on your production systems.