# DHCP snooping

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/dhcp-snooping

## Quick definition

DHCP snooping is a security tool used on network switches. It checks every DHCP message to make sure it comes from a trusted source, like your real DHCP server. If a bad device tries to pretend to be the DHCP server, the switch blocks that message. This stops attackers from tricking devices into using fake network settings.

## Simple meaning

Think of your home network as a community mailroom. In the mailroom, there is one official package delivery person who brings all the packages. Everyone in the building knows that only this person is allowed to deliver packages. The official delivery person is like your real DHCP server. A DHCP server is a computer on your network that automatically gives out IP addresses to devices like your laptop, phone, or printer. An IP address is just a unique identifier that lets devices talk to each other, kind of like a phone number.

Now, imagine someone in a fake uniform walks into the mailroom and starts handing out packages that look official but are actually dangerous. These fake packages might have the wrong address or could even be harmful. In your network, a rogue or fake DHCP server does the same thing. It tries to give out wrong IP addresses and network settings. If a device accepts these fake settings, it can be redirected to scam websites, have its traffic intercepted, or be locked out of the network entirely.

DHCP snooping is like a security guard at the mailroom door. The guard has a list of who is allowed to deliver packages. Only the official delivery person is on that list. The mailroom floor where packages arrive is untrusted, but the door where the delivery person enters is trusted. In networking terms, a trusted port is a port on the switch where the real DHCP server is connected. All other ports are untrusted by default. The switch looks at every DHCP message coming in from an untrusted port. If the message looks like it is from a DHCP server, the switch blocks it. Only messages from the trusted port with the real server are allowed.

This security guard also checks the packages themselves. For example, it makes sure that the address on the package matches the place where the package was sent from. In DHCP terms, this means the snooping feature checks that the device asking for an IP address on one port does not claim to be from a different port. This prevents a type of attack where a device tries to use someone else's network access. DHCP snooping also keeps a log or a table of which IP addresses have been given to which devices. This table, called the DHCP snooping binding database, helps the switch know which devices are allowed on the network. It can also be used with other security features to stop devices from using fake IP addresses.

In everyday life, you can see DHCP snooping in action at a large office with hundreds of computers. Without it, anyone could plug a small $30 router into the network and start handing out fake IP addresses, causing chaos. The IT team would spend hours finding the problem. With DHCP snooping enabled on the switch, that rogue router would be instantly ignored. The network stays safe and all the computers get their correct IP addresses from the real server. It is a simple but powerful way to make sure only trusted devices give out network settings.

## Technical definition

DHCP snooping is a Layer 2 security feature on network switches that filters DHCP messages based on port trust states and MAC address validation. It is defined in RFC 2131 for DHCP operations, and the snooping mechanism itself is an industry-standard implementation found in enterprise switches from vendors like Cisco, Juniper, Arista, and HP. The primary goal is to prevent rogue DHCP server attacks, DHCP starvation attacks, and IP address spoofing. When enabled, the switch listens to DHCP traffic and classifies ports as either trusted or untrusted. By default, all ports are untrusted. Only ports with a manually configured trust state are allowed to send DHCP server messages, such as DHCPOFFER, DHCPACK, and DHCPNAK.

When a client on an untrusted port sends a DHCPDISCOVER message, the switch forwards it normally. Any DHCP server message that arrives on an untrusted port is inspected. If the switch detects a DHCPOFFER, DHCPACK, or DHCPNAK on an untrusted port, it drops that packet immediately. This effectively neutralizes any rogue DHCP server plugged into the network. DHCP snooping performs DHCP message validation. It checks the source MAC address in the Ethernet frame against the client hardware address in the DHCP packet. If these do not match, the packet is dropped. This prevents MAC spoofing attacks where a device claims a different identity.

Another critical function is the building and maintenance of a DHCP snooping binding database. This database contains a mapping of the client MAC address, IP address assigned, VLAN ID, port number, and lease time. Every time a server successfully assigns an IP via DHCPACK, the switch adds an entry to this table. When the lease expires or a DHCPRELEASE is received, the entry is removed. This binding table is then used by other security features, such as Dynamic ARP Inspection (DAI) and IP Source Guard. DAI uses the binding table to validate ARP packets, preventing man-in-the-middle attacks. IP Source Guard uses it to filter IP traffic from a port, allowing only packets with a source IP that matches the binding entry.

The implementation of DHCP snooping requires careful planning. Network administrators must designate which switch ports connect to the legitimate DHCP server. These are often uplink ports to a server VLAN or a router that acts as a DHCP relay. In networks with redundant servers, multiple trusted ports can be configured. The switch must also trust all ports that connect to a DHCP relay agent, since relay agents forward DHCP server messages. If ports are misconfigured as trusted, the security is bypassed. If a legitimate DHCP server is connected to an untrusted port, clients will never receive IP addresses. The feature also has rate-limiting capabilities. DHCP snooping can throttle the number of DHCP messages per second from a single untrusted port, preventing DHCP starvation attacks where a rogue client floods the server with fake requests to exhaust the IP pool.

VLANs add complexity. DHCP snooping operates on a per-VLAN basis. The administrator must enable snooping on specific VLANs where client devices are present. The server often sits in a different VLAN, so the trusted port must be in the server VLAN or configured to traverse VLANs via a trunk. The switch must also handle DHCP messages that cross VLANs via DHCP relay. In such cases, the relay agent IP address is inserted into the DHCP packet, and the snooping feature uses that information for validation. The binding database is also per-VLAN, so a device on VLAN 10 will have a separate binding entry from a device on VLAN 20.

Real-world IT deployments often involve hundreds of switches and thousands of ports. DHCP snooping is a lightweight feature that runs in hardware on most modern switches, so it has negligible performance impact. It is considered a best practice for any enterprise or campus network. On exam objectives for CCNA and Network+, DHCP snooping is a core topic. Security+ and AZ-104 cover it at a higher level, emphasizing its role in defending against Layer 2 attacks. AWS and Google Cloud do not directly implement DHCP snooping because the hypervisor handles DHCP, but the concept translates to cloud security groups and IPAM controls. Understanding how the binding table integrates with DAI and IP Source Guard is a common exam scenario.

