What is DHCP Snooping?
DHCP Snooping is a security feature on managed switches that inspects DHCP traffic, only forwards replies from trusted DHCP servers and records per port which IP address was leased to which MAC address. This stops a laptop, rogue device or wrongly connected router from handing out a forged IP configuration, which could otherwise lead to Spoofing, eavesdropping or network outages. The binding table that DHCP Snooping builds is also the foundation for IP Source Guard and Dynamic ARP Inspection.
In OT networks, DHCP Snooping prevents a laptop, rogue Switch or compromised field device from rerouting traffic from PLCs or SCADA servers via a forged IP configuration.
🧠 What problem does DHCP Snooping solve?
DHCP (defined in RFC 2131 from 1997) has no authentication: a client accepts the first offer that arrives. Anyone who connects their own DHCP server can therefore give clients their own gateway and DNS server and take up a Man-In-The-Middle position. DHCP Snooping addresses four risks:
- Rogue DHCP servers - an improvised access point, a home router or a laptop with internet sharing that hands out addresses
- DHCP starvation - an attacker requests every address in the pool using ever-changing MAC addresses, so legitimate devices no longer receive one
- Forged release - an attacker sends a DHCPRELEASE on behalf of another device and ends its lease
- Lack of visibility - without a binding table you do not know which device uses which address on which port
The feature also improves network stability in OT: duplicate addresses and misrouted traffic caused by a wrongly connected device are prevented. That makes DHCP Snooping a logical building block alongside MAC Binding, Port Security and a Zero Trust Architecture.
⚙️ How does DHCP Snooping work?
The switch divides its ports into trusted and untrusted. By default every port is untrusted; only the port towards the real DHCP server or the uplink to the distribution layer is made trusted. The switch then assesses every DHCP message:
| Situation | Switch behaviour |
|---|---|
| Server message (DHCPOFFER, DHCPACK, DHCPNAK, DHCPLEASEQUERY) on an untrusted port | Dropped |
| Client message (DHCPDISCOVER, DHCPREQUEST) on an untrusted port | Forwarded, provided the source MAC matches the client hardware address |
| DHCPRELEASE or DHCPDECLINE for a binding on another port | Dropped |
| Packet with a relay address (giaddr) or option 82 on an untrusted port | Dropped by default |
| DHCPACK from a trusted port | Switch writes MAC, IP, lease time, VLAN and port into the binding table |
This binding table is the most important output of DHCP Snooping. IP Source Guard uses it to block packets with a spoofed source IP, and Dynamic ARP Inspection checks ARP replies against it to stop ARP Spoofing.
🔧 Which settings and default values are common?
The exact options vary by vendor. On Cisco IOS, including the industrial IE switches, the following starting points apply:
| Setting | Typical value or default |
|---|---|
| DHCP Snooping globally and per VLAN | Off by default; only active once enabled per VLAN |
| Check of source MAC against client hardware address | On by default |
| Insert option 82 (Relay Agent Information, RFC 3046) | On by default |
| Rate limit on untrusted ports | None by default; recommended at most 100 packets per second |
| Rate limit exceeded | Port goes into the err-disabled state |
| Binding database write delay | 300 seconds |
| Maximum number of bindings (Catalyst 3750) | 8,192 |
Two details deserve attention. First, the binding database: after a reboot the table is empty unless the switch writes it to flash or a server. Storing lease times correctly requires NTP. Without NTP a Cisco switch still writes the database, but the lease expiry times are wrong after a reload; if NTP is configured but the time server is unreachable, the switch stops writing new bindings altogether. Second, option 82: when the switch inserts this option and the DHCP server sits in the same VLAN, some servers reject the request because the relay address is 0.0.0.0. In that case, disable insertion or configure the server to accept it.
Industrial switches from vendors such as Cisco (IE series) and Hirschmann (HiOS) offer DHCP Snooping together with IP Source Guard and Dynamic ARP Inspection. Support and options vary by model and firmware version, so check the datasheet. Unmanaged switches cannot do it, so a managed switch is a prerequisite.
🏭 How do you deploy DHCP Snooping in an OT network?
OT networks differ from office networks: many PLCs, I/O modules and drives have a static IP address, and PROFINET devices usually receive their name and address from the controller via DCP, not via DHCP. EtherNet/IP devices, by contrast, often ship with BOOTP or DHCP enabled. A practical approach:
- Take inventory per VLAN of which devices use DHCP or BOOTP and which have a fixed address, for example from your Asset Inventory.
- Decide on trusted ports: only uplinks and the port to your own DHCP server. Leave all end-device ports untrusted.
- Enable it per VLAN, starting with a maintenance or engineering VLAN where laptops are connected and disconnected regularly.
- Set a rate limit on untrusted ports, generous enough for start-up peaks (for example after a whole cabinet loses power).
- Add static bindings for devices with fixed addresses before you activate IP Source Guard or Dynamic ARP Inspection; otherwise you block legitimate process traffic.
- Persist the binding database with a synchronised clock and send alerts about dropped packets via Syslog to your SIEM.
- Test in a maintenance window and document the configuration as part of your hardening baseline.
| OT scenario | What DHCP Snooping does |
|---|---|
| Maintenance laptop with internet sharing enabled | Its DHCP offers are dropped on the untrusted port |
| Production network with a fixed IP range | A fault or misbehaving device can no longer hand out addresses |
| Rogue device tries to redirect traffic | The forged gateway never reaches the clients |
| Link with Asset Inventory | The binding table shows which device received which IP on which port |
🛡️ Which measures do you combine with DHCP Snooping?
DHCP Snooping is one layer in a defence-in-depth approach and works best together with other layer 2 and access measures:
| Measure | What it adds |
|---|---|
| IP Source Guard | Blocks packets with a spoofed source IP address |
| Dynamic ARP Inspection | Checks that ARP traffic matches the binding table |
| Port Security | Limits the number of MAC addresses per port and dampens starvation |
| 802.1X | Authenticates devices before they are granted access |
| VLAN isolation | Separates untrusted ports and devices from process traffic |
| Network Segmentation | Limits the damage to one zone, in line with IEC 62443 |
The classic DHCP Snooping feature only protects IPv4. Comparable functions exist for IPv6: DHCPv6-Shield (RFC 7610, called DHCPv6 Guard by Cisco) and RA-Guard (RFC 6105).
❓ Frequently asked questions
Does DHCP Snooping still help if all my OT devices have a static IP address?
DHCP Snooping remains useful because it blocks rogue DHCP servers that give laptops and temporary devices a forged configuration. Devices with a static address, however, do not end up in the binding table automatically. Add static bindings for them before you enable IP Source Guard or Dynamic ARP Inspection.
What is the difference between a trusted and an untrusted port in DHCP Snooping?
On a trusted port, DHCP Snooping forwards all DHCP messages, including server replies. On an untrusted port, the switch drops server messages such as DHCPOFFER and DHCPACK. Only uplinks and the port to the real DHCP server should be trusted.
Why does a port go err-disabled after enabling DHCP Snooping?
With DHCP Snooping, a port goes err-disabled when a rate limit is configured and the number of DHCP packets exceeds the configured rate limit. This sometimes happens legitimately, for example with an access point or many devices starting up at once. Raise the limit or configure automatic recovery.
Why does DHCP Snooping need NTP?
DHCP Snooping stores bindings with their lease time in a database on flash or a server. Without correct time via NTP the expiry times are wrong after a reboot. If an NTP server is configured but unreachable, Cisco switches stop writing new bindings to the database altogether, so those bindings are missing after a reboot.
Does DHCP Snooping protect against PROFINET attacks?
DHCP Snooping only inspects DHCP and BOOTP traffic and does not see PROFINET DCP, which PROFINET devices use to receive their name and IP address. PROFINET needs segmentation, port security and monitoring instead. DHCP Snooping is at most a supplement for laptops and IT equipment in the same zone.
Is DHCP Snooping mandatory under NIS2?
No, NIS2 and the Dutch Cybersecurity Act do not name DHCP Snooping as a specific measure. They do require appropriate technical measures for network security. DHCP Snooping is a low-cost way to contribute to that, because the feature is already built into most managed switches.
📌 In summary
DHCP Snooping lets only trusted DHCP servers hand out addresses and records per port which device has which IP address; that makes it the foundation for IP Source Guard and Dynamic ARP Inspection in your OT network.
Enable it per VLAN, make only uplinks trusted, set a rate limit, provide NTP and add static bindings for devices with fixed addresses. This gives you better spoofing protection and more visibility of your network without disrupting legitimate process traffic.