DHCP snooping is a security feature intended to prevent rogue DHCP server from sending malicious DHCP replies.
When DHCP snooping is enabled, the switch intercept all the DHCP requests, and discards DHCP replies coming from “untrusted” ports. The offending switch ports are automatically shut down and put in err disable state.
DHCP snooping also has a database containing client MAC address, IP address offered, lease time, and so on for all the completed DHCP bindings.
The following tutorial was written by Edward Yardley (a Network Engineer with 10-year experience in the IT industry) at packetpushers.net. Let’s understand DHCP Snooping Configuration in detail.
Why do we need DHCP Snooping?
We need DHCP Snooping to prevent a man-in-the middle attack on our network. The potential exists for an attacker to pretend (spoof) to be the DHCP server and respond to DHCPDISCOVER messages before the real server has time to respond. DHCP Snooping allows switches on the network to trust the port a DHCP server is connected to (this could be a trunk) and not trust the other ports. It also maintains a list of DHCP address bindings by inspecting traffic flowing between clients and the DHCP server, which provides certainty around who the real hosts are. The binding information collected by DHCP Snooping is used by other security features like IPSG and DAI.
The Topology
Our client connects to an untrusted port; all ports are untrusted by default. When the client machine sends a DHCPDISCOVER message with DHCP Snooping enabled, the switch will only send the DHCP broadcast message to trusted ports. In this case our distribution switch is acting as the DHCP server, but a DHCP server running external to the switch could also be used. A trusted port is the only port which is allowed to send DHCP Server responses such as DHCPOFFER.
Configuration
Let’s jump onto SW1 and enable DHCP Snooping:
SW1(config)#ip dhcp snooping
SW1(config)#We also need to enable it for our VLANs. In this case we’re only using VLAN 1:
SW1(config)#ip dhcp snooping vlan 1
SW1(config)#
Great so far! Now, we make Fa0/1 facing DSW1 a trusted port:
SW1(config)#int fa0/1
SW1(config-if)#ip dhcp snooping trust
SW1(config-if)#
It’s a good idea to enable rate limiting on the untrusted ports. This is specified in packets per second, and is used to prevent an attacker from hammering our DHCP server with so many requests that it exhausts all of the IP addresses it has to offer:
SW1(config-if)#ip dhcp snooping limit rate ?
<1-4294967294> DHCP snooping rate limitSW1(config-if)#ip dhcp snooping limit rate 25
SW1(config-if)#
Verification
Let’s take a look at the DHCP Snooping config:
SW1#sh ip dhcp snooping
Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:
1-200
Insertion of option 82 is enabled
Interface Trusted Rate limit (pps)
———————— ——- —————-
FastEthernet0/1 yes unlimited
FastEthernet0/24 no 25
SW1#
Next we connect our client machine to Fa0/24 on SW1. We can see the DHCP binding has been captured by DHCP Snooping:
The DHCP Snooping binding table contains the MAC address, IP, lease time, lease type, VLAN ID and attached interface for each client.
DHCP Option 82
DHCP Option 82 has the potential to cause network engineers an awful lot of grief if we don’t keep it in check. When DHCP Snooping is enabled, DHCP Option 82 is inserted into DHCP packets as they pass through a switch. Option 82 contains information about the specific port a client machine is connected to. DHCP packets also carry a “giaddr” field which is set to 0.0.0.0 by default (a non-zero value). (EDIT: I originally said giaddr was a field in Option 82, however it is a field in the DHCP packet not Option 82 itself.) Both of these things will show up in error messages if something is misconfigured. In the topology above, Option 82 isn’t a problem because DHCP Snooping isn’t enabled on DSW1 (only on SW1), so let’s add another switch:
In this topology, the ports facing our DHCP server, Fa0/2 on SW1 and Fa0/11 on SW2, have been configured as trusted ports. By default, SW1 will insert DHCP Option 82 into all DHCP packets it receives from the client. Also by default, SW2 will drop those packets as soon as it receives them. A switch with DHCP Snooping enabled will drop packets on untrusted ports that contain Option 82 or have a non-zero giaddr (e.g. 0.0.0.0). This is what is seen in debug on SW2 when SW1 sends a DHCPDISCOVER out port Fa0/2:
%DHCP_SNOOPING-5-DHCP_SNOOPING_NONZERO_GIADDR: DHCP_SNOOPING drop message with non-zero giaddr or option82 value on untrusted port
Remember that port Fa0/24 on SW2 is an untrusted port from DHCP Snooping’s point of view, so it drops the packets by default because Option 82 exists. That traffic never makes it to DWS1. There are several ways to get around this problem, although initially, I got myself very confused while I was labbing various topologies. (It took a Hawaiian vacation to straighten things out!) We’ll solve this problem by using one command on SW2 that will trust packets with DHCP Option 82 that are received on untrusted ports.
SW2(config)#ip dhcp snooping information option allow-untrusted
Because our DHCP server is a Cisco IOS device, it also needs to trust DHCP packets with option 82 set:
DSW1(config)#ip dhcp relay information trust-all
We’re pretty much done here. An alternative would be to make port Fa0/24 a trusted port, but this would expose us security-wise. We could also stop DHCP Snooping from inserting Option 82 in the first place (using #no ip dhcp snooping information option). Here I wanna encourage you to lab this up yourself and play with the various combinations of inserting DHCP Option 82, trusting it, and not trusting it. You could also swap DSW1 for a router or use DHCP server from another vendor. I found Marko Milivojevic’s four part in-depth post on Understanding DHCP Snooping helpful when coming to grips with DHCP Option 82 in particular.
More Discussion from Cisco Support Community
DHCP Snooping & DHCP Pool on 2960 switch
Q: “Hi! I want to configure IP DHCP Snooping on a switch which has also a DHCP Pool configured (i.e. the switch is the DHCP server in VLAN 1). Is there a “trusted” interface to be defined in this special case? Perhaps somebody has a working config example for me? Thanks!”
A: “Hello, AFAIK, you won’t need any trusted interface because there is no input dhcp traffic that the switch (dhcp server) will generate. The traffic will only be output from the switch to whatever client it is communicating with.”
More RELATED RESOURCES:
Catalyst 2960 Switch Software Configuration Guide, 12.2(25)FX-Configuring DHCP Features
PDF file: How to configure Dynamic Host Configuration Protocol (DHCP) snooping on Catalyst 6500 series?
