DHCP - Step by Step DHCP Troubleshooting

 

Step by Step DHCP Troubleshooting

 

Understanding Where DHCP Problems Can Occur

DHCP problems can arise due to a multitude of reasons.

 

The most common reasons are configuration issues. However, many DHCP problems can be caused by software defects in operating systems, Network Interface Card (NIC) drivers, or DHCP/BootP Relay Agents running on routers. Due to the number of potentially problematic areas, a systematic approach to troubleshooting is required.

 

Short List of Possible Causes of DHCP Problems:

 

· Catalyst switch default configuration

· DHCP/BootP Relay Agent configuration

· NIC compatibility issue or DHCP feature issue

· Faulty NIC or improper NIC driver installation

· Intermittent network outages due to frequent spanning tree computations

· Operating system behavior or software defect

· DHCP server scope configuration or software defect

· Cisco Catalyst switch or IOS DHCP/BootP Relay Agent software defect

Unicast Reverse Path Forwarding (uRPF) check failing because the DHCP offer is received on a

different interface than expected. When the Reverse Path Forwarding (RPF) feature is enabled on an interface, a Cisco router can drop Dynamic Host Configuration Protocol (DHCP) and BOOTstrap Protocol (BOOTP) packets that have source addresses of 0.0.0.0 and destination addresses of 255.255.255.255. The router can also drop all IP packets that have a multicast IP destination at the interface. This issue is documented in CSCdw31925 (registered customers only).

· DHCP database agent is not used, but DHCP conflict logging is not disabled

 

Start to Troubleshoot:

 

A.    Verify Physical Connectivity

 

First, verify physical connectivity of a DHCP client and server. If connected to a Catalyst switch, verify that both the DHCP client and server have physical connectivity.

 

For IOS based switches command to show port status is show interface <interface>. If the state of the interface is anything other than <interface> is up, line protocol is up, the port will not pass traffic, including DHCP client requests. The output from the commands is as follows:

 

Switch#show interface fastEthernet 0/1

FastEthernet0/1 is up, line protocol is up

Hardware is Fast Ethernet, address is 0030.94dc.acc1 (bia 0030.94dc.acc1)

 

 

Excessive data link errors cause ports on some Catalyst switches to go into an errdisabled state

 

B.    Test Network Connectivity by Configuring Client Workstation with Static IP Address (Client END TS required FSO Support)

 

When troubleshooting any DHCP Issue, it is important to verify network connectivity by configuring a static IP address on a client workstation. If the workstation is unable to reach network resources despite having a statically configured IP address, the root cause of the problem is not DHCP. At this point, network connectivity troubleshooting is required.

 

C.    Verify Issue as a Startup Problem (Client END TS required FSO support)

 

If the DHCP client is unable to obtain an IP address from the DHCP server on startup, attempt to obtain an IP address from the DHCP server by manually forcing the client to send a DHCP request. Issue the following steps to manually obtain an IP address from a DHCP server for the operating systems listed below.

 

Ipconfig/release

Ipconfig/renew

 

If the DHCP client is able to obtain an IP address by manually renewing the IP address after the PC has

Completed the bootup process, the issue is most likely a DHCP startup issue. If the DHCP client is attached to a Cisco Catalyst switch, the problem is most likely due to a configuration issue dealing with STP portfast and/or channeling and trunking. Other possibilities include NIC card issues and switch port startup issues.

 

Troubleshooting Steps D and E should be reviewed to rule out switch port configuration and NIC card issues as the root cause of the DHCP problem.

 

D.    Verify Switch Port Configuration (STP Portfast and Other Commands)

 

If the switch is a Catalyst 2900/4000/5000/6000, verify that the port has STP portfast enabled and

trunking/channeling disabled. The default configuration is STP portfast disabled and trunking/channeling

auto, if applicable. For the 2900XL/3500XL/2950/3550 switches, STP portfast is the only required

configuration. These configuration changes resolve the most common DHCP client issues that occur with an initial installation of a Catalyst switch.

 

E.      Distinguishing whether DHCP Clients Obtain IP Address on the Same Subnet or VLAN as DHCP Server

 

It is important to distinguish whether or not DHCP is functioning correctly when the client is on same subnet or VLAN as the DHCP server. If the DHCP is working correctly on the same subnet or VLAN as the DHCP server, the DHCP issue may be with the DHCP/BootP Relay Agent. If the problem persists even with testing DHCP on the same subnet or VLAN as the DHCP server, the problem may actually be with the DHCP server.

 

F.     Verify Router DHCP/BootP Relay Configuration

 

Issue the steps below to verify the configuration:

 

1.      When configuring DHCP relay on a router or SVI , verify that the ip helper−address command is located on the correct interface. The ip helper−address command must be present on the inbound interface of the DHCP client workstations and must be directed to the correct DHCP server.

 

2.      Verify that the global configuration command no service dhcp is not present. This configuration

parameter will disable all DHCP server and relay functionality on the router. The default

configuration, service dhcp, will not appear in the configuration, and is the default configuration command. If the service dhcp is not enabled, the clients do not receive the IP addresses from the DHCP server.

 

3.      When applying ip helper−address commands to forward UDP broadcasts to a subnet broadcast

address, verify that no ip directed−broadcast is not configured on any outbound interface that the UDP broadcast packets needs to traverse. The no ip directed−broadcast will block on any translation of a directed broadcast to physical broadcasts. This interface configuration is default configuration in software versions 12.0 and higher.

4.      Forwarding DHCP broadcasts to the DHCP server's subnet broadcast address is an occasional

software issue. When troubleshooting DHCP, always attempt to forward DHCP UDP broadcasts to the DHCP server's IP address.

 

G.    Subscriber Identification (82) Option Turned On  (Note : Mostly I have not seen if this using in Anglo )

 

“Option 82 is supposed to be used in distributed DHCP server/relay environment, where relays insert additional information to identify the client’s point of attachment.”

 

The DHCP relay agent information (option 82) feature enables the DHCP relay agents (Catalyst switches) to include information about itself and the attached client when it forwards DHCP requests from a DHCP client to a DHCP server.

 

The DHCP server can use this information to assign IP addresses, perform access control, and set quality of service (QoS) and security policies (or other parameter−assignment policies) for each subscriber of a

service−provider network.

 

When DHCP snooping is enabled on a switch, it automatically enables option 82.

 

If the DHCP server is not configured to handle the packets with option 82, it ceases to allocate the address to that request.

In order to resolve this issue, disable the subscriber identification option (82) in the switches (relay agents) with the global configuration command, no ip dhcp relay information option.

 

H.    DHCP Database Agent and DHCP Conflict Logging

 

A DHCP database agent is any host_for example, an FTP, TFTP, or RCP server_that stores the DHCP

bindings database. You can configure multiple DHCP database agents, and you can configure the interval

between database updates and transfers for each agent. Use the ip dhcp database command to configure a database agent and database agent parameters.

If you choose not to configure a DHCP database agent, disable the recording of DHCP address conflicts on the DHCP server.

 

Execute the no ip dhcp conflict logging command to disable the DHCP address conflict logging. Clear the previously logged conflicts with clear ip dhcp conflict.

 

If this fails to disable the conflict logging, this error message appears:

 

%DHCPD−4−DECLINE_CONFLICT: DHCP address conflict: client

 

I.       Check CDP for IP Phone Connections

 

When the switchport that is connected to the Cisco IP phone has Cisco Discovery Protocol (CDP) disabled, the DHCP server cannot assign an appropriate IP address to the phone. The DHCP server tends to assign the IP address that belongs to the data VLAN / subnet of the switchport. If the CDP is enabled, the switch is able to detect that the Cisco IP Phone requests the DHCP and can provide the correct subnet information. The DHCP server then is able to allot an IP address from the voice VLAN / subnet pool. There are no explicit steps required to bind the dhcp service to the voice vlan.

 

J.     Removing Down SVI Disrupts DHCP Snooping Operation

 

On the Cisco Catalyst 6500 series switches, an SVI (in shutdown state) is created automatically after it

configures the DHCP to snoop for a particular VLAN. The presence of this SVI has direct implications on the correct operation of DHCP snooping.

 

DHCP snooping on the Cisco Catalyst 6500 series switches that run Native IOS is implemented mostly on Route Processor (RP or MSFC), not on Switch Processor (SP or Supervisor). The Cisco Catalyst 6500 series intercepts packets in hardware with VACLs that supply the packets to a Local Target Logic (LTL) subscribed to by the RP. Once the frames enter the RP, they first need to be associated with an L3 Interface (SVI) IDB before they can be passed off to the snooping part. Without an SVI, this IDB does not exist, and the packets get dropped in the RP.

 

K.    Limited Broadcast Address

 

When a DHCP client sets the broadcast bit in a DHCP packet, the DHCP server and relay agent send DHCP messages to clients with the all−ones broadcast address (255.255.255.255). If the ip broadcast−address command has been configured to send a network broadcast, the all−ones broadcast sent by DHCP is overridden. In order to remedy this situation, use the ip dhcp limited−broadcast−address command to ensure that a configured network broadcast does not override the default DHCP behavior.

 

Some DHCP clients can only accept an all−ones broadcast and are not able to acquire a DHCP address unless this command is configured on the router interface connected to the client.

 

L.     Debugging DHCP Using Router debug Commands (Best Part for Advance TS DHCP but careful for doing this)

 

Verify Layer 3 Switch is Receiving DHCP Request Using debug Commands

 

On Layer 3 Switch that support software processing of DHCP packets, you can verify whether a switch is receiving the DHCP request from the client. The DHCP process will fail if the Switch is not receiving requests from the client.

 

This troubleshooting step involves configuring an access−list for debugging output. This access−list is for debugging purposes only and is not intrusive to the Switch.

 

In global configuration mode, enter the following access−list:

access−list 100 permit ip host 0.0.0.0 host 255.255.255.255

 

In exec mode, enter the following debug command:

 

debug ip packet detail 100

 

(Note: Debug ip packet detail command is dangers to use in production environment use carry fully)

 

Sample output:

 

Switch#debug ip packet detail 100

IP packet debugging is on (detailed) for access list 100

Switch#

 

00:16:46: IP: s=0.0.0.0 (Ethernet4/0), d=255.255.255.255, len 604, rcvd 2

00:16:46: UDP src=68, dst=67

00:16:46: IP: s=0.0.0.0 (Ethernet4/0), d=255.255.255.255, len 604, rcvd 2

00:16:46: UDP src=68, dst=67

 

From the output above, it is clear that the router is receiving the DHCP requests from the client. This output only shows a summary of the packet and not the packet itself. Therefore, it is not possible to determine if the packet is correct. Nevertheless, the router did receive a broadcast packet with the source and destination IP and UDP ports that are correct for DHCP.

 

Verify Router or Layer 3 switch is Receiving DHCP Request and Forwarding Requests to DHCP Server Using debug

Commands

 

Additional entries in the access−list can be added to see if the router is communicating successfully with the DHCP server. Again, these debugs do not look into the packet, but you can confirm whether or not the DHCP relay agent is forwarding requests to the DHCP server.

 

In global configuration mode, create the following access−list:

 

access−list 100 permit ip host 0.0.0.0 host 255.255.255.255

access−list 100 permit udp host <dhcp_relay_agent> host <dhcp_server> eq 67

access−list 100 permit udp host <dhcp_server> host <dhcp_relay_agent> eq 67

 

For example:

access−list 100 permit ip host 0.0.0.0 host 255.255.255.0

access−list 100 permit udp host 192.168.1.1 host 192.168.2.2 eq 67

access−list 100 permit udp host 192.168.1.1 host 192.168.2.2 eq 68

access−list 100 permit udp host 192.168.2.2 host 192.168.1.1 eq 67

access−list 100 permit udp host 192.168.2.2 host 192.168.1.1 eq 68

 

In exec mode, enter the following debug command:

 

Router#

00:23:44: IP: s=0.0.0.0 (Ethernet4/0), d=255.255.255.255, len 604, rcvd 2

00:23:44: UDP src=68, dst=67

!−−− Router receiving DHCPDISCOVER from DHCP client.

00:23:44: IP: s=192.168.1.1 (local), d=192.168.2.2 (Ethernet4/1), len 604, sendg

00:23:44: UDP src=67, dst=67

!−−− Router forwarding DHCPDISCOVER unicast to DHCP server using DHCP/BootP Relay Agent source 00:23:44 IP: s=192.168.2.2 (Ethernet1), d=192.168.1.1, len 328, rcvd 4

00:23:44 UDP src=67, dst=67

!−−− DHCP server sending DHCPOFFER to DHCP/BootP Relay Agent.

00:23:44: IP: s=0.0.0.0 (Ethernet4/0), d=255.255.255.255, len 604, rcvd 2

00:23:44: UDP src=68, dst=67

!−−− Router receiving DHCPREQUEST from DHCP client.

00:23:44: IP: s=192.168.1.1 (local), d=192.168.2.2 (Ethernet4/1), len 604, sendg

00:23:44: UDP src=67, dst=67

!−−− Router forwarding DHCPDISCOVER unicast to DHCP server using DHCP/BootP Relay Agent source 00:23:44 IP: s=192.168.2.2 (Ethernet1), d=192.168.1.1, len 328, rcvd 4

00:23:44 UDP src=67, dst=67

!−−− DHCP server sending DHCPACK back to DHCP/BootP Relay Agent.

 

From the output above, it is clear that the router is receiving the DHCP requests from the client and

forwarding the request, per the DHCP/BootP Relay Agent configuration, to the DHCP server. The DHCP

server also replied directly to the DHCP/BootP Relay Agent. This output only shows a summary of the packet and not the packet itself. Therefore, it is not possible to determine if the packet is correct or whether the server is replying with a DHCPNAK. Nevertheless, the router did receive a broadcast packet with the source and destination IP and UDP ports that are correct for DHCP, and there is two−way communication with the DHCP server

 

Verify Router or Layer 3 Switch is Receiving and Forwarding DHCP Request Using debug ip udp Command

 

The debug ip udp command can be used to trace the path of a DHCP request through a router. However, this debug is intrusive in a production environment, since all processed switched UDP packets will be displayed to the console. This debug should not be used in production.

 

Warning: The debug ip udp command is intrusive, and may cause high Central Processing Unit

(CPU) utilization.

 

Verify Router or Layer 3 Switch is Receiving and Forwarding DHCP Request Using debug ip dhcp server packet Command

 

If the router IOS is 12.0.x.T or 12.1 and supports the IOS DHCP server functionality, additional debugging can be done using the debug ip dhcp server packet command. This debug was intended for use with the IOS DHCP server feature, but can be used for troubleshooting the DHCP/BootP Relay Agent feature as well. As with the previous troubleshooting steps, router debugs do not provide an exact determination of the problem since the actual packet cannot be viewed. However, debugs do allow inferences to be made regarding DHCP processing.

 

In exec mode, enter the following debug command:

 

debug ip dhcp server packet

 

Router#debug ip dhcp server packet

00:20:54: DHCPD: setting giaddr to 192.168.1.1.

!−−− Router received DHCPDISCOVER/REQUEST/INRORM and setting Gateway IP address to 192.168.1.1 00:20:54: DHCPD: BOOTREQUEST from 0063.6973.636f.2d30.3065.302e.3165.6632.2e63..

!−−− BOOTREQUEST includes DHCPDISCOVER, DHCPREQUEST, and DHCPINFORM.

!−−− 0063.6973.636f.2d30.3065.302e.3165.6632.2e63 indicates client identifier.

00:20:54: DHCPD: forwarding BOOTREPLY to client 00e0.1ef2.c441.

!−−− BOOTREPLY includes DHCPOFFER and DHCPNAK.

!−−− Client's MAC address is 00e0.1ef2.c441.

00:20:54: DHCPD: broadcasting BOOTREPLY to client 00e0.1ef2.c441.

!−−− Router is forwarding DHCPOFFER or DHCPNAK broadcast on local LAN interface.

00:20:54: DHCPD: setting giaddr to 192.168.1.1.

!−−− Router received DHCPDISCOVER/REQUEST/INFORM and set Gateway IP address to 192.168.1.1 00:20:54: DHCPD: BOOTREQUEST from 0063.6973.636f.2d30.3065.302e.3165.6632.2e63..

!−−− BOOTREQUEST includes DHCPDISCOVER, DHCPREQUEST, and DHCPINFORM.

!−−− 0063.6973.636f.2d30.3065.302e.3165.6632.2e63 indicates client identifier.

00:20:54: DHCPD: forwarding BOOTREPLY to client 00e0.1ef2.c441.

!−−− BOOTREPLY includes DHCPOFFER and DHCPNAK.

!−−− Client's MAC address is 00e0.1ef2.c441.

00:20:54: DHCPD: broadcasting BOOTREPLY to client 00e0.1ef2.c441.

!−−− Router is forwarding DHCPOFFER or DHCPNAK broadcast on local LAN interface.

 

 

 

 

END___________