The premiere source of truth powering network automation. Open and extensible, trusted by thousands.
NetBox is now available as a managed cloud solution! Stop worrying about your tooling and get back to building networks.
DHCP Snooping and Dynamic ARP Inspection
By stretch | Wednesday, August 18, 2010 at 3:01 a.m. UTC
DHCP snooping is a feature which allows a Cisco Catalyst switch to inspect DHCP traffic traversing a layer two segment and track which IP addresses have been assigned to hosts on which switch ports. This information can be handy for general troubleshooting, but it was designed specifically to aid two other features: IP source guard and dynamic ARP inspection. These features help to mitigate IP address spoofing at the layer two access edge. I've already covered IP source guard (with and without DHCP), so today we'll look at how to implement dynamic ARP inspection.
First, we need to enable DHCP snooping, both globally and per access VLAN:
Switch(config)# ip dhcp snooping
Switch(config)# ip dhcp snooping vlan 10
Switch(config)# ^Z
Switch# show ip dhcp snooping
Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:
10
DHCP snooping is operational on following VLANs:
10
DHCP snooping is configured on the following L3 Interfaces:
Insertion of option 82 is enabled
circuit-id format: vlan-mod-port
remote-id format: MAC
Option 82 on untrusted port is not allowed
Verification of hwaddr field is enabled
Verification of giaddr field is enabled
DHCP snooping trust/rate is configured on the following Interfaces:
Interface Trusted Rate limit (pps)
------------------------ ------- ----------------
In this scenario, our multilayer switch is relaying DHCP requests toward a central DHCP server elsewhere on the network, a behavior enabled by adding one or more ip helper-address commands under the access VLAN interface. However, if the access switch was functioning only at layer two, we would have to designate our uplink interfaces as trusted interfaces by applying the command ip dhcp snooping trust to the layer two interfaces. This informs the switch that DHCP responses are allowed to arrive on those interfaces.
Legitimate DHCP clients and their assigned IP addresses will appear in the DHCP snooping binding table:
Switch# show ip dhcp snooping binding MacAddress IpAddress Lease(sec) Type VLAN Interface ------------------ --------------- ---------- ------------- ---- -------------------- 00:19:AA:7D:E6:88 192.168.10.2 86250 dhcp-snooping 10 FastEthernet0/3 Total number of bindings: 1
Next, we'll enable dynamic ARP inspection for the VLAN. (When enabling the feature for multiple VLANs, a range of VLAN numbers can be specified.)
Switch(config)# ip arp inspection vlan 10 Switch(config)# ^Z Switch# show ip arp inspection Source Mac Validation : Disabled Destination Mac Validation : Disabled IP Address Validation : Disabled Vlan Configuration Operation ACL Match Static ACL ---- ------------- --------- --------- ---------- 10 Enabled Active Vlan ACL Logging DHCP Logging Probe Logging ---- ----------- ------------ ------------- 10 Deny Deny Off Vlan Forwarded Dropped DHCP Drops ACL Drops ---- --------- ------- ---------- --------- 10 0 0 0 0 Vlan DHCP Permits ACL Permits Probe Permits Source MAC Failures ---- ------------ ----------- ------------- ------------------- 10 0 0 0 0 Vlan Dest MAC Failures IP Validation Failures Invalid Protocol Data ---- ----------------- ---------------------- --------------------- 10 0 0 0
Notice in the above output that source MAC, destination MAC, and IP address validation are indicated as being disabled. We can optionally enable one or more of these additional validation checks to achieve even more thorough security with the command ip arp inspection validate followed by the address type.
Now suppose an intruder connects to VLAN 10 on interface FastEthernet0/5 and begins sending gratuitous ARP replies, purporting to be the default router for the subnet in an attempt to initiate a man-in-the-middle attack. The switch inspects these ARP packets and does not find an entry in the DHCP snooping table for the source IP address 192.168.10.1 on port FastEthernet0/5. The packets are consequently discarded by the switch, as evidenced by this log message:
%SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Res) on Fa0/5, vlan 10. ([0013.6050.acf4/192.168.10.1/ffff.ffff.ffff/192.168.10.1/05:37:31 UTC Mon Mar 1 1993])
We can see the drop counter begin to increase in the output of show ip arp inspection:
Switch# show ip arp inspection Source Mac Validation : Disabled Destination Mac Validation : Disabled IP Address Validation : Disabled Vlan Configuration Operation ACL Match Static ACL ---- ------------- --------- --------- ---------- 10 Enabled Active Vlan ACL Logging DHCP Logging Probe Logging ---- ----------- ------------ ------------- 10 Deny Deny Off Vlan Forwarded Dropped DHCP Drops ACL Drops ---- --------- ------- ---------- --------- 10 22 2 2 0 Vlan DHCP Permits ACL Permits Probe Permits Source MAC Failures ---- ------------ ----------- ------------- ------------------- 10 22 0 0 0 Vlan Dest MAC Failures IP Validation Failures Invalid Protocol Data ---- ----------------- ---------------------- --------------------- 10 0 0 0
A word of caution
If the DHCP server is an IOS router directly connected to the layer two segment, you may see it throw the following error if DHCP server debugging is enabled (debug ip dhcp server packet):
DHCPD: inconsistent relay information. DHCPD: relay information option exists, but giaddr is zero.
The router is complaining about the presence of DHCP option 82 with a null value being added by the switch performing DHCP snooping. This is easily remedied by issuing the command no ip dhcp snooping information option in global configuration on the switch to disable the addition of option 82 to DHCP requests. Check out this article by Internetwork Expert for more information.
Posted in Switching
Comments
August 18, 2010 at 7:01 a.m. UTC
Great post on the two, although another word of caution... If you are enabling this in a production environment be sure to let DHCP snooping run for at least half the time of the DHCP leases if not more. With ARP Inspection depending on the DHCP snooping table, it is going to need to have some entries or you will be seeing a lot of those log messages. :)
August 18, 2010 at 11:55 a.m. UTC
My typical problem when implementing DAI was, that there were always PCs with hardcoded IP-addresses, regardless what the Client-Staff told me ... To help myself, I wrote a little (very basic) Python-script, that compares the entries of the DHCP-snooping-bindings with the the arp-entries of the connected L3-switch. You can download the script on my blog. The page is in german, but the script is pretty easy to use.
September 1, 2010 at 10:29 p.m. UTC
Hi there,
I really liked your article here. I set up dhcp snooping on a site using your guide this evening and it worked great. However I am a little confused about the "ip dhcp snooping information option" command. On the site I implemented tonight I configured "no ip dhcp snooping information option" on every switch, works fine but on a previous site I have "ip dhcp snooping information option" on all switches and DHCP snooping still works.
In both cases the DHCP Server is a cisco switch.
Should I do a "no ip dhcp snooping information option" on my previous config, is there an impact on issuing it or if I leave it as is is there a danger of problems down the road?
Many thanks,
Josey
October 24, 2010 at 12:41 a.m. UTC
@robgil: Serious question, because I've held off implementing DAI in our environment (University) as a result: What happens when (not if) the switch is reloaded because of a power disruption? Actually, may have answered my own question - I seem to remember that you can have the binding table written to a non-volatile location (TFTP or the like) so that it's immediately repopulated when the switch reloads.
Has anyone tried this and found that it does/doesn't work well?
Retro-fitting the network with DAI also raises a fear about just who you'll end up cutting off because they've been given a static IP that isn't recorded anywhere (by someone else, of course!)?
@stretch: Great site. Just discovered it. Keep up the good work.
Cheers,
Ben.
April 12, 2011 at 4:14 p.m. UTC
Hi Jeremy
I have 2 3560 distribution switches both connected via L2 etherchannel. Underneath it is 10 access switches mix of 3550s and 2950Gs. I want to implement arp inspection and dhcp snooping. my dhcp server is on the 3550 switch. ip helper address is also implemented on my 3560s. my question is, where do I place the dhcp snooping and ip arp inspection? do i need to place it also on the trunk ports? including the etherchannel?
thanks in advance.
May 29, 2011 at 7:58 p.m. UTC
Hi John, i think you need to put the ip dhcp snooping and ip arp inspection configuration in the global configuration ( you also need to specify which vlan you would want to implement these features.) You need to put the ip dhcp snooping trust and ip arp inspection trust in the uplinks. (e.g. trunk ports to other switches)
June 21, 2011 at 8:35 a.m. UTC
Hi,
Do we need to create the DHCP snooping table? or it will get generated automatically?
Thanks,
N9.
October 18, 2012 at 8:44 p.m. UTC
Good article. :)
Also remember to "ip arp inspection trust" any uplink ports to other switches in the environment. Non-issue in a single switch environment like this how-to.
March 21, 2013 at 1:28 a.m. UTC
An alternative to the "no ip dhcp snooping information option" would also be to have the router that is acting as the IOS DHCP server configured with the "ip dhcp relay information trust-all" command.
The command makes IOS DHCP server accept empty giaddr in the DHCP messages.
May 11, 2015 at 5:08 p.m. UTC
thanks
March 7, 2016 at 5:00 p.m. UTC
Just don't configure DHCP snooping with 15.0(2)SE5 on a 3560 :)
August 12, 2016 at 10:52 p.m. UTC
HI what happen if enabled ip arp inspection with dhcp snooping in wifi guest network ? DIA block dhcp messages or not if no entry on dhcp binding table if new guest connected to netork what happen ?