Rate Limiting and Trust

Lab Objectives

• Enable and secure DHCP Snooping on access switches and mark uplinks as trusted so only legitimate DHCP replies reach clients.
• Understand how rate limiting on untrusted ports (conceptually for ARP-based protections) prevents spoofing floods and how to handle false positives in production.
• Verify DHCP client behavior by forcing DHCP lease release/renew and confirming bindings.

Lab Tasks (Try It Yourself First!)

Complete these tasks WITHOUT looking at the solution below. Use ? and show commands to figure it out.

Task 1: Enable DHCP Snooping Globally and per-VLAN

Enable DHCP snooping on each access switch for VLANs 10, 20 and 30. Also disable DHCP Option 82 insertion (the network’s DHCP server does not support Option 82).

Task 2: Mark Uplink Interfaces as Trusted

On each access switch, configure the interface that connects to the upstream router/switch (the uplink) as a DHCP snooping trusted port so DHCP server replies can pass. Leave PC-facing access ports untrusted.

Task 3: Test DHCP Assignment from Clients

On PC1 and PC3 (devices in VLANs 10 and 20), run a release then renew to force DHCP activity and confirm they receive the correct addresses from the network DHCP server.

Think About It: If an access port is configured as trusted by mistake, what kinds of attacks or accidental failures might that allow? Conversely, why would overly aggressive rate limiting on untrusted ports cause legitimate devices to lose connectivity?

---

Lab Solution

Base Topology (exact)

                [Internet]
               203.0.113.1
                    |
               R1 (Gateway)
              Gi0/0: 10.10.10.1
              Gi0/1: 10.10.20.1
              Gi0/2: 10.10.30.1
              /     |     \
           R2      R3      R4

Gi0/0: 10.10.10.2 | Gi0/0: 10.10.30.2 Gi0/1: 10.10.40.1 | / \ | S1 S2 S3 / \ | /
PC1 PC2 PC3 PC4 PC5

IP SCHEME (used in verification)

• VLAN 10 (Sales): 192.168.1.0/24
• VLAN 20 (Engineering): 192.168.2.0/24
• VLAN 30 (Management): 192.168.3.0/24

---

Task 1 Solution: Enable DHCP Snooping Globally and per-VLAN

What we are doing: We enable the switch to inspect DHCP traffic and build a binding table of client MAC/IP info. Disabling Option 82 insertion is required when the DHCP server cannot process option 82.

! On each access switch (S1, S2, S3)
ip dhcp snooping
ip dhcp snooping vlan 10,20,30
no ip dhcp snooping information option

What the commands do and why they matter:

• ip dhcp snooping — Enables DHCP snooping globally. This allows the switch to monitor DHCP messages and track which ports lease which IPs (the binding table). In production this prevents rogue DHCP servers from handing out bad IP information.
• ip dhcp snooping vlan 10,20,30 — Limits DHCP snooping operation to the specified VLANs where clients exist; reduces processing and keeps the binding table relevant.
• no ip dhcp snooping information option — Prevents the switch from inserting DHCP Option 82 (circuit ID). Use this when the DHCP server does not accept option 82; inserting it could break DHCP in your environment.

Verify:

show ip dhcp snooping

Expected output (excerpted and annotated):

Switch# show ip dhcp snooping
DHCP snooping is enabled
DHCP snooping is enabled on the following VLANs:
10,20,30
DHCP snooping is configured to insert option 82: NO
DHCP snooping binding database is not configured
Trusted VLANs: 10,20,30

Tip: If you do not see the VLANs listed, ensure the VLANs exist on the switch with show vlan brief and that SVI/port VLAN assignment is correct.

---

Task 2 Solution: Mark Uplink Interfaces as Trusted

What we are doing: We set the uplink ports that connect toward R1/R2/R3 as DHCP snooping trusted, allowing DHCP server responses to traverse those ports. Access-facing ports remain untrusted to block rogue DHCP replies from end hosts.

! On S1: assume Gi0/1 is uplink toward R2
interface Gi0/1
 ip dhcp snooping trust

! On S2: assume Gi0/1 is uplink toward R3
interface Gi0/1
 ip dhcp snooping trust

! On S3: assume Gi0/1 is uplink toward R4 (or toward R1 aggregation)
interface Gi0/1
 ip dhcp snooping trust

