An IPv4 host misconfigured with a /16 mask on a /24 subnet still reaches neighbouring /24s; how does proxy ARP hide the error?
answer
- mask decides on-link before ARP
- too-wide mask means more ARP
- router answers for remote /24s
- same MAC, many IPs
basics
~20 sA /16 mask makes the host treat other /24s as on-link, so it ARPs for those hosts directly. A proxy-ARP router answers with its own MAC and routes the traffic, so everything works until proxy ARP goes away.
solid answer
~40 sThe host decides on-link versus gateway by masking (RFC 1122 §3.3.1.1). With /16, a destination like 10.40.2.30 masks to the host's own 10.40.0.0, so the host broadcasts an ARP request for it instead of using its gateway. The target is on another segment and never hears it, but the router has a route to it through a different interface and sends a proxy reply carrying its own MAC; the host frames traffic to the router, which routes it. Replies come back normally because the server's mask is right. The giveaway is the host's ARP cache: many 10.40.x.x addresses all mapped to the router's MAC. When proxy ARP is disabled or the router replaced, the host loses the other subnets but keeps its own /24 and the internet.
go deeper
Recall that the mask, not ARP, decides whether a destination is local, and that a router with proxy ARP can answer for hosts that are really remote.
Do the AND for each destination by hand, show which ones the host ARPs for, and explain why the return traffic needs no proxy.
Read the symptoms: one MAC for many IPs, unanswered ARP inside the wide prefix, and a partial outage with a delay after proxy ARP is turned off.
Treat proxy ARP that is silently covering for wrong masks as hidden coupling between host configuration and router behaviour, to be removed on purpose rather than discovered.
## The setup A small site has a router with two interfaces: | Interface | Address | Subnet behind it | |---|---|---| | A | 10.40.1.1/24 | 10.40.1.0/24 (office hosts) | | B | 10.40.2.1/24 | 10.40.2.0/24 (servers) | Host H should be 10.40.1.25/24 with gateway 10.40.1.1. Someone configured it as **10.40.1.25 with mask 255.255.0.0** (/16) instead. The server S is 10.40.2.30/24, configured correctly. The router has **proxy ARP** enabled on interface A, as some router platforms do by default. Yet H reaches S, the internet and its own neighbours, and nobody notices the mistake. ## Why it still works RFC 1122 §3.3.1.1 says a host decides "on-link or via gateway" by masking the destination and its own address and comparing the results. Walk H's three kinds of destination through that rule: 1. **A neighbour, 10.40.1.80.** 10.40.1.80 AND 255.255.0.0 = 10.40.0.0, the same as H's 10.40.0.0. On-link, and genuinely so: H broadcasts an ARP request and the neighbour answers. Correct either way. 2. **The server, 10.40.2.30.** 10.40.2.30 AND 255.255.0.0 = 10.40.0.0 — a match, so H wrongly decides S is on-link and broadcasts an ARP request for 10.40.2.30 on the office segment. S never hears it. The router does: its route for 10.40.2.0/24 leaves through interface B, not A, so it sends a proxy reply mapping 10.40.2.30 to **its own interface-A MAC**. H's frames go to the router, which routes them to S. 3. **An outside address, 198.51.100.7.** 198.51.100.7 AND 255.255.0.0 = 198.51.0.0, which differs from 10.40.0.0. Off-link, so H sends to its gateway 10.40.1.1 exactly as a correctly configured host would. Each of those proxied addresses gets its own ARP cache entry on H, and each was created by a broadcast that a correctly masked host would never have sent. The **return path needs no help**. S's mask is right: 10.40.1.25 AND 255.255.255.0 = 10.40.1.0, which differs from S's 10.40.2.0, so S sends replies to its gateway 10.40.2.1 normally. ## What reveals it - **One MAC for many addresses.** H's ARP cache holds an entry for 10.40.1.1, another for 10.40.2.30, and one more for every other 10.40.x.x address it has talked to outside 10.40.1.0/24 — all with the same MAC, the router's interface-A MAC. A correctly masked host caches only its gateway for remote traffic, because it never ARPs for off-link destinations. - **Unanswered requests inside the /16.** For a 10.40.x.x address the router has no specific route to, a router following RFC 1027 does not answer (the RFC forbids using the default route for this check), so H's ARP request times out and the host reports the destination unreachable locally — while an internet address, outside the /16, still works through the gateway. - **ARP broadcasts that should not exist.** H broadcasts a request for every new remote 10.40.x.x destination, where a correctly configured host would ARP only for its gateway. - **The wrong broadcast address.** H's directed broadcast is 10.40.255.255 instead of 10.40.1.255, so anything relying on subnet broadcast behaves oddly. ## The day it breaks The mistake surfaces when the router stops answering: proxy ARP is disabled as hardening, the router is replaced by one whose implementation leaves proxy ARP off, or the interface is reconfigured. Then H can still reach its own /24 and the internet, but **not** the other 10.40.x.x subnets — a partial outage whose pattern is the diagnosis. It may not even start at once: H's cached mappings still point at the router's MAC, and the router still forwards frames sent to it, so traffic continues until those entries age out and H's fresh ARP requests go unanswered. How long that takes depends on the host's implementation (RFC 1122 §2.3.2.1 requires some flushing mechanism, and suggests timeouts on the order of a minute where proxy ARP is in use). ## The fix Correct H's mask — or, better, the DHCP scope or template that produced it — to /24, so H sends remote traffic to its gateway. Then check the other hosts on the segment the same way: a mask error made by a template is rarely made once, and every host that carries it depends on the router in the same silent way. Only after that is it safe to turn proxy ARP off on the interface. Proxy ARP was not wrong here; it masked the configuration error. RFC 1027 built exactly this situation on purpose: hosts kept the mask of the whole network, excluding the subnet bits, and the routers proxied between subnets the hosts could not see. What was a design in 1987 is a hidden error today.
- Why does the misconfigured host still reach the internet normally?An internet address such as 198.51.100.7 masks to 198.51.0.0 under /16, which differs from the host's 10.40.0.0, so the host correctly treats it as off-link and sends it to its default gateway. Only destinations inside the too-wide /16 take the ARP path that depends on the proxy.
- After proxy ARP is disabled, why might the failure appear minutes later rather than at once?The host's ARP cache still maps the remote addresses to the router's MAC, and the router still forwards frames sent to it — disabling proxy ARP only stops new replies. Traffic continues until those entries age out; then the host's fresh requests go unanswered. The ageing time is the host implementation's, so the delay varies.
saying these in an interview costs you the question
- A host with a wrong mask falls back to its default gateway when ARP fails.
- The server's replies need proxy ARP too, even though its own mask is correct.
- Remote destinations always get their own ARP cache entries on any host.
- If everything works, the subnet mask must be correct.
- Proxy ARP changes the host's routing table to add the other subnets.