First, the essential ideas
- MAC address and port security
- A MAC address identifies a local Ethernet interface. Port security limits which source MAC addresses may enter a switch port; it is not proof of a human identity.
- DHCP and snooping
- Dynamic Host Configuration Protocol leases IPv4 settings. DHCP snooping filters certain DHCP messages and learns a table linking a client's address, MAC, VLAN, interface and lease.
- ARP and DAI
- Address Resolution Protocol maps local IPv4 neighbors to MAC addresses. Dynamic ARP Inspection (DAI) checks incoming ARP on untrusted ports against permitted bindings or an explicit ARP policy.
- Trusted port
- Trust is specific to a feature. DHCP snooping trust permits server-side DHCP messages on that input; DAI trust bypasses ARP validation there. Neither means every attached device is safe.
- Binding and VLAN
- A binding records a relationship between an address and a local attachment. A VLAN is a separate Layer 2 broadcast domain; this lab uses VLAN 10 on two access ports.
- Restrict and error-disabled
- Port-security restrict drops violating traffic and reports violations without disabling the whole port. Shutdown mode can place a port in error-disabled state, requiring cause correction before recovery.
- Sticky learning
- Sticky secure MAC learning adds learned addresses to the running configuration. They persist across restart only if saved appropriately; ordinary dynamic learning is a different state.
Build the dependency chain deliberately: correct cabling and VLAN, working DHCP, an observed client binding, then ARP inspection. Port security is a parallel source-MAC control. Trust settings belong to each feature and must follow the actual role of the connected device.
See the idea
Three controls, three questions
Check source MACs, learn the lease, then validate the ARP claim against the right evidence.
Constrain the source
Port security limits the permitted source MAC set. It is not authenticated user identity.
What this model leaves out: This is a dependency comparison, not a physical topology. Trust, static hosts and restart persistence require separate design.
Full visual explanation and references
Three records compare port security, DHCP snooping and Dynamic ARP Inspection with the fact each control checks.
This is a dependency comparison, not a physical topology. Trust, static hosts and restart persistence require separate design.
- Constrain the source
Port security limits the permitted source MAC set. It is not authenticated user identity.
www.cisco.com - Learn the binding
Snooping records Client's leased IP, MAC, VLAN and port while respecting the server trust boundary.
www.cisco.com - Validate the claim
DAI checks untrusted ARP against permitted evidence. A static gateway needs its explicitly designed exception.
www.cisco.com
One idea at a time
Start with something familiar.
Draw three boxes labeled source MAC, DHCP lease and ARP claim. Place each control beside the fact it checks. This prevents the common assumption that one security command verifies every aspect of a connected endpoint.
Why learn this?
Layer 2 controls can stop unwanted local traffic, but an incorrect trust boundary can also stop legitimate clients. A trustworthy rollout needs a binding baseline and an explicit explanation of which port may send server messages.
An everyday comparison
Imagine three separate checks at a facility: a badge limit at a door, an equipment assignment register, and a check that a person claiming an item matches that register. The analogy is about separate records, not literal network authentication.
What happens in a network
Port security resembles limiting presented identifiers; DHCP snooping supplies a lease-to-port record; DAI compares an IPv4-to-MAC claim against approved evidence. None of these checks alone validates the entire endpoint.
Where the comparison stopsA MAC address can be copied, DHCP can fail, and trusted ports bypass particular checks. This analogy does not turn these features into authenticated identity or encrypted transport.
Follow one worked example
- Learn the real client binding first.
The client obtains a DHCP address and the switch records its actual MAC, leased IPv4 address, VLAN and ingress port. The exact lease is observed, not assumed.
Why: DAI needs suitable evidence for an untrusted dynamic client before normal ARP traffic can be accepted.
- Keep client and server roles distinct.
The router-facing port is trusted for DHCP replies and for its static gateway ARP. The client-facing port stays untrusted for both features.
Why: Trusting the client would bypass the checks the lesson is supposed to establish.
- Test fresh neighbor resolution after one fault.
Removing only router-facing DAI trust makes its unbound static ARP claim fail validation. Clearing the client's lab neighbor cache forces a fresh test.
Why: An existing neighbor entry can hide an ARP problem; a repeat ping without fresh resolution may not exercise inspection.
Your first small task
On paper, list the client MAC, leased address, VLAN and port that a snooping binding should contain. Then explain why the manually addressed router gateway should not be expected to appear as a DHCP client entry.
Show a hint
Ask which device requested DHCP configuration and which device supplied it.
Check the expected result
The client record includes all four attachment facts; the statically addressed router did not obtain that address through a client lease.
Pause and explain it in your own words
Does ip dhcp snooping trust automatically trust the port for DAI?
Show a hint
The two features inspect different protocols and have separate configuration commands.
Show the explanation
No. DHCP snooping trust and ip arp inspection trust are separate controls. Inspect each state independently; an intended server-facing role may need both in this lab, but a client-facing port should not receive either as a shortcut.
Short answer
What should you understand today?
Port security limits source MAC addresses, DHCP snooping controls DHCP messages and records leases, and Dynamic ARP Inspection validates local IPv4 address claims. They solve different problems and depend on correct port roles. Verify the client's binding before enabling inspection, and never fix a missing binding by trusting every edge port.
Before you begin
Learning targets
- Review VLAN access ports, DHCP leases, IPv4 ARP and console configuration modes.
- Use dedicated Catalyst 9200 IOS XE 17.12 and ISR4321 IOS XE 17.9 hardware with authorized software.
- Use one Ubuntu 22.04 host with dhclient and iproute2 installed, with only its lab NIC managed manually.
- Compare source-MAC limits, DHCP message validation and ARP binding checks.
- Configure and inspect port security, DHCP snooping and DAI on their correct ports.
- Recognize why a static gateway lacks a dynamically learned client binding.
- Repair one server-facing DAI trust error and repeat address-resolution tests.
Words you will meet
Open a word when you need its meaning. You do not need to memorize the whole list before reading.
MAC address and port security
A MAC address identifies a local Ethernet interface. Port security limits which source MAC addresses may enter a switch port; it is not proof of a human identity.
DHCP and snooping
Dynamic Host Configuration Protocol leases IPv4 settings. DHCP snooping filters certain DHCP messages and learns a table linking a client's address, MAC, VLAN, interface and lease.
ARP and DAI
Address Resolution Protocol maps local IPv4 neighbors to MAC addresses. Dynamic ARP Inspection (DAI) checks incoming ARP on untrusted ports against permitted bindings or an explicit ARP policy.
Trusted port
Trust is specific to a feature. DHCP snooping trust permits server-side DHCP messages on that input; DAI trust bypasses ARP validation there. Neither means every attached device is safe.
Binding and VLAN
A binding records a relationship between an address and a local attachment. A VLAN is a separate Layer 2 broadcast domain; this lab uses VLAN 10 on two access ports.
Restrict and error-disabled
Port-security restrict drops violating traffic and reports violations without disabling the whole port. Shutdown mode can place a port in error-disabled state, requiring cause correction before recovery.
Sticky learning
Sticky secure MAC learning adds learned addresses to the running configuration. They persist across restart only if saved appropriately; ordinary dynamic learning is a different state.
Port security constrains sources, not identities
On a static access port, port security can limit the number of allowed source MAC addresses and use static, dynamic or sticky learning. In this one-host lab the maximum is one. That value is not universal: a phone with a downstream PC or a virtualized host can legitimately introduce additional MAC addresses. Choose the limit from the actual port role. A copied MAC address also shows why this control is not a replacement for authenticated access.
- Determine the expected source count before choosing a maximum.
- Sticky entries in running configuration are not automatically saved startup state.
DHCP snooping builds evidence while enforcing roles
Snooping must be enabled globally and for the intended VLAN. Ports start untrusted; the real server-facing port is deliberately trusted. The learned binding connects the client address to its MAC, VLAN and port. It is not the server's own lease database, and it is not simply the switch MAC table. A missing binding may result from enabling snooping after an existing lease was acquired, wrong VLAN selection or a failed DHCP exchange.
- Server-facing trust follows topology, not an arbitrary uplink label.
- A preexisting client lease may require a legitimate renewal before the switch learns it.
DAI checks ARP against permitted relationships
DAI is an ingress feature. On an untrusted port it validates ARP using suitable bindings or an explicitly configured ARP policy; a trusted port bypasses those checks. For our dynamically addressed client, snooping supplies the needed record. The static gateway is different: it does not acquire its interface address through DHCP. We trust only the directly connected, dedicated router port for its ARP traffic in this small topology.
- DAI concerns IPv4 ARP, not IPv6 neighbor discovery.
- A trust bypass is a security boundary decision and needs an explicit reason.
Operational dependencies need a restart plan
Dynamic bindings are operational state. Their persistence across a switch restart needs a supported database-agent design, valid storage and careful platform review. This exercise does not configure or test that persistence. Saving the running switch configuration is not the same as preserving every current binding. Rate limits also matter: legitimate bursts can trigger protection, so arbitrary aggressive limits are not a substitute for measured baselines.
- Do not reboot a protected access network as a diagnostic shortcut.
- Preserve the exact trust state, VLAN and binding evidence with timestamps.
Diagnose a failed ARP exchange without weakening the edge
A host can retain a valid DHCP address while losing gateway reachability. Check the client neighbor cache, DAI counters, current binding and trust states before changing the addressing. In the controlled fault, only the dedicated router port loses DAI trust. Its static gateway address lacks a matching dynamic client binding, so fresh ARP from that router can be rejected. The repair restores the documented router-facing exception, not client trust.
- A valid lease does not prove local address resolution works.
- Remove the known fault and retest before changing unrelated security controls.
Map configuration practice without overstating it
The lesson addresses the three controls named in v1.1 objective 5.7 and the corresponding subset of announced v2.0 objective 4.7. Storm control and RA guard are reserved for Day 52. v1.1 remains current through 2 February 2027; v2.0 begins 3 February. This physical lab is a practical alternative when a virtual switch lacks a supported implementation; the built-in GNS3 Ethernet switch has no equivalent IOS security CLI.
- Record platform and release before interpreting unsupported commands.
- Runtime, independent review and rendered-visual inspection are separate from authored coverage.
Real-world walkthrough
The lease is valid, but the gateway will not answer
In a fictional classroom rollout, a learner enables ARP inspection after verifying DHCP. The client keeps its address, yet a fresh gateway ping fails. A peer suggests trusting the client port. The better investigation checks which ARP messages are being dropped and whether the gateway is statically addressed on a port whose trust state was accidentally changed.
- Preserve the client's actual address, mask, gateway and MAC before assuming DHCP failed.
- Compare the DHCP snooping binding with the client's VLAN and physical port; do not substitute the ordinary MAC table.
- Inspect DAI trust on both used ports and compare drop counters before and after a bounded fresh-ARP test.
- Restore only the known dedicated-router trust exception, keeping the client untrusted.
- Repeat neighbor resolution and gateway ping, and document that no hostile-traffic or performance test was performed.
Guided GNS3 lab
A protected DHCP edge with a reversible DAI fault
Configure port security, DHCP snooping and DAI on a dedicated Catalyst edge and correlate their state with one client. No physical hardware runtime is claimed; these instructions predict observations for an authorized isolated lab.
Addressing plan
| Device | Interface | Address | Purpose |
|---|---|---|---|
| R1 | GigabitEthernet0/0/0 | 192.0.2.1/24 | Static gateway and DHCP server. |
| Client | enp1s0 | DHCP: 192.0.2.100-254/24; gateway 192.0.2.1 | Record the actual allocated address and MAC. |
| SW1 | Gi1/0/1 and Gi1/0/2 | Layer 2 VLAN 10; no IP address required | Separate server trust from untrusted client ingress. |
Set up the lab
- Use only dedicated disconnected equipment. Back up configurations and keep direct serial/USB console access; never use production ports.
- On each Cisco device use its documented console defaults, normally 9600 baud, 8 data bits, no parity, 1 stop bit and no flow control. Verify actual settings and show version.
- On Client, verify enp1s0 with ip -br link and ensure no NetworkManager or networkd DHCP client is managing that lab NIC. Do not stop management services on a real workstation.
- No hardware is available here for execution. Paper alternative: trace lease, binding, ARP validation and the trust fault. Practical alternative: a licensed virtual platform explicitly documenting all three features, with its own port mapping.
- Do not save the experiment over existing startup files. The final good state may be retained only as a dedicated lab configuration; restore the pre-lab backup through a separate approved workflow when dismantling.
Prepare VLAN 10 and both access ports
Open SW1's direct physical console in your terminal application before typing; verify its hostname. Use only the two recorded, otherwise unused lab ports. First inspect their baseline configuration and the software release; stop if either port belongs to an existing service.
enable
show version
configure terminal
vlan 10
exit
interface range GigabitEthernet1/0/1 - 2
switchport mode access
switchport access vlan 10
no shutdown
endWhat each command means
enable- Enter privileged EXEC on this authorized lab device; stop if access is not authorized.
show version- Record the actual switch platform and release.
configure terminal- Enter global configuration from privileged EXEC; changes affect the active configuration.
vlan 10- Create the isolated exercise VLAN.
exit- Return from VLAN configuration to global configuration.
interface range GigabitEthernet1/0/1 - 2- Select exactly the two documented lab ports.
switchport mode access- Set explicit access mode for the lab links.
switchport access vlan 10- Place both untagged links in VLAN 10.
no shutdown- Enable only these isolated interfaces.
end- Return to privileged EXEC without saving or undoing the accepted changes.
- What you should see
- Expect both used ports assigned to VLAN 10; let spanning tree reach forwarding before testing.
- Why this step matters
- Exact port ownership and VLAN membership establish the boundary within which later trust settings are meaningful.
Build the dedicated DHCP server
Open R1's direct physical console in your terminal application before typing; verify its hostname. Use the connected router interface and a fresh DHCP pool. The excluded addresses prevent the server from leasing the gateway or low reserved addresses.
enable
configure terminal
interface GigabitEthernet0/0/0
ip address 192.0.2.1 255.255.255.0
no shutdown
exit
ip dhcp excluded-address 192.0.2.1 192.0.2.99
ip dhcp pool EDGE51
network 192.0.2.0 255.255.255.0
default-router 192.0.2.1
endWhat each command means
enable- Enter privileged EXEC on this authorized lab device; stop if access is not authorized.
configure terminal- Enter global configuration from privileged EXEC; changes affect the active configuration.
interface GigabitEthernet0/0/0- Select the port directly attached to SW1's server-facing access port.
ip address 192.0.2.1 255.255.255.0- Assign the static gateway address on VLAN 10's subnet.
no shutdown- Enable the dedicated router link.
exit- Return to global configuration to define the DHCP service.
ip dhcp excluded-address 192.0.2.1 192.0.2.99- Reserve gateway and low addresses outside the dynamic pool.
ip dhcp pool EDGE51- Create this lab's DHCP address pool.
network 192.0.2.0 255.255.255.0- Declare the pool subnet and mask.
default-router 192.0.2.1- Supply the correct local gateway to clients.
end- Return to privileged EXEC without saving or undoing the accepted changes.
- What you should see
- Expect a pool for this directly attached subnet; no relay is required.
- Why this step matters
- A controlled server must exist before snooping is enabled so its legitimate path can be explicitly trusted.
Enable snooping with a narrow server boundary
Open SW1's direct physical console in your terminal application before typing; verify its hostname. Enable the feature globally and for VLAN 10, then trust only the router-facing port. Disable option-82 insertion only for this simple direct-server lab; keep the client port at its default untrusted state.
configure terminal
ip dhcp snooping
ip dhcp snooping vlan 10
no ip dhcp snooping information option
interface GigabitEthernet1/0/1
ip dhcp snooping trust
end
show ip dhcp snoopingWhat each command means
configure terminal- Enter global configuration from privileged EXEC; changes affect the active configuration.
ip dhcp snooping- Enable global DHCP snooping processing.
ip dhcp snooping vlan 10- Enable inspection and learning for VLAN 10.
no ip dhcp snooping information option- Omit relay-information insertion in this isolated no-relay topology.
interface GigabitEthernet1/0/1- Select the verified direct server connection.
ip dhcp snooping trust- Allow legitimate DHCP server messages arriving on this port.
end- Return to privileged EXEC without saving or undoing the accepted changes.
show ip dhcp snooping- Confirm the VLAN scope and each port's trust role.
- What you should see
- Expect VLAN 10 enabled, Gi1/0/1 trusted and Gi1/0/2 untrusted.
- Why this step matters
- Snooping trust is assigned because of a server role, not because a cable points upward on a diagram.
Acquire and record a real lease
Open Client's local terminal console before typing. Verify enp1s0 is the dedicated lab NIC and no other DHCP process manages it. Acquire a lease, then record all address and neighbor facts.
sudo dhclient -1 -v enp1s0
ip -4 address show dev enp1s0
ip route
ping -c 3 192.0.2.1What each command means
sudo dhclient -1 -v enp1s0- Request one DHCP lease on the isolated Client NIC and show exchange details.
ip -4 address show dev enp1s0- Read the actual IPv4 address and mask rather than assuming the first pool address.
ip route- Inspect the installed gateway route.
ping -c 3 192.0.2.1- Verify basic Client-to-gateway replies before enabling DAI.
- What you should see
- Expect a lease from the declared pool and gateway replies; stop if either is missing.
- Why this step matters
- The observed lease is evidence for later inspection, while the ping establishes a working local baseline.
Confirm binding and configure the protected edge
Open SW1's direct physical console in your terminal application before typing; verify its hostname. Check the binding before enabling DAI. It must show Client's observed MAC and leased IP on VLAN 10, Gi1/0/2. Configure one-source restrict port security there, and separately trust the static gateway port for DAI.
show ip dhcp snooping binding
configure terminal
interface GigabitEthernet1/0/2
switchport port-security
switchport port-security maximum 1
switchport port-security violation restrict
exit
interface GigabitEthernet1/0/1
ip arp inspection trust
exit
ip arp inspection vlan 10
endWhat each command means
show ip dhcp snooping binding- Verify the learned client-to-IP-to-VLAN-to-port relationship.
configure terminal- Enter global configuration from privileged EXEC; changes affect the active configuration.
interface GigabitEthernet1/0/2- Select only the single-client access port.
switchport port-security- Enable source-MAC security on this static access port.
switchport port-security maximum 1- Limit this deliberately single-host port to one secure source.
switchport port-security violation restrict- Drop and report violations without selecting shutdown mode.
exit- Return to global configuration before selecting the server port.
interface GigabitEthernet1/0/1- Select the dedicated static gateway connection.
ip arp inspection trust- Bypass DAI only for ARP arriving from the dedicated router.
exit- Return to global configuration for VLAN-wide inspection.
ip arp inspection vlan 10- Enable DAI on the isolated VLAN after the binding is confirmed.
end- Return to privileged EXEC without saving or undoing the accepted changes.
- What you should see
- Expect both security features configured with the client still untrusted for DHCP and ARP.
- Why this step matters
- The gateway's static address is not a DHCP client binding; its explicit exception has a different reason from the client rule.
Establish a fresh-ARP protected baseline
Open Client's local terminal console before typing. Clear only neighbor entries on the isolated lab NIC, then repeat the gateway test. Do not clear caches or change addresses on other interfaces.
sudo ip neigh flush dev enp1s0
ping -c 3 192.0.2.1
ip neigh show dev enp1s0What each command means
sudo ip neigh flush dev enp1s0- Remove cached local neighbor mappings only on the lab NIC.
ping -c 3 192.0.2.1- Force fresh resolution and test the protected gateway path.
ip neigh show dev enp1s0- Inspect the learned gateway neighbor entry after the test.
- What you should see
- Expect gateway replies and a resolved neighbor while all three controls are configured.
- Why this step matters
- A cached MAC could conceal an ARP inspection problem; a fresh neighbor test exercises the dependency.
Inspect controls and introduce one trust fault
Open SW1's direct physical console in your terminal application before typing; verify its hostname. Record the secure address, binding and DAI counters. Remove only DAI trust from Gi1/0/1, leaving DHCP snooping trust and the client port unchanged. Never apply this fault to a shared uplink.
show port-security interface GigabitEthernet1/0/2
show ip arp inspection statistics vlan 10
configure terminal
interface GigabitEthernet1/0/1
no ip arp inspection trust
endWhat each command means
show port-security interface GigabitEthernet1/0/2- Read the single-client secure state and violation mode.
show ip arp inspection statistics vlan 10- Record the pre-fault DAI counters.
configure terminal- Enter global configuration from privileged EXEC; changes affect the active configuration.
interface GigabitEthernet1/0/1- Select the dedicated router-facing lab port.
no ip arp inspection trust- Introduce the deliberate static-gateway validation fault.
end- Return to privileged EXEC without saving or undoing the accepted changes.
- What you should see
- Expect only the router-facing DAI trust state to change.
- Why this step matters
- The two trust features are separate; keeping DHCP trust intact isolates the ARP validation problem.
Observe the fresh-resolution failure
Open Client's local terminal console before typing. Keep the leased address unchanged and clear the same lab neighbor cache. Repeat only the gateway test so the changed observation can be compared with the protected baseline.
sudo ip neigh flush dev enp1s0
ping -c 3 192.0.2.1
ip neigh show dev enp1s0What each command means
sudo ip neigh flush dev enp1s0- Remove the existing gateway mapping so ARP must run again.
ping -c 3 192.0.2.1- Test the gateway while its static ARP arrives through an untrusted port.
ip neigh show dev enp1s0- Record an unresolved or failed neighbor state if resolution is blocked.
- What you should see
- Expect no successful gateway echo exchange because gateway ARP lacks a permitted binding on that newly untrusted input.
- Why this step matters
- The client can retain a DHCP lease while ARP fails; this is not evidence that the lease service stopped.
Restore the explicit gateway exception
Open SW1's direct physical console in your terminal application before typing; verify its hostname. Compare drop counters, then restore only the known DAI trust setting. Do not trust the client port or turn off DAI globally to recover this path.
show ip arp inspection statistics vlan 10
configure terminal
interface GigabitEthernet1/0/1
ip arp inspection trust
end
show ip arp inspection interfaces
show ip dhcp snooping bindingWhat each command means
show ip arp inspection statistics vlan 10- Compare actual drops against the prior baseline.
configure terminal- Enter global configuration from privileged EXEC; changes affect the active configuration.
interface GigabitEthernet1/0/1- Select the same dedicated router-facing port.
ip arp inspection trust- Restore the intended static-gateway ARP exception.
end- Return to privileged EXEC without saving or undoing the accepted changes.
show ip arp inspection interfaces- Confirm server trust and retained client untrusted state.
show ip dhcp snooping binding- Confirm Client's binding still matches its observed lease.
- What you should see
- Expect the documented trust roles restored; counters may retain historical drops.
- Why this step matters
- The fix targets the known fault while preserving inspection at the untrusted edge.
Retest and close the controlled experiment
Open Client's local terminal console before typing. Clear only the lab neighbor cache again and repeat the identical test. Preserve the baseline, fault and recovery results before any teardown.
sudo ip neigh flush dev enp1s0
ping -c 3 192.0.2.1
ip neigh show dev enp1s0What each command means
sudo ip neigh flush dev enp1s0- Ensure the recovery test also performs fresh address resolution.
ping -c 3 192.0.2.1- Verify recovery through the restored gateway exception.
ip neigh show dev enp1s0- Confirm a usable gateway neighbor entry now exists.
- What you should see
- Expect replies and a resolved gateway neighbor; do not claim this result without observing it.
- Why this step matters
- The same fresh-resolution procedure before and after repair provides a controlled comparison.
Retain only the verified isolated configuration
Open SW1's direct physical console in your terminal application before typing; verify its hostname. Inspect the final controls without adding traffic or saving over a shared startup file. Record that port-security violations and reboot persistence were not tested. Keep the dedicated lab isolated or disconnect its two data cables after documenting final state.
show port-security interface GigabitEthernet1/0/2
show ip dhcp snooping
show ip dhcp snooping binding
show ip arp inspection interfacesWhat each command means
show port-security interface GigabitEthernet1/0/2- Record the learned source and configured restrict mode.
show ip dhcp snooping- Confirm the intended DHCP VLAN and trust scope.
show ip dhcp snooping binding- Preserve the actual client binding evidence.
show ip arp inspection interfaces- Record final DAI trust states on both used ports.
- What you should see
- Expect the good protected baseline restored and the temporary trust fault absent.
- Why this step matters
- A closing record must separate configured features from traffic cases or restart behavior that were not exercised.
Verify
- Require a working client lease and gateway ping before turning on DAI.
- Match actual client MAC, IP, VLAN 10 and Gi1/0/2 across endpoint and snooping evidence.
- Verify port-security mode and learned source separately from DHCP and DAI trust.
- Use identical fresh-neighbor tests before the fault, during it and after restoration.
- Record that attack traffic, port-security violations, rate limits and reboot persistence are unmeasured.
Troubleshoot
- If no binding appears, check global/VLAN snooping, the DHCP exchange and the trusted server port before enabling DAI.
- If Client has a lease but cannot resolve its gateway, inspect DAI drops and the router-facing ARP trust exception; do not trust Client.
- If port security drops legitimate traffic, compare the actual source count and learned MAC with the one-host prerequisite; do not raise limits blindly.
- If hardware syntax differs, stop and consult the actual release guide. GNS3 built-in switching is not a substitute IOS security implementation.
GNS3 does not provide Cisco images. A license or entitlement must permit the image in the selected environment; do not share or redistribute image files. Cisco Modeling Labs is an official alternative. Its supplied Cisco reference images are licensed for use within CML, not automatically for export to GNS3. An unlicensed learner must use the explicitly labeled paper alternative, not report simulated Cisco execution.
- Restore ip arp inspection trust only on the dedicated router-facing port and repeat the gateway test.
- Preserve the known good isolated lab state; disconnect the two data cables when finished so the DHCP service cannot reach other networks.
- For complete teardown, use the saved dedicated pre-lab configuration through its approved recovery method. Do not erase shared equipment or redistribute software.
Practice set
Answer before you reveal
01Which record does DAI use for this dynamic Client?
The ordinary forwarding MAC table alone does not establish the allowed IPv4-to-MAC relationship used in this exercise.
02Why is the router's static address absent from dynamic client bindings?
Static nodes require an explicitly designed policy or justified trusted boundary rather than an assumed dynamic record.
03Does DHCP trust also configure ARP trust?
One permits legitimate DHCP server messages; the other bypasses ARP validation. Inspect both independently.
04Why clear Client's neighbor cache in all three tests?
A cached address can allow traffic without testing the inspection path that the experiment is intended to evaluate.
05Does restrict mode authenticate a user?
MAC-based limits do not prove identity, application permissions or encrypted communication.
06What is missing from a claim of reboot-safe protection here?
Saving configuration is not a substitute for preserving dynamic bindings, and this lesson does not perform a reboot.
Knowledge check
Quiz: prove the reasoning
Keep these
Technical takeaways
- Source-MAC limits, DHCP validation and ARP inspection answer different questions.
- Trust is feature-specific and follows a documented port role.
- Verify the real binding before enabling dependent inspection.
- Static-address devices require deliberate handling, not an assumed DHCP record.
- Force fresh address resolution when testing an ARP-specific fault.
- Restore the narrow known exception while keeping client ports untrusted.