Switching · Access Security

ARP poisoning

Recognize a false gateway mapping and connect the symptom to a defensive control.

Independent lab examples; selected output and frame summaries are illustrative. Port naming and command support vary by switch and software release.

Network and objective

IPv4 ARP behavior in an isolated explanatory scenario; no attack tooling is required.

H1 expects gateway 192.168.10.1 at MAC 0200.0000.0001. A conflicting ARP message claims that gateway address belongs to 0200.0000.0099 on an untrusted access port.

Physical links are solid; device roles and relevant links are labeled.

How it works

ARP resolves a local IPv4 next-hop address to an Ethernet MAC. Ordinary ARP does not authenticate the sender, so a host may accept an incorrect mapping and send frames to the wrong device.

This affects the local Ethernet segment, not the BGP routing table. H1’s destination IP can remain unchanged while its Ethernet destination becomes wrong. Depending on what happens to those frames, traffic may be intercepted or simply lost.

Compare the endpoint’s neighbor cache with the intended gateway identity, then locate both MAC addresses in the switch table. Do not treat every MAC change as malicious: gateway failover, replacement hardware, and duplicate IP mistakes can also alter observations.

Configure or inspect

No feature change is required for this conceptual comparison. Inspect the operational state below on an isolated compatible lab platform.

Verify the result

Illustrative output · selected lines

H1 neighbor-cache evidence (normalized)
Before: 192.168.10.1 -> 0200.0000.0001
After:  192.168.10.1 -> 0200.0000.0099
SW1#show mac address-table address 0200.0000.0099
Vlan  Mac Address      Type     Ports
10    0200.0000.0099   DYNAMIC  Gi1/0/2

The unexpected mapping and its access-port location justify investigation. A static switch MAC entry would only change forwarding; it would not validate the IPv4-to-MAC claim received by the endpoint.

Failure and recovery

H1 loses the gateway after accepting the conflicting ARP claim. Clearing the cache alone gives temporary recovery if invalid claims continue.

Isolate the unauthorized source through the incident process, restore the verified gateway mapping, and deploy DAI with valid DHCP bindings or an ARP ACL for static hosts. Confirm legitimate gateway failover still works.

Key Takeaways

ARP lacks built-in sender authentication.
A wrong mapping changes the Ethernet next hop.
Inspect endpoint and switch evidence together.
Legitimate changes can resemble an attack.
DAI validates ARP claims at untrusted ingress.