A.
1. Switch will watch all dhcp requests and build a table of ip-mac bindings for each port.
2. Switch will drop all dhcp RESPONSES from untrusted ports. (eg. If an end user places a dhcp server on their PC or device and connects to your switch, they won't be able to hand out addresses)
Q. What ports should I make trusted or untrusted?
A. Any ports you expect a dhcp response to come from. This includes the port your DHCP server resides on, as well as switch uplink ports. Make everything else untrusted.
Q. What is option 82?
A. Option 82 adds switch and port information to the DHCP request, so that the dhcp server can log information about the exact location of the client. Useful for tracking down malicious end users.
Q. I am on a procurve and there is something about authorized servers.
A. Put in the IP address of any DHCP servers you have in your network as authorized.
Q. So what about the arp inspection stuff?
A.
Malicious use 1. Think of a malicious user who responds to an arp request for the default gateway's IP address with their own mac. Now all the traffic goes to the malicious user rather than the router. (man in the middle attack)
Malicious use 2. A malicious or malfunctioning computer can send out thousands of arp responses filling up arp tables
Malicious use 3. A malicious or malfunctioning computer can send out arp responses (or gratuitous arp) to false mac addresses breaking network communication.
Arp inspection uses the DHCP snooping binding table to ensure that any arp response from an end user is only for the IP and Mac address they have been properly given by the DHCP server.
Q. This sounds like great security enhancements, are there any "Gotcha's I should know about?"
A. Two of them I can think of.
#1 Say you love this idea and go turn on dhcp-snooping and ip arp inspection today. A computer arp's for the DG or another device but their IP is not in the table yet, they still have a day left on their DHCP lease before they need to renew it. Their arp is dropped and they can't talk to that device. Fix#1, enable DHCP-snooping AT LEAST a full DHCP lease time prior to enabling arp inspection.
#2 Similar to number one. So say you have dhcp-snooping going, and you enable arp inspection, and everything is working fantastic. Now your maintenance window comes along and you need to upgrade your ios and reboot the switch. Now you rebooted and the DHCP-binding table cleared and you are stuck with problem #1 again, until the DHCP leases are renewed clients can't ARP. Fix#2 There is a way to save the database to flash before you reload, or even better, store a copy of the DHCP-snooping table off the switch, on a tftp server.
Q. Configurations?
Cisco:
(config)# ip dhcp snooping
(config)# ip dhcp snooping vlan 20,25-28
(config)# ip dhcp snooping verify mac-address
(config)# interface GigabitEthernet 2/2
(config-if)# ip dhcp snooping trust (for DHCP server connected interfaces and switch uplinks *do all of them since spanning tree could re-converge and send requests up alternate paths!*)
(config)# ip dhcp snooping limit rate 10
(config)# ip dhcp snooping database tftp://10.1.1.1/file
(config)# show running-config dhcp
(config)# ip arp inspection vlan 20,25-28
Procurve:
dhcp-snooping
dhcp-snooping authorized-server #.#.#.#
dhcp-snooping authorized-server #.#.#.#
dhcp-snooping vlan 5 10 20 99
interface a4
dhcp-snooping trust
dhcp-snooping database file tftp://
show dhcp-snooping
show dhcp-snooping stats
show dhcp-snooping binding
arp-protect vlan 5 10 20 99
**dhcp-snooping on many(most?) procurve switches breaks PXE booting/imaging, and as far as I can tell has only been fixed on a few switch models, if you use PXE booting, test this feature before rolling it out to a production environment**
I will look at IP source-guard soon as it also uses the dhcp-snooping database
Thoughts? Suggestions? Accusations? Comments on my mental health?