## Real-life example

Imagine you are the manager of a large apartment complex with 500 residents. Each resident has a mailbox in the central mailroom. The mailroom has a single official mail carrier, Carol, who works for the post office. Carol knows everyone by name and always delivers the correct mail to the right box. One day, a person named Dave moves into the building. Dave is not an employee, but he sets up a fake mailbox and starts putting flyers into residents' slots pretending to be the building management. The flyers ask residents to click a link and enter their private information. Some residents fall for it and give away their passwords.

In this analogy, Carol is your legitimate DHCP server. Dave is a rogue DHCP server. The residents are your network devices. The flyers are fake IP configuration messages. The mailroom is the network switch. DHCP snooping acts like a security guard named Sam stationed at the mailroom entrance. Sam has a list of every official mail carrier. Carol's name is on the list. Dave's name is not. Every time someone tries to drop mail into the slots, Sam checks their ID. If the person is not on the list, Sam escorts them out. So when Dave tries to put his fake flyers, Sam stops him at the door. The residents never even see Dave's flyers.

But Sam does more than just check IDs. He also watches the residents. If a resident from apartment 3B tries to drop a letter into the slot of apartment 4D, Sam knows that is odd. He checks his logbook. The logbook shows that resident from 3B is only ever supposed to receive mail for 3B, not send mail to other people. In networking terms, Sam is checking the MAC address and port binding. A device on port 3 should only ask for an IP address from that port, not claim to be on port 4. Sam also keeps a log of every piece of mail that Carol delivers. He writes down which resident got which mail and when. This log is the DHCP snooping binding database. If a resident later tries to claim they got a different package, Sam can check the log.

Now, what if someone tries to overwhelm Carol? Imagine a person named Eve sends 10,000 fake letters to Carol saying "please send mail to empty apartment 999." Carol wastes time trying to deliver mail to non-existent residents. This is a DHCP starvation attack. Sam the guard notices Eve sending letters too fast. Sam says, "Hold on, you are only allowed to send one letter per second." Eve's letters get ignored after the first few. Carol is free to focus on real residents.

Finally, Sam's logbook helps other security guards. A guard named Amy handles identity checks. She uses Sam's log to see who lives in which apartment. If someone tries to say they are from apartment 1A but Sam's log shows that 1A belongs to someone else, Amy stops them. That is Dynamic ARP Inspection. Another guard named Isaac checks the packages leaving the building. If a package has a return address that does not match Sam's log for that resident, Isaac does not let it leave. That is IP Source Guard. All of these guards work together, but Sam the DHCP snooping guard is the foundation. Without Sam, the other guards have no log to check.

## Why it matters

DHCP snooping matters because it addresses a fundamental vulnerability in Ethernet networks: the lack of authentication for DHCP messages. DHCP is a broadcast-based protocol, meaning any device on the same network segment can send and receive DHCP messages. This open nature makes it easy for an attacker to introduce a rogue DHCP server. If a rogue server gives out a fake default gateway address, all traffic from the victim device goes through the attacker's machine. The attacker can then capture passwords, emails, and other sensitive data. This is called a man-in-the-middle attack and is one of the most dangerous threats on a local network.

Without DHCP snooping, IT professionals have few other defenses. You could manually configure static IP addresses on every device, but that is impractical for any network larger than a home network. You could use 802.1X authentication to control device access, but that does not prevent a rogue server on an already authenticated port. You could VLAN segments to isolate traffic, but if the rogue server is on the same VLAN as clients, it still works. DHCP snooping provides a simple, hardware-enforced boundary that is easy to configure and maintain.

In practical IT, DHCP snooping is often a requirement for compliance frameworks like PCI DSS or HIPAA. These standards require that network access is controlled and that unauthorized devices cannot disrupt services. A failing audit can lead to fines or loss of business. Snooping also reduces help desk tickets. When a user plugs in a personal router for better Wi-Fi, they often create IP conflicts. Snooping naturally blocks that router's DHCP server, preventing the conflict. The user might complain that the router does not work, but the network remains stable for everyone else.

DHCP snooping is a prerequisite for other security features. DAI and IP Source Guard both rely on the binding table. Therefore, enabling snooping unlocks a layered security strategy. For the CCNA and Network+ exams, you are expected to know not just what DHCP snooping does, but also how to configure it, what the default states are, and how it interacts with other features. For Security+, you need to understand the types of attacks it prevents. For AZ-104, while you do not configure it on Azure resources, you must understand it applies to on-premises network security. In the cloud, virtual switches and NSGs provide similar protection, but the concept is the same.

## Why it matters in exams

DHCP snooping appears in multiple certification exams because it is a foundational Layer 2 security mechanism. For the Cisco CCNA (200-301), it is a major topic under the Network Access section. The exam objectives require you to describe DHCP snooping, configure it on a switch, and troubleshoot its operation. You will see questions about trust states, the binding database, and integration with DAI. The CCNA often includes scenario-based questions where a network is experiencing IP address conflicts, and you must identify that a rogue DHCP server is the cause and that DHCP snooping is the solution. You will also need to know how to verify snooping with show commands like 'show ip dhcp snooping' and 'show ip dhcp snooping binding'.

For CompTIA Network+ (N10-008 or later), DHCP snooping falls under network security and hardening. The exam calls for knowing how to prevent DHCP-based attacks. You do not need to memorize Cisco configuration syntax, but you must understand the concept and the default behavior of trusted vs. untrusted ports. You may see a question like: "A network administrator wants to prevent a rouge DHCP server from assigning IP addresses on the LAN. Which feature should they implement?" The answer is DHCP snooping.

CompTIA Security+ (SY0-601) covers DHCP snooping as a mitigation technique against man-in-the-middle and DHCP spoofing attacks. The focus here is on attack identification and defense. You might get a question describing an attacker plugging a laptop into a conference room jack and distributing fake gateway addresses. You then choose which security control would block this. Security+ also ties snooping to the concept of network segmentation and port security.

