Architecture and operating model
DHCP snooping blocks server replies arriving on untrusted access ports and builds bindings from client MAC, IP, VLAN, port and lease data. Dynamic ARP Inspection compares ARP packets with those bindings. IP Source Guard constrains source IP/MAC data packets to the expected binding. These controls are complementary rather than interchangeable.
If an uplink toward the legitimate DHCP server remains untrusted, clients cannot obtain addresses. Marking a user port trusted allows rogue replies across the boundary. Trust should follow the expected server-response path, not a generic assumption that every trunk is safe.
Static devices, phone-PC passthrough, virtualization hosts, port channels and switch restarts all affect binding lifecycle. If the binding database is not persistent, DAI or IP Source Guard can interrupt service after restart. Begin with observation or a narrow VLAN pilot to discover real exceptions.
- 1DHCP exchange
- 2Binding table
- 3ARP validation
- 4Source IP/MAC enforcement
Design parameters
- Trusted ports
- Trust only legitimate DHCP response paths; do not trust access ports by default.
- Rate limit
- Measure normal renewal bursts, phones and virtualization behavior before setting DHCP packet limits.
- Static devices
- Use static bindings or a scoped policy for printers, cameras and infrastructure instead of disabling controls.
- Persistence
- Verify the binding database destination, availability and reload behavior after restart.
Worked example
For an access VLAN with two uplinks and 48 user ports, trust only the port channel on the DHCP server path. Enable snooping and collect bindings for 24 hours, then add DAI, followed by IP Source Guard on five pilot ports. Confirm distinct bindings for a phone and the attached PC.
If 300 clients send DHCPREQUEST within 60 seconds, the average is 5 packets/s while the peak may be much higher. Capture real peaks through telemetry rather than selecting an arbitrary limit, then retain measured headroom.
Example commands: replace lab values and confirm permissions and software versions before use.
# Syntax varies by vendor and release; map this workflow in a lab.
show ip dhcp snooping binding
show ip arp inspection statistics
show ip verify source
# Start with one pilot VLAN and a bounded port group.Troubleshooting
| Observation | Likely cause / distinction | Verification |
|---|---|---|
| Clients receive 169.254 addresses | Server replies may be dropped on an untrusted port or VLAN scope is missing. | Compare snooping drop counters, uplink trust and the VLAN path to the server. |
| DHCP works but traffic fails | IP Source Guard lacks a binding or the client uses a static address. | Match the port/VLAN binding against the client's actual IP and MAC. |
| Gateway ARP entry disappears | DAI may drop legitimate static infrastructure ARP without a binding. | Review inspection logs, ARP ACL/static binding and gateway port role. |
Acceptance checks
- Reject a rogue DHCP OFFER on an access port.
- Observe a legitimate lease renewal.
- Drop a forged ARP reply through DAI.
- Reject a packet using another client's address.
- Test binding behavior after switch restart.
- Validate static-device and phone-PC cases.
Related concepts
Layer 2 and Layer 3 boundaries
A VLAN creates a separate broadcast domain; routing and access policies govern communication between VLANs. Review trunk allowed lists, access-port assignment and gateway placement together. A network diagram should show where packets are routed and filtered, not merely which cables connect devices. Sharing a switch does not require sharing privileges. When access fails, confirm VLAN and addressing first, then gateway, route and policy matching.
Trust boundary and failure domain
A trust boundary separates components governed by different access decisions; a failure domain groups resources that one event can affect together. Two VLANs do not create a strong trust boundary when routing between them is unrestricted. Backups in different folders still share a failure domain if one administrator can delete both. Assess physical location, identity provider, management account, network path and power source separately. Test which access paths and recovery options remain available when a component is lost.
Authentication and sessions
Authentication proves who a user or workload is; authorization determines what that identity may do. Successful sign-in does not grant access to every resource. User sessions, service identities, API tokens and device certificates have different lifecycles. Design session duration, token renewal, employee departure, lost-device handling and emergency access alongside initial sign-in. Measure which existing sessions remain usable and which new accesses are denied when the identity provider becomes unavailable.
Least privilege and separation of duties
Least privilege limits the permissions needed for a task to specific resources and time periods. Giving everyone the same administrator role complicates access reviews and investigations. Separate daily-use identities from privileged accounts, and restrict interactive use and unnecessary network access for service identities. An access matrix should show which operation an identity may perform on each resource. Test whether an application keeps working after a permission is removed: unnecessary privileges sometimes become visible only during controlled reduction.
Availability versus recovery
High availability aims to keep service running through specified failures with a short interruption; backup recovers lost or corrupted data from an earlier point. A cluster can replicate an accidental deletion to another node. HA therefore does not replace backup. Consider DNS, identity, network, storage and power dependencies together. Successful node failover is insufficient by itself: measure user sessions, application writes and external integrations after the transition as well.
Telemetry and time correlation
Telemetry combines logs, metrics and events that explain system behaviour. A log describes an event, a metric shows behaviour over time, and a distributed trace follows a request across components. Clock differences can make one event appear to occur at several times. Use synchronized clocks, reliable source identifiers and consistent time-zone handling. Alarm design should consider duration and user impact alongside thresholds. Monitor gaps in collection separately: absence of logs must not be interpreted as absence of incidents.
Primary documentation
Prepared by the Doz Teknoloji technical team using the primary references below. Calculations and lab scenarios state their assumptions; validate the applicable product version before rollout.