Troubleshooting TCP/IP
Total Page:16
File Type:pdf, Size:1020Kb
4620-1 ch05.f.qc 10/28/99 12:00 PM Page 157 Chapter 5 Troubleshooting TCP/IP In This Chapter ᮣ Troubleshooting TCP/IP in Windows 2000 Server ᮣ TCP/IP troubleshooting steps ᮣ Defining which is the best TCP/IP troubleshooting tool to solve your problem ᮣ Mastering basic TCP/IP utilities roubleshooting is, it seems, an exercise in matrix mathematics. That is, Twe use a variety of approaches and influences to successfully solve our problems, almost in a mental columns-and-rows format. These approaches may include structured methodologies, inductive and deductive reasoning, common sense, experience, and luck. And this is what troubleshooting is made of. Troubleshooting TCP/IP problems is really no different from troubleshooting other Windows 2000 Server problems mentioned in this book, such as instal- lation failures described in Chapter 2. Needless to say, Windows 2000 Server offers several TCP/IP-related tools and utilities to assist us, but more on the specifics in a moment. TCP/IP Troubleshooting Basics The goal in TCP/IP troubleshooting is very simple: fix the problem. Too often, it is easy to become overly concerned about why something happened instead of just fixing the problem. And by fixing the problem, I mean cost effectively. 1. Be cost effective. Don’t forget that several hours’ worth of MCSE-level consulting could more than pay for the additional bandwidth that may easily solve your TCP/IP WAN-related problem. Don’t overlook such an easy fix when struggling to make a WAN connection between sites utilizing Windows 2000 Server. Too little bandwidth is typically the result of being penny wise and pound foolish. Oh, and it also causes nasty timeout conditions that can wreak havoc on your TCP/IP-based network. And if you want to make a complex database unhappy, just give it too little bandwidth on a TCP/IP-based WAN. 4620-1 ch05.f.qc 10/28/99 12:00 PM Page 158 158 Part II: TCP/IP I I 2. Experience is the best teacher. One of the more challenging corporate training assignments I frequently face is when I’m asked to deliver a custom TCP/IP and Windows 2000 Server troubleshooting session. The challenge is this: I’m not sure I can teach troubleshooting. It’s really just something you do and you’re ultimately skilled at it or not. TCP/IP troubleshooting ability is heavily based on experience. The good news is that the more time on the computer you put in (“stick time”), the better you will do. 3. Use inductive reasoning. Microsoft officially recommends pursuing a TCP/IP troubleshooting strategy of working from the bottom up, such as starting at the Physical Layer of the Open Standards Interconnections (OSI) model and proceeding to look at more broader influences such as the applications you are running. This enables you to isolate a problem. Such an approach is also known as induction or inductive reasoning, which Webster’s New World Dictionary defines as “a bringing forward of separate facts or instances, esp. so as to prove a general statement.” This mindset is largely the basis for this chapter, as individual tools and utilities that in reality would be used independently to solve a larger TCP/IP-related problem will be discussed. That is, you would start with a specific tool to solve a discrete problem and, as troubleshooting both goes and grows, resolve more global TCP/IP issues. In contrast, deductive reasoning is really better suited for the Windows 2000 Server developers in feature-set brainstorming sessions where the whole idea is to come up with great new features and then work down to the implementation specifics. Webster’s defines deduction as “Logic — the act or process of deducing; reasoning from a known principle to an unknown, from a general to the specific.” 4. Use the in-house help. Many wonderful tools are included in Windows 2000 Server for use in your TCP/IP troubleshooting efforts. These include native commands and utilities such as IPConfig and ping that will be reviewed in this chapter. And given that Windows 2000 Server is often bundled with the full version of BackOffice, don’t forget the full-featured version of Network Monitor included in Microsoft Systems Management Server (SMS). You will recall that tools such as Network Monitor were discussed at length in Part VI of this book, “Optimizing and Troubleshooting Windows 2000 Server.” 5. Don’t forget third-party tools. Not surprisingly, a wide range of third-party TCP/IP troubleshooting tools is available to assist you. One favorite, which will be discussed in Chapter 9, is PingPlotter, a low-cost shareware application from Richard Ness at Nessoft (www.nesssoft.com). PingPlotter is included on the CD-ROM that accompanies this book. This application tests ping connectivity and measures ping performance across WAN hops. 6. Always reboot. Last, but certainly not least, you must always reboot when modifying anything related to the TCP/IP protocol stack in Windows 2000 Server. Even though the “stack” has improved dramatically, I still don’t trust it completely. In my eyes, there is nothing like a complete reboot where you shut the computer down for 15 seconds after you’ve modified 4620-1 ch05.f.qc 10/28/99 12:00 PM Page 159 Chapter 5: Troubleshooting TCP/IP 159 I I any TCP/IP protocol settings. And it’s an easy lesson to overlook! Here’s why. Let’s assume you switch your IP address from a dynamic DHCP- assigned address to a static IP address. So far, so good. But if at this moment, you run the IPConfig command that reports basic TCP/IP configuration information (discussed later in this chapter), you will note that the TCP/IP configuration information reports the new, updated IP address as if it were properly bound to the network adapter. Don’t you believe it for a minute! Always reboot. In fact, if you want my $59.95’s worth, I’d highly recommend you follow Step Zero — that is to completely cold-reboot your Windows 2000 Server prior to concluding you have any problems with TCP/IP. Don’t ask me why, but I’ve seen many Windows 2000 Server TCP/IP-related gremlins disappear this way. And that’s something you won’t read about in the official MCSE study guides. Trust me. First Step: Ask the Basic Questions So where do you go from here? Remember that troubleshooting any problem is a function of asking enough questions. Here is a short list of questions you can start your TCP/IP troubleshooting journey with. It is by no means inclusive. I What’s working? I What’s not working? I What is the relationship between the things that work and the things that don’t? I Did the things that don’t work now ever work on this computer or network? I If the answer is yes, what has changed since they last worked? You can ask more specific questions in your quest to resolve your TCP/IP problems. These questions are presented and answered at the end of the chapter. Second Step: Define the Tools Having completed this first step, you’re ready to begin troubleshooting TCP/IP in Windows 2000 Server. Table 5-1 provides a list of TCP/IP diagnostic utilities and troubleshooting tools, many of which will be discussed further in this chapter. 4620-1 ch05.f.qc 10/28/99 12:00 PM Page 160 160 Part II: TCP/IP I I Table 5-1 Windows 2000 Server TCP/IP Troubleshooting Tools and Utilities Utility/Tool Description ARP Address Resolution Protocol. Enables you to view local computer ARP table entries to detect invalid entries. Hostname Typing this at the command line returns the current host name of the local computer. IPConfig Current TCP/IP information is displayed. Command line switches enable you to release and/or renew your IP address. Nbtstat Connections using NetBIOS over TCP/IP and protocol statistics are displayed. The LMHOSTS cache is updated (purged and reloaded). Netstat Active TCP/IP connections are displayed in addition to TCP/IP statistics. Nslookup Internet domain name servers are queried and recorded; domain host aliases, domain host services, and operating system information is returned. Ping Packet Internet Gopher. Tests connections and verifies configurations. Route Displays, prints, or modifies a local routing table. Tracert Checks the route from the local to a remote system. FTP File Transfer Protocol. This tool is used for two-way file transfers between hosts. TFTP Trivial File Transfer Protocol. Provides another form of two- way file transfer between hosts. Typically used when one host demands TFTP. I’ve used this in conjunction with router configuration and troubleshooting scenarios. Telnet Basic terminal emulation program that establishes a session with another TCP/IP host running a Telnet host. RCP Remote Copy Protocol. Enables you to copy files between TCP/IP-based hosts. RSH Remote Shell. Enables you to be authenticated by and run UNIX commands on a remote UNIX host. Rexec Enables you to be authenticated by and run processes on a remote computer. Finger System information is retrieved from a remote computer running TCP/IP and supporting the Finger command. Microsoft Internet Explorer Browser used for locating information and retrieving resources from the Internet. 4620-1 ch05.f.qc 10/28/99 12:00 PM Page 161 Chapter 5: Troubleshooting TCP/IP 161 I I Two important TCP/IP-related “tools” that are missing in Windows 2000 Server are native NFS client support and the whois command. For NFS client support, as discussed in Part VI of this book, “Optimizing and Troubleshooting Windows 2000 Server,” check with NetManage or WRQ, two independent software vendors that provide NFS client solutions for Windows 2000 Server.