What is the first step in troubleshooting an issue where a single computer is unable to lease an address?

Over the last several years, TCP/IP has gone from being the protocol that only geeks use, to a universal protocol that everyone uses, thanks to the widespread use of the Internet. TCP/IP has been around for decades and is a solid, reliable, mature protocol. Most of the time when there is a TCP/IP related problem, the problem is related to the way that one or more of the hosts on the network are configured. This article will walk you through the process of troubleshooting some common TCP/IP issues.

Step 1: Check the configuration

The first step in the troubleshooting process is to check the TCP/IP configuration. The easiest way to do this is to open a Command Prompt window and enter the IPCONFIG /ALL command. Windows will then display the configuration results. It's important to point out that some computers have multiple network interface cards, and Windows may also treat a Firewire port as a network adapter. You must therefore be careful to make sure that you are looking at the configuration that's bound to the interface that's actually connected to the network.

If the configuration appears to be blank, then the interface has not been assigned an IP address. IP addresses can be assigned manually, or via a DHCP server. If your organization uses a DHCP server to assign IP addresses, then try entering the following series of commands to see if the machine is able to obtain an IP address:

IPCONFIG /RELEASE

IPCONFIG /RENEW

IPCONFIG /ALL

If the machine is still unable to obtain an IP address, then there are several things that could be causing the problem. For example, the DHCP server might have already given out all of its addresses. You can check the server's logs to see if this is the case. Another possible cause is that you might have a bad network cable. Try attaching another machine to the network cable / network jack that the malfunctioning machine is attached to and see if the known good machine is able to attach to the network.

Still another possible problem is that the network card is not installed correctly through Windows. In most cases, Windows XP will automatically detect a network card and load the drivers for it automatically. However, Windows XP is notorious for misidentifying network cards. If you are having trouble attaching to the network, it might be a good idea to pop open the computer's case and check to make sure that the make and model of the network card that's installed matches the driver that is loaded into Windows.

If the driver matches and you are still having problems, try going to the network card manufacturer's Web site and downloading the newest driver for the card. I have seen several situations in which a new driver fixed the problem. If you have tried everything that I have suggested and are still unable to acquire an IP address, try reseating or replacing the network card. Network cards have been known to go bad for no apparent reason.

Communications failure

If your NIC (network interface card) has an IP address associated with it, but the machine is unable to communicate across the network, then you will have to use a slightly different approach to troubleshooting the problem. The first question that you need to consider is the source of the IP address. Was the address entered manually into Windows, or was it leased from a DHCP (Dynamic Host Configuration Protocol) server?

If the address came from a DHCP server, then you can eliminate a lot of possible causes of the problem right now. If the machine is able to lease an IP address, then it means that the computer's network card is functioning and that the connection to the switch is good.

Don't be deceived though. When a computer leases an address from a DHCP Server, the lease is valid for a specific period of time. If the machine has successfully leased the address in the past but the lease has not yet expired, then it might appear that the machine has obtained a lease, when in reality the machine is holding onto an IP address that it acquired during a previous session. The easiest way to find out for sure what is going on is to use the IPCONFIG /RELEASE and the IPCONFIG /RENEW commands to get rid of the old lease and acquire a new one.

If the NIC has an IP address, but the address has been assigned manually, then the first thing that you will need to do is to perform some basic connectivity tests. You can do this in much the same way as I talked about earlier. Try plugging a known good PC into the network connection to make sure that the connection is good. Make sure that the NIC has the correct drivers. In essence, you will want to make sure that your hardware is functioning before you continue.

Once you have done some basic hardware testing, open a Command Prompt window and try pinging the computer's own IP address. If the ping is successful, then it means that the TCP/IP protocol stack is at least functional. If you receive an error message stating "Destination Host Unreachable" then it means there is something wrong with the way the machine is set up. It could be that Windows doesn't recognize the network card, or it could be that a necessary system file has been deleted or corrupted. You might try removing and re-installing the network card and its drivers. If that doesn't work, try re-applying the Windows Service Pack since doing so will refresh all of the system files.

Assuming that the machine is able to ping itself, try pinging another machine on your network by IP address. If your machine is able to ping itself, but is not able to ping another computer on the network (by IP address) then try to ping a few more computers. If you are not able to establish communications with any of them, then look for a bad network link or perhaps a bad network card.

If you are able to successfully ping other machines on your network by IP address, try pinging those machines by hostname. If you don't know the hostname, then you could use the ping /a command against the machine's IP address to resolve the address to a host name. Another alternative is to ping a Web site. Most Web hosts block pings, but as of the time that this article was written, www.espn.com would still respond to pings.

If you are able to ping machines on your network and on the Internet by host name, then your machine is successfully communicating. If you can ping by IP address but not by hostname, then the problem is probably DNS related. Enter the IPCONFIG /ALL command to make sure that your machine is configured to use a DNS server. If there is a DNS server specified, make sure that the DNS server's IP address has been entered correctly. If everything appears normally, try pinging the DNS server to make sure that you can communicate with it.

If you can ping the DNS server, the DNS server's IP address has been entered correctly, and the DNS server seems to be resolving addresses for other people on your network, then the problem probably isn't DNS related. I recommend checking your HOSTS file. It is located in the C:\WINDOWS\SYSTEM32\DRIVERS\ETC folder. The HOSTS file is a legacy component of TCP/IP that really isn't used anymore. It was previously used to associate a Web site with an IP address before DNS became popular. Today, a lot of browser hijackers and various forms of spyware work by altering the hosts file. Try displaying the HOSTS file through Notepad. You might be surprised at what you see. If you see entries that shouldn't be there, you can either delete them or delete the entire HOSTS file.

Conclusion

In this article, I have explained that configuration problems can prevent TCP/IP from functioning correctly. I then went on to discuss the TCP/IP troubleshooting process.

Brien Posey is an award-winning author who has written more than 3,000 articles and written or contributed to 27 books. You can visit his personal Web site at www.brienposey.com.

Copyright © 2005 IDG Communications, Inc.

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:

  1. Go to GitHub, and download the tss_tools.zip file.

  2. Copy the Tss_tools.zip file, and expand it to a location on the local disk, such as to the C:\tools folder.

  3. 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.

  4. 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.