Sunteți pe pagina 1din 10

11/18/2017 CCNP Studies: Configuring DHCP Snooping - Packet Pushers -



You are here: Home / Blogs / CCNP Studies: Con guring DHCP Snooping

CCNP Studies: Con guring DHCP Snooping

Edward Yardley August 3, 2012

Ive been enthralled with the security features for Catalyst switches. Ive had to plug
away at the theory and lab work recently, but have probably gone a little further
down the rabbit hole in this area. I feel that solid knowledge of DHCP Snooping is
needed as a foundation for other security features. Both IP Source Guard and
Dynamic ARP Inspection rely on it, so if youve got your head around snooping, youll
be in good shape.

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 traf c owing 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.
Latest Podcasts
The topology
The Weekly Show

Show 366: Inside Cisco EVPN

(Sponsored) November 17, 2017

Our client connects to an untrusted port; all ports are untrusted by default. When
Network Break
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 Network Break 161: Broadcom Bids For
our distribution switch is acting as the DHCP server, but a DHCP server running Qualcomm; Level 3s BGP Blues
external to the switch could also be used.A trusted port is the only port which is November 13, 2017

allowed to send DHCP Server responses such as DHCPOFFER.

Con guration Datanauts

Lets jump onto SW1 and enable DHCP Snooping: Datanauts 110: The Future Of Storage
November 15, 2017

SW1(con g)#ip dhcp snooping

SW1(con g)# Priority Queue 1/10
11/18/2017 CCNP Studies: Configuring DHCP Snooping - Packet Pushers -

We also need to enable it for our VLANs. In this case were only using VLAN 1: PQ 135: Mastering Python Networking
The Book November 9, 2017

SW1(con g)#ip dhcp snooping vlan 1

SW1(con g)#
The Community Show

Advocating For Enterprise Interests At

Great so far! Now, we make Fa0/1 facing DSW1 a trusted port: The IETF IETF 99 August 22, 2017

SW1(con g)#int fa0/1

Recent Comments
SW1(con g-if)#ip dhcp snooping trust
SW1(con g-if)# IA on Show 366: Inside Cisco EVPN

Stephen Hampton on A Request For

Its a good idea to enable rate limiting on the untrusted ports. This is speci ed 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: Greg Ferro on Ciscos Viptela Challenge:
Integration without alienation

Peyton Maynard-Koran on Show 365:

SW1(con g-if)#ip dhcp snooping limit rate ? You Cant Do That In Enterprise
<1-4294967294> DHCP snooping rate limit Networks

Steven Iveson on Show 365: You Cant

SW1(con g-if)#ip dhcp snooping limit rate 25
Do That In Enterprise Networks
SW1(con g-if)#
Drew Conry-Murray on Show 365: You
Cant Do That In Enterprise Networks

Veri cation
Lets take a look at the DHCP Snooping con g:

SW1#sh ip dhcp snooping

Switch DHCP snooping is enabled
DHCP snooping is con gured on following VLANs:
Insertion of option 82 is enabled
Interface Trusted Rate limit (pps)
- -
FastEthernet0/1 yes unlimited
FastEthernet0/24 no 25

Next we connect our client machine to Fa0/24 on SW1. We can see the DHCP
binding has been captured by DHCP Snooping: 2/10
11/18/2017 CCNP Studies: Configuring DHCP Snooping - Packet Pushers -

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 dont 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 speci c port a client machine is connected to. DHCP packets
also carry a giaddr eld which is set to by default (a non-zero value). (EDIT: I
originally said giaddr was a eld in Option 82, however it is a eld in the DHCP
packet not Option 82 itself. Thanks to Bob for pointing this out.) Both of these things
will show up in error messages if something is miscon gured. In the topology above,
Option 82 isnt a problem because DHCP Snooping isnt enabled on DSW1 (only on
SW1), so lets add another switch:

In this topology, the ports facing our DHCP server, Fa0/2 on SW1 and Fa0/11 on
SW2, have been con gured 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. This is what is seen in debug on SW2 when SW1 sends a
DHCPDISCOVER out port Fa0/2:

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 Snoopings
point of view, so it drops the packets by default because Option 82 exists. That traf c
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!) Well solve this problem by
using one command on SW2 that will trust packets with DHCP Option 82 that are
received on untrusted ports.

SW2(con g)#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(con g)#ip dhcp relay information trust-all 3/10
11/18/2017 CCNP Studies: Configuring DHCP Snooping - Packet Pushers -

Were 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 rst place (using #no ip dhcp snooping
information option). Well leave it here for now, but I 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 Milivojevics four part in-depth post on
Understanding DHCP Snooping helpful when coming to grips with DHCP Option 82
in particular.

About Edward Yardley


Feedback says

August 4, 2012 at 12:12 PM

it is very knowledgeable article


Bob says

August 7, 2012 at 12:24 PM

Are you sure the giaddr is contained in the Option 82 eld?


Edward Yardley says

August 8, 2012 at 12:59 AM

Good spotting Bob. Ill edit the post, giaddr is in the DHCP packet not in Option 82


Martin says 4/10
11/18/2017 CCNP Studies: Configuring DHCP Snooping - Packet Pushers -
February 16, 2013 at 2:17 PM

Hi, why would you leave uplink ports in untrusted state? I was always under the impression
that all ports apart from uplinks and ports connected to DHCP servers should be


Madhav Pai says

January 25, 2017 at 6:58 AM

Martin, Fa0/24 is downlink for Sw1. This switch is not supposed to trust DHCP offer
and DHCP Ack messages coming from the downlink.


CCSmooth1 says

April 4, 2013 at 1:07 AM

Very informative article by the way, but I have the same question as Martin. Why would
Fa0/24 be considered an untrusted port? In my CCNP studies I always understood Trunk
ports like switch to switch uplinks were to be considered trusted ports. Only edge ports
facing clients should be untrusted. Am I missing something?


james says

April 5, 2016 at 6:16 AM

I believe that f0/24 should be remained as an untrust port since the port could be
used for an illegitimate DHCP server connection(as mentioned in the article- security
hole). The all DHCP response packets such as DHCPOFFER,DHCPACK and
DHCPNACK should come through f0/11, not through f0/24. If an illegitimate DHCP
server is attached to the SW1 and a client connected to the SW2 could get an IP from
the illegitimate server not from the DSW1 when the f0/24 is a Trust port.


Brain2000 says

November 4, 2017 at 10:42 PM

If SW1 is controlled by a 3rd party that would be true. But if you control SW1,
then you know that all ports (except the uplink 0/2) are set to UNTRUSTED,
which will render any rogue DHCP server useless.

Therefore, SW2 0/24 should be changed to TRUSTED, and option 82 and DHCP
relay should be changed back.

By having option 82 and DHCP relay available for all untrusted ports to set, you
have essentially traded one vulnerability for another.

Remember, leave all UPLINKS, DOWNLINKS, and DHCP servers in DHCP

trusted mode. Make sure ALL other ports are untrusted. That will build a DHCP
perimeter around your entire network. 5/10
11/18/2017 CCNP Studies: Configuring DHCP Snooping - Packet Pushers -


Guy Morrell says

August 7, 2014 at 10:45 AM

Great article. Making it clear youve switched to port Fa 0/24 on SW1 prior to con guring
limit rate 25 would help.


ElBloguero says

November 10, 2014 at 5:33 PM

Thank you, exactly what I was looking for.


GamingVic says

November 17, 2014 at 8:59 PM

How would putting trust on our trunk links expose us security wise?


Sam says

April 20, 2016 at 7:02 PM

I believe that on switch 2 the only port that DHCP replies should be received from is
f0/11. By setting port f0/24 to trust we would inadvertently allow DHCP replies to
come from Switch1 f0/2. When attempting to secure switch2 from rogue DHCP
servers, we should protect it from any possible threats. Making f0/24 an untrusted
port removes this possible threat.


Dealers comments says

January 11, 2015 at 4:20 PM

Thanks, Great article


dorjee says

February 22, 2015 at 1:39 PM 6/10
11/18/2017 CCNP Studies: Configuring DHCP Snooping - Packet Pushers -

Hi, ios version is running on SW1 layer 3 switch?


Morten says

March 16, 2015 at 1:27 PM

You have set up the dhcp snooping, but no DHCP snooping database agent, so upon a
reload your database will be lost, which might cause network problems.


Fahad says

October 2, 2015 at 7:36 AM

hello and thanks for the helpfull article

Pl tell me if a rouge dhcp server found on the port which is un-trusted.
The port will be shut down ? if shutdown it will up automatically ?


Manik says

