Troubleshooting DHCP

Lesson Contents

Troubleshooting DHCP is normally pretty straight forward. Most issues are related to configuration errors (wrong DHCP pools and such). In this lesson I want to show you two DHCP related issues that are a bit harder to solve.

DHCP Service

DHCP Client Server Cisco Routers

We’ll start with a simple scenario. The router on the left side is our DHCP Client and the router on the right side will be our DHCP Server. The Client however is not receiving any IP addresses…what could be wrong?

Let’s verify by checking if the interfaces are up and running:

DHCPClient#show ip interface brief 
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            unassigned      YES DHCP   up                   up  

First I’ll verify if the interface on the DHCP client is up/up and that it has been configured for DHCP, this is indeed the case. Let’s check the DHCP server:

DHCPServer#show ip interface brief 
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            192.168.12.2    YES manual up                   up

I also want to make sure the interface on the DHCP server is up/up and that it has an IP address. This looks fine to me. Let’s start by looking at the DHCP client:

DHCPClient#debug dhcp detail 
DHCP client activity debugging is on (detailed)

If I want to be absolutely sure that the client is not the issue I can enable debug dhcp detail to see if the DHCP client is sending DHCP discover messages. Here’s what we see:

DHCPClient# Hostname: DHCPClient
DHCP: new entry. add to queue, interface FastEthernet0/0
DHCP: SDiscover attempt # 1 for entry:
Temp IP addr: 0.0.0.0  for peer on Interface: FastEthernet0/0
Temp  sub net mask: 0.0.0.0
DHCP Lease server: 0.0.0.0, state: 1 Selecting
DHCP transaction id: 289
Lease: 0 secs,  Renewal: 0 secs,  Rebind: 0 secs
Next timer fires after: 00:00:04
Retry count: 1   Client-ID: cisco-cc00.1ab0.0000-Fa0/0
Client-ID hex dump: 636973636F2D636330302E316162302E
                    303030302D4661302F30

You’ll see some debug output like above. This proves that my DHCP client is sending DHCP Discover messages; the client doesn’t seem to be the problem here. Let’s check the DHCP server:

DHCPServer#show ip dhcp pool 

Pool MYPOOL :
 Utilization mark (high/low)    : 100 / 0
 Subnet size (first/next)       : 0 / 0 
 Total addresses                : 254
 Leased addresses               : 0
 Pending event                  : none
 1 subnet is currently in the pool :
 Current index        IP address range                    Leased addresses
 192.168.12.1         192.168.12.1     - 192.168.12.254    0

We’ll use the show ip dhcp pool command to check if there is a DHCP pool. You can see that we do have a DHCP pool called “MYPOOL” and it’s configured for the 192.168.12.0 /24 subnet. This is looking fine to me. Let’s find out if the DHCP server is doing anything:

DHCPServer#show ip dhcp server statistics 
Memory usage         8754
Address pools        1
Database agents      0
Automatic bindings   0
Manual bindings      0
Expired bindings     0
Malformed messages   0
Secure arp entries   0

Message              Received
BOOTREQUEST          0
DHCPDISCOVER         0
DHCPREQUEST          0
DHCPDECLINE          0
DHCPRELEASE          0
DHCPINFORM           0

Message              Sent
BOOTREPLY            0
DHCPOFFER            0
DHCPACK              0
DHCPNAK              0

We can use show ip dhcp server statistics to see if the DHCP server is doing anything. You can see that it’s not doing anything…what could this mean? Take a look below:

DHCPServer#show ip sockets 
Proto    Remote      Port      Local       Port  In Out Stat TTY OutputIF

This is a command you probably don’t see every day. Show ip sockets shows us on which ports the router is listening. As you can see it’s not listening on any ports…if I don’t see port 67 here (DHCP) it means that the DHCP service has been disabled. Let’s enable it:

DHCPServer(config)#service dhcp

Let’s enable the service. Take a look at the sockets again:

DHCPServer#show ip sockets 
Proto    Remote      Port      Local       Port  In Out Stat TTY OutputIF
 17 0.0.0.0             0 192.168.12.2       67   0   0 2211   0

That’s better! Now we see the router is listening on port 67, this means the DHCP service is active. After a few seconds, the client will receive an IP address:

DHCPClient# %DHCP-6-ADDRESS_ASSIGN: Interface FastEthernet0/0 assigned DHCP address 192.168.12.1, mask 255.255.255.0, hostname DHCPClient

As soon as the DHCP service is running you can see the client receives an IP address through DHCP…problem solved!

Lesson learned: If everything is OK, make sure the DHCP service is running.

DHCP Relay

Let’s try something else, take a look at this topology:

DHCP Client Relay Server Cisco Routers

Take a look at the scenario above. We have 3 routers; the router on the left side is configured as a DHCP client for its FastEthernet 0/0 interface. The router on the right side is configured as a DHCP server. Keep in mind that DHCP discover messages from clients are broadcasted and not forwarded by routers. This is why we require the ip helper command on the router in the middle called relay. The problem in this scenario is that the client is not receiving any IP addresses through DHCP…

First let’s check if the client has been configured to use DHCP:

DHCPClient#show ip int brief
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            unassigned      YES DHCP   up                   up

First we’ll verify that the interface has been configured for DHCP. We can see this by using the show ip interface brief command. To verify that the client will send a DHCP discover message I will do a quick shut / no shut:

DHCPClient(config)#interface fastEthernet 0/0
DHCPClient(config-if)#shutdown
DHCPClient(config-if)#no shutdown

Let’s see if the DHCP server receives the DHCP discover:

DHCPServer#show ip dhcp server statistics 
Memory usage         23054
Address pools        1
Database agents      0
Automatic bindings   1
Manual bindings      0
Expired bindings     0
Malformed messages   0
Secure arp entries   0

Message              Received
BOOTREQUEST          0
DHCPDISCOVER         12
DHCPREQUEST          0
DHCPDECLINE          0
DHCPRELEASE          0
DHCPINFORM           0

Message              Sent
BOOTREPLY            0
DHCPOFFER            12
DHCPACK              0
DHCPNAK              0

We can see that the DHCP Discover messages are received at the DHCP server and that we send DHCP Offer messages in return. This means that the router in the middle has been configured with IP helper otherwise I wouldn’t even receive these messages. DHCP offer messages have been sent but I don’t see any DHCPACK (Acknowledgment) messages. This gives me a clue that something is going on…

Let’s enable a debug on the DHCP server:

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now!

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You’ve Ever Spent on Your Cisco Career!
  • Full Access to our 799 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)
563 Sign Ups in the last 30 days
satisfaction-guaranteed

  • 100% Satisfaction Guaranteed!
  • You may cancel your monthly membership at any time.
  • No Questions Asked!

Tags: ,


Forum Replies

  1. Hi Rene,

    I also noticed that subnet needs to be the same between the “giaddr” and the pool you create. Otherwise DHCP server won’t offer an IP address to the client. Just my observation. Please correct me if I’m wrong. Thanks.

  2. I have setup a dhcp pool on my switch… It will work for maybe 10 min and stop working… Any Idea what is causing the switch to do that…

  3. When an IP has been reserved for a device? What would cause the device not to pick up the reserved IP?

  4. Hello David

    There are no special conditions that would cause a reserved IP to fail to be assigned to the host it was reserved for. The same errors or faults that may be encountered for a normal DHCP assignment may also cause a reserved DHCP assignmnent to fail.

    The only additional error that may occur is a mistake in the configuration of the static binding.

    I hope this has been helpful!

    Laz

4 more replies! Ask a question or join the discussion by visiting our Community Forum