Persistent unknown unicast - A peering-LAN case study#

James Rice, Jump Networks Ltd

• Why: A textbook-quality L2 postmortem: a single MAC change can flood member traffic (including HTTPS SNI and emergency-call signalling) to hundreds of ports indefinitely, via a kernel-level neighbor-discovery quirk. This is the kind of hard-won operational lesson that transfers to any shared L2.
• What: Shows that unknown unicast on peering LANs is not always transient. RFC 4861 §7.3.1 "forward-progress confirmation" lets a stale ND entry stay REACHABLE indefinitely: when member B changes MAC, A keeps sending to the old MAC; the exchange floods those frames to all member ports; some members' devices (skipping the L2 my-station check) forward the packet onward to B; B's reply via that third-party path counts as forward progress, so no Neighbor Solicitation is ever sent. A unicast NS to the stale MAC gets flooded too, and the NA arriving from the new MAC without a TLLA option confirms reachability without updating the cached MAC (RFC 4861 §7.2.5) — the entry stays stale and REACHABLE.
• How: Kernel-level trace through neigh_confirm()/neigh_timer_handler() and ndisc_recv_na()/neigh_update(); a reproducible demo (published Nov 2024) using ip neigh replace with a dead MAC produces duplicate ping replies — each duplicate being a different member's device routing a packet it had no business handling. Includes a five-year timeline of reports and partial remediations at one IXP, plus a frank operator self-examination about disclosure.
• Where applicable: The five-year timeline is one-IXP-specific, but the mechanism is general to any Linux/BSD host on a shared L2 segment — DC fabrics, exchange LANs, any environment where MAC changes meet ND caches. Valuable for L2 design and failure-mode reasoning.