Microsoft AZ-104 includes DHCP snooping lightly, primarily in the context of on-premises network components when migrating to Azure. Azure itself does not use DHCP snooping, but the exam expects you to know that it secures on-premises networks. Questions could be about hybrid networking and the need to secure DHCP in the local data center before connecting to Azure.

Google ACE and AWS SAA rarely test DHCP snooping directly because cloud providers manage DHCP at the hypervisor level. However, for the AWS SAA, you might encounter it in the context of the AWS Well-Architected Framework, where the security pillar discusses preventing unauthorized services. The concept is analogous to using AWS Network ACLs to filter traffic. You might see a question about securing a hybrid network on-premises before extending into AWS.

CompTIA A+ touches on DHCP snooping at a superficial level. It is part of understanding network security and troubleshooting connectivity. A+ questions might ask: "A user plugged a switch into the network and now other users cannot get IP addresses. What is the most likely cause?" The answer could be a rogue DHCP server, and the solution could be implementing DHCP snooping. The A+ does not go into configuration details but expects you to know the function.

In all exams, common question patterns include: identifying the correct port to set as trusted, understanding that snooping blocks DHCP server messages on untrusted ports, and knowing that the binding table stores MAC-to-IP mappings. You may also see questions about what happens when a legitimate DHCP server is connected to an untrusted port or how snooping prevents starvation attacks. Being able to read configuration excerpts and identify misconfigurations is key for CCNA. For Network+ and Security+, focus on the problem-solution pairing.

## How it appears in exam questions

DHCP snooping questions appear in several forms across exams. The most common type is the scenario-based question. For example: "A company has a flat Layer 2 network. Users in the finance department report that they cannot access the internet. A technician notices that some workstations have IP addresses in the 192.168.100.0/24 range instead of the expected 10.10.10.0/24 range. What is the most likely cause?" The answer is a rogue DHCP server, and the solution is to enable DHCP snooping. Another variation: "An administrator configures DHCP snooping on a switch. After configuration, users on VLAN 10 cannot obtain IP addresses. What is the most likely issue?" The answer is that the port connected to the DHCP server is still untrusted.

Configuration-based questions are also frequent, especially on CCNA. You might be shown a partial configuration:

interface GigabitEthernet1/0/1
 description Connection to DHCP Server
 ip dhcp snooping trust

Then the question asks: "Which of the following is true regarding the configuration?" You need to know that this interface will now accept DHCP server messages. Alternatively, a question might show a configuration missing the 'ip dhcp snooping trust' command and ask why clients are not getting IP addresses.

Troubleshooting questions often involve show command outputs. For instance, you see:

Switch# show ip dhcp snooping
Switch DHCP snooping is enabled
DHCP snooping is configured on the following VLANs:
10 20
Insertion of option 82 is enabled
 interface GI1/0/1 (trusted)
 interface GI1/0/2 (untrusted)
 interface GI1/0/3 (untrusted)

The question then asks: "Based on the output, which port is connected to the legitimate DHCP server?" The answer is GI1/0/1 because it is trusted. Another question might show the output of 'show ip dhcp snooping binding' with entries and ask you to interpret which device has which IP. Or you might be asked what happens if a DHCPACK arrives on GI1/0/2, it will be dropped.

Some questions combine DHCP snooping with DAI. Example: "An administrator enables DHCP snooping and Dynamic ARP Inspection. A host on an untrusted port sends an ARP reply claiming the IP address 10.0.0.1, but the DHCP snooping binding table shows that 10.0.0.1 is assigned to a different MAC address on a different port. What will DAI do?" The answer is that DAI drops the ARP reply.

In Security+, questions may focus on attack types. For example: "Which attack is mitigated by DHCP snooping?" Options might include MAC flooding, DHCP starvation, ARP poisoning, and VLAN hopping. The correct answer is DHCP starvation and DHCP spoofing. They may also ask: "What is the function of the DHCP snooping binding database?" with answer choices about IP-to-MAC mappings.

Finally, some questions test the default behavior: "By default, all ports on a switch with DHCP snooping enabled are considered..." The answer is untrusted. Memorizing this default is critical because it is a common trap. If you think default is trusted, you will get the question wrong.

## Example scenario

You are a new IT technician at a medium-sized school. The school has 200 computers in the library and classrooms. All computers get their IP addresses from a central server located in the server room. One morning, the librarian calls you saying that half of the library computers cannot access the internet. When you check, you see that some computers have IP addresses like 192.168.1.50 and some have 10.0.0.25. The school normally uses addresses like 172.16.0.100. You suspect something is wrong.

You start walking around the library and notice a student has plugged a small home router into the network jack near a desk. The student brought it for better Wi-Fi. That router is acting as a DHCP server and handing out IP addresses like 192.168.1.x. The library computers that connected to the network after the router was plugged in received those addresses instead of the correct ones. Those computers cannot reach the internet because the router has no connection to the school's gateway.

To fix this, you would enable DHCP snooping on the school's main switch. You would configure the port connected to the central DHCP server in the server room as a trusted port. All other ports would remain untrusted. Then, even if a student plugs in another router, its DHCP messages will be dropped by the switch. The network will remain stable. You also need to tell the student that personal routers are not allowed. After enabling snooping, you would clear the IP addresses on the affected computers by running 'ipconfig /release' and 'ipconfig /renew' on Windows or 'dhclient -r' on Linux. They will get correct addresses from the real server.

This scenario is almost exactly what you might see in a Network+ or CCNA troubleshooting question. The key signs are: inconsistent IP addresses, inability to access the internet, and a device plugged in that should not be there. The fix is DHCP snooping.

## DHCP Snooping Fundamentals: Trust and Untrust Boundaries

