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___________
No comments:
Post a Comment