DHCP Snooping - High CPU

Unanswered Question
Feb 5th, 2009

I have a LAN environment with roughly 4000 end devices that utilized DHCP. At the core we have two 6500 series route-switches with sup-720s, a distribution layer with 4000 series switches, and either 3560 or 2950 access series switches at the edge.

We have a need to protect the environment from rouge DHCP servers, so I deployed DHCP snooping in the following fashion. On one core box that also has the DHCP servers directly connected I configured DHCP snooping for four /24 networks and trusted the ports to the DHCP servers. On the other core box I configured DHCP snooping for the same four networks and only trusted the trunks to the other core. At the distribution layer I again configured DHCP snooping for the same four networks and trusted the uplinks to the core.

I observed the following behavior:

- The CPU utilization on the 6500's went from 1-3% to 80-99% utilization and sustained that same level for more than 15 minutes.

- Two processes DHCP snooping and IP input were causing the spike

- If I disabled DHCP snooping on either core box the CPU of the box would immediately settle to 1-3%

- When I disabled DHCP snooping on one 6500 the other core boxes' CPU would also drop to 1-10%

- If I added DHCP snooping rate limiting to 200 pps on the interface it would shut the interface down (expected behavior, but not sure if I should expect 200 pps or how to better calculate expectations)

- The distribution switches CPU went from 3-6% to 25-35%

- I seem to also recall that one distribution switch was not building any bindings


1.) Are these expected results of deploying DHCP snooping?

2.) What are the limits on the quantity of traffic inspected? Obviously the CPU has to process these packets but what is an equation to find out how much traffic I can inspect per platform?

3.) Why would removing the DHCP snooping process on one core switch cause the second switches CPU load to be reduced?

4.) How do you go about estimating an expected DHCP request per second variable?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (1 ratings)
Giuseppe Larosa Thu, 02/05/2009 - 12:18

Hello David,

you should implement DHCP snooping as near to the end users as possible to spread the load of packet examination on multiple devices.

I think you should verify if you can activate it on the access layer switches and if not to apply it on the distribution.

At the core level if implemented in access and distribution you should be able to stay without it.

3) some type of interaction between the two cores was occurring no more can be said without a detailed analysis

Hope to help


d.hillman Thu, 02/05/2009 - 12:39

Thank you for your time. Snooping has been deployed on access switches that support the configuration, on the distribution, and on the core layer.

3.) That is the very odd relationship. was it causality or correlation? What process, sequence of events, or reaction would cause a different switches CPU to run so high? Routing process if dropping relationships, spanning-tree events if BPDUs were not being sent reliability, etc. However through this event basic connectivity between systems and other resources were available.

schmij01 Fri, 02/06/2009 - 11:03

You really don't need snooping enabled on a distribution device unless it has end hosts attached to it. The protection, as mentioned, really only needs to be done at the edge. Unless you have a threat of rogues in your core, you don't need it configured there either especially if it is creating problems. DHCP snooping doesn't need to be end-to-end.

d.hillman Fri, 02/06/2009 - 11:22

I appreciate and understand that. Unfortunately we have some older gear in our network which prevents me from covering all my bases without leveraging the technology at the core.


This Discussion