Back to Learning
CCNA · 200-301Intermediate

IOS DHCP Server: The Pool That Leased the Gateway

An IOS DHCP pool handed a client the router’s own gateway address. Diagnose the missing exclusion and clear the fallout yourself, live, right below.

Interactive simServicesDHCPAddressing

Symptom

Most clients on the subnet are perfectly fine. One has an address conflict, and the reason is that the pool was allowed to hand out the router's own gateway address.

Your mission

Prove the cause, then fix it

Format

Guided CLI investigation

IOS DHCP Server: The Pool That Leased the Gateway

Investigate before you configure.

Use the CLI evidence to isolate the fault, make the smallest safe correction, then verify the network state changed.

Observe the symptom and link state.

Diagnose by comparing the protocol evidence.

Verify the expected device state and confirm the original symptom is resolved.

Console access: R1

This workspace stacks for portrait phones. Rotate to landscape for the full split-screen console.

Need a hint?

Reveal the root cause when you're ready.

Try the investigation first, then use this as your escape hatch, not a dead end.

Locked

Sign up with your email to open IOS DHCP Server: The Pool That Leased the Gateway, free. You get the root cause and the full step-by-step fix.

No spam. The fix lands in your inbox too. Signing up includes 4 guided labs free, tracked against your email. After that, the Learning Pass unlocks every remaining lab.

Lab debrief

Turn the session into a repeatable troubleshooting pattern.

Use this reference after your attempt: first explain the symptom, then verify the evidence, then confirm the repair.

The problem

R1 is the DHCP server for VLAN 10 on 192.168.10.0/24. Most clients work normally. One user has an IP address conflict, and several report that anything off their own subnet drops out intermittently. The pool, the trunk and the interface all look correctly configured.

What you'll practice

  • Read the addresses in a DHCP binding table rather than the count
  • Recognise an address conflict as a symptom of pool overlap
  • Reserve infrastructure addresses with ip dhcp excluded-address
  • Clear the operational state that a configuration change does not undo

1. Why some clients work and one does not

A pool that overlaps infrastructure only breaks the client unlucky enough to be handed the overlapping address. Everyone else is fine. You will learn to read a mixed picture like that as pool overlap rather than as a failing DHCP service.

2. Nothing is reserved unless you reserve it

ip dhcp excluded-address is global configuration and applies to every pool on the router. Without it a pool will happily lease the router's own address, the HSRP virtual address, or a printer. You will see why reserving a block at the bottom of every user subnet is the convention.

3. Configuration does not undo operational state

Adding the exclusion stops the next bad lease but does not reclaim the one already issued or clear the recorded conflict. You will clear both explicitly, which is a habit that applies well beyond DHCP.

The topology

R1 routes and serves DHCP for VLAN 10 on 192.168.10.0/24, holding the gateway address 192.168.10.1 on its Gi0/0.10 subinterface.

Commands to run yourself

The real diagnostic commands for this lab, copy-paste ready. Run these in the same order to reproduce the investigation on your own session.

Read what was leased
show ip dhcp binding
Check for conflicts
show ip dhcp conflict
Read the pool configuration
show running-config | section dhcp

Topology diagram

Frequently asked

Why is only one client affected if the pool is wrong for the whole subnet?

Because the pool only hands out one address at a time, and only the client that received the overlapping address has a problem. Every client that got a higher address is completely unaffected. That partial picture is the tell: a genuinely broken DHCP service fails everyone, while a pool that overlaps infrastructure fails whoever happens to draw the bad address.

Does show ip dhcp pool tell me whether addresses are excluded?

No, and that is worth knowing before you go looking. On IOS the pool view reports the total and leased counts and is completely unchanged by adding an exclusion. Confirm exclusions with show running-config | section dhcp instead, where they appear as global lines above the pool block.

Why clear the binding and the conflict after fixing the configuration?

The exclusion only governs future allocations. The client that already holds the gateway address keeps it until its lease expires or you clear the binding, and the conflict the server recorded stays in the conflict table until you clear that too. Configuration and operational state are separate, and fixing one does not tidy the other.

Ready to run this lab yourself?

No setup, no image sourcing. Book a session or ask for a live demo.