As the others have pointed out that behavior is out of the box, the whole point of DHCP snooping is to prevent rouge DHCP servers on the network, here's a packet validation output from a 6500 series running 12-2SX code:
Packet Validation The switch validates DHCP packets received on the untrusted interfaces of VLANs with DHCP snooping enabled. The switch forwards the DHCP packet unless any of the following conditions occur (in which case the packet is dropped): •The switch receives a packet (such as a DHCPOFFER, DHCPACK, DHCPNAK, or DHCPLEASEQUERY packet) from a DHCP server outside the network or firewall. •The switch receives a packet on an untrusted interface, and the source MAC address and the DHCP client hardware address do not match. This check is performed only if the DHCP snooping MAC address verification option is turned on. •The switch receives a DHCPRELEASE or DHCPDECLINE message from an untrusted host with an entry in the DHCP snooping binding table, and the interface information in the binding table does not match the interface on which the message was received. •The switch receives a DHCP packet that includes a relay agent IP address that is not 0.0.0.0. There's further considerations if you have a relay agents using Option 82 and it gets ugly so you're best of doing some reading... In high level you plug a rouge DHCP server on a switchport which is un-trusted the end result is any DHCP messages from this server will be dropped as it's switchport is not configured to be "trusted" So you're clients sending DHCPDISCOVER messages will not get a reply from the rouge DHCP but only from the DHCP server you configured to be switchport trusted. HTH -- BR Tony On 23 July 2014 05:31, Taqdir Singh <[email protected]> wrote: > thanks friends. > > suppose if i dont want to use to DIA and source guard.. then is there any > way that I dont want snooping binding database to be created because i will > never use DIA > > i just want dhcp snooping to drop packets based on dhcp packets only but > not to create entry in binding table > > > On Wed, Jul 23, 2014 at 8:41 AM, Ryan Jensen <[email protected]> wrote: > > > You can use the bindings db for dynamic arp inspection. It compares > > entires in the table to the arp messages being seen. > > Ex: the bindings table says IP 1.1.1.2 is on port G0/4. Someone does arp > > request for 1.1.1.2 and the arp reply comes from int G0/6.... That's a > > violation and the arp reply would be dropped. > > You can backup the bindings db to tftp priodically and then download that > > table when it boots up to restore the bindings. > > > > > > On Tuesday, July 22, 2014, Taqdir Singh <[email protected]> wrote: > > > >> Hi Team, > >> > >> > >> DHCP Snooping creates snooping database with help of DHCP packets > flowing > >> through > >> > >> > >> but once switch is rebooted by default the database is lost > >> > >> but clients will still have the IP address. > >> > >> So my question is.. now in this case switch wont be having the DHCP > >> binding > >> database.. will client still be able to communicate and do normal work. > >> > >> if yes.. then what is the benifit of keeping DHCP snooping binding > table ? > >> > >> i think if it just drops dhcp offer/ack packets on untrusted ports thats > >> good.. but why it creates entry in binding table > >> > >> > >> > >> -- > >> _______________________________________________ > >> Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: > >> > >> iPexpert on YouTube: www.youtube.com/ipexpertinc > >> > > > > > -- > > > Thanks & regards, > > Taqdir Singh > Ph: (+91) 8826009496 > _______________________________________________ > Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: > > iPexpert on YouTube: www.youtube.com/ipexpertinc > _______________________________________________ Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc
