Attacks on a plain switch
Start with a plain switch and no defences. It learns the source MAC (hardware address) of every frame and forwards whatever arrives. Port 3 leads to the real router; the laptop and the attacker sit on ports 1 and 2.
Port 2 sends frames, each from a new made-up MAC. The switch learns them all into its MAC table, which has fixed room. Once full, it cannot relearn real MACs, so it floods their frames out of every port, port 2 too.
Next, port 2 asks for address after address, each time claiming a different made-up client MAC. The router cannot tell these from new devices, so it hands out leases until its pool is empty. Real newcomers get nothing from it.
The laptop joins and broadcasts a DHCPDISCOVER, so port 2 hears it too. The starved router stays silent, and the attacker answers, naming itself as gateway. Plain DHCP cannot prove which server is real, so the laptop accepts.
Say the laptop did get the real gateway, 192.168.1.1. The attacker sends it an ARP reply it never asked for: 192.168.1.1 is at my MAC. ARP has no authentication, so the laptop overwrites its entry. Its router-bound frames now reach port 2.
The defended switch
Now the same switch gets three defences. Port 3 leads to the real router, so it is marked trusted. Ports 1 and 2 face ordinary devices, so they are untrusted and get checked. Watch each attack again.
Port security
Port security caps how many MAC addresses (the hardware IDs in every frame) one port may use, here 1. Port 2 has already learned the attacker's real MAC, so its allowance is full.
The attacker sends a stream of frames, each with a made-up source MAC, to overflow the switch's MAC table. Every new MAC breaks port 2's limit, so the switch drops those frames and counts violations. The table never fills.
DHCP snooping
The laptop joins and broadcasts a DHCPDISCOVER: is there a DHCP server, the service that hands out addresses? The switch floods the broadcast, so the router hears it, and so does the attacker.
The attacker answers with a fake DHCPOFFER that names itself as the gateway. DHCP snooping lets server messages (OFFER, ACK) in only through trusted ports. This one arrived on untrusted port 2, so it is dropped.
The router's DHCPOFFER, and later its DHCPACK, arrive on trusted port 3, so they pass. The laptop gets 192.168.1.101, with the real router, 192.168.1.1, as its gateway.
As the DHCPACK passes, snooping writes a binding: this MAC got this IP, on this port and VLAN, for the 24-hour lease. The attacker's own earlier lease is already a row.
ARP inspection
The attacker sends an ARP reply claiming 192.168.1.1 is at its own MAC. Dynamic ARP Inspection checks it against the bindings: port 2 owns only 192.168.1.166. The claim does not match, so it is dropped.
The laptop asks who has 192.168.1.1, saying 192.168.1.101 is at its own MAC, on port 1. That matches its binding, so it goes through. The router answers from trusted port 3, which is not inspected.
All together
Port security stops MAC flooding, DHCP snooping stops rogue servers, and ARP inspection, built on snooping's table, stops ARP spoofing. They guard only this switch's access ports, and devices with fixed addresses need bindings typed in by hand.
Inside the switch
;; step 1/15 · plain-switch · plain one access switch · VLAN 1 · 192.168.1.0/24 · no defences on port 1 laptop 00:00:5e:00:53:01 192.168.1.101 port 2 attacker 00:00:5e:00:53:66 192.168.1.166 port 3 router 00:00:5e:00:53:fe 192.168.1.1 (DHCP server, gateway) MAC table (6 slots drawn): 00:00:5e:00:53:01 → 1, 00:00:5e:00:53:66 → 2, 00:00:5e:00:53:fe → 3 every frame is believed: nothing checks who really sent it
Port security and Dynamic ARP Inspection are switch-vendor features, not IEEE or IETF standards; names and defaults differ between vendors. DHCP snooping's trusted ports and bindings are standardised for source address validation as SAVI-DHCP (RFC 7513). Devices with fixed (static) addresses never send a DHCPACK through the switch, so they have no binding; put them on trusted ports or add their bindings by hand.