DHCP snooping is a layer 2 security feature that acts as a firewall between untrusted hosts and trusted DHCP servers. It is primarily deployed on network switches to filter and validate DHCP messages, preventing rogue DHCP servers from distributing malicious IP configurations. The core concept relies on designating switch ports as either trusted or untrusted. A trusted port is one where legitimate DHCP servers are connected, while an untrusted port is typically facing end-user devices or other unsecured network segments. By default, all ports are untrusted unless explicitly configured as trusted. When a DHCP server message, such as a DHCPOFFER or DHCPACK, is received on an untrusted port, the switch drops it immediately. This simple boundary mechanism stops a malicious actor from plugging a laptop running a fake DHCP server into an access port and hijacking IP address assignments for other clients.

The second fundamental mechanism is the DHCP snooping binding database. Every time a client on an untrusted port successfully obtains a lease via DHCP, the switch records a binding entry. This entry includes the client’s MAC address, the assigned IP address, the lease time, the VLAN, and the port where the client is connected. The switch uses this database to perform additional checks. For instance, DHCP snooping can enforce that only the client with the correct MAC address can use the IP address that was leased to it. This prevents IP address spoofing attacks, where an attacker claims to have a different IP address to bypass security policies or intercept traffic. The binding database is also critical for other security features, such as IP Source Guard and Dynamic ARP Inspection, which rely on the DHCP snooping bindings to validate packets at Layer 2.

DHCP snooping also validates DHCP message types. It ensures that DHCPDISCOVER and DHCPREQUEST messages originate from untrusted ports and that DHCPOFFER and DHCPACK messages are only accepted on trusted ports. This prevents a rogue server from sending forged offers or acknowledgments. The feature can rate-limit DHCP traffic on untrusted ports. An attacker might flood the network with bogus DHCP requests to exhaust the lease pool or cause a denial of service. By configuring a rate limit, the switch discards excessive DHCP messages, protecting both the legitimate DHCP server and the network infrastructure.

From an exam perspective, understanding trust boundaries is the most heavily tested concept. You must know that a trusted port is where the authorized DHCP server lives, and that any DHCP server-like response on an untrusted port is immediately dropped. The binding database is often the foundation for follow-on multiple-choice questions about IP Source Guard or ARP inspection. The CCNA, Network+, and Security+ exams will expect you to identify the correct sequence: enable DHCP snooping globally, enable it per VLAN, then configure trusted uplink ports, and optionally set rate limits. The AWS SAA exam may not test on-premise switch configuration directly, but it tests the equivalent concept in VPC DHCP options sets and security groups, which mimic trust boundaries for DHCP within cloud environments. The goal is to compartmentalize and trust only authorized sources of IP configuration data.

DHCP snooping is not a complete security solution but a foundational Layer 2 defense. It prevents rogue DHCP servers, IP address spoofing, and DHCP starvation attacks. When combined with IP Source Guard and Dynamic ARP Inspection, it creates a powerful triad of access-layer security. Network professionals must be precise in their configuration, because a misconfigured trusted port on an access interface can completely nullify the protection. The exams reward candidates who understand the directionality of DHCP messages and the assignment of trust.

## The DHCP Snooping Binding Database: Structure and Verification

The DHCP snooping binding database is the central repository of trusted lease information. When a DHCP client on an untrusted port successfully completes a DORA (Discover, Offer, Request, Acknowledge) process, the switch records a binding that maps the client's MAC address to the leased IP address, along with the VLAN, port, and lease expiration time. This database is not just a log; it is actively used to filter traffic. For example, if a host on an untrusted port sends a packet with a source IP address that does not match its binding entry, the switch can drop that packet if IP Source Guard is enabled. Similarly, DHCP snooping itself uses the database to validate DHCPRELEASE and DHCPDECLINE messages, ensuring they come from the legitimate lease holder.

The database can be stored in volatile memory (RAM) or, on more advanced switches, saved to persistent storage or an external server via a binding file. In a production environment, a switch reboot would lose the dynamic bindings, potentially causing a brief period where IP Source Guard is enforced but no bindings exist, which could block all traffic. To prevent this, network engineers configure a file system location where the switch periodically writes the binding database. When the switch reboots, it reads this file to restore the bindings. The CCNA and Network+ exams test this concept by asking what happens to the binding database after a switch reload. The correct answer is that dynamic bindings are lost unless a persistent binding file is configured and available.

Verifying the binding database is a common troubleshooting step. On Cisco IOS, the command "show ip dhcp snooping binding" displays all current bindings. This output shows the MAC address, IP address, lease time, VLAN, and interface. If a binding is missing, the client may be unable to communicate if IP Source Guard is enabled. Missing bindings often occur because DHCP snooping is not enabled on the correct VLAN, or because the client received its IP address from a rogue server that was not filtered. Another common verification is "show ip dhcp snooping" to confirm global and VLAN-level status.

Exams like Security+ and CCNA include questions where a scenario describes a client that can obtain an IP address but cannot communicate with other hosts. The answer often points to a missing DHCP snooping binding that blocks IP Source Guard. The Google ACE exam might present a similarly structured problem in a Google Cloud context, though there the equivalent is VPC flow logs and packet mirroring rather than a switch database. Nevertheless, the abstract concept of a trusted binding table is universal.

The binding database also supports static entries. In cases where a device has a static IP address (like a printer or server), you can manually add a static DHCP snooping binding. This ensures that IP Source Guard will allow traffic from that device even though it did not obtain its IP via DHCP. The command for this on Cisco is "ip dhcp snooping binding <mac> vlan <vlan> <ip> interface <interface-id>". Static bindings are stored in the same database as dynamic bindings and survive reboots if written to the persistent file.

the binding database is the operational memory of DHCP snooping. It must be accurate and complete for dependent features to work. The exams test your understanding of how bindings are created, how they are verified, and what happens when they are missing or expired. Recognizing that a client's inability to communicate after a successful DHCP lease is often a binding database issue is a key troubleshooting skill.

## DHCP Snooping Rate Limiting and DHCP Starvation Protection

DHCP starvation is a denial-of-service attack where an attacker floods a network with DHCP requests, each using a different spoofed MAC address. The legitimate DHCP server eventually exhausts its pool of available IP addresses, causing new clients to fail to obtain leases. DHCP snooping counters this attack through rate limiting on untrusted ports. Rate limiting sets a maximum number of DHCP packets per second that the switch will accept from a given port. If the limit is exceeded, the switch can either drop the excess packets, or optionally err-disable the port to completely stop the attack.

