Beruflich Dokumente
Kultur Dokumente
MEMBER LOG
HOME SHOWS NEWS HOSTS TOOLBOX SPONSOR CONTACT Search this website
You are here: Home / Blogs / CCNP Studies: Con guring DHCP Snooping
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.
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
Lets jump onto SW1 and enable DHCP Snooping: Datanauts 110: The Future Of Storage
November 15, 2017
http://packetpushers.net/ccnp-studies-configuring-dhcp-snooping/ 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
Veri cation
Lets take a look at the DHCP Snooping con g:
Next we connect our client machine to Fa0/24 on SW1. We can see the DHCP
binding has been captured by DHCP Snooping:
http://packetpushers.net/ccnp-studies-configuring-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 0.0.0.0 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. 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 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.
Because our DHCP server is a Cisco IOS device, it also needs to trust DHCP packets
with option 82 set:
http://packetpushers.net/ccnp-studies-configuring-dhcp-snooping/ 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.
Comments
Feedback says
Reply
Bob says
Reply
Good spotting Bob. Ill edit the post, giaddr is in the DHCP packet not in Option 82
itself.
Reply
Martin says
http://packetpushers.net/ccnp-studies-configuring-dhcp-snooping/ 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
untrusted.
Reply
Martin, Fa0/24 is downlink for Sw1. This switch is not supposed to trust DHCP offer
and DHCP Ack messages coming from the downlink.
Reply
CCSmooth1 says
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?
Reply
james says
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.
Reply
Brain2000 says
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.
http://packetpushers.net/ccnp-studies-configuring-dhcp-snooping/ 5/10
11/18/2017 CCNP Studies: Configuring DHCP Snooping - Packet Pushers -
Reply
Great article. Making it clear youve switched to port Fa 0/24 on SW1 prior to con guring
limit rate 25 would help.
Reply
ElBloguero says
Reply
GamingVic says
How would putting trust on our trunk links expose us security wise?
Reply
Sam says
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.
Reply
Reply
dorjee says
http://packetpushers.net/ccnp-studies-configuring-dhcp-snooping/ 6/10
11/18/2017 CCNP Studies: Configuring DHCP Snooping - Packet Pushers -
Reply
Morten says
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.
Reply
Fahad says
Reply
Manik says
Reply
Andrew says
Reply
Adi says
Reply
Max says
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
http://packetpushers.net/ccnp-studies-configuring-dhcp-snooping/ 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.
Reply
de verdad que no logro realizar la con guracion para evitar los ataques de servidores dhcp
ilegitimos.
Reply
Binoj says
Hello,
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
released.
con gs as follows :
Core :
http://packetpushers.net/ccnp-studies-configuring-dhcp-snooping/ 8/10
11/18/2017 CCNP Studies: Configuring DHCP Snooping - Packet Pushers -
interface GigabitEthernet0/1
switchport trunk allowed vlan 10,20
switchport trunk encapsulation dot1q
switchport mode trunk
Edge switch :
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
I have tested with trust option in uplink as well, but it was not working.
Reply
Leave a Reply
Your email address will not be published. Required elds are marked *
Comment
http://packetpushers.net/ccnp-studies-configuring-dhcp-snooping/ 9/10
11/18/2017 CCNP Studies: Configuring DHCP Snooping - Packet Pushers -
Name *
Email *
Website
Post Comment
Copyright 2017 Packet Pushers Interactive, LLC All Rights Reserved Designed by Teal Umbrella
http://packetpushers.net/ccnp-studies-configuring-dhcp-snooping/ 10/10