What the commands do and why they matter:

• interface Gi0/1 selects the physical interface.
• ip dhcp snooping trust marks that interface as trusted for DHCP messages. Trusted ports are typically upstream toward DHCP servers or relay agents. This is crucial because DHCP server replies (DHCPOFFER/DHCPACK) must be allowed from those directions. If you mistakenly mark an access port as trusted, an attacker could run a rogue DHCP server there and hand out malicious IP/gateway/DNS information.

Verify:

show ip dhcp snooping

Expected relevant section:

DHCP snooping is enabled
Trusted interfaces:
  Gi0/1 (vlan 10,20,30)
  ...other trusted ports...

Also verify the port trust state:

show running-config interface Gi0/1

Expected:

interface Gi0/1
 ip dhcp snooping trust

---

Task 3 Solution: Test DHCP Assignment from Clients

What we are doing: Force clients to release and renew their DHCP leases so DHCP snooping can observe assignments and populate the binding table.

On Windows clients (PC1, PC3):

• ipconfig /release
• ipconfig /renew

What the steps do and why they matter:

• ipconfig /release tells the client to drop its current DHCP lease — useful to simulate fresh address assignment.
• ipconfig /renew requests a new lease. The switch inspects DHCP traffic and creates entries in the binding table so we can correlate MAC ↔ IP ↔ VLAN ↔ Port. In production, this binding prevents IP spoofing and is used by other security features.

Verify:

show ip dhcp snooping binding

Expected sample output:

Switch# show ip dhcp snooping binding
MacAddress          IpAddress      Lease(sec)  Type  VLAN  Interface
a1b2.c3d4.e5f6      192.168.1.10   86398       dhcp  10    Gi0/2
a7b8.c9d0.e1f2      192.168.2.11   86399       dhcp  20    Gi0/3

If entries appear for PC1/PC3 with the correct VLAN and interface, DHCP snooping is working as intended.

---

Troubleshooting Scenario

Scenario: PC3 does not receive an IP after ipconfig /renew

Symptom: PC3 shows APIPA (169.254.x.x) or no IP after renew.
Your task: Find and fix the issue.
Hint: Check whether the switch port toward the DHCP server is trusted and review the switch binding table.

Solution:

1. On the access switch connected to PC3, run:

show ip dhcp snooping
show ip dhcp snooping binding
show running-config interface Gi0/1

2. If uplink Gi0/1 is not listed as trusted, configure:

interface Gi0/1
 ip dhcp snooping trust

3. Re-run ipconfig /renew on PC3. The DHCP offer should now pass and an entry appear in the binding table. Explanation: DHCP replies are blocked on untrusted ports; marking the uplink as trusted allows legitimate server replies.

Warning: Do not mark random access ports as trusted to avoid enabling rogue DHCP servers.

---

Verification Checklist

• DHCP snooping globally enabled on each switch.
• VLANs 10, 20, 30 configured for DHCP snooping.
• Uplink interfaces toward upstream routers/switches are marked ip dhcp snooping trust.
• DHCP bindings present in show ip dhcp snooping binding for client MAC/IPs.

Common Mistakes

Symptom	Cause	Fix
Clients receive no DHCP address	Uplink not trusted — DHCP server replies blocked	Configure ip dhcp snooping trust on uplink interface
DHCP bindings empty after renew	DHCP snooping disabled or wrong VLANs configured	Enable ip dhcp snooping and ip dhcp snooping vlan 10,20,30
Rogue DHCP server hands out addresses	Access port mistakenly marked trusted	Remove ip dhcp snooping trust from access ports; only trust uplinks

Challenge Task

Implement a mitigation strategy that limits the rate of DHCP-related or ARP-related traffic on untrusted ports to protect against floods, but avoid blocking legitimate bursts (e.g., during mass-boot). Design the policy: decide which ports to trust, which VLANs to limit, and how to adjust thresholds for noisy environments. Document your tuning rationale and test by generating burst traffic from multiple clients.

Real-world insight: In production networks, you typically mark uplinks as trusted and apply rate limits on access ports so a misbehaving device cannot flood the control plane. If legitimate events (e.g., many devices booting in a lab) trip limits, temporarily increasing the threshold or briefly trusting a port can resolve false positives. Think of trust like a VIP pass — it tells the switch "this direction is allowed to carry server responses."