The default rate limit on many switch platforms is 15 packets per second (pps) on untrusted ports. This is generally sufficient for legitimate clients, which typically send a few DHCP messages during boot-up. An attacker sending thousands of requests per second will trigger the rate limit, protecting the DHCP server and the network. The exam-relevant aspect is that rate limiting is configured on a per-interface basis and applies only to untrusted ports. Trusted ports (where the DHCP server resides) should not have rate limiting applied, or if they do, the threshold must be set high enough to accommodate server-to-switch traffic like DHCPOFFER bursts.

When a port enters err-disable state due to a DHCP rate-limit violation, it must be manually re-enabled or automatically recovered using the err-disable recovery mechanism. On Cisco switches, the command "errdisable recovery cause dhcp-rate-limit" enables automatic recovery after a configurable timeout. This is tested in exam scenarios where a network administrator notices an access port is down after a recent DHCP flood incident. The correct remediation is to either clear the err-disable state or configure automatic recovery.

Another important nuance is that rate limiting does not distinguish between legitimate high usage and an attack. For example, a conference room with dozens of guests connecting simultaneously might briefly exceed the limit. In such cases, network engineers can temporarily raise the limit or use burst parameters (if supported) to accommodate normal use while still protecting against persistent floods. The Security+ exam often includes a question about how to mitigate DHCP starvation, and the answer is enabling DHCP snooping with rate limiting on untrusted ports.

On the operational side, verifying rate limit settings is done with "show ip dhcp snooping interface <interface-id>". This output shows the rate limit configured and the number of packets dropped due to rate limiting. If you see many dropped packets, it could indicate an attack or a misconfigured limit that is too low. The AZ-104 exam does not directly cover on-premise DHCP snooping, but the concept of rate limiting is analogous to Azure DDoS Protection Standard and the ability to throttle traffic per source IP. The AWS SAA exam tests rate limiting in the context of API Gateway throttling and WAF rate-based rules.

rate limiting is the primary mechanism for preventing DHCP starvation. It is simple to implement but requires careful tuning to avoid false positives. The exams emphasize the relationship between untrusted ports and rate limits, as well as the recovery behaviors when limits are exceeded. A well-configured DHCP snooping deployment includes both trust boundaries and rate limits to cover the two major DHCP-related attacks: rogue servers and starvation.

## Integrating DHCP Snooping with IP Source Guard and Dynamic ARP Inspection

DHCP snooping alone provides significant security, but its real power emerges when combined with IP Source Guard and Dynamic ARP Inspection (DAI). These three features create a comprehensive Layer 2 security framework that prevents IP address spoofing, ARP spoofing, and related man-in-the-middle attacks. Understanding how they interlock is a common theme in CCNA, Security+, and Network+ exams.

IP Source Guard (IPSG) uses the DHCP snooping binding database to filter IP traffic on untrusted ports. After DHCP snooping is enabled and bindings are created, IPSG examines every IP packet leaving an untrusted port. It checks whether the source IP address of the packet matches the binding for that port and VLAN. If no binding exists, or if the IP does not match, the packet is dropped. This prevents an attacker from manually configuring an IP address that is used by another legitimate device, thereby stopping IP spoofing. For example, if a user tries to statically set their IP to 192.168.1.50, but the DHCP snooping binding for that port shows 192.168.1.100, IPSG will drop all packets with source IP 192.168.1.50. The configuration requires first enabling DHCP snooping and IPSG on the interface: "ip verify source" (or "ip verify source port-security" on some platforms). The exam notes that IPSG only checks source IP by default; to also verify MAC address, you must enable port security or use "ip verify source vlan dhcp-snooping".

Dynamic ARP Inspection (DAI) is the third pillar. ARP spoofing attacks occur when an attacker sends forged ARP replies to associate their MAC address with the IP address of a legitimate device, such as the default gateway. DAI intercepts all ARP packets on untrusted ports and validates them against the DHCP snooping binding database. It checks if the MAC address and IP address in the ARP packet match a valid binding for the source port. If they do not match, the ARP packet is dropped. This prevents the attacker from impersonating the gateway or another host. DAI also validates ARP packets received on trusted ports without checking, under the assumption that those ports connect to authorized infrastructure.

To enable DAI, you use the command "ip arp inspection vlan <vlan-list>" globally, and you must also define which ports are trusted for ARP with "ip arp inspection trust" (though by default all ports are untrusted for ARP inspection). A common exam scenario involves a user reporting intermittent connectivity after plugging into a switch port. The troubleshooting steps often include checking whether DAI is blocking ARP because the client’s ARP packet does not match the binding (e.g., after a NIC replacement changed the MAC address). The solution is to either update the binding or, temporarily, disable ARP inspection on the port.

Another important integration point is port security. Some implementations require port security to also be enabled on the interface for full MAC-IP binding enforcement. For example, in Cisco’s configuration, "ip verify source port-security" enables both IPSG and port security, which then checks the source MAC address against the allowed MAC address list. This creates a triple validation: IP, MAC, and port.

The main exam takeaway is that DHCP snooping provides the binding database, and IPSG and DAI are consumers of that database. Without DHCP snooping, IPSG and DAI cannot function because they have no authoritative data to validate against. The Security+ exam often has a multi-step scenario question where a network admin must enable all three features in the correct order. The answer is always: (1) enable DHCP snooping globally and per VLAN, (2) configure trusted ports, (3) enable IP Source Guard on untrusted interfaces, (4) enable Dynamic ARP Inspection on the same VLANs. This layered approach is a textbook example of defense in depth at Layer 2.

In cloud exams like AWS SAA or Google ACE, the equivalent is not a direct configuration but understanding that you must separate trusted and untrusted subnets (e.g., using security groups and network ACLs) and validate IP addresses at the instance level. However, the underlying principle of a trusted binding table is abstracted into AWS Config rules or Google Cloud’s VPC packet mirroring with threat detection. The core lesson is that a single point of validation is never enough; layering authentication and verification at multiple points creates a robust security posture.

