ip dhcp snooping limit rate
Protect DHCP infrastructure from exhaustion attacks by rate-limiting DHCP traffic on untrusted switch ports.
Definition: ip dhcp snooping limit rate is a Cisco IOS interface config command. Limits the rate of DHCP packets that can be received on a switch port. Ports exceeding the rate limit are err-disabled automatically, protecting against DHCP starvation attacks and rogue DHCP servers.
Overview
The `ip dhcp snooping limit rate [pps]` command is a critical security feature in Cisco IOS that mitigates DHCP starvation attacks by rate-limiting DHCP packets on a per-interface basis. DHCP snooping itself is a security mechanism that filters untrusted DHCP messages and builds a DHCP snooping binding database to prevent rogue DHCP servers from handing out malicious IP addresses. However, even with DHCP snooping enabled, an attacker can flood the network with DHCP requests (e.g., using tools like Yersinia or Scapy) to exhaust the DHCP server's address pool, a classic DHCP starvation attack.
By limiting the rate of DHCP packets (discover, request, decline, release, inform) on an interface, this command prevents such floods from overwhelming the DHCP server or the switch's control plane. The command is typically applied on access ports facing untrusted end hosts (e.g., user PCs) where DHCP clients reside. It is not used on uplink ports or ports connected to trusted DHCP servers, as those are configured with `ip dhcp snooping trust`.
The rate limit is specified in packets per second (pps), and if the threshold is exceeded, the interface may be err-disabled (if configured with `errdisable recovery cause dhcp-rate-limit`) or simply drop excess packets. This command is part of a broader DHCP snooping configuration workflow: first enable DHCP snooping globally (`ip dhcp snooping`), then enable it on specific VLANs (`ip dhcp snooping vlan vlan-id`), then configure trusted interfaces (`ip dhcp snooping trust`), and finally apply rate limits on untrusted interfaces. Without rate limiting, a single compromised host could generate thousands of DHCP requests per second, causing the DHCP server to allocate all its addresses and potentially crashing the switch's CPU due to excessive DHCP snooping processing.
The command is available in privileged EXEC mode (config-if) and does not require any special privilege level beyond standard administrative access. Changes take immediate effect and are written to the running configuration. It is important to note that the rate limit applies to all DHCP packets received on the interface, not just those from a single MAC address, so legitimate multi-client scenarios (e.g., a hub behind a single port) may require a higher limit.
The default is no rate limit, meaning unlimited DHCP packets are allowed. A common mistake is setting the rate too low, causing legitimate DHCP clients to fail when multiple devices boot simultaneously (e.g., after a power outage). The recommended rate depends on the expected number of clients and their boot behavior; typical values range from 5 to 100 pps.
This command is supported on Cisco Catalyst switches running IOS (e.g., 2960, 3560, 3750, 3850) and IOS-XE (e.g., 9300, 9400). It is not available on IOS-XR or NX-OS (which uses `ip dhcp snooping limit rate` with different syntax). In summary, `ip dhcp snooping limit rate` is a simple yet powerful tool to enforce DHCP packet hygiene at the edge, preventing a common denial-of-service vector while allowing legitimate DHCP operations.
ip dhcp snooping limit rate <packets-per-second>When to Use This Command
- Prevent DHCP starvation attacks where an attacker floods DISCOVER packets to exhaust the pool
- Rate-limit DHCP on access ports to 10-15 pps (normal end devices rarely send more than 1-2 pps)
- Trigger err-disable on ports showing abnormal DHCP rates for automated threat response
- Applied on untrusted ports as part of DHCP snooping hardening
Parameters
| Parameter | Syntax | Description |
|---|---|---|
| pps | <1-2048> | Specifies the maximum number of DHCP packets per second allowed on the interface. Valid range is 1 to 2048 packets per second. A common mistake is setting this value too low (e.g., 1 pps) which can block legitimate DHCP traffic from multiple clients, or too high (e.g., 2048) which may not effectively prevent starvation attacks. The optimal value depends on the expected number of clients and their boot behavior; for a typical access port with one PC, 5-10 pps is sufficient. |
Command Examples
Set rate limit on access port
Switch(config)# ip dhcp snooping Switch(config)# ip dhcp snooping vlan 10 Switch(config)# interface GigabitEthernet1/0/1 Switch(config-if)# ip dhcp snooping limit rate 15 Switch(config-if)# end Switch# show ip dhcp snooping | include GigabitEthernet1/0/1 GigabitEthernet1/0/1 yes untrusted 15
Understanding the Output
show ip dhcp snooping shows each port's trust state and configured rate limit. The rate limit column shows packets-per-second. Ports that exceed the rate are automatically err-disabled and require errdisable recovery or manual shutdown/no shutdown.
Configuration Scenarios
Prevent DHCP Starvation on an Access Port for a Single User
A network administrator wants to protect the DHCP server from starvation attacks on a switch port connecting a single user PC. The port is untrusted and should only allow a low rate of DHCP packets.
Topology
PC1---(Gi0/1)SW1(Gi0/24)---DHCP Server (10.0.1.1)Steps
- 1.Step 1: Enable DHCP snooping globally: SW1(config)# ip dhcp snooping
- 2.Step 2: Enable DHCP snooping for the relevant VLAN (e.g., VLAN 10): SW1(config)# ip dhcp snooping vlan 10
- 3.Step 3: Configure the uplink port as trusted: SW1(config)# interface GigabitEthernet0/24; SW1(config-if)# ip dhcp snooping trust
- 4.Step 4: Configure the access port with rate limiting: SW1(config)# interface GigabitEthernet0/1; SW1(config-if)# ip dhcp snooping limit rate 10
! Global DHCP snooping ip dhcp snooping ip dhcp snooping vlan 10 ! ! Uplink to DHCP server interface GigabitEthernet0/24 ip dhcp snooping trust ! ! Access port for PC interface GigabitEthernet0/1 ip dhcp snooping limit rate 10
Verify: Use `show ip dhcp snooping` to verify the rate limit is applied. Look for the interface under 'Interface' column with 'Rate limit (pps)' showing 10. Also use `show ip dhcp snooping statistics` to see if any packets have been dropped due to rate limiting.
Watch out: If the PC is a laptop that may have a virtual machine or multiple network adapters, it could generate more than 10 DHCP requests per second during boot, causing legitimate DHCP failures. In such cases, increase the rate limit to 20-30 pps.
Rate Limiting on a Port with Multiple Clients via a Hub
A switch port connects to a hub that serves 10 users in a conference room. Each user's PC may send DHCP requests simultaneously when they boot up. The administrator needs to set a rate limit high enough to accommodate all clients but still prevent abuse.
Topology
PC1-10---Hub---(Gi0/5)SW1(Gi0/24)---DHCP Server (192.168.1.1)Steps
- 1.Step 1: Enable DHCP snooping globally: SW1(config)# ip dhcp snooping
- 2.Step 2: Enable DHCP snooping for VLAN 20: SW1(config)# ip dhcp snooping vlan 20
- 3.Step 3: Configure uplink as trusted: SW1(config)# interface GigabitEthernet0/24; SW1(config-if)# ip dhcp snooping trust
- 4.Step 4: Configure the hub port with a higher rate limit: SW1(config)# interface GigabitEthernet0/5; SW1(config-if)# ip dhcp snooping limit rate 100
! Global DHCP snooping ip dhcp snooping ip dhcp snooping vlan 20 ! ! Uplink to DHCP server interface GigabitEthernet0/24 ip dhcp snooping trust ! ! Port with hub interface GigabitEthernet0/5 ip dhcp snooping limit rate 100
Verify: Use `show ip dhcp snooping` to confirm the rate limit of 100 pps on Gi0/5. Also check `show ip dhcp snooping statistics` to see if any drops occur. If drops are seen, consider increasing the limit further.
Watch out: A common mistake is forgetting that the rate limit applies to all DHCP packets, including renewals. If clients renew their leases at the same time (e.g., after a DHCP server reboot), the combined rate may exceed the limit. Monitor the statistics and adjust accordingly.
Troubleshooting with This Command
When troubleshooting DHCP issues related to rate limiting, the first step is to verify that DHCP snooping is enabled globally and on the correct VLANs using `show ip dhcp snooping`. This command displays the status of DHCP snooping, the trusted interfaces, and the rate limits configured on each interface. Healthy output shows the interface with the expected rate limit (e.g., 'Rate limit (pps): 10') and no packets dropped.
Problem indicators include 'Rate limit (pps): unlimited' (meaning no rate limit is applied) or a high number of dropped packets in the statistics. Use `show ip dhcp snooping statistics` to see the count of packets dropped due to rate limiting. If the drop count is increasing, the rate limit is too low for the legitimate traffic.
Common symptoms that this command helps diagnose include: clients failing to obtain an IP address (especially after a power outage when many devices boot simultaneously), intermittent DHCP failures, or the DHCP server showing a sudden spike in requests followed by silence. A step-by-step diagnostic flow: 1) Check `show ip dhcp snooping` to confirm rate limits are applied. 2) Check `show ip dhcp snooping statistics` for drops. 3) If drops are present, temporarily increase the rate limit or remove it to see if DHCP works. 4) If DHCP works without rate limit, the limit is too low; calculate the required rate based on the number of clients and their boot behavior. 5) Also check `show interfaces status err-disabled` to see if the interface went into err-disable state due to DHCP rate limit violation (if `errdisable recovery cause dhcp-rate-limit` is configured). Correlate with `debug ip dhcp snooping` to see real-time packet processing and identify if packets are being dropped.
For example, `debug ip dhcp snooping` will show messages like 'DHCP_SNOOPING: drop packet on interface Gi0/1 due to rate limit exceeded'. Additionally, use `show ip dhcp snooping binding` to verify that legitimate clients are being added to the binding table. If a client is not in the binding table, it may indicate that its DHCP packets were dropped.
Remember that rate limiting only affects DHCP packets; other traffic is unaffected. If clients can ping but not get an IP, the issue is likely DHCP-related. Also, ensure that the DHCP server is reachable and that the uplink port is trusted; otherwise, DHCP replies from the server might be dropped.
In summary, the key to troubleshooting is monitoring the drop counters and adjusting the rate limit based on observed traffic patterns.
CCNA Exam Tips
CCNA exam: DHCP snooping must be globally enabled (ip dhcp snooping) AND enabled per VLAN (ip dhcp snooping vlan <id>) before rate limiting takes effect
Trusted ports (uplinks to routers/DHCP servers) should not have rate limits and do not need them
Rate limiting is for untrusted access ports only
Common Mistakes
Applying rate limit without enabling ip dhcp snooping globally first — has no effect
Applying rate limits on trusted ports (uplinks) — this can drop legitimate DHCP traffic from the server
Setting rate too low (below 15) causing legitimate hosts with DHCP relay scenarios to err-disable
ip dhcp snooping limit rate vs spanning-tree portfast
Both ip dhcp snooping limit rate and spanning-tree portfast are interface configuration commands that alter default port behavior but for very different reasons. They may be applied on the same access port, leading to confusion about their distinct roles—one enforces DHCP security by rate-limiting packets, while the other optimizes STP convergence for host ports.
| Aspect | ip dhcp snooping limit rate | spanning-tree portfast |
|---|---|---|
| Primary function | Limits DHCP packet rate to mitigate DHCP starvation/rogue server attacks | Bypasses STP listening/learning states for fast port transition to forwarding |
| Effect on port forwarding | No direct effect; port remains up unless rate exceeded (then err-disabled) | Port directly enters forwarding state upon link up |
| Trigger for action | DHCP packet rate exceeds configured limit (pkts/sec) | Link comes up |
| Failure consequence | Port placed in err-disabled state (can be auto-recovered) | Potential layer2 loops if misapplied; use with BPDU guard |
| Configuration mode | Interface configuration (also global default) | Interface configuration |
| Typical use | Switchports facing untrusted DHCP clients or untrusted network segments | Switchports connected to end hosts, servers, or routers |
Use ip dhcp snooping limit rate when you need to protect the network from DHCP starvation or rogue DHCP server attacks by rate-limiting DHCP packets on untrusted switchports.
Use spanning-tree portfast when connecting end hosts to eliminate the 30-second STP convergence delay and allow immediate port forwarding.
Platform Notes
On Cisco IOS-XE (e.g., Catalyst 9300, 9400), the command syntax is identical: `ip dhcp snooping limit rate [pps]` under interface configuration mode. However, the output of `show ip dhcp snooping` may include additional fields like 'Packet rate limit (pps)' and 'Packet drop count'. In IOS-XE 16.x and later, the command is fully supported.
On NX-OS (e.g., Nexus 3000, 9000), the equivalent command is `ip dhcp snooping limit rate [pps]` but with a different range (1-1000 pps) and the configuration is applied under interface mode as well. However, NX-OS uses a different DHCP snooping architecture; for example, the global enable is `ip dhcp snooping` and VLAN enable is `ip dhcp snooping vlan vlan-id`. The rate limit command works similarly but the statistics are viewed via `show ip dhcp snooping statistics`.
On ASA firewalls, DHCP snooping is not supported; instead, ASA uses DHCP guard or other mechanisms. On IOS-XR, DHCP snooping is not available; instead, IOS-XR uses DHCPv4 relay and security features like DHCP option 82 insertion. For older IOS versions (12.x), the command exists but the maximum rate limit may be lower (e.g., 100 pps).
In IOS 15.x and 16.x, the range is 1-2048 pps. There is no difference in syntax between IOS and IOS-XE. Always verify the platform documentation for exact ranges and behavior.
For Catalyst 2960-X and 3560-X, the command works as described. On some older platforms like Catalyst 2950, DHCP snooping may not be supported at all. In summary, the command is consistent across modern IOS and IOS-XE platforms, with minor variations in NX-OS.
Related Commands
show ip dhcp snooping binding
Displays the DHCP snooping binding table showing MAC address to IP address mappings, the VLAN, lease time, and the port each binding is associated with. Used by Dynamic ARP Inspection and IP Source Guard as a trusted source.
spanning-tree portfast
Bypasses the STP Listening and Learning states on a port, moving it directly to Forwarding after the link comes up. Eliminates the default 30-second STP convergence delay for ports connected to end hosts.
Practice for the CCNA 200-301
Test your knowledge with practice questions covering all CCNA 200-301 exam domains.
Practice CCNA 200-301 Questions