cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Join Customer Connection to register!
737
Views
0
Helpful
6
Replies
dangreen12
Beginner

DHCP Snooping binding database

After we configured DHCP Snooping on out access switch, all works well. I see dhcp bindings with the "sh ip dhcp snooping binding" command. I don't quite understand why we need to see the bindings on the switch as we know the client PC's are getting IPs the typical way. More importantly, I understand that if we reload the access switch (to do an IOS upgrade, the switch loses power, etc.), the lose the previous bindings. This part concerns me. So it is suggested that we create a location to a TFTP database in case the switch reloads so you can fetch previous bindings. For example:  ip dhcp snooping database <TFTP URL>

 

If we DO lose the bindings database do we impact the user traffic? I tested by being on my PC, got an IP, and ran extended pings to a web server. I cleared my binding entry using the "clear ip dhcp binging <My IP> and it cleared and it didn't impact my computer's IP connectivity, pings continued to flow. I can't reload the switch to test that impact.

 

This issue of users being impacted if the switch reloads scares me. 

6 REPLIES 6
Giuseppe Larosa
Hall of Fame Master

Hello @dangreen12 ,

>> So it is suggested that we create a location to a TFTP database in case the switch reloads so you can fetch previous bindings. For example: ip dhcp snooping database <TFTP URL>

 

Follow this recommendation so that in case of switch reload it can read the current bindings from the TFTP server.

 

This feature is really important is you have also enabled security feature like DHCP snooping , Dynamic ARP Inspection and IP source guard that all of them rely on knowing where an IP address is located (which port ) and if it had been assigned by DHCP.

If these features are enabled the risk in case of reload without the use of an external TFTP server to recover the current DHCP bindings is that all user traffic is somewhat impacted with legitimate DHCP clients seen as non authorized.

 

Hope to help

Giuseppe

 

Thx for the reply. We are not doing IP Source Guard or DAI. Just DHCP Snooping for the reason of stopping anyone on a user vlan from plugging in a device or system that provides DHCP services and causing conflict. A couple followup questions if that is OK or I can enter another posting.

 

1. So in terms of creating a TFTP database so the switch can read the current bindings from the TFTP server, considering I am not doing IPSG or DAI,  if the switch reloads, does this mean if i don't have the TFTP database setup that the switch binding table will clear and each computer will need to do a renew and get an IP and the bindings rebuild?  What I am wondering is if there is an impact to the users during this rebuild. Or if they need to manually renew for an IP. 

 

2. I noticed that when I do a "show ip dhcp snooping" I see these entries below. I take it these are just default with DHCP Snooping.

 

Verification of hwaddr field is enabled
Verification of giaddr field is enabled

 

 

 

If the switch reloads that has the ip dhcp snooping binding table and I don't have the original binding table I assume the client machines on untrusted ports (that are in the binding table) lose their IP as if there was an "ipconfig /release". True?  If so I imagine the worst case is that the client machine has to do an "ipconfig /renew" and they are off and running again. Whether that renew happens automatically or the client has to do the renew manually. Any thoughts?  I'm still trying to identify if there is a true impact if we reload the switch and lose the binding table.

Hi Dangreen,

 

Thanks, for bringing this up.

 

DHCP snooping database feature is really required to safeguard our L2 data, however we came across many instances where the prod access switch is rebooted, and so the clients loss the connectivity.

 

But once the switch is back up again, the end devices will start sending the requests on the associated ports where in our environment we have L2 functions enabled like spanning tree, trust ports and untrust ports.

 

The switch has the capability to rebuilt it's DHCP database table on it's own, also we will take frequent backups of the switch using automated tools so even though the switch reboots we have the latest backups that includes the client connectivity details but as per me, the switch will rebuilt it again the existing Database table

 

MHM Cisco World
Collaborator

TFTP is use because the NVRAM is limit so in order to not full NVRAM with this binding we use TFTP server database.
That what I know.

That makes sense. Thanks!  Now I'm reading about the process to see if, after the switch reloads, if it just finds the database file and pulls it in automatically.