## Common mistakes

- **Mistake:** Thinking all ports should be configured as trusted by default.
  - Why it is wrong: If all ports are trusted, the switch does not filter any DHCP server messages. A rogue DHCP server on any port would work, completely defeating the purpose of DHCP snooping.
  - Fix: Only configure trust on ports that are explicitly connected to your known, legitimate DHCP server or DHCP relay agent. All other ports should remain untrusted.
- **Mistake:** Enabling DHCP snooping but forgetting to enable it on the correct VLANs.
  - Why it is wrong: DHCP snooping operates per VLAN. If you enable it globally but do not specify the VLANs, the feature will not inspect any traffic. Clients will get fake IP addresses from rogue servers on unmonitored VLANs.
  - Fix: Use the command 'ip dhcp snooping vlan <vlan-id>' to explicitly add each VLAN where client devices are connected and where the DHCP server is reachable.
- **Mistake:** Connecting the legitimate DHCP server to an untrusted port.
  - Why it is wrong: The switch will then drop DHCPOFFER, DHCPACK, and DHCPNAK messages from that legitimate server. No client will ever receive a valid IP address, causing a complete network outage.
  - Fix: Always configure the port connected to the real DHCP server as trusted. Use 'ip dhcp snooping trust' under the interface configuration.
- **Mistake:** Confusing DHCP snooping with Dynamic ARP Inspection (DAI) and thinking they are the same feature.
  - Why it is wrong: They are separate features. DHCP snooping filters DHCP messages and builds the binding table. DAI uses that binding table to validate ARP packets. DAI does not block DHCP messages directly.
  - Fix: Enable DHCP snooping first, then DAI. DAI requires the DHCP snooping binding database to function. Without snooping, DAI has no reference table to validate ARP.
- **Mistake:** Assuming DHCP snooping prevents all DHCP-related attacks, including DHCP starvation.
  - Why it is wrong: DHCP snooping rate-limits DHCP messages per port, but if the administrator does not configure rate limiting, a flood of DHCPDISCOVER messages can still exhaust the server's IP pool.
  - Fix: Configure the 'ip dhcp snooping limit rate <packets-per-second>' command on untrusted ports to prevent starvation. A typical rate is 10-15 packets per second per port.
- **Mistake:** Forgetting that DHCP relay agents also need to be on trusted ports.
  - Why it is wrong: A relay agent receives DHCP server messages and forwards them to clients. If the relay agent is on an untrusted port, the switch drops those forwarded server messages, and clients cannot get IP addresses.
  - Fix: Identify all ports connected to routers or Layer 3 switches that perform DHCP relay and mark them as trusted ports.

## Exam trap

{"trap":"A question shows a switch with DHCP snooping enabled, and all ports are marked as untrusted. The DHCP server is connected to port Gi1/0/24. Learners are asked: 'Will clients receive IP addresses?'","why_learners_choose_it":"Many learners think DHCP snooping only blocks rogue servers, so they assume the real server on untrusted port will still work. They also mistakenly believe the default trust state is 'trusted' and do not realize that the default is untrusted.","how_to_avoid_it":"Always remember: the default state of every port when DHCP snooping is enabled is 'untrusted'. If the legitimate DHCP server is on an untrusted port, the switch drops all DHCP server messages (OFFER/ACK/NAK) from that port. Therefore, clients will NOT receive IP addresses. The correct answer is 'No, because the legitimate server is on an untrusted port.' Always check the port trust configuration in the scenario."}

## Commonly confused with

- **DHCP snooping vs Dynamic ARP Inspection (DAI):** DAI validates ARP packets to prevent man-in-the-middle attacks. It uses the DHCP snooping binding database to know which IP address belongs to which MAC address on which port. DHCP snooping itself only filters DHCP messages and builds that database. DAI is a separate feature that depends on DHCP snooping. (Example: DHCP snooping stops a fake DHCP server from giving out an IP. DAI stops a device from pretending to be 192.168.1.1 by using a fake ARP reply.)
- **DHCP snooping vs IP Source Guard (IPSG):** IPSG filters IP traffic on a port based on the DHCP snooping binding table. It ensures that a device can only send packets with the IP address assigned to it by DHCP. DHCP snooping does not filter data traffic; it only filters DHCP control messages. (Example: DHCP snooping stops a rogue server. IPSG stops a device from sending packets with an IP address that was not assigned to it, preventing IP spoofing.)
- **DHCP snooping vs Port Security:** Port security limits the number of MAC addresses allowed on a switch port and can block traffic from unknown MACs. It does not inspect DHCP messages at all. DHCP snooping specifically looks at DHCP packet types and port trust. They solve different problems: port security for physical device control, snooping for DHCP protocol security. (Example: Port security stops a stranger from plugging into the network. DHCP snooping stops that same device from acting as a DHCP server.)
- **DHCP snooping vs DHCP relay:** DHCP relay forwards DHCP broadcast messages across subnets so clients on one subnet can get IP addresses from a server on a different subnet. It does not provide any security filtering. DHCP snooping is purely a security feature and has nothing to do with forwarding broadcasts to other subnets. (Example: A router with DHCP relay forwards a request from VLAN 10 to a server in VLAN 20. DHCP snooping on the switch checks the reply that comes back from that relay and ensures it comes from a trusted port.)

## Step-by-step breakdown

1. **Enable DHCP snooping globally** — The administrator enters global configuration mode and types 'ip dhcp snooping'. This turns on the feature on the switch but does not activate it on any VLAN yet. Without this step, no DHCP message inspection occurs.
2. **Enable DHCP snooping on specific VLANs** — The administrator then uses 'ip dhcp snooping vlan <vlan-id>' to specify which VLANs should be monitored. Only traffic on these VLANs is filtered. This is important because you may have a management VLAN where DHCP is not needed or where a server sits.
3. **Configure trusted and untrusted ports** — Interfaces connected to the legitimate DHCP server or DHCP relay agent are set as trusted with 'ip dhcp snooping trust' under interface mode. All other interfaces remain untrusted by default. The switch will now block DHCP server messages on untrusted ports.
4. **Configure rate limiting (optional)** — The administrator can set a limit on the number of DHCP packets per second on untrusted ports using 'ip dhcp snooping limit rate <rate>'. This prevents a DHCP starvation attack where a client sends thousands of DHCPDISCOVER messages.
5. **Enable option 82 insertion (optional for DHCP relay)** — When a DHCP relay is used, the switch can insert option 82 (Relay Agent Information Option) into client requests. This helps the server know which port the client is on. Some networks require this, and it is enabled by default.
6. **Switch builds the DHCP snooping binding table** — As clients successfully get IP addresses via DHCPACK, the switch records the MAC address, assigned IP, VLAN, port number, and lease time in the binding database. This table is stored in RAM and can be viewed with 'show ip dhcp snooping binding'.
7. **Filter DHCP messages on untrusted ports** — The switch inspects every DHCP packet arriving on an untrusted port. If the packet is a DHCPOFFER, DHCPACK, or DHCPNAK, it is immediately dropped. DHCPDISCOVER and DHCPREQUEST are forwarded normally to the server. This blocks rogue servers while allowing client requests.
8. **Validate MAC addresses in DHCP packets** — For DHCP packets on untrusted ports, the switch checks that the source MAC address in the Ethernet frame matches the 'chaddr' field in the DHCP payload. If they do not match, the packet is dropped. This prevents a client from spoofing its MAC address in DHCP requests.
9. **Handle lease expiration and bindings cleanup** — When a lease expires or the client sends a DHCPRELEASE, the switch removes the corresponding entry from the binding table. This keeps the database accurate and prevents stale entries from being used by DAI or IPSG.
10. **Provide binding table to DAI and IPSG** — The DHCP snooping binding table is used by Dynamic ARP Inspection and IP Source Guard. DAI checks ARP packets against the table, and IPSG filters data packets based on the table. This provides a layered security approach starting from DHCP snooping.

## Practical mini-lesson

DHCP snooping is a security feature that you will likely configure on every enterprise switch you manage. Let us walk through a real configuration practice. First, you must understand the network topology. You have a core switch that connects to the DHCP server on port Gi1/0/48. The server is in VLAN 100. Client devices are in VLAN 10, 20, and 30. You have access switches that connect to the core via trunk ports.

Global configuration begins with 'ip dhcp snooping' on both the core and access switches. Then you specify the VLANs: 'ip dhcp snooping vlan 10,20,30,100'. Note that you include the server VLAN 100 as well, because the server messages traverse that VLAN. On the core switch, you set Gi1/0/48 to trusted. On the access switches, you set the uplink port to the core as trusted, because DHCP server messages will come through that trunk. All client-facing ports remain untrusted.

Set rate limiting on client ports to something reasonable like 10 packets per second. Use 'interface range Gi1/0/1-24' and then 'ip dhcp snooping limit rate 10'. This ensures no single client can flood the network with DHCP requests. Also verify that option 82 insertion is enabled globally (it is by default). If you have a DHCP relay agent, make sure it is configured to trust the relay agent's IP address. On some switches, you need to enter 'ip dhcp snooping information option allow-untrusted' if you have untrusted ports with relay agents, but that is rare and usually a security risk.

What can go wrong? The most common mistake is forgetting to enable snooping on the server VLAN. The server port is trusted, but if the server VLAN is not in the snooping list, the switch does not inspect traffic on that VLAN at all. Another issue is the binding table filling up. Large networks with many temporary devices (like guest Wi-Fi) can exhaust the switch's memory for binding entries. In that case, you might need to adjust the maximum binding count or rely on the relay agent to provide option 82 data so the switch can use a more compact table.

Professionals should also know how to clear the binding table using 'clear ip dhcp snooping binding' or clear specific entries with '*'. This is useful when you change DHCP scopes or when troubleshooting IP conflicts. Also, monitor the log for 'DHCP_SNOOPING_DROP' messages. These indicate packets being dropped, which could be legitimate traffic if your configuration is wrong.

Finally, remember that DHCP snooping is not a cure-all. It does not encrypt DHCP traffic. It does not prevent a rogue server that is on a trusted port. It does not protect against attacks on the DHCP server itself, like directly hacking the server's software. It is a Layer 2 defense, not a replacement for firewalls or endpoint security. Always use it as part of a defense-in-depth strategy.

## Commands

```
ip dhcp snooping
```
Enables DHCP snooping globally on the switch. This is the first configuration step. Without this, all VLAN-level and interface-level DHCP snooping commands are ignored.

*Exam note: Exams test that this global command must be issued before any VLAN-specific DHCP snooping configuration. It is a prerequisite.*

```
ip dhcp snooping vlan 10,20,30
```
Enables DHCP snooping on specific VLANs (e.g., VLANs 10, 20, 30). DHCP snooping only operates on the VLANs explicitly listed. Traffic on other VLANs is not filtered.

*Exam note: Common exam question: 'Which command limits DHCP snooping to VLAN 10?' The answer is 'ip dhcp snooping vlan 10'. Another variant tests that snooping is VLAN-specific, not global after the global enable.*

```
interface gigabitethernet0/1
 ip dhcp snooping trust
```
Configures the interface as a trusted port for DHCP snooping. Use this on ports connected to legitimate DHCP servers or uplinks to other trusted switches. All other ports remain untrusted by default.

*Exam note: Exam scenario: A network engineer plugs a legitimate DHCP server into port Gi0/1 but users cannot get IPs. The fix is to configure 'ip dhcp snooping trust' on that port. The default untrusted setting drops server messages.*

```
ip dhcp snooping limit rate 10
```
Sets a rate limit of 10 DHCP packets per second on an untrusted port. Packets exceeding this limit are dropped. Use this to prevent DHCP starvation attacks.

*Exam note: Tested in Security+ and CCNA: 'What command mitigates DHCP starvation?' Answer: 'ip dhcp snooping limit rate'. Also note that the default is 15 pps on many platforms.*

```
ip dhcp snooping information option allow-untrusted
```
Allows DHCP snooping to add or process option 82 (relay agent information) on untrusted ports. Normally, option 82 is stripped on untrusted ports. Use this in ISP environments or when DHCP relay agents are used on untrusted ports.

*Exam note: CCNA exam: 'A DHCP relay agent is connected to an untrusted switch port and clients fail to get IPs.' The solution is this command to allow option 82. Tests understanding of how DHCP snooping modifies relay information.*

```
ip dhcp snooping binding 0011.2233.4455 vlan 10 192.168.1.50 interface gigabitethernet0/2
```
Creates a static DHCP snooping binding entry. Useful for devices with static IPs, like printers or servers, so that IP Source Guard allows their traffic.

*Exam note: Exams test the difference between dynamic and static bindings. A static binding survives a switch reboot and is manually created. Used when a host does not use DHCP but must be allowed by IPSG.*

```
show ip dhcp snooping binding
```
Displays the DHCP snooping binding database, including MAC, IP, lease time, VLAN, and interface. Use to verify that clients have successfully leased IPs and bindings are present.

*Exam note: Common troubleshooting question: 'Which command shows if a client has a valid DHCP snooping entry?' Answer: 'show ip dhcp snooping binding'. If the entry is missing, IPSG may block traffic.*

```
errdisable recovery cause dhcp-rate-limit
```
Enables automatic recovery from err-disable state caused by a DHCP rate-limit violation. After the timeout (default 300 seconds), the port is automatically re-enabled.

*Exam note: Exam scenario: A switch port goes into err-disable after a DHCP flood. The admin wants automatic recovery. 'errdisable recovery cause dhcp-rate-limit' is the correct command. Tests knowledge of err-disable recovery mechanisms.*

## Troubleshooting clues

- **Clients cannot obtain IP address from DHCP server connected to switch** — symptom: Clients are stuck with 169.254.x.x APIPA addresses. DHCP server is up and reachable.. Most likely, the port where the DHCP server is connected is not configured as a trusted port. DHCP snooping drops all server messages (DHCPOFFER, DHCPACK) on untrusted ports by default. (Exam clue: Exams present this exact scenario: 'A network engineer plugs in a new DHCP server but clients get APIPA.' The answer is to configure 'ip dhcp snooping trust' on the server port.)
- **IP Source Guard blocking legitimate traffic after DHCP lease renewal** — symptom: Host can get a DHCP lease but traffic is immediately dropped. 'show ip verify source' shows no binding or outdated binding.. DHCP snooping binding did not update after lease renewal, possibly because DHCP snooping is not enabled on the correct VLAN, or the binding database file is corrupt and not being written. The host may still have a lease but the switch binding is missing or expired. (Exam clue: Exam question: 'A client renews its IP address but cannot communicate. Which command shows if the binding exists?' Correct answer: 'show ip dhcp snooping binding'. If missing, the solution is to verify the VLAN snooping config or clear the binding and force a new request.)
- **Port goes into err-disable state frequently** — symptom: Switch port shows 'err-disabled' in status. Cause is listed as 'dhcp-rate-limit'.. The rate limit configured on the port is too low for legitimate traffic. This can happen when many clients connect simultaneously (e.g., in a conference room). The switch detects excessive DHCP packets and disables the port. (Exam clue: Troubleshooting question: 'A port keeps going err-disabled after a large meeting. What is the likely cause?' Answer: rate limit too low. Next step: increase the limit or set burst parameters. The command is 'ip dhcp snooping limit rate <value>'.)
- **ARP replies being dropped for legitimate hosts** — symptom: Hosts can ping each other but cannot ping the default gateway. Dynamic ARP Inspection is enabled.. DAI is dropping the host's ARP reply because the MAC or IP in the ARP packet does not match the DHCP snooping binding. This commonly happens after a NIC replacement, as the MAC address changes but the binding still has the old MAC. (Exam clue: CCNA or Security+ scenario: 'After replacing a network card, a workstation cannot reach the Internet. DAI is enabled.' The fix is to clear the old binding or disable DAI on the port temporarily. The exam tests understanding that DAI validates against the binding database.)
- **Static IP devices (printers, servers) cannot communicate** — symptom: Devices with static IP configuration are unreachable, even though they are configured correctly and the network is working for DHCP clients.. If IP Source Guard is enabled on the port, it requires a DHCP snooping binding. Since the device did not get its IP via DHCP, no binding exists. IPSG drops all packets from that source IP. (Exam clue: Exam asks: 'How to allow a static IP printer on a port with IPSG?' The answer: create a static DHCP snooping binding with the 'ip dhcp snooping binding' command. This tests the concept of static entries in the binding database.)
- **DHCP server logs show thousands of requests from same switch port** — symptom: Legitimate clients report DHCP failures. Server shows millions of DHCPDISCOVER messages from various MAC addresses but from the same switch port.. This is a DHCP starvation attack in progress. The port likely has no rate limit configured, or the limit is too high. The attacker is flooding with spoofed MAC addresses. (Exam clue: Security+ question: 'What is the first step to stop a DHCP starvation attack?' Answer: enable DHCP snooping with a rate limit on the untrusted port. The exam also tests that rate limiting is configured per interface.)
- **DHCP option 82 (relay agent information) is missing in logs** — symptom: Remote DHCP relay agents report that option 82 is stripped from forwarded requests. DHCP server cannot identify the source subnet.. DHCP snooping removes option 82 from DHCP messages received on untrusted ports by default. If the relay agent is connected to an untrusted port, the option is lost. The command 'ip dhcp snooping information option allow-untrusted' is needed. (Exam clue: CCNA exam: 'A DHCP relay agent on an access switch loses option 82 information.' The fix is to use the 'allow-untrusted' keyword. Tests deep understanding of DHCP snooping's interaction with relay agents.)

## Memory tip

Think of DHCP snooping as the bouncer at a club: all ports are untrusted (no entry) unless they are on the VIP trusted list. The bouncer only lets server messages (the VIP packets) from the trusted door.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/dhcp-snooping