Lab ts-ips-01 - Troubleshooting DHCP and NAT Tickets

DHCP and NAT are the two services a help desk hears about most, because when either breaks, users notice immediately: no address, or no internet. Both fail in quiet, specific ways where the configuration looks fine until you read the one counter or one interface flag that gives it away. This lab gives you three IP Services tickets on the five-node base topology. It is part of the PingLabz CCNA Troubleshooting Labs, fits Cisco Modeling Labs Free, and every output was captured on Cisco IOS XE.

The topology and healthy state

R2 is the border router. Its LAN side (Ethernet0/0, 10.20.0.0/24) is the inside; its link to R3 (Ethernet0/1, 10.30.30.0/30) is the outside. R3's loopback 10.255.0.3 stands in for an internet host. R2 also runs a DHCP server for the LAN and PAT overload toward the outside. Two devices share the LAN: R1 is a statically addressed inside host at 10.20.0.1 (it stands in for a server you test the internet path from), and HOST1 is the DHCP client that pulls its address from R2. Healthy, the inside host reaches the internet and gets translated:

R1# ping 10.255.0.3 source 10.20.0.1
!!!!!
Success rate is 100 percent (5/5)

R2# show ip nat translations
Pro Inside global      Inside local    Outside local   Outside global
icmp 10.30.30.1:1024   10.20.0.1:2     10.255.0.3:2    10.255.0.3:1024

Lab setup: this topology boots with all three faults already in place. The DHCP fault is independent, but the two NAT faults stack: fixing the first NAT problem will not restore the internet by itself, because the second is still in the way. Read the counters after each change instead of assuming one fix is the whole story.

What you will learn

• How to read show ip dhcp pool to see why a server is handing out nothing, and how to confirm a lease from the server side.
• The two NAT failures that look identical from the client but are one line apart in the config.
• Why show ip nat statistics is the first command for any "no internet" NAT ticket.
• How to separate a NAT interface problem from a NAT ACL problem in one look.

Ticket 1: "HOST1 can't get an IP"

Reported symptom: "The new machine on the LAN isn't getting an address. The DHCP server is up."
Success criterion: a client on the LAN gets an address from the pool.

HOST1 is the DHCP client, and it is the device that cannot get a lease. Since you cannot always log into an end host, diagnose from the server, which is where the answer is anyway. The interface is up and asking, so the question is what the server has to offer. Read the pool:

R2# show ip dhcp pool
Pool LAN-POOL :
 Total addresses                : 254
 Leased addresses               : 0
 Excluded addresses             : 254
 Current index   IP address range            Leased/Excluded/Total
 0.0.0.0         10.20.0.1   - 10.20.0.254    0     / 254   / 254

Every address in the scope is excluded. The binding table confirms the server has handed out nothing:

R2# show ip dhcp binding
Bindings from all pools not associated with VRF:
IP address      Client-ID/Hardware address/User name   Lease expiration   Type   State   Interface
   (none)