Topology:
R2 - SW1 - R1 - SW2 - R3
R2 - R1: 10.1.0.0/16
R3 - R1: 10.1.2.0/24
R2 uses 10.1.1.1
R3 uses 10.1.2.1
Basically, a larger network is needed to reach a smaller network (overlapped) via a router.
Enabling this is very simple; just use the command ip proxy-arp on the interface.
But I didn’t understand the purpose of ARP Proxy at first and questioned why anyone would design a network like this.
After looking into it, I found a few use cases.
Some IoT devices have limited network stack support, only functioning within the local network (often hardcoded with a fixed netmask, e.g., /16). These devices don’t support a default gateway or IP routing, but we may want to place them in different subnets.
For example:
- R2 - R1: 10.1.0.0/16
- R3 - R1: 10.1.2.0/16
Even though we want to use /24 subnets, hardware limitations force us to use /16, and only ARP is supported for communication.
Since R2 and R3 are separated by a router and are in different broadcast domains, ARP broadcasts cannot pass from R2 to R3. This is where ARP Proxy comes in to forward ARP requests on their behalf.
Another use case is due to legacy network designs.
Some companies originally used a large network, like a /16, with no need for subnets. Later, they decided to move to smaller subnets, like /24, and segment the network.
Now, the new smaller subnets and the original large network are in different broadcast domains:
- R2 - R1: 10.1.0.0/16
- R3 - R1: 10.1.2.0/24
In this case, ARP Proxy needs to be enabled on the R2-R1 side. Why not on R1-R3 as well?
When R2 tries to reach 10.1.2.1, since 10.1.0.0/16 included 10.1.2.1, an ARP request sent to get R3’s MAC address. The ARP reaches the router, which replies to R2 with its own MAC, then forwards the ARP request to R3 and caches R3’s MAC.
When R3 sends packets to R2, 10.1.1.1 is outside the 10.1.2.0/24 subnet, so it forwards the traffic through its default gateway instead of using ARP. This is why ARP Proxy is not required on the R1-R3 side.