In days of olde when networks were bold and subnets freaked out the support teams, we embraced Proxy ARP (RFC 1027) in a big way. So what are we talking about with Proxy ARP? We're going to dive into it here.

Proxy ARP was often used as an excuse to the 'zero-effort networking' club. Enabling proxy ARP allows hosts on the same IP subnet to be segmented beyond the normal layer 3 boundary (i.e. router) and still be able to find each other. It is commonly used for RAS type setups where we have a number of hosts connecting to the router with for example VPN or PPTP. The remote clients will be assigned IP addresses in from the local network despite the fact they are NOT connected locally. The router is then responsible for 'proxying' the ARP traffic.

Perhaps we just need a quick stop off looking at ARP, how does that work? So ARP or the Address Resolution Protocol works to allow a source and destination host in the same network to discover each others IP address by issuing a layer 2 broadcast to the all MAC addresses host i.e. FF.FF.FF.FF.FF.FF. Every host on the broadcast segment (ports on the hub/switch) will open and inspect the broadcast layer2 frame (because they should) and check the layer3 header. When the host discovers the frame was not meant for them the frame is dropped...except of course the actual destination. I should point out perhaps before the comments start that a switch will flood the ARP out of all ports if it doesn't already know the MAC address OR if it's ARP table is full.

The receiving station picks up the ARP request, recognises the destination IP is itself and fires a unicast ARP back to the source of the ARP along with it's MAC address . The destination host also may store the MAC and IP address of the sender in it's own cache (reciprocal learning). Clever modern switches will often snoop this ARP traffic to build their own tables too...ah efficiency!

So thats ARP, what is proxy ARP?

With proxy ARP we are essentially using the benefits of ARP (i.e. find someone I don't know for me) on a much larger scale to help to 'blend' disperate physical networks to create one logical network.. Proxy ARP is all about ethernet segmentation. On a large network imagine a network of 1000 hosts. In the days before fast layer 3 switches you may choose to have one huge /22 network for 1022 useable hosts. Thats a massive broadcast domain and as such will cause you a lot of hassle for things like...well ARP. Any layer 2 broadcast frame will be sent everywhere and that is bad. We'll also get unnecessarily high traffic volumes across the network due to lack of segmentation (remember this is hub technology not switching). So what we may have done is to whip a router in there for segment the network.

Lets take an example below. We have two floors in a building with around 500 IP users per floor making a total of 1000 IP addresses. We have chosen a /22 network to provide us with 1022 useable hosts. That is all good. So we don't want a huge network spread across both floors and therefore we place a router in between the floors. The router is configured with IP as shown on the picture and also proxy ARP is enabled (this is on by default in Cisco IOS). Remember that configuring the IP addresses on the diagram will cause the router to moan saying that the IP address is already in use since we cannot have two interfaces in the same network. So we configure those interfaces with /23 netmasks (255.255.254.0)

Proxy ARP Topology

The hosts are given an IP address in the 172.16.0.0/23 range on one side and the 172.16.2.0/23 on the other. We cannot assign IP addresses from each network into the other one i.e. 172.16.1.100 would not be visible to 172.16.1.5 if we placed it into the First Floor network segment. Lets discuss the mechanism of proxy ARP.

Lets say we have a server (SERVER A) with IP address 172.16.3.100 and a client (CLIENT A) wishing to use that server on IP address 172.16.1.5. The server happens to be located on the 1st floor and the client on the ground floor. CLIENT A 'ARPs out' (sends an ARP broadcast request) for the IP address of SERVER A. The router, configured for Proxy ARP then 'arps out' via it's locally connected network on 172.16.2.0/23 for SERVER_A. SERVER_A sees the ARP request coming from the ROUTER and adds the routers MAC address as the source MAC for CLIENT_A then responds using a unicast ARP reply. The router sees the reply, add that information to it's own MAC table and proxies the response back to CLIENT_A. CLIENT_A then puts the MAC address of ROUTER into it's table as the source for SERVER_A.

Now of course we're all good to go. Lets lab it up!

Screen shot 2011-08-23 at 13.50.55

We're going to use Router GROUND_FLOOR and Router FIRST_FLOOR to be our 'hosts'. It will allow us to examine the ARP table and debug ARP requests. So we've segmented the network into two using the router but crucially for proxy ARP the 'hosts' to GROUND_FLOOR and FIRST_FLOOR are in the same logical subnet of 172.16.0.0/22.

Here is the IP configuration of PROXY_ROUTER using the /23 mask!

Screen shot 2011-08-23 at 13.52.41

Screen shot 2011-08-23 at 13.52.47

We make sure proxy ARP is running using the 'show ip interface fa0/0 command'

Screen shot 2011-08-23 at 13.54.08

The IP configuration for router (hosts) GROUND_FLOOR and FIRST FLOOR are using the /22 mask!

Screen shot 2011-08-23 at 13.55.07

Screen shot 2011-08-23 at 13.55.19

And finally lets just look at the ARP table entries for each node in turn PROXY_ROUTER, GROUND_FLOOR then FIRST FLOOR. Note that we only know our own IP address and MAC address information.

Screen shot 2011-08-23 at 13.56.27

Screen shot 2011-08-23 at 13.57.02

Screen shot 2011-08-23 at 13.57.34

Right. we're ready. So we're going to ping FIRST_FLOOR from GROUND_FLOOR. We expect the PROXY_ROUTER to pick up the broadcast ARP request and realise it has a connected interface in the network for FIRST_FLOOR. It will then generate a new ARP request and place that onto the network segment which FIRST_FLOOR sits on. FIRST_FLOOR will open the ARP request and respond to PROXY_ROUTER with it's MAC address for 172.16.3.100. At the same time FIRST_FLOOR will add the MAC address of PROXY_ROUTER as the SOURCE for GROUND_FLOOR (remember PROXY_ROUTER has proxied the ARP request from GROUND_FLOOR). PROXY_ROUTER will then generate a new ARP response back to GROUND_FLOOR who will receive the response and generate it's own ARP table entry with the source MAC of PROXY_ROUTER for destination FIRST_FLOOR.

Lets check it out!

Screen shot 2011-08-23 at 14.01.55
Notice the timeout for getting the first ping reply? Thats due to not having the MAC address and then the delay from PROXY_ROUTER proxying the ARP request to FIRST_FLOOR. However we did prove out the theory...lets just check that the MAC address we have learned for FIRST_FLOOR is actually that of the locally attached network interface for PROXY_ROUTER.

Screen shot 2011-08-23 at 14.03.22

Yes, we can see that the MAC address for PROXY_ROUTERs fa0/0 interface and the ARP 'Hardware Addr' on GROUND_FLOOR (for FIRST_FLOOR) match. Now we also said that both the proxy and the destination will also populate their ARP tables with this new information...did that happen?

Screen shot 2011-08-23 at 14.01.55

Screen shot 2011-08-23 at 14.03.22

All good.

So you said there was some bad, some downside? Yes indeed. Well on a relatively small scale this looks pretty good and you'd be right. On a larger scale though you need to consider the effects on the PROXY_ROUTER with regards to the MAC table. As the proxying grows the table will grow and that consumes RAM and CPU cycles! If you push a router hard enough it will become affected if it's always polling our for ARP.

Good luck with your studies.
© 2011 defaultrouteuk.com

Cisco, IOS, CCNA, CCNP, CCIE are trademarks of Cisco Systems Inc.
JunOS, JNCIA, JNCIP, JNCIE are registered trademark of Juniper Networks Inc.