WINDOWS 2000 TROUBLE SHOOTING TCP/I P phần 3 docx

122 Chapter 3 • Windows 2000 TCP/IP Troubleshooting Guidelines This is where you configure the maximum amount of disk space the log can occupy, and what should occur when the limit is reached. You can also clear the log here, with the click of a button. You can also filter the events in a specified log. When you archive the log, however, the entire log will be saved regardless of filtering. You must be an administrator in order to set logging options. Tools of the Trade Chapter 4 will look in detail at some of the tools you can use to assist in your “diagnosis” and plan a “cure” for the problem. Perhaps the most important tool for a network troubleshooter is a good protocol analyzer. To really learn what’s going on with the network, you have to examine the packets themselves. This requires not only that you have a good analyzer, but that you learn how to use it. There are many types available, from stand-alone and handheld devices to software-only solutions. Microsoft’s Network Monitor (often referred to as ”NetMon”) is a good tool for analyzing Windows-based networks. A big advantage is that a basic version of NetMon is included with the Windows 2000 Server oper- ating systems (see Figure 3.12). This free version of NetMon will only capture packets that are sent from or to the server on which it is installed. If you want to capture pack- ets for the entire network, you need the enhanced version of Network Monitor, which is part of Microsoft’s System Management Server. In Chapter 4, we will discuss in detail how to use NetMon and other network analysis tools. When we have finally gathered as much data as possible, we can move on to the next phase in the troubleshooting process. The Problem Isolation Phase This is the Diagnostic, or Analysis phase. This is where you take the large amount of information gathered from your investigative sources (results of monitoring and analysis equipment, users’ answers to questions, and your own personal observations), determine which bits are relevant and which can be discarded (in any thorough investigation, there will always be much more “data” than useful “information”), and use the rest to put together the pieces of the puzzle and solve the mystery. NOTE 91_03.qx 2/25/00 10:59 AM Page 122 Windows 2000 TCP/IP Troubleshooting Guidelines • Chapter 3 123 One of your objectives during this phase is to look for patterns. Has this problem occurred here before? Do the “symptoms” match something you’ve heard about or read about? The first step in analyzing the informa- tion is to organize it in a fashion that will allow you to notice trends and pick out the key facts. Organizing and Analyzing the Information This step may be done on paper, on screen, or in your head, but it is important that you sort through all the random facts and numbers you’ve gathered to determine which facts support which theories (and which would tend to negate which theories, too). In its simplest form, the process would work like this: Your user reports that the network file server, BIGSERVER, is “gone” from the network. (BIGSERVER is a Windows 2000 member server in a mixed-mode domain). Figure 3.12 The Microsoft Network Monitor included with Windows 2000 Server. 91_03.qx 2/25/00 10:59 AM Page 123 124 Chapter 3 • Windows 2000 TCP/IP Troubleshooting Guidelines Given that information, what are some scenarios that could cause the problem? It’s possible, although unlikely, that BIGSERVER has crashed. Since the machine itself sits a few feet away from your own workstation, you use your visual observation skills to confirm that BIGSERVER is up and running. You’ve eliminated one possibility. Another is that BIGSERVER’s network card has malfunctioned, a cable has loosened, or something else has caused the server to become disconnected from the network. You continue your investigation by trying to access BIGSERVER from your own workstation. You are able to ping the server with no problem using its IP address. You have eliminated another possibility: you now know that BIGSERVER is connected to the network. And since you can ping him successfully, you know his TCP/IP configuration is okay. You now consider the possibility of a name resolution problem. Perhaps the network’s DNS server is down. You try pinging BIGSERVER by name, and get a response. The DNS server is working properly. Could the problem be with the network’s browser service? You check “My Network Places” and find that BIGSERVER is listed in the domain. Perhaps there’s a problem with NetBIOS name resolution. The user didn’t say what application he was using that made BIGSERVER disap- pear, so maybe its not a host name problem, but a NetBIOS name prob- lem. You double-click BIGSERVER in the My Network Places windows, and you see all of BIGSERVER’s network shares. At this point, you’ve narrowed the problem down considerably, and decided that it must be specific to the complaining user’s workstation. You go to that computer, which is running NT Workstation, and question the user further. What exactly does he mean when he says BIGSERVER is “gone?” The user tells you that he has tried to FTP to BIGSERVER and is unable to do so. He also opens up My Network Places and clicks on BIGSERVER’s name. Nothing happens. At this point you suspect a problem with the workstation’s configura- tions, but don’t know whether it’s a browse issue, a name resolution issue, or a TCP/IP connectivity issue. You ask if he tried to ping BIGSERVER and he replies that he did, using the server’s IP address, but received “some kind of error message.” Now you’re hot on the trail of the problem! You know it’s not a name reso- lution problem, since that wouldn’t affect your ability to ping by IP address. You know the server’s IP address is configured and working properly because you were able to ping from your own workstation. Now you open a command prompt, attempting to ping BIGSERVER and reproduce the problem. When you type “ping 192.168.1.2” at the command line, you receive the message shown in Figure 3.13. 91_03.qx 2/25/00 10:59 AM Page 124 Windows 2000 TCP/IP Troubleshooting Guidelines • Chapter 3 125 This error indicates that something is wrong with the TCP/IP stack. You get the same message when you attempt to ping the loopback address, 127.0.0.1. That convinces you that TCP/IP is not working. You open the local area connection’s Properties box and discover that TCP/IP is not installed on the machine. Upon further questioning, the user tells you that he uninstalled the protocol from “another connection.” He points to the connection icon for the VPN, assuring you that he didn’t change anything on the local area connection. You sigh and explain that uninstalling the protocol from one connec- tion removes it from all of them that use that network card, and you rein- stall and reconfigure TCP/IP. BIGSERVER magically reappears. The user asks you why he was still able to “see” the other servers, and you show him that the NetBEUI protocol was still installed after he removed TCP/IP. The servers he was still able to connect to were on his local net- work segment and were running NetBEUI. Since BIGSERVER’s only net- working protocol is TCP/IP and the workstation’s only protocol was NetBEUI, they had no common protocol over which they could communi- cate. You go back to your station to reassess the company’s practice of allowing users to be administrators of their own workstations. Setting Priorities Since troubles tend to come in threes (or even bigger “gangs”), an impor- tant step in troubleshooting is to first prioritize the problems themselves, and then prioritize the factors that affect your efforts to solve them. Figure 3.13 Ping error message. 91_03.qx 2/25/00 10:59 AM Page 125 126 Chapter 3 • Windows 2000 TCP/IP Troubleshooting Guidelines Prioritizing the Problems In categorizing problems, priorities are usually set based on one of two criteria (or a combination of both): ■ Productivity factors ■ Political factors The first is easy to understand, and prioritizing problems based on their effect on productivity is fairly easy to do. It’s obvious that, in general: 1. Problems that affect the entire network are higher priority than those that affect only a few users. 2. Problems that affect mission-critical activities (such as on-time delivery of time-sensitive material) are higher priority than those that affect less urgent activities (such as routine archiving of data). 3. Problems that are ongoing and worsen with time are higher priority than those that occur only occasionally and then clear up on their own. The second prioritization factor is a bit subtler, and may not be talked about or even acknowledged. In fact, the “unwritten rules” may be in direct conflict with the company’s stated policies. Every organization has its “pecking order” and its internal politics. It might seem that a problem affecting a whole department of clerks’ ability to access word processing documents is clearly a higher priority than a problem that prevents one user from surfing the Web. However, if that one user happens to be the CEO, who is addicted to his daily dose of online stock market reports and is in the throes of withdrawal, logical methods of prioritizing may not be applicable. Prioritizing the Solutions When developing possible solutions, you will want to decide what factors are most important to your company in general, and in this particular instance. Factors to consider: Cost. Don’t forget that the immediate monetary outlay to implement the solution doesn’t tell the whole story in terms of total cost. You must also consider ongoing associated costs, and intangibles, just as the time of those who will do the work and the time lost by those who are unable to work while the network is down. Time. This is closely related to cost, and is a potentially high cost due to loss in productivity. Sometimes the (seemingly) more 91_03.qx 2/25/00 10:59 AM Page 126 Windows 2000 TCP/IP Troubleshooting Guidelines • Chapter 3 127 expensive solution, if it fixes the problem more quickly, is more cost-effective in the long run. Longevity. Do you need a long-lasting solution that will solve the problem permanently, or are you planning to reconfigure the entire network and install all new equipment three months from now and you only need a “fix” that will last until then? Performance. If a more expensive solution also improves overall performance at the same time it fixes the problem, it may be well worth the extra expense. Sometimes problems present perfect upgrade opportunities. Taking Corrective Measures Sometimes there will be several available solutions; which one you imple- ment will depend on many factors, including the priorities you’ve set. In some cases, the decision will be determined by budgetary restrictions. For instance, if too many users log on the domain at the same time when they start work each morning and cause a network slowdown, one solu- tion is to buy additional servers to act as domain controllers. Another, less expensive answer might be to stagger the times at which employees’ workdays begin in 15-minute increments. In other cases, performance or time is the top priority, regardless of cost. One Change at a Time Remember the third commandment: Only implement one change at a time and assess the effects of that change before trying something else. This will save you much grief in the long run. Order of Implementation It makes sense to try the easiest solutions, the least time-consuming ones, the less expensive ones, and the least invasive ones first. If a patient complains of a minor headache, a doctor is likely to have him try taking a couple of aspirin to see if that relieves the symptom, rather than starting out with a more drastic treatment, like brain surgery. Monitoring Results The last official step in troubleshooting is to assess the results of your actions, determine whether your “fix” worked, whether it was 91_03.qx 2/25/00 10:59 AM Page 127 128 Chapter 3 • Windows 2000 TCP/IP Troubleshooting Guidelines only a temporary workaround or actually solved the problem, and what can be done to prevent the problem from recurring in the future. The assessment and follow-up stage should also include developing a succinct summarization of the problem and solution, which may be dis- seminated to any or all of the following: Superiors within the company: If the problem had significant or ongoing impact on the operation of the network, you may need to submit a report to your supervisors or management personnel. The affected user(s): One way to prevent problems in the future is to make them a learning experience for the users (as well as for you). Educate the users about what happened, inform them of anything they can do to prevent it from happening, or failing that, the best course of action for them to take if it does happen. The hardware or software vendor(s): If the problem indicates a failure of network hardware or a bug in a software component, you may want to notify the vendor. Submitting a formal report makes it more likely the problem and its solutions may be incorporated into the vendor’s own documentation, such as the Microsoft Knowledge Base. Your permanent records: Don’t forget to record the details in your log or journal, so that if the problem arises again—even if you’ve been promoted to a high-level upper-management jet-setting position and are not on hand when it happens—all the information will be there and time won’t be spent researching or engaging in the same trial-and-error experimentation all over again. Using Forms and Check lists Forms serve a useful purpose by helping you to organize your information at the same time you’re collecting it. A form that incorporates check lists can serve as a guideline for your queries, and helps ensure that you don’t forget something important. It can also speed up the troubleshooting process. Finally, the form itself can serve as the permanent record of what happened and how it was addressed. You can develop your own forms that contain fields specific to your company and its network, using the following sample form as a starting point. 91_03.qx 2/25/00 10:59 AM Page 128 Windows 2000 TCP/IP Troubleshooting Guidelines • Chapter 3 129 Network Troubleshooting Information Form Date: Time: Person reporting problem: Name/location of computer displaying problem: Briefly describe the nature of the problem as specifically as possible: History–former occurrences of this problem: Exactly what was being done on the computer when the problem occurred? What programs and processes were running when the problem occurred? What error messages (if any) were displayed? Was the computer restarted? ❏ restarted by operator ❏ automatic restart If the computer was restarted, did it boot into the operating system normally? If no, describe any problems, freezes, error messages, or unusual behavior upon reboot. Operating system: Version Domain/workgroup: 91_03.qx 2/25/00 10:59 AM Page 129 130 Chapter 3 • Windows 2000 TCP/IP Troubleshooting Guidelines Network Protocols installed (in order of binding): Network connectivity check: ❏ Network accessible via browse list ❏ Can connect to other computers via UNC path ❏ Can ping loopback ❏ Can ping local host ❏ Can ping another computer on same segment ❏ Can ping near side of router ❏ Can ping far side of router ❏ Can ping host on a remote segment Error messages encountered in PING attempts: TCP/IP Configuration check list: ❏ DHCP client ❏ IP address ❏ Subnet mask ❏ Default gateway ❏ DNS primary Secondary ❏ WINS primary Secondary ❏ Advanced TCP/IP settings: ❏ MAC address ❏ Protocol Analysis: Tool Used Results: Hardware/Physical environment check list: ❏ NIC ❏ Hub(s) ❏ Router(s) ❏ Cables ❏ Power ❏ Temperature ❏ Humidity ❏ EMI/RFI/ESD 91_03.qx 2/25/00 10:59 AM Page 130 Windows 2000 TCP/IP Troubleshooting Guidelines • Chapter 3 131 Antivirus: Updated Virus check run: Event Logs: significant entries: Narrative (in chronological order, describe your response to the problem): Diagnosis: Solution: Recommended follow-up: Summary In this chapter, we covered some general principles of troubleshooting and problem-solving and discussed ways of applying them to our jobs as network support professionals. We discussed the Ten Commandments of Troubleshooting: 1. Know thy network. 2. Use the tools of the trade. 3. Take it one change at a time. 4. Isolate the problem. 5. Recreate the problem. 6. Don’t overlook the obvious. 7. Try the easy way first. 91_03.qx 2/25/00 10:59 AM Page 131 [...]... 1 533 DHCP Options and BOOTP Vendor Extensions 1 534 Interoperation Between DHCP and BOOTP 1541 Dynamic Host Configuration Protocol (DHCP) 1542 Clarifications and Extensions for the Bootstrap Protocol 1547 Requirements for Point-to-Point Protocol (PPP) 1548 Point-to-Point Protocol (PPP) 1549 PPP in High-level Data Link Control (HDLC) Framing 1552 PPP Internetwork Packet Exchange Control Protocol (IPXCP)... for Low-Speed Serial Links 1157 Simple Network Management Protocol (SNMP) 1179 Line Printer Daemon Protocol 1188 IP over FDDI 1191 Path MTU Discovery 1201 IP over ARCNET 1 231 IEEE 802.5 Token Ring MIB (MIB-II) 1256 ICMP Router Discovery Messages 132 3 TCP Extensions for High Performance 133 2 PPP Internet Protocol Control Protocol (IPCP) 133 4 PPP Authentication Protocols 1518 An Architecture for IP Address... Architecture s IP in Windows 2000 s TCP and UDP in Windows 2000 s IPSec s TCP/IP Registry Settings 135 91_tcpip_04.qx 2/25/00 10:57 AM Page 136 136 Chapter 4 • Windows 2000 TCP/IP Internals Introduction Microsoft has rewritten and enhanced its TCP/IP stack on several occasions The protocols that were extensively redesigned for NT 3. 5 have evolved with each improvement to the corporate operating system,... Subnetting Procedure 959 File Transfer Protocol (FTP) 1001, 1002 NetBIOS Service Protocols 1009 Requirements for Internet Gateways 1 034 , 1 035 Domain Name System (DNS) 1042 IP over Token Ring 1055 Transmission of IP over Serial Lines (IP-SLIP) 1112 Internet Group Management Protocol (IGMP) 1122, 11 23 Host Requirements (communications and applications) 1 134 Point-to-Point Protocol (PPP) 1144 Compressing TCP/IP... can capture packets not only from the machine on which it’s installed but also those sent to and from other machines on the network, is part of Microsoft’s Systems Management Server 91_ 03. qx 2/25/00 10:59 AM Page 134 91_tcpip_04.qx 2/25/00 10:57 AM Page 135 Chapter 4 Windows 2000 TCP/IP Internals Solutions in this chapter: s Windows 2000 Enhancements to the TCP/IP Stack s Windows 2000 TCP/IP Architecture... Management Protocol (IGMP), version 2, which supports IP multicasting Microsoft has also added new features to make Windows 2000 their most TCP/IP-friendly operating system yet TCP/IP is the native network/transport protocol for Windows 2000 and is installed by default when you install the operating system RFC Compliance The Windows 2000 implementation of Microsoft TCP/IP supports a large number of... increase our efficiency, and provided a sample form that network administrators can customize for use in their own companies 91_ 03. qx 2/25/00 10:59 AM Page 133 Windows 2000 TCP/IP Troubleshooting Guidelines • Chapter 3 133 FAQs Q: Why is it important to follow a model or set of steps in troubleshooting? A: Adopting a problem-solving model and proceeding through the steps in a methodical manner, in... in the Windows 2000 implementation The focus in Windows 2000 has been on creating a TCP/IP stack that is scalable, in keeping with Windows 2000 s intended use in enterprise networks, and one that is versatile, easy to administer, and performs well Windows 2000 still supports the features that made the Windows NT TCP/IP stack easy to work with, such as IP routing and Internet Group Management Protocol...91_ 03. qx 2/25/00 10:59 AM Page 132 132 Chapter 3 • Windows 2000 TCP/IP Troubleshooting Guidelines 8 Document what you do 9 Practice the art of patience 10 Seek help from others We discussed the many sources of troubleshooting documentation available for Windows 2000 administrators, both from Microsoft and from third parties We looked at the new and vastly improved Help file system, and the printed... various aspects of how the protocols work RFCs are used to describe Internet standards, and go through a formal approval process before being adopted Microsoft states that Windows 2000 TCP/IP supports the following RFCs: 768 7 83 791 792 7 93 816 826 854 862 8 63 864 865 867 894 User Datagram Protocol (UDP) Trivial File Transfer Protocol (TFTP) Internet Protocol (IP) Internet Control Message Protocol (ICMP) . 2000 TCP/IP Internals Solutions in this chapter: ■ Windows 2000 Enhancements to the TCP/IP Stack ■ Windows 2000 TCP/IP Architecture ■ IP in Windows 2000 ■ TCP and UDP in Windows 2000 ■ IPSec ■ TCP/IP. Point-to-Point Protocol (PPP) 1548 Point-to-Point Protocol (PPP) 1549 PPP in High-level Data Link Control (HDLC) Framing 1552 PPP Internetwork Packet Exchange Control Protocol (IPXCP) 91_tcpip_04.qx. (MIB-II) 1256 ICMP Router Discovery Messages 132 3 TCP Extensions for High Performance 133 2 PPP Internet Protocol Control Protocol (IPCP) 133 4 PPP Authentication Protocols 1518 An Architecture for IP Address