DHCP Snooping Verification

Lab Objectives

• Enable and verify DHCP Snooping on the access switch and confirm the DHCP snooping binding table.
• Demonstrate that a rogue DHCP server on an untrusted port is blocked by DHCP Snooping.
• Practice interpreting verification output to debug DHCP Snooping issues in a small network.

Try to complete the tasks first without the solution. Use ?, show commands and the topology below to investigate.

Base topology (use this exact diagram — IPs and interface names are 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 subnets used in this lab:

• 10.10.10.0/24 — R1 ↔ R2
• 10.10.20.0/24 — R1 ↔ R3
• 10.10.30.0/24 — R1 ↔ R4
• 10.10.40.0/24 — R2 ↔ S1 uplink
• 192.168.1.0/24 — VLAN 10 (Sales)
• 192.168.2.0/24 — VLAN 20 (Engineering)
• 192.168.3.0/24 — VLAN 30 (Management)
• 203.0.113.0/24 — Public/Internet simulation

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: Configure DHCP pools on R2

Create DHCP pools for VLANs 10, 20 and 30 on R2 so that clients in Sales, Engineering and Management can obtain addresses from the correct networks. Use default-router IPs of 192.168.1.1, 192.168.2.1 and 192.168.3.1 respectively.

Task 2: Enable DHCP Snooping on S1 and trust the R2 uplink

Enable DHCP Snooping globally on S1, restrict it to VLANs 10, 20, 30, and mark the uplink towards R2 as a trusted interface (so DHCP offers from the legitimate server are allowed).

Task 3: Verify bindings and test rogue DHCP server blocking

• Verify DHCP snooping bindings on S1.
• Connect a rogue DHCP server to a PC port on S3 (or simulate a server offering leases). Confirm that S1 drops DHCP offers from the rogue server and does not install those bindings.

Think About It: Why must the uplink to the legitimate DHCP server be marked as trusted? What would happen if you mistakenly marked an access port (where end hosts attach) as trusted?

---

Lab Solution

Task 1 Solution: Configure DHCP pools on R2

What we are doing: We create DHCP pools on R2 so it can lease addresses for VLAN 10, 20 and 30. The switch/access-layer devices will forward DHCP requests to R2 (either because R2 is directly connected to those subnets or via relay). The DHCP server needs the network and default-router information to issue correct leases.

R2(config)# ip dhcp pool SALES
R2(dhcp-config)# network 192.168.1.0 255.255.255.0
R2(dhcp-config)# default-router 192.168.1.1
R2(dhcp-config)# exit
R2(config)# ip dhcp pool ENGG
R2(dhcp-config)# network 192.168.2.0 255.255.255.0
R2(dhcp-config)# default-router 192.168.2.1
R2(dhcp-config)# exit
R2(config)# ip dhcp pool MGMT
R2(dhcp-config)# network 192.168.3.0 255.255.255.0
R2(dhcp-config)# default-router 192.168.3.1
R2(dhcp-config)# exit

What each command does and why it matters:

• ip dhcp pool NAME — creates a DHCP pool named NAME. This tells the router to manage leases for that pool.
• network X Y — defines the subnet that the pool will service (addresses to give clients).
• default-router Z — the gateway address handed to clients (critical so clients know their next hop). These are fundamental for the network to assign correct IP configuration to clients.

Verify:

R2# show ip dhcp pool

Expected output (example):

Pool SALES :
  Utilization mark (high/low)    : 100 / 0
  Subnet size (first/next)       : 255.255.255.0
  Total addresses                : 254
  Leased addresses               : 0
Pool ENGG :
  ...
Pool MGMT :
  ...

---

Task 2 Solution: Enable DHCP Snooping on S1 and trust the R2 uplink

What we are doing: Turn on DHCP Snooping on S1 for the VLANs used by clients and mark the interface that faces the legitimate DHCP server (R2) as trusted. Trusted interfaces are allowed to forward DHCP server messages (DHCPOFFER/DHCPACK). Untrusted ports (default) are prevented from sending DHCP server messages.

S1(config)# ip dhcp snooping
S1(config)# ip dhcp snooping vlan 10,20,30
S1(config)# interface GigabitEthernet0/1
S1(config-if)# description Uplink-to-R2
S1(config-if)# ip dhcp snooping trust
S1(config-if)# exit

What each command does and why it matters:

• ip dhcp snooping — enables DHCP Snooping globally on the switch. Without this, no DHCP messages are inspected or filtered.
• ip dhcp snooping vlan 10,20,30 — limits DHCP Snooping operation to those VLANs only; performance-wise you only inspect relevant traffic.
• interface GigabitEthernet0/1 / ip dhcp snooping trust — marks the uplink to R2 as trusted so legitimate DHCP server replies are allowed through. If you forget to trust the real server the switches will drop legitimate DHCP replies and clients won't get leases.

Verify:

S1# show ip dhcp snooping

Expected output (example):

DHCP snooping is enabled
DHCP snooping is configured on following VLANs: 10,20,30
DHCP snooping is operational on following VLANs: 10,20,30
DHCP snooping is configured on the following interfaces:
  GigabitEthernet0/1 trust
DHCP snooping is configured globally, and is enabled on the device
Total number of DHCP snooping bindings: 0

---

Task 3 Solution: Verify bindings and test rogue DHCP server blocking

What we are doing: Confirm DHCP bindings learned from legitimate DHCP server and then demonstrate that a rogue DHCP server on an untrusted port is blocked. The binding table maps client MAC → IP → VLAN → interface. If a rogue server tries to hand out addresses, the switch will drop server-to-client packets on untrusted ports.

To view bindings:

S1# show ip dhcp snooping binding

Expected output (example) after some clients have leased:

MacAddress          IpAddress      Lease(sec)  Type     VLAN  Interface
0011.2233.4455      192.168.1.10   86399       dhcp-snooping 10 GigabitEthernet0/5
00aa.bbcc.ddee      192.168.2.20   86399       dhcp-snooping 20 GigabitEthernet0/6

To see dropped DHCP packets (indicative of blocked rogue server):

S1# show ip dhcp snooping statistics

Expected output (example):

DHCP snooping statistics:
  Total DHCP packets received : 10
  Total DHCP packets dropped  : 2
  Total DHCP packets forwarded: 8
  Packets dropped because of untrusted port : 2

Interpretation:

• Bindings show legitimate leases correlated to access ports (interfaces where clients are connected).
• The statistics report shows packets dropped due to being received on an untrusted port — this is how DHCP Snooping prevents rogue DHCP servers from handing out addresses.

Real-world context: In production networks, DHCP Snooping is used at the access layer to ensure only known DHCP servers (on trusted uplinks) can assign IP configuration. This prevents a compromised laptop or malicious device from acting as a DHCP server and disrupting client connectivity.

---

Troubleshooting Scenario

Scenario: Clients on VLAN 10 cannot obtain IP addresses

Symptom: PC1 and PC2 fail to get IP addresses via DHCP; show ip dhcp snooping shows no bindings for VLAN 10.

Your task: Find and fix the issue.

Hint: Check which interfaces are trusted and where the DHCP server is connected.

Solution:

• On S1, confirm the uplink interface to R2 is actually GigabitEthernet0/1 and that it has ip dhcp snooping trust.
• If you accidentally trusted the wrong port (e.g., a user access port), remove trust from that port and ensure R2 uplink is trusted.

Fix commands:

S1(config)# interface GigabitEthernet0/1
S1(config-if)# ip dhcp snooping trust
S1(config-if)# exit
S1(config)# interface GigabitEthernet0/5
S1(config-if)# no ip dhcp snooping trust

Why this works: If the uplink to R2 is not trusted, legitimate DHCP replies are dropped. Marking R2 uplink as trusted allows server replies through and clients will receive leases.

---

Verification Checklist

• R2 has DHCP pools for VLANs 10,20,30.
• S1 has DHCP Snooping enabled and is configured for VLANs 10,20,30.
• Uplink to R2 on S1 is marked ip dhcp snooping trust.
• show ip dhcp snooping binding lists client MAC/IP/VLAN/interface entries.
• show ip dhcp snooping statistics shows packets dropped from untrusted ports when a rogue DHCP server is present.

Common Mistakes

Symptom	Cause	Fix
No DHCP leases for clients	Legitimate DHCP server uplink not trusted	interface Gi0/1 -> ip dhcp snooping trust on the switch that receives server replies
Rogue DHCP server leases exist	Access port accidentally trusted	no ip dhcp snooping trust on that access interface
No entries in binding table	DHCP Snooping not enabled for the VLAN	ip dhcp snooping vlan 10,20,30
Statistics show many dropped packets	DHCP replies arriving on untrusted uplink (miswired)	Verify physical cabling and trust flags; fix interface trust configuration

Challenge Task

Configure DHCP Snooping across all access switches (S1, S2, S3) and then enable Dynamic ARP Inspection (DAI) using the DHCP Snooping binding database so that ARP spoofing is prevented. Verify that ARP requests from a spoofed MAC are dropped. (No step-by-step provided — use your knowledge from this lesson to extend to DAI.)

Tip: DHCP Snooping provides the authoritative mapping of IP-to-MAC-to-port that many security features (like DAI) rely on in production networks. This is why getting the binding table correct is critical.