Troubleshooting general networking through TCP/IP is probably the single most frequent troubleshooting process that any desktop administrator will go through, so it’s important to understand what’s going on so that you can get a better idea of what choices are made along the way.

Computers (either Internet or local Windows 2000 networked systems) default to TCP/IP as their networking protocol. Each system that runs TCP/IP must have a unique IP address and appropriate subnet mask in order to communicate properly. In order for a system to further communicate with systems outside of the local area network such as on the Internet or on other subnets, a default gateway must be assigned, and a DNS Server address assigned as well.

There are three different ways that a system can obtain IP configuration information: someone manually assigns a number to the system; the system is configured to locate a DHCP Server which will then assign a number to the system; or the system is configured to locate a DHCP server, but doesn’t find one, in which the system will be assigned a number in the 169.254 range with a 255.255 subnet.

When you attempt to communicate with a system on the local LAN, your computer compares the IP address and subnet mask of the computer with your IP address and subnet mask. If they match appropriately, communications can take place. If they don’t match, it’s very similar to a letter where the address and the ZIP code do not match. If you are attempting to contact a system that is outside the boundaries of the LAN, the system quickly determines this, and then refers to the default gateway (usually a router) to essentially ‘leave town’ (which is the LAN) and take the road to wherever it goes, which is usually an Internet Service Provider. Subsequent gateways and routers determine the best place for your communication to go, and either the data reaches its destination or it dies trying. Now, that’s pretty simple, and pretty much all that you need to know in order to do most of the troubleshooting here. There is one other tidbit that might come in handy that will help you figure out where the problem(s) may lay, and that’s DNS. DNS (Domain Naming Service) is a server/protocol that maintains a list of specific computer names (Fully Qualified Domain Names, FQDNs) and their corresponding IP addresses. This allows us wacky humans to attempt communication by name rather than IP address.

Now that you have an idea of how it works, here’s a generic way of testing just about every type of connectivity on your network.

  1. Open a command window, and type IPCONFIG /ALL
  2. Locate your current IP address.
  3. If it’s, you may have a problem: if DHCP is on the network, then you’re not getting there, which could mean a problem with you, or a problem with the DHCP server.
  4. Try IPCONFIG /RELEASE followed by IPCONFIG /RENEW. If you are configured to obtain an IP address automatically, the system will again look for a DHCP server. If it again is not found, you have a problem. IF it is found, step 1 should reveal a completely different IP address.
  5. Write down the default gateway that’s assigned to your IP address. Also write down the primary and secondary DNS server addresses.
  6. If there is no default gateway, then either DHCP hasn’t been configured to give you one, or you haven’t been manually configured to have one. If your intention is to access the Internet or another network, you must have a default gateway address.
  7. If you have no DNS server addresses, again DHCP hasn’t been configured to give you one, or you haven’t been configured to have one. DNS is pretty much required to.
  8. Type PING followed by the address for the default gateway.
  9. If you receive a response, then local networking communications are functioning properly.
  10. Type PING followed by the Internet name for a Web site, such as The system will attempt to determine the IP address associated with that FQDN.
  11. IF it is successful, the system will display the IP address for that name, and proceed to contact it. This proves that the connection between your gateway and the ISP and the destination is intact.
  12. If DNS is down or not functional, the name will not resolve, and you will receive an unknown host response on the screen.
  13. PING the primary and/or secondary DNS server IP address. The physical location of the server may or may not be on your local LAN. The idea is to PING the DNS server that is on the other side of the gateway.
  14. If this PING is successful, you have established that the connection between your gateway and the ISP is intact, but that something is wrong between the ISP and the destination. Call the ISP to troubleshoot from there. The problem is definitely not with you.
  15. If this PING is unsuccessful, you can assume that the connection between your gateway and the ISP is not intact. Again, call the ISP to troubleshoot. The problem may be ISP-based, such as the DNS server is down, or it may be that the physical router connection between the gateway and the ISP is having problems.