January 30, 2016 at 3:10 AM

Thanks for the write up. Consise and to the point.


Andrew says

June 29, 2016 at 9:30 AM

Thank you Edward, very useful post.


Adi says

March 5, 2017 at 1:14 PM

I wandered so much to understand this, nally got it thanks


Max says

April 5, 2017 at 3:37 PM

I am not seeing an issue, if you trusted fa0/24 it shouldnt make a difference, it is a trunk
port. If you are having a rouge host somehow connect to fa0/24 then you have a bigger
problem then a simple DHCP issue as someone would have to physically cabled their 7/10
11/18/2017 CCNP Studies: Configuring DHCP Snooping - Packet Pushers -

machine into one of your Trunk ports.. It comes down to a what comes rst, the chicken or
the egg scenario, but ultimately who cares because the elephant is in your switching closet
trampling on your network? I understand where the argument is coming from where you
shouldnt have offers/acks/nacks coming from that port, but that shouldve been the case
on all of your other access ports on sw1 to begin with making the condition impossible.


Jorge Rodriguez says

May 11, 2017 at 6:20 PM

estoy teniendo problemas con esta con guracion.

al declarar en el sw el ip dhcp snooping , luego la vlan permitida y luego el puerto troncal

como seguro solamente, no me permite ningun otro puerto a menos que lo declare seguro.

de verdad que no logro realizar la con guracion para evitar los ataques de servidores dhcp


Binoj says

October 11, 2017 at 8:43 AM


I have done a setup to test the dhcp snooping in packet tracer. My DHCP server is
con gured in core (3560). I have setup one 2960 switch and assigned some clients to it.
Attacker server is also bind to 2960. So while doing the snooping , I am not getting dhcp

con gs as follows :

Core :

Core#sh ip dhcp snooping

Switch DHCP snooping is enabled
DHCP snooping is con gured on following VLANs:
DHCP snooping is operational on following VLANs:
Smartlog is con gured on following VLANs:
Smartlog is operational on following VLANs:
DHCP snooping is con gured on the following L3 Interfaces:

Insertion of option 82 is disabled

circuit-id default format: vlan-mod-port
remote-id: 0001.6320.66B3 (MAC)
Option 82 on untrusted port is not allowed
Veri cation of hwaddr eld is enabled
Veri cation of giaddr eld is enabled
DHCP snooping trust/rate is con gured on the following Interfaces: 8/10
11/18/2017 CCNP Studies: Configuring DHCP Snooping - Packet Pushers -

Interface Trusted Allow option Rate limit (pps)

- -
GigabitEthernet0/1 no no unlimited
Custom circuit-ids:

Core#ip dhcp pool lap


ip dhcp snooping vlan 20

no ip dhcp snooping information option
ip dhcp snooping

interface GigabitEthernet0/1
switchport trunk allowed vlan 10,20
switchport trunk encapsulation dot1q
switchport mode trunk

Edge switch :

ip dhcp snooping vlan 20

no ip dhcp snooping information option
ip dhcp snooping

interface FastEthernet0/1
switchport access vlan 20
switchport mode access
interface FastEthernet0/2
switchport access vlan 20
switchport mode access
interface FastEthernet0/10
description Attacker-server
switchport access vlan 20
switchport mode access

interface GigabitEthernet0/1
switchport trunk allowed vlan 10,20
ip dhcp snooping trust
switchport mode trunk

In port 20 Attacket pc is con gured with dhcp pool enabled.

I have tested with trust option in uplink as well, but it was not working.


Leave a Reply
Your email address will not be published. Required elds are marked *

Comment 9/10
11/18/2017 CCNP Studies: Configuring DHCP Snooping - Packet Pushers -

Name *

Email *


Post Comment

PacketPushers Podcast PacketPushers Articles Website Information Connect

Full Feed All the News & Blogs Frequently Asked Questions Contact PacketPushers
Weekly Show Only the Latest News Subscribe Ask Us Anything!
The Network Break Only The Community Blogs Sponsorship Subscribe to Podcasts
Brie ngs In Brief How To Pitch Us Become a Member
Datanauts Search Meet the Hosts Sponsorship
Full Stack Journey Terms & Conditions
Search this website Search
Priority Queue Privacy Policy
Community Podcast

Copyright 2017 Packet Pushers Interactive, LLC All Rights Reserved Designed by Teal Umbrella 10/10