The access layer protections are usually presented as a list of independent features, which is the reason so many deployments of them go badly. They are not independent. One of them builds a table; two of them do nothing except read that table; and a fourth is unrelated to all three. Deploying them in the wrong order, or deploying the consumers before the table is complete, produces an outage that looks like a hardware fault and is not.
Seen correctly the arrangement is simple. The switch watches address assignment and records which address was given to which device on which port. Everything else is an enforcement point reading that record: a device whose address does not appear in it cannot claim that address in an address-resolution message, and cannot send traffic using it. The security value comes entirely from the record being accurate.
This article covers why these features are really one feature, how the record is built and what destroys it, what address-resolution inspection actually validates and what it does not, what source enforcement adds and where broadcast limiting fits in, and the deployment order that avoids taking the site down. It is written for the lab rather than for the written exam, and sits alongside the rest of the CCIE Enterprise Infrastructure lab certification track.
Address assignment snooping builds one table and the enforcement features read it, so the accuracy and persistence of that table determines whether the enforcement protects the network or disconnects it.Why Are These Really One Feature?
What is the relationship?
Address assignment snooping observes the exchange between a client and the address server and records the result: this hardware address holds this network address, in this VLAN, on this port, until this time. That record is the binding table. Address resolution inspection reads it to decide whether a device may claim an address, and source enforcement reads it to decide whether a device may send traffic using one. Neither consumer has any other source of truth, so the quality of both is exactly the quality of the table.
A Deeper Dive into the Dependency
What the record contains
Five fields, and each one is used by something. The hardware address and the network address, which together are the binding being asserted. The VLAN, because the same network address may legitimately exist in two of them. The port, which is what makes the record an enforcement point rather than merely a fact. And the remaining lease time, which is what causes the entry to expire when the device leaves.
The port field is the one that does the work. A record saying an address belongs to a device is useful; a record saying it belongs to a device on a specific port lets the switch discard anything claiming that address anywhere else, which is the entire protection being offered.
The trust boundary, which is the only real design decision
Every port is either trusted or untrusted, and the rule is straightforward: trusted means the switch believes what arrives there. Ports facing other switches, and the port toward the address server, are trusted. Ports facing client devices are not.
Getting this wrong in one direction disables the protection; getting it wrong in the other disconnects the site. An untrusted uplink means server responses arriving from the rest of the network are discarded, so no client on this switch is ever given an address. That is the most common first-attempt failure and it happens within seconds of enabling the feature.
Why the consumers fail closed
Both enforcement features discard what they cannot verify. That is the correct behaviour for a security control and it means an incomplete table is indistinguishable, from a client's perspective, from an attack being blocked. A device with no entry is denied, whether it is an attacker or a printer that was configured with a static address in 2014.
So the operational burden of these features is entirely about completeness. Every device that does not obtain its address from the server needs a manually created record, and finding all of them before enforcement begins is the bulk of the deployment work.
The feature that is not part of this
Broadcast and multicast rate limiting reads nothing and protects against something else: a forwarding loop or a misbehaving device flooding the segment. It is genuinely independent, it can be deployed on its own at any time, and it is grouped with these features only because it also lives on an access port.
Treating it as part of the same project delays it for no reason. It is low risk, immediately useful, and does not depend on any table being correct.
Where port security sits
Limiting the number of hardware addresses on a port is a different control with a different purpose, and it becomes relevant here in one specific way: source enforcement can validate the hardware address as well as the network address, and doing so requires port security to be enabled on the same port. Without it, only the network address is checked.
That distinction matters, because network-address-only enforcement can be defeated by a device that spoofs the hardware address of a legitimate host. Combining the two closes that gap, at the cost of managing address limits on every port.
| Feature | Depends on | Validates | Fails closed? |
|---|---|---|---|
| Assignment snooping | Nothing | Where server responses may originate | Yes |
| ARP inspection | The binding table | Address-resolution claims | Yes |
| Source guard | The binding table | Source address of data traffic | Yes |
| Source guard with MAC check | Binding table + port security | Source address and hardware address | Yes |
| Storm control | Nothing | Broadcast and multicast rate | No — it limits |
How Is the Table Built, and What Destroys It?
Where do entries come from?
Two sources. Observed assignments, created when the switch sees a client accept an address from the server, and removed when the lease expires or the device releases it. And manual entries, created for devices that never speak to the address server because they hold a static address. The first source is automatic and the second is the deployment work. Everything the table does not contain will be blocked as soon as enforcement is enabled.
A Deeper Dive into the Table
Enabling it, with trust in the same change
Two commands enable it globally and per VLAN, and a third trusts the uplink. Those three belong in one change, applied together. Splitting them means a window during which the switch is discarding legitimate server traffic, and on a busy access switch that window is long enough to generate calls.
! All three together. Never enable without trusting the uplink.
Sw1(config)# ip dhcp snooping
Sw1(config)# ip dhcp snooping vlan 10,20,30
!
Sw1(config)# interface TenGigabitEthernet1/0/1
Sw1(config-if)# description Uplink to distribution
Sw1(config-if)# ip dhcp snooping trust
!
! Client ports: untrusted by default, plus a rate limit
Sw1(config)# interface range GigabitEthernet1/0/1 - 48
Sw1(config-if-range)# ip dhcp snooping limit rate 15
Persistence, which is not optional
The table lives in memory. A reload empties it, and on the next boot the switch has no record of any device. Both enforcement features then discard everything from every client until each one renews its lease, which for a typical lease length means hours of a site being down after what should have been a routine restart.
Writing the table to storage and reading it back at boot prevents this entirely. It is one command plus a location, it costs nothing, and omitting it converts every reload into an outage. There is no situation in which enforcement should be enabled without it.
! Without this, a reload takes the site down until every lease renews
Sw1(config)# ip dhcp snooping database flash:dhcp-snooping.db
Sw1(config)# ip dhcp snooping database write-delay 60
Sw1(config)# ip dhcp snooping database timeout 60
!
! Confirm it is actually writing
Sw1# show ip dhcp snooping database
Agent URL : flash:dhcp-snooping.db
Write delay Timer : 60 seconds
Last succeded write time : 14:02:11 UTC Mon Sep 14 2026
Total Attempts : 148 Successful transfers : 148
show ip dhcp snooping binding returns almost nothing on a switch with many connected devices. Fix: configure the database agent so the table is written to storage and restored at boot — and treat this as a prerequisite for enabling any enforcement, not an enhancement.The devices that were never in the table
Anything with a static address. Printers, building management controllers, cameras, test equipment, a server somebody configured by hand, and the machine in the corner that nobody can identify. None of these ever exchange anything with the address server, so no entry is ever created, and all of them stop working the moment enforcement begins.
Finding them is the real work of the deployment. The address management records will be incomplete. A reliable approach is to read the address-resolution table on the distribution layer, compare it against the binding table, and investigate every address present in one and absent from the other. That difference is the list of manual entries required.
! Find what needs a static entry: present in ARP, absent from bindings
Sw1# show ip dhcp snooping binding
MacAddress IpAddress Lease(sec) Type VLAN Interface
------------------ --------------- ---------- ------------- ---- ---------
00:1B:44:11:3A:B7 10.10.10.51 84203 dhcp-snooping 10 Gi1/0/12
!
! Then create what is missing
Sw1(config)# ip source binding 00:1B:44:11:0C:22 vlan 10 10.10.10.240 interface Gi1/0/24
!
Sw1# show ip source binding
Insertion of the relay information option
The switch can add information identifying the port a request arrived on, which is useful where the address server assigns based on location. It also causes a well-known interoperability problem: a relay or server that receives a request carrying that information from a device which is not acting as a relay may discard it, and every client on the switch fails to obtain an address.
Two resolutions exist. Configure the upstream device to accept it, which is correct where the information is actually wanted. Or stop inserting it, which is correct where it is not. What must not happen is leaving it inserted and undiagnosed, because the symptom — no addresses issued — is identical to the untrusted uplink failure and the two are frequently confused.
! If the upstream relay or server rejects the option, either
! stop inserting it on the access switch...
Sw1(config)# no ip dhcp snooping information option
!
! ...or accept it upstream, where the information is wanted
Dist1(config)# ip dhcp relay information trust-all
!
! Diagnose which failure you have
Sw1# show ip dhcp snooping statistics
Rate limiting the request path
A client port should not produce many address requests per second. Limiting the rate contains a device that is malfunctioning or deliberately exhausting the address pool, and the limit can be low because legitimate use is low.
The limit must not be applied to the uplink, where the aggregate of every client's traffic legitimately passes. Applying a client-port limit to a trunk disables the switch's entire address assignment path and produces yet another failure with the same symptom as the previous two.
What Does Address Resolution Inspection Actually Validate?
What is checked?
Every resolution message arriving on an untrusted port is compared against the binding table. If the sender claims a network address that the table says belongs to a different hardware address, or to a device on a different port, the message is discarded. Trusted ports are not checked at all. Optionally the hardware addresses inside the message can be compared against those in the frame header, which catches a class of malformed message the basic check permits.
A Deeper Dive into Resolution Inspection
The attack it prevents
Address resolution has no authentication. Any device can answer for any address, and a device that answers for the gateway's address receives traffic intended for the gateway. It can then forward it onward, which makes the attack invisible to the user and gives the attacker a copy of everything.
Inspection prevents it by checking the claim against a record of what was actually assigned. An attacker claiming the gateway's address has no entry saying it owns that address, so the claim is discarded before it reaches any other device. The protection is complete against this attack and depends entirely on the record being right.
Trust, again, and the same failure
Uplinks must be trusted. An untrusted uplink means every resolution message from the rest of the network is inspected against a table that contains only locally connected devices, so everything from beyond this switch is discarded — including the gateway's own responses.
The result is a switch whose clients cannot resolve anything outside their own segment. It is a complete isolation of the access layer and it happens the instant the feature is enabled on a VLAN without the trust configuration alongside it.
! Enable per VLAN, and trust the uplinks in the same change
Sw1(config)# ip arp inspection vlan 10,20,30
!
Sw1(config)# interface TenGigabitEthernet1/0/1
Sw1(config-if)# ip arp inspection trust
!
! Additional validation - not on by default
Sw1(config)# ip arp inspection validate src-mac dst-mac ip
The additional validation, and why it is not default
The basic check compares the claim against the table. The additional checks compare the hardware addresses inside the message against those in the frame header, and reject messages carrying invalid or unexpected network addresses. Together they close gaps that a carefully constructed message could otherwise exploit.
They are not enabled by default because they reject some legitimate but unusual traffic produced by particular devices and operating systems. Enabling them is right, and it should be done after the basic deployment is stable so that anything they break is unambiguous.
Statically addressed devices, and the list-based alternative
A device with no binding entry cannot pass inspection. The manual entry created for the table handles this, and there is a second mechanism: an explicit list of permitted hardware and network address pairs, applied to a VLAN, consulted before the table.
Which to use is a matter of preference. Manual bindings keep everything in one place and are read by both consumers. An explicit list is easier to review as a document and applies only to resolution inspection. Using both, for different devices, produces a situation where nobody can say why a given device is permitted, which is worth avoiding.
! Alternative to a binding: an explicit permitted list
Sw1(config)# arp access-list STATIC-HOSTS
Sw1(config-arp-nacl)# permit ip host 10.10.10.240 mac host 001b.4411.0c22
Sw1(config-arp-nacl)# permit ip host 10.10.10.241 mac host 001b.4411.0c23
!
Sw1(config)# ip arp inspection filter STATIC-HOSTS vlan 10
The rate limit that disables ports
Untrusted ports carry a default limit on inspected messages per second, and exceeding it puts the port into an error state. This is intentional — a device generating a flood of resolution messages is malfunctioning or hostile — and it has a specific false positive: a port carrying legitimately high resolution traffic, such as one feeding a small unmanaged switch with many devices behind it.
Two responses. Raise the limit on those specific ports, having established why the traffic is high. And configure automatic recovery, so that a port disabled by a transient burst returns without an engineer. Leaving recovery unconfigured means every false positive becomes a manual intervention. Reading this once is not the same as being able to do it under time pressure, which is what repetition against realistic CCIE lab practice scenarios is for.
! Raise the limit where the traffic is legitimately high
Sw1(config)# interface GigabitEthernet1/0/24
Sw1(config-if)# ip arp inspection limit rate 100
!
! And always configure recovery
Sw1(config)# errdisable recovery cause arp-inspection
Sw1(config)# errdisable recovery interval 300
!
! What has been dropped, and where
Sw1# show ip arp inspection statistics
Sw1# show ip arp inspection interfaces
What Does Source Enforcement Add, and Where Does Rate Limiting Fit?
What is the difference?
Resolution inspection checks claims about who owns an address. Source enforcement checks the traffic itself: a frame whose source address does not match the binding for the port it arrived on is discarded. So a device that never sends a resolution message, and simply transmits using an address it does not own, is stopped by the second and not the first. Broadcast rate limiting is unrelated to both and addresses flooding rather than impersonation.
A Deeper Dive into Enforcement and Limiting
What source enforcement catches
Traffic sent with a forged source address. That covers a device attempting to impersonate another host, a device configured with an address belonging to something else, and a device attempting to send traffic from an address range it has no business using.
The check is per port and per frame, applied in hardware, so it costs nothing at forwarding time. What it costs is accuracy in the table, again, and this is the feature where an incomplete table is most immediately visible, because it discards data traffic rather than control messages.
The two modes
Network address only, or network address and hardware address together. The second is stronger and requires port security to be enabled on the port, because that is what gives the switch an authoritative view of which hardware address belongs there.
The weaker mode is defeated by a device that also spoofs the hardware address of the legitimate host, which is not difficult. Where the threat model includes a capable attacker on the access layer, the stronger mode is the one that matters. Where the concern is misconfiguration and casual misuse, the weaker mode is sufficient and simpler.
! Network address only
Sw1(config)# interface range GigabitEthernet1/0/1 - 48
Sw1(config-if-range)# ip verify source
!
! Network address and hardware address - needs port security
Sw1(config-if-range)# switchport port-security
Sw1(config-if-range)# switchport port-security maximum 2
Sw1(config-if-range)# ip verify source port-security
!
! What is being enforced, per port
Sw1# show ip verify source
Interface Filter-type Filter-mode IP-address Mac-address Vlan
--------- ----------- ----------- ------------- ------------------ ----
Gi1/0/12 ip trk active 10.10.10.51 10
Where it must not be enabled
Uplinks and trunks. A trunk carries traffic from every device on every switch below it, none of which has a binding on this switch, so enabling enforcement there discards essentially everything. This is the same trust mistake as the previous two features and produces the most dramatic version of it.
Also any port connected to a router, a firewall or anything else that legitimately forwards traffic on behalf of other addresses. Those devices send traffic with source addresses that are not theirs, which is exactly what this feature exists to discard.
Broadcast and multicast rate limiting
A separate concern entirely: a port that begins flooding, because of a loop, a failed network card or a misbehaving application, can saturate a segment. Limiting the proportion of a port's capacity that broadcast or multicast traffic may consume contains it to that port.
Thresholds are expressed as a percentage of capacity or as a rate, and the default action is to discard the excess while leaving the port up. Configuring it to disable the port instead is appropriate where the cause is more likely to be a loop than a burst, because a disabled port is a clearer signal and stops the problem completely.
! Contain flooding to the port causing it
Sw1(config)# interface range GigabitEthernet1/0/1 - 48
Sw1(config-if-range)# storm-control broadcast level 1.00
Sw1(config-if-range)# storm-control multicast level 2.00
Sw1(config-if-range)# storm-control action trap
!
! What has been suppressed, and on which ports
Sw1# show storm-control
Interface Filter State Upper Lower Current
--------- ------------- ----------- ----------- -----------
Gi1/0/12 Forwarding 1.00% 1.00% 0.02%
Choosing thresholds that do not fire on normal traffic
Multicast is the one to be careful with. A segment carrying video distribution or a discovery-heavy application can legitimately run a substantial proportion of multicast, and a threshold set by copying the broadcast figure will discard it.
Measure before setting, as with any threshold. Broadcast on a normal client segment is a very small fraction of capacity and a low threshold is safe; multicast varies enormously between environments and should be set from what this network actually does.
Deploying the limit early
Because it depends on nothing, it can go in immediately and independently of everything else in this article. It is low risk with a sensibly chosen threshold, it provides immediate protection against the most common cause of an access layer outage, and it does not have to wait for a binding table to be complete.
Grouping it into the same project as the table-dependent features delays it by however long that project takes, which is typically months. There is no reason to.
| Feature | Stops | Enable on | Never on |
|---|---|---|---|
| Resolution inspection | Address claim spoofing | Client VLANs | Untrusted uplinks |
| Source guard, address only | Forged source addresses | Client ports | Trunks and router ports |
| Source guard with MAC | The above, plus MAC spoofing | Client ports with port security | Trunks and router ports |
| Broadcast limiting | Flooding from one port | Anywhere, immediately | — |
| Multicast limiting | Flooding from one port | After measuring | Video segments, untested |
In Which Order Should This Be Deployed?
What is the sequence?
Rate limiting first and separately, because it depends on nothing. Then snooping, with the trust configuration in the same change and persistence configured immediately. Then a period of doing nothing while the table fills, followed by the search for every device that will never appear in it. Then resolution inspection, watching the drop counters. Then source enforcement, on client ports only, one wiring closet at a time. Every step verified before the next begins.
A Deeper Dive into the Deployment
The step people skip
The waiting. After snooping is enabled the table fills gradually, as each device renews, over a period as long as the lease lifetime. Enabling enforcement before that is complete blocks everything that has not yet renewed, which on the first day is most of the site.
A full lease lifetime is the minimum and twice that is better, because it catches devices that were switched off for a day. The time costs nothing — snooping alone blocks nothing — and skipping it produces the outage the whole sequence exists to avoid.
Finding the static devices properly
Comparing the resolution table at the distribution layer against the binding table gives the list. Every address present in the first and absent from the second is a device that will be blocked. Each one needs to be identified, and the outcome is either a manual binding entry or a decision to move it to dynamic addressing.
The second outcome is better where it is possible, because a manual entry is a permanent maintenance item that will outlive everyone who understands why it exists. A device moved to dynamic addressing needs no entry at all.
! The comparison that produces the work list
Dist1# show ip arp vlan 10 | include Vlan10
Sw1# show ip dhcp snooping binding vlan 10
!
! Anything in the first and not the second needs a decision:
! a static binding, or a move to dynamic addressing
Sw1(config)# ip source binding 00:1B:44:11:0C:22 vlan 10 10.10.10.240 interface Gi1/0/24
!
Sw1# show ip source binding | count
Enabling inspection with the counters open
Resolution inspection is the first step that discards anything. Enable it on one VLAN, on one switch, and read the drop statistics before proceeding. A non-zero drop count on the first day is expected and every entry in it should be identified before the feature is extended.
Extending it to the whole site before reading those counters means that when something breaks, the affected population is the entire site rather than one VLAN. The information gained is the same and the consequence of being wrong is not.
Source enforcement, last and slowly
This is the step that discards data traffic, so its failures are immediate and total for the affected device. One wiring closet at a time, with a period of observation between, is slow and is the right pace. There is no benefit to completing it quickly and there is a substantial cost to getting it wrong across a building.
The specific things to check before each closet: no trunk has it enabled, no router or firewall port has it enabled, and every statically addressed device in that closet has a binding entry.
A verification set for each stage
After snooping: the table has roughly as many entries as there are devices, and the database agent is writing successfully. After the static work: the difference between the resolution table and the binding table is zero, or every remaining difference is understood. After inspection: the drop counters are zero or explained. After enforcement: every port's filter state is as intended and no trunk appears in the list.
! One check per stage, in order
Sw1# show ip dhcp snooping binding | count
Sw1# show ip dhcp snooping database | include Successful|Failed
Sw1# show ip arp inspection statistics | include Dropped
Sw1# show ip verify source | count active
!
! And the overall view
Sw1# show ip dhcp snooping
Sw1# show ip arp inspection
What to monitor afterwards
Three things. The binding table's entry count, which should track the number of connected devices and whose sudden drop indicates a database or lease problem. The database agent's success count, which should never stop increasing. And the inspection drop counter, which should be near zero in steady state and whose increase is either an attack or a device that changed.
The second is the one that fails silently. A database agent that has stopped writing gives no symptom at all until the next reload, at which point the outage is total and the cause is weeks old.
Blueprint framing
The CCIE Enterprise Infrastructure v1.1 blueprint covers these access layer protections within its infrastructure security domain. What is asked is usually the relationship between them — which feature builds the table, which ones consume it, and what happens to a statically addressed device — rather than a full deployment.
| Stage | Enable | Verify before proceeding | Risk if skipped |
|---|---|---|---|
| 1 | Rate limiting | Thresholds do not fire normally | Low |
| 2 | Snooping + trust + persistence | Database agent is writing | Reload becomes an outage |
| 3 | Nothing — wait | Table has filled | Enforcement blocks the site |
| 4 | Static bindings | Resolution table matches bindings | Static devices blocked |
| 5 | Resolution inspection, one VLAN | Drop counters understood | Site-wide isolation |
| 6 | Source enforcement, one closet | No trunk or router port enabled | Total loss on those ports |
Conclusion
These are not three security features and one more. They are a database and two consumers of it, plus an unrelated rate limit that happens to live on the same ports. Address assignment snooping records which device holds which address on which port; resolution inspection and source enforcement do nothing except read that record and discard what contradicts it. The protection is real and complete against the attacks it targets, and it is worth exactly as much as the record is accurate.
Which means the deployment is a data problem rather than a configuration one. The table takes a full lease lifetime to become accurate and there is no way to accelerate it. Every device that holds a static address will never appear in it and must be found, identified and either given a manual entry or moved to dynamic addressing. And the table lives in memory, so without persistence configured every reload empties it and every enforcement feature then blocks every device until it independently renews.
The failures are all the same failure in different clothes. An untrusted uplink, a trunk with source enforcement enabled, a rate limit applied to the wrong port — each is the switch refusing to believe something it should have been told to trust, and each takes out considerably more than the port it was applied to. Enable the trust in the same change as the feature, verify each stage before starting the next, and deploy the rate limiting immediately and separately, because it depends on none of this and should not wait for it. More CCIE Enterprise Infrastructure material — labs, protocol breakdowns and study guides — is collected on the SPOTO CCIE site.
External Links
- RFC 2131 — Dynamic Host Configuration Protocol
- RFC 3046 — DHCP Relay Agent Information Option
- RFC 826 — An Ethernet Address Resolution Protocol
- RFC 5227 — IPv4 Address Conflict Detection
- RFC 2827 — Network Ingress Filtering
- Cisco Learning Network — CCIE Enterprise Infrastructure
Reference Notes
- RFC 2131 specifies DHCP, including the lease and its renewal, which determines how long a binding remains valid and how quickly a table rebuilds after being lost.
- RFC 2131 describes the four-message exchange between client and server, which is what a snooping switch observes in order to create a binding.
- RFC 3046 defines the relay agent information option, which carries information identifying the circuit a request arrived on, and notes that a relay agent may discard messages containing it from untrusted sources.
- RFC 826 specifies ARP, which contains no authentication of the sender's claim to the address it advertises.
- RFC 5227 describes IPv4 address conflict detection, in which hosts use ARP to detect duplicate addresses, illustrating that any host may assert any address.
- RFC 2827 recommends ingress filtering so that traffic with a source address the sender could not legitimately hold is discarded at the network edge.
- Cisco documentation describes DHCP snooping, in which ports are untrusted by default and server messages arriving on untrusted ports are discarded.
- Cisco documentation describes the DHCP snooping binding database and the database agent that writes it to persistent storage, without which the bindings are lost on reload.
- Cisco documentation describes dynamic ARP inspection, which validates ARP packets on untrusted ports against the snooping binding database and supports additional validation of source and destination MAC addresses and IP addresses.
- Cisco documentation describes the default ARP inspection rate limit on untrusted interfaces and the error-disable action taken when it is exceeded.
- Cisco documentation describes IP source guard, which filters traffic by source IP address, and the port-security option which additionally filters by source MAC address and requires port security on the interface.
- The CCIE Enterprise Infrastructure v1.1 unified exam topics include Layer 2 security features within the infrastructure security domain.