Solution: Proxy ARP Causing Unexpected Routing Behavior¶

Triage¶

Check if proxy ARP is enabled on router interfaces:
```
show running-config interface GigabitEthernet0/0
show running-config interface GigabitEthernet0/1
```
Look for the absence of no ip proxy-arp (it is ON by default on many platforms).
Verify from a host -- check ARP table for remote IPs:
```
arp -a
```
If 10.1.1.1 (router) and 10.2.2.50 (remote host) both show the same MAC, proxy ARP is in effect.
Confirm with a targeted ARP request from a host:
```
arping -I eth0 10.2.2.50
```
If the router responds with its own MAC, proxy ARP is confirmed.
Run traceroute to see the apparent path:
```
traceroute 10.2.2.50
```
With proxy ARP, this may show a single hop (the router) or appear direct.
Check the router's ARP processing load:
```
show processes cpu | include ARP
```

Root Cause¶

Proxy ARP is enabled on the router interfaces (the default on many Cisco IOS platforms). When a host on subnet 10.1.1.0/24 sends an ARP request for a host on 10.2.2.0/24, the router -- which has interfaces on both subnets -- responds to the ARP request with its own MAC address. The host then sends traffic for the remote IP to the router's MAC, and the router forwards it.

This effectively bypasses subnet boundaries and any security segmentation that relies on Layer 3 separation. Hosts communicate across subnets without needing a properly configured default gateway or explicit routes, and the traffic may bypass inter-VLAN ACLs depending on how they are applied.

Fix¶

Disable proxy ARP on all router interfaces where it is not explicitly needed:

configure terminal
interface GigabitEthernet0/0
  no ip proxy-arp
interface GigabitEthernet0/1
  no ip proxy-arp
interface GigabitEthernet0/2
  no ip proxy-arp
end
write memory

Before disabling, ensure all hosts have: - Correct subnet mask - Correct default gateway configured - No dependency on proxy ARP for legitimate routing

After disabling, flush ARP caches on affected hosts:

# Linux
ip neigh flush all
# Windows
arp -d *

Rollback / Safety¶

If hosts lose connectivity after disabling proxy ARP, they likely lack a default gateway. Re-enable temporarily: ip proxy-arp on the interface.
Test on a single interface/VLAN first before applying globally.
Document which interfaces had proxy ARP enabled for rollback.
Schedule during a maintenance window to minimize disruption.

Common Traps¶

Not realizing proxy ARP is enabled by default; the config may not show it explicitly because it is the default behavior.
Disabling proxy ARP without first verifying that all hosts have default gateways, breaking connectivity for misconfigured hosts.
Assuming that subnet segmentation equals security -- proxy ARP silently defeats this assumption.
Confusing proxy ARP with gratuitous ARP or ARP spoofing; proxy ARP is a legitimate (if often undesirable) router feature.
Forgetting to flush host ARP caches after disabling; stale entries persist for the ARP cache timeout duration.