DHCP Troubleshooting Cisco Commands

DHCP Troubleshooting Cisco Commands

It explains DHCP Troubleshooting, how to adopt a systematic approach to problem solving, due to the number of potentially problematic areas. Also how to verify possible DHCP configuration errors using Cisco Commands.
DHCP problems may arise due to various reasons, such as software defects in operating systems, NIC drivers or DHCP relay agents. However, the most frequent cause is configuration problems. Due to the number of potentially problematic areas, a systematic approach to problem solving is required, as shown in the following table:

Task No.	Description
Task 1 of troubleshooting:	Resolve address conflicts.
Task 2 of troubleshooting:	Verify physical connectivity.
Task 3 of troubleshooting:	Test with a static IPv4 address.
Task 4 of troubleshooting:	Verify switch port configuration.
Task 5 of troubleshooting:	Test from the same subnet or VLAN.
DHCP Troubleshooting Table.

DHCP Troubleshooting tasks

• TASK 1: RESOLVE IPV4 ADDRESS CONFLICTS

Leasing an IPv4 address may expire on a client that is still connected to a network. If the client does not renew the lease, the DHCP server can reassign that IPv4 address to another client. When the client restarts, it requests an IPv4 address. If the DHCP server does not respond quickly, the client uses the last IPv4 address. The problem arises when two clients use the same IPv4 address, which creates a conflict.

The show ip dhcp conflict command   shows all address conflicts that register the DHCP server, as shown in the following result. The server uses the ping command   to detect clients. The client uses the address resolution protocol (ARP) to detect conflicts. If an address conflict is detected, the latter is removed from the pool and is not assigned until an administrator resolves the conflict.

R1 # show ip dhcp conflict

IP address Detection Method Detection time

192.168.10.32 Ping Feb 16 2013 12:28 PM

192.168.10.64 Gratuitous ARP Feb 23 2013 08:12 AM

This result shows the IP addresses that have conflicts with the DHCP server. Shows the detection method and detection time for conflicting IP addresses offered by the DHCP server.

• TASK 2: VERIFY PHYSICAL CONNECTIVITY

First, use the  show interfaces interface  command  to confirm that the router interface that functions as the default gateway for the client is operational. If the interface has another state that is not activated, the port does not pass traffic, even DHCP client requests.

• TASK 3: TEST CONNECTIVITY USING A STATIC IP ADDRESS

When solving any DHCP problem, verify network connectivity by configuring static IPv4 address information on a client workstation. If the workstation cannot reach network resources with a statically configured IPv4 address, the root cause of the problem is not DHCP. At this point, it is necessary to solve network connectivity problems.

• TASK 4: VERIFY SWITCH PORT CONFIGURATION

If the DHCP client cannot obtain an IPv4 address from the DHCP server during startup, try to obtain an IPv4 address from the DHCP server by manually forcing the client to send a DHCP request.

Note : If there is a switch between the client and the DHCP server and the client cannot obtain the DHCP configuration, the cause may be problems with the switch port configuration. These causes may include trunk and pipeline problems, STP and RSTP. PortFast and perimeter configurations solve the most common DHCPv4 client problems that occur with an initial installation of a Cisco switch.

• TASK 5: TEST THE OPERATION OF DHCPV4 ON THE SAME SUBNET OR VLAN

It is important to distinguish whether DHCPv4 works correctly when the client is on the same subnet or VLAN as the DHCPv4 server. If DHCPv4 works correctly when the client is on the same subnet or VLAN, the problem may be the DHCP relay agent. If the problem persists even with the DHCPv4 test on the same subnet or VLAN as the DHCPv4 server, there may actually be a problem with the DHCPv4 server.

Verification of the router's DHCPv4 configuration

When the DHCPv4 server is located on a LAN other than that of the client, the router interface that interacts with the client must be configured to relay DHCPv4 requests by configuring the help IPv4 address. If the help IPv4 address is not configured correctly, DHCP client requests are not forwarded to the DHCPv4 server.

Follow these steps to verify the router configuration:

• Step 1:  Verify that the ip helper-address command   is configured on the correct interface. This command must be present on the LAN input interface that contains the DHCPv4 client workstations and must be directed to the correct DHCPv4 server. In the illustration, the result of the show running-config command   verifies that the DHCP4 relay IPv4 address refers to the DHCPv4 server address in 192.168.11.6.

The show ip interface command can also be used to verify DHCP re-transmission on an interface.

• Step 2:  Verify that the global no service dhcp configuration command has not been configured  . This command disables all functionality of the DHCP server and router relay. The service dhcp command   does not appear in the running configuration, because it is the default configuration

In the illustration, the  show running-config | include no service dhcp  verifies that the DHCPv4 service is enabled, because there is no match for the  show running-config | include no service dhcp . If the service had been disabled, the result would show the no service dhcp command  .

R1 # show running-config | interface GigabitEthernet0 / 0
interface GigabitEthernet0 / 0
 ip address 192.168.10.1 255.255.255.0
 ip helper-address 192.168.11.6
 auto duplex
 speed auto
R1 #

R1 # show running-config | include no service dhcp

Debugging DHCP

On routers configured as DHCP servers, the DHCP process fails if the router does not receive requests from the client. As a troubleshooting task, verify that the router receives the DHCP request from the client. This troubleshooting step includes the configuration of an ACL for debugging.

The illustration shows an extended ACL that allows only packets with UDP destination ports of 67 or 68. These are the typical ports used by DHCP clients and servers when sending DHCP messages. The extended ACL is used with the debug ip packet command   to display only DHCP messages.

R1 (config) # access-list 100 permit udp any any eq 67
R1 (config) # access-list 100 permit udp any any eq 68
R1 (config) # end
R1 # debug ip packet 100 
IP packet debugging is on for access list 100
* IP: s = 0.0.0.0 (GigabitEthernet0 / 1), d = 255.255.255.255,
Len 333, rcvd 2
* IP: s = 0.0.0.0 (GigabitEthernet0 / 1), d = 255.255.255.255,
len 333, stop process pak for forus packet
* IP: s = 192.168.11.1 (local), d = 255.255.255.255
(GigabitEthernet0 / 1), len 328, sending broad / multicast

The result shown in the illustration shows that the router receives DHCP requests from the client. The source IP address is 0.0.0.0, because the client does not yet have an IP address. The destination is 255.255.255.255, because the client's DHCP detection message is sent as broadcast. In this result, only a summary of the package is shown, and not the DHCPv4 message itself. However, the router received a broadcast packet with the appropriate source and destination UDP and IP ports for DHCPv4. In the result of complete debugging, all packets in DHCPv4 communications between the client and the DHCPv4 server are displayed.

Another useful command to perform troubleshooting of DHCPv4 operation is the debug ip dhcp server events command  . This command reports server events, such as address assignments and database updates.

R1 # debug ip dhcp server events
DHCPD: returned 192.168.10.11 to address pool LAN-POOL-1
DHCPD: assigned IP address 192.168.10.12 to client
0100.0103.85e9.87.
DHCPD: checking for expired leases.
DHCPD: the lease for address 192.168.10.10 has expired.
DHCPD: returned 192.168.10.10 to address pool LAN-POOL-1