Troubleshooting Network Connections
With little news in the Windows 2000 bug and hotfix space this week, I decided to share some simple network troubleshooting techniques. I spent most of the past 2 weeks troubleshooting network connectivity and mail access problems on my network and for a client, and you can use the same tools and procedures to diagnose these problems on your networks. Most people don't realize that a network is a fluid, ever-changing structure with millions of parts, and that network connectivity, whether local or through the Internet, undergoes multiple daily hiccups (outages) that last a few minutes to an hour or more. Most of the hiccups are transitory—they’re caused by a link that’s down because a network administrator is rebooting, replacing, or reconfiguring a box that your message or request requires to identify or locate its destination. A network infrastructure is similar to our road system: When a cone zone (outage) pops up, we either wait until the cones come down, or we take a detour to get to our destination.
Only a few reasons exist for why you might be unable to connect to a Web, mail, or VPN server on your corporate network or on the Internet: Your system must be able to translate a DNS name, the destination must be operational, an open path must exist between your system and the destination, and you must have appropriate permissions.
Most of us use names to identify our destination of choice, so we visit http://www.travelocity.com or http://www.winnetmag.com, or pick up mail from pop3.denver.qwest.com. However, each name is simply an alias that must translate into a valid, registered TCP/IP address to uniquely identify the destination. When messages hit the network, they carry source and destination information as TCP/IP addresses, not the corresponding names. Windows uses either DNS or WINS to translate names into addresses. DNS is the naming standard for TCP/IP networking on corporate networks and the Internet, and WINS is a Microsoft-proprietary naming standard we use to resolve resources such as \\vpnserver\laserjet or \\broadway\officeadmin into TCP/IP addresses. After you successfully change a name into an address, your message or request must have an open path to its destination.
To identify the most likely source of a specific connectivity problem, you must first display your system’s TCP/IP configuration; second, verify that you have the correct name and that the name has a valid TCP/IP address; and third, verify that you can reach your destination by its address. To help you perform these actions, I compiled the following list of command-line tools. If using these commands indicates that you can translate a DNS name, that the destination is operational, and that an open path exists between your system and the destination, your access problem is most likely related to authentication or permission issues.
Network Connectivity Command-line Tools
To identify the most likely source of a specific connectivity problem, you must first display your system’s TCP/IP configuration; second, verify that you have the correct name and that the name has a valid TCP/IP address; and third, verify that you can reach your destination by its address. To help you perform these actions, I compiled the following list of command-line tools. If using these commands indicates that you can translate a DNS name, that the destination is operational, and that an open path exists between your system and the destination, your access problem is most likely related to authentication or permission issues.
- Ipconfig /all displays your machine's TCP/IP settings. The two most important settings are Default Gateway and DNS server.
- Nslookup translates a TCP/IP name into a TCP/IP address. This command is analogous to using an online phone book to look up an individual’s name (the TCP/IP name) and telephone number (the TCP/IP address). By default, when you type Nslookup at a command prompt, your request goes to the DNS server that you or your ISP defines in your TCP/IP settings. If the DNS server is not functional, you’ll get a "DNS request timed out" error message, which means the network administrator is most likely working on the DNS server. If the DNS server is operational, it responds with a greater than sign (>) and waits for you to type the name you're trying to reach. If the DNS server replies with the name followed by a TCP/IP address, you know you have the correct name for your destination.
- Ping asks a specific network destination whether it's online and available. You can ping a system by name or address. This command is like saying hello on the telephone and waiting for the person you called to respond with a "hi." If the person you called replies, you know you can have a conversation. When you ping a destination such as http://www.google.com, and Google responds with four replies, you know you can resolve the name and that the system is operational. A nonoperational destination doesn't reply; instead, you see the error message "Request timed out." The "timed out" reply has three likely causes: The name is incorrect, the DNS server can't translate the name, or the system you're attempting to access is out of service. One scenario in which an operational system doesn't respond to a Ping request occurs when a network administrator—for security reasons—specifically disables the system’s ability to reply.
- Tracert shows you all the stopping points between your system and a specific destination. You can trace a system by name or by address. This command is akin to mapping the turns you need to make in your car to arrive at your destination. This command is the easiest way to verify that your request has an open path to its destination. Tracert responds with a list of systems, one line at a time, that are required to route your message or request to the destination. If a key component on this path is unavailable, Tracert replaces the timing and name data with asterisks and the error message "Request timed out." If you can’t trace a route to the destination, you’ll need to wait until the missing piece is operational or someone provides an alternative path. The first system in Tracert’s output should be the same system that appears in the Default Gateway field of your system’s TCP/IP configuration.
- Netmon is a sophisticated packet sniffer that records detailed information about every message your system sends or receives. When the above commands indicate you have network connectivity, but you’re still having trouble, Netmon is the tool of last resort. Although reading network traces is nerdy beyond belief, you can almost always identify the cause of the communication breakdown.
