cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post
Level 13

DHCP Snooping

Jump to solution

We've had a recent users bring a personal wireless router and plug it into the network and consequently some of our clients started dropping off the network as they were picking up DHCP leases from this rouge device. We've had a recommendation to use DHCP Snooping which will stop this from happening in the future.

I've found some Cisco articles which aren't particulary an easy read and was wondering if anyone in the community had configured DHCP Snooping in the past and if they've got any hits\tips or issues they've had with the technology?

Thanks

Jon

Labels (1)
0 Kudos
1 Solution
Level 11

Jon -

Yup, it's pretty effective to be honest. As thamizh85 has stated, it works on the basis of trusted and untrusted ports for DHCP messages. It does start getting complicated if you are using DHCP relay agents on your network (for instance, a central L3 switch that forwards DHCP requests from all VLANs to a specific DHCP server) -  by default, the Cisco switches will insert what's known as an Option 82 message with the result that the return OFFER messages get blocked when a relay agent is in play. The following should work at a basic level to prevent rogue devices from offering DHCP addresses:

conf t

ip dhcp snooping (enables DHCP snooping globally on the switch)

no ip dhcp snooping information option (turns off the option 82 messages)

ip dhcp snooping vlan xx (specifies the vlan(s) that you want the feature to be active on)

Interface <<trunk_link>> (i.e. the link where your DHCP server actually resides)

   ip dhcp snooping trust (self evident)

If you want to start getting into keeping the DHCP binding tables on the switch etc then the config gets a lot more complex!!

If you aren't already it may also be worth looking at configuring mac address limits, bpdu guard and portfast on your access ports to further limit the potential damage from these devices.

View solution in original post

8 Replies
Level 11

Jon -

Yup, it's pretty effective to be honest. As thamizh85 has stated, it works on the basis of trusted and untrusted ports for DHCP messages. It does start getting complicated if you are using DHCP relay agents on your network (for instance, a central L3 switch that forwards DHCP requests from all VLANs to a specific DHCP server) -  by default, the Cisco switches will insert what's known as an Option 82 message with the result that the return OFFER messages get blocked when a relay agent is in play. The following should work at a basic level to prevent rogue devices from offering DHCP addresses:

conf t

ip dhcp snooping (enables DHCP snooping globally on the switch)

no ip dhcp snooping information option (turns off the option 82 messages)

ip dhcp snooping vlan xx (specifies the vlan(s) that you want the feature to be active on)

Interface <<trunk_link>> (i.e. the link where your DHCP server actually resides)

   ip dhcp snooping trust (self evident)

If you want to start getting into keeping the DHCP binding tables on the switch etc then the config gets a lot more complex!!

If you aren't already it may also be worth looking at configuring mac address limits, bpdu guard and portfast on your access ports to further limit the potential damage from these devices.

View solution in original post

Goliath

I'm just starting to implment DHCP snooping and have a question our DHCP server is a VM and there's 7 hosts in the cluster, I presume from your config above I will need to add the snooping trust config to every single interface on every single host in the cluster so 42 interfaces on the switches need the trust statement or do I just put the trust config on the trunk from our core to the switche(s) that the VM hosts are patched to?

Thanks

Jon

0 Kudos

Hi Jon -

The config I suggested is really for the access/distribution switches supporting your clients (as they are the ones that are likely to be connecting rogue DHCP servers), so the command:

Interface <<trunk_link>> (i.e. the link where your DHCP server actually resides)

   ip dhcp snooping trust (self evident)

Should go on the uplink port that links your access switch back to the core (i.e. "trust" DHCP messages coming from your server room). If you can sketch a quick diagram that would give me a better idea

Regards,

John

0 Kudos

John

See below the basic layout of our network, access switch at the top 6500 core in the middle and 3750 switches provide connectivity for our servers.

Our DHCP server resides on a VM so while it’s located on the 3rd ESX server it could in the event of a failure move to either of the other two ESX servers so just need to know where to put the trust statement?

Thanks

Jon

0 Kudos

Hi Jon

In this case I'd put the trust statement on the interface that your access switch uses to connect to the 6500 (you can use it on the Port-Channel interface if you are using aggregate links). Unless you wish to start storing DHCP binding tables etc as mentioned in my first answer, putting the config just on your access switch (you don't mention the model number but I'll assume 3750) will stop anyone connecting a rogue DHCP server to that access switch from handing out leases etc, as the switch will only trust DHCP messages coming from your 6500.

If you wanted to go a step further, you could add the config to the 6500, this time adding the trust statement to the interfaces that connect the three ESX hosts etc (but note that you shouldn't add it to the 6500 interface connecting to your access switch; as any DHCP server-type messages coming FROM that switch shouldn't be trusted!!).

Regards,

John

John

Thanks that’s a great help.

Jon

0 Kudos

Thanks Goliath.

0 Kudos
Level 12

The underlying idea in using DHCP snooping is that, your production DHCP server is not supposed to be connected to any of the access switch ports. So we design them to permit only DHCPDISCOVER packets and block any DHCPOFFER packets coming from such ports. If the rogue DHCP server is going to impact your network, it has to push DHCPOFFER packets through your access ports and that is where you have configured your switch to distrust such offer packets.

Of course, there should be a valid DHCP server for every Vlan (or network segment) and you identify to which port it is connected (normally the Uplink or the Trunk to upstream switches). You would configure that as trusted port, such that DHCPOFFERs can continue to flow from that port. This way you ensure only valid server is providing your DHCP offers. That is the rough outline, but of course there are much more details to be taken care of if you were to implement it.