What is one indication that a windows computer did not receive an ipv4 address from a dhcp server

Table of Contents Show

Troubleshooting checklist
Data collection
DHCP Server log
Network trace

Article
2 minutes to read

This article discusses how to troubleshoot problems that occur on the DHCP server.

Troubleshooting checklist

Check the following settings:

The DHCP server service is started and running. To check this setting, run the net start command, and look for DHCP Server.
The DHCP server is authorized. See Windows DHCP Server Authorization in Domain Joined Scenario.
Verify that IP address leases are available in the DHCP server scope for the subnet the DHCP client is on. To do this, see the statistic for the appropriate scope in the DHCP server management console.
Check whether any BAD_ADDRESS listings can be found in Address Leases.
Check whether any devices on the network have static IP addresses that have not been excluded from the DHCP scope.
Verify that the DHCP server is bound to at least one IP address, and that this is within the subnet of the scopes from which IP addresses must be leased out (unless using DHCP relay). To do this, run the Get-DhcpServerv4Binding or Get-DhcpServerv6Binding cmdlet. Server connection bindings are configured in the DHCP server management console under IPv4 / IPv6 Advanced Properties.
Verify that only the DHCP server is listening on UDP port 67 and 68. No other process or other services (such as WDS or PXE) should occupy these ports. To do this, run the netstat -anb command.
Verify that the DHCP server IPsec exemption is added if you are dealing with an IPsec-deployed environment.
Verify that the relay agent IP address can be pinged from the DHCP server.
Enumerate and check configured DHCP policies and filters.

Event logs

Check the System and DHCP Server service event logs (Applications and Services Logs > Microsoft > Windows > DHCP-Server) for reported issues that are related to the observed problem. Depending on the kind of issue, an event is logged to one of the following event channels: DHCP Server Operational Events DHCP Server Administrative Events DHCP Server System Events DHCP Server Filter Notification Events DHCP Server Audit Events

Data collection

DHCP Server log

The DHCP Server service debug logs provide more information about the IP address lease assignment and the DNS dynamic updates that are done by the DHCP server. These logs by default are located in %windir%\System32\Dhcp. For more information, see Analyze DHCP Server Log Files.

Network trace

A correlating network trace may indicate what the DHCP server was doing at the time that the event was logged. To create such a trace, follow these steps:

Go to GitHub, and download the tss_tools.zip file.
Copy the Tss_tools.zip file, and expand it to a location on the local disk, such as to the C:\tools folder.
Run the following command from C:\tools in an elevated Command Prompt window:
TSS Ron Trace <Stop:Evt:>20321:<Other:>DhcpAdminEvents NoSDP NoPSR NoProcmon NoGPresult

Note

In this command, replace <Stop:Evt:> and <Other:> with the event ID and the event channel that you are going to focus on in your tracing session. The Tss.cmd_ReadMe_Help.docx files that are contained in the Tss_tools.zip file provide more information about all available settings.
After the event is triggered, the tool creates a folder that is named C:\MS_DATA. This folder will contain some useful output files that provide general information about the network and domain configuration of the computer. The most interesting file in this folder is %Computername%_date_time_packetcapture_InternetClient_dbg.etl. By using the Network Monitor application, you can load the file, and set the display filter on the “DHCP or DNS” protocol to examine what is going on behind the scenes.

Dynamic Host Configuration Protocol, or DHCP, eases the task of administering IP addresses for network endpoints by centralizing address allocation configuration.

Troubleshooting DHCP can be challenging and requires a basic knowledge of the protocol and how networks function. Below are some common DHCP problems and how to fix them.

There are two basic types of DHCP server configurations:

centralized server-based DHCP servers in enterprise networks; and
DHCP servers running on local network devices.

1. Centralized server-based DHCP server in an enterprise network

When an endpoint needs an IP address, it broadcasts its DHCP packets. Network devices then relay those requests across the network to the enterprise DHCP server.

Network devices must have correct configurations to properly handle the requests and responses. If something is misconfigured, endpoint devices will not obtain a valid address.

2. DHCP server running on a local network device

The second type of DHCP configuration is what small remote branches or in-home networks frequently use. The DHCP server runs on a local network device, such as a wireless router, that connects the site to the internet.

The advantage of this configuration is the DHCP server is local to the site and can continue to function even if connectivity to the enterprise network fails. This enables users at these locations to access cloud-based SaaS applications. However, the proliferation of internet-enabled devices -- such as desktops, laptops, and digital assistants, as well as mobile, home automation and IoT devices -- could easily cause a local server to run out of addresses in its default configuration, which might have only 50 or 100 addresses available.

The first step in diagnosing DHCP is to examine your device's IP address and network settings. You'll need to verify it is using DHCP and not a manually configured address.

If it is configured to use DHCP and has an IP address, note the address, subnet mask, default router and DNS servers. The image below shows this information for a MacBook Pro.

DHCP succeeded.

If a device is unable to get an IP address via DHCP, it will use an automatic private IP address from the address range 169.254.x.y, as shown in the image below.

DHCP failed, and an automatic private IP address was selected.

The following reasons could cause DHCP errors and compel a device to use a self-assigned IP address:

the DHCP server failed;
all available addresses have been allocated;
the network to the server failed;
a configuration change affected DHCP packet relay;
a configuration mistake happened during new installation; or
media access control (MAC) address filtering is enabled, and the new device isn't included in the server's configuration.

The most common reasons for this error include DHCP server failure, no available addresses and network failure.

Error 1. No address assigned

The first DHCP error is no assigned IP address. The most common reasons for this error include DHCP server failure, no available addresses and network failure. To start diagnosis, verify the following items:

the DHCP server is functional;
the DHCP server hasn't run out of addresses; and
there isn't a network failure.

If any devices in the affected subnet can get or renew their addresses, then the server and the network are functioning properly. Check that the DHCP server's address pool still has addresses available.

You should also check for a network problem in the part of the network where the failing device is connected. It could be an incorrect switch port configuration, or perhaps the switch for your device has disconnected from the rest of the subnet. If your device is portable, move it to a good network connection, and try to get a DHCP address. A failure at this point indicates something is incorrect in the device configuration itself, not in the network or with the DHCP server.

For a new installation where no devices are working correctly, you should investigate network configuration mistakes that prevent the DHCP relay operation from working correctly. Also, check for MAC address filtering, which isn't used often, but should be verified.

The most challenging step will likely be checking network connectivity, simply because a variety of causes could cause a failure. You can start the diagnostic process by assigning a manual address to one device. Use that address to verify basic network connectivity to the DHCP server with ping and traceroute. If that works, then you'll need to check that the network device configurations are set to relay DHCP packets and that no blocking firewall rules exist. Look for simple things like typographical mistakes in addresses.

Be advised that some malware can create a denial-of-service attack by making DHCP requests until all addresses have been consumed. Each request uses a different MAC address, so you can examine the switch forwarding table to find the port on which many MAC addresses have been detected. This enables you to identify the infected device.

Error 2. Address is assigned but no connectivity

The next DHCP error is when an address is assigned but the device can't communicate with other devices. In this case, the following reasons could cause a DHCP error:

IP address conflict, where another device is using the same address;
a rogue DHCP server hands out same addresses; or
a rogue DHCP server hands out addresses outside the address range.

For conflicting IP addresses, you'll need to track down both devices by finding the MAC address of both devices. You'll then need to find the switch port to which each device is connected. A good network management system can help you with this process. One of the devices may have a manually assigned address from the DHCP address range. A best practice is to reserve separate address ranges for devices with fixed addresses.

In another case, a rogue DHCP server may hand out addresses from the same address range or a different address range. You may need to conduct network sleuthing with packet capture tools to identify the location of rogue servers.

The key symptom of a rogue DHCP server is the endpoints always get their addresses via DHCP. The addresses can be from the same range, or the rogue server may be using a different range than what's assigned to the subnet. In either case, you'll need to track down the rogue server and remove it from the network or disable DHCP on it.

Some network equipment vendors have a feature to detect rogue DHCP servers, frequently called DHCP snooping. You may be able to use it to identify and suppress the action of undesirable DHCP servers.

Error 3. Address is valid but is missing DHCP options

The next DHCP error is where an address is valid but the DHCP options are not properly configured. DHCP options pass additional information to the endpoint to do things like identify a default gateway (option 3), make DNS requests (option 6) or identify a Trivial FTP server from which to download a device configuration (option 66).

The exact troubleshooting steps vary by the endpoint device type and its function. For example, VoIP phones need multiple DHCP options set. You'll need to refer to vendor documentation for configuration guidance.

Here is a quick DHCP troubleshooting guide that covers the common errors and their causes.

Use this chart to diagnose and fix DHCP errors.

DHCP troubleshooting is challenging because it involves several components: the endpoint device, its network connection, the network devices -- like routers, switches, access points and firewalls -- and the DHCP server itself.

As with all network troubleshooting, a methodical approach works best. Gather facts, and perform tests that verify whether a component is working or not. In rare cases, you may need to use packet captures to verify that DHCP exchanges are happening or to identify rogue DHCP servers.