“At work I've got a cisco 3750 switch and few end devices which of course are company proprietary, connected to this switch in a separate VLAN. Now these end devices generate dhcp traffic "request" and is being propagated across all the sites where these devices are connected.
Now I've been reading stuff about dhcp snooping features which is great but in this instance these end devices don't have a DHCP server. In this scenario all these end end devices have got static ip addresses allocated.
Also my senior engineer being very narrow minded wants me to implement this change only on the interface level and not on the configuration level.
Can someone please confirm if I can just only enable "ip dhcp snooping trust" on the interface level which i believe will stop the dhcp traffic?”
The above question is about DHCP snoopingconfiguration. Here we will list some related tech tips and examples to give a response.
Every example in the response post has been tested in a lab environment with a Cisco 3550, Infoblox DHCP servers, a Netgear router as a "rogue" dhcp server, and a MacBook Pro as a client. The 3550 is configured with ip routing and a layer 3 interface on the subnet where the DHCP servers are located (10.0.10.0/24). VLAN 20 has been created on the 3550 with an interface ip address of 10.0.20.254/24. All the DHCP server configuration and helper addresses were tested and working prior to implementing DHCP snooping to eliminate any doubt as to whether the DHCP snooping configuration is working or not. So, let's get started.
For DHCP snooping to work, you have to enable it globally. That is done with the following global configuration command:
Switch(config)#ip dhcp snooping
You also have to tell the switch which VLANs to monitor. In a production environment, this would be the client VLANs, not a transit VLAN that leads to the rest of the network. This is done with the following command:
Switch(config)#ip dhcp snooping vlan 20
At this point DHCP snooping is configured and enabled. There are several default settings that can be modified later, but that can be delt with after we verify things are working. Here is the basic show command to verify DHCP snooping is working (specifically the top few lines):
Switch#show ip dhcp snooping
Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:
DHCP snooping is operational on following VLANs:
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)
------------------------ ------- ----------------
Once you verify DHCP snooping is working, you can verify DHCP lease information starts to populate the DHCP snooping binding table on the switch with the following command:
Switch#show ip dhcp snooping binding
MacAddress IpAddress Lease(sec) Type VLAN Interface
------------------ --------------- ---------- ------------- ---- --------------------
AA:2C:DD:09:D1:CD 10.0.20.28 28781 dhcp-snooping 20 FastEthernet0/13
Total number of bindings: 1
If you have a DHCP server plugged into a switch with DHCP snooping enabled, or if you have a layer 2 LAN port connected to an upstream switch where the DHCP server resides, you'll have to trust that port. To do this, enter the following command in interface configuration mode:
Switch(config-if)#ip dhcp snooping trust
Any DHCP responses that come from an untrusted port (all the other ports) will simply be dropped without any notification. To test this out, after this was all configured and working, I connected a Netgear router with DHCP enabled into another VLAN 20 access port on the 3550. I forced a DHCP request to be sent out by the client and nothing happened. No log messages or warnings, nothing. Just to be sure the rogue DHCP server was working; I disabled snooping and unplugged the 3550 uplink to the production network. The client received a 192.168.1.2 ip address immediately. I released the IP, reconfigured snooping and tested again. The client received an IP from the authorized DHCP server and nothing happened with the fake DHCP server port.
I wish the switch was smart enough to put the switch-port connected to the rogue DHCP server into err-disable mode, but at least it stops the unauthorized DHCP server from actually handing out IP leases.
This concludes the basic DHCP snooping configuration. For additional information regarding DHCP snooping configuration options, check out these links:
Also, for reference, here are the relevant parts of my 3550 lab configuration:
description Layer 3 uplink to production network
ip address 10.0.10.253 255.255.255.0
description Rogue DHCP server
switchport access vlan 20
switchport mode access
switchport access vlan 20
switchport mode access
ip address 10.0.20.254 255.255.255.0
ip helper-address 10.0.10.106
ip helper-address 10.0.10.107
One final thought. If you are rolling this out into production, be sure to do so during a change window and test a client DHCP request with ipconfig /release and ipconfig /renew to be sure it can get an IP address and it shows up in the binding table.
Notes: This configuration was tested in a lab environment. If you use this configuration to modify a production environment, you do so at your own risk. The information in this post is provided as an example so you can custom tailor it to your own network. Don't blame me if this information is misused and causes an outage to production systems.
More Related Cisco Tech Tips: