CHAPTER 10: Network Management 516 FIGURE 10.16B Sample PacketTrap Perspective capture (Permission granted by PacketTrap Perspective) FIGURE 10.16C Sample Event Viewer display Self Test 517 FIGURE 10.16D Sample diagram of a network When planning and establishing your local policies and procedures 14. you have to recognize that some state and/or federal regulations might apply to your organization. You are working at the local county hospital; which of the following regulations should your organization need to be aware of? A. HIPAA B. Sarbanes-Oxley Act of 2002 C. ISO/IEC 27002:2005 D. All of the above You have been delegated the responsibility of creating all of your 15. network’s documentation. As you research this topic you find out that you must create CM documentation. What types of CM docu- mentation must you create? A. Wiring schematics, physical/logical network diagrams, baselines, policies, procedures, configurations, and regulations B. Wiring schematics, physical/logical network diagrams, load bal- ancing, policies, procedures, configurations, and cache engines C. Wiring schematics, technical network diagrams, baselines, poli- cies, procedures, configurations, and regulations D. Building schematics, physical/logical network diagrams, base- lines, policies, procedures, configurations, and regulations CHAPTER 10: Network Management 518 SELF TEST QUICK ANSWER KEY A1. D2. C3. D4. B5. C6. A7. A8. B9. D10. B11. D12. C13. D14. A 15. 519 CHAPTER 11 EXAM OBJECTIVES IN THIS CHAPTER A TROUBLESHOOTING METHODOLOGY 520 THE OSI MODEL 525 WINDOWS TOOLS 529 LINUX TOOLS 553 NETWARE TOOLS 557 OTHER NETWORK TROUBLESHOOTING TOOLS 558 IMPORTANCE OF NETWORK DOCUMENTATION 561 INTRODUCTION Throughout this exam guide, we’ve talked about the fundamentals of network protocols and network operating systems. In this chapter, we’ll bring together that knowledge to help you in troubleshooting any errors or problems that occur on your network. We’ll begin by talking about the overall methodology that you’ll use to troubleshoot a network. This begins with gathering infor- mation about a problem to try to determine its cause. You’ll then use your understanding of networking concepts as well as your knowledge of how your particular network is configured, to isolate the point where the problem is occurring. By eliminating points of failure in a systematic fashion, you can eliminate trouble spots one by one, until you’ve located the cause of the problem. Maintaining accurate documentation of the physical layout of your network is essential for this process, as is having a firm grasp of the layers of the Open Systems Interconnect (OSI) model and the devices that operate at the various layers. To help you in troubleshooting your network, there are many software utilities for both the Windows and Linux operating systems that will assist you in pinpointing the exact nature of a failure. You’ll start with tools that will test basic network connectivity to determine if two computers can communicate with each other in any way. You can then move onto more Network Troubleshooting Tools CHAPTER 11: Network Troubleshooting Tools 520 detailed tools that will show you every aspect about the path that a network packet takes to travel from one computer to another, or to gather detailed information about name resolution issues. You also have access to a wide range of testers for physical network components such as network cables and wall jacks. By combining a broad understanding of networking concepts with specific knowledge of the different troubleshooting tools available to you, you will be able to effectively troubleshoot any issues you might face when administering a network. A TROUBLESHOOTING METHODOLOGY Before we talk about specific tools and utilities that you can use to trouble- shoot your network, it’s important that you have an overall structure in place that will help you perform that troubleshooting. Unfortunately, networking technologies haven’t advanced to the point that a router will flash up an error message like, “My default gateway is misconfigured, please correct this.” Instead, it is up to you to determine what a problem is before you’ll be able to go about fixing it. When you’re troubleshooting a problem relating to network connectivity, you need to have an understanding of your network as a whole so that you can determine where the trouble is occurring. One of the key factors in network troubleshooting is isolating the issue to figure out whether it’s being caused by a single workstation or cable, or if it’s a larger issue affecting numerous users on your network. You can break down the troubleshooting process into two major steps: Gathering information Analyzing the information you’ve gathered Gathering Information About a Problem To troubleshoot a problem, you first need to identify the problem. This can be a challenge when you’re trying to gather information from different users on your network, especially if you’re dealing with a situation where you’re receiving reports of multiple problems at the same time. You need to determine which component of your network is causing the issue; this can be a physical component like a network cable, or a logical component like the Internet Protocol (IP) configuration for a particular network interface card (NIC). You’ll use the information you gather to determine which component of your network has failed or is misconfigured. A Troubleshooting Methodology 521 Your first step should be to gather information from your users about the nature of the problem. Some questions you’ll probably want to ask include the following: 1. What is the exact nature of the problem? Try to be as specific as possible when making this determination. For example, you may get a report that your users are unable to browse external hosts on the Internet. To get a better understanding of the problem, you need to determine if they have lost all physical connectivity to the outside world, or if it’s only a specific application that isn’t functioning. Your troubleshooting steps will be different if a user can ping outside hosts, but not connect to a specific Web server, versus not being able to connect to the outside world in any way. 2. How many computers are affected by this problem? If the issue is isolated to a single computer, it is likely that the cause of the problem will be related to the computer itself. If it is affecting all computers on a particular subnet or those connected to a particular hub or switch, you can use this information to help you in the troubleshooting process. You can probably tell from this that your troubleshooting will be far more successful if you have detailed information about your network’s physical topology. Because of this, one of the most critical documents you can have on hand when troubleshooting, is a network dia- gram detailing the physical layout of your network. You should also maintain some type of database containing the IP address configuration of your routers, switches, servers, and worksta- tions. 3. When did the problem begin to occur? More specifically, you should find out what changed on the network when the issues first began. If your users began to experience connectivity issues after you installed a new router, your first step will be to check the configuration of the router. Sometimes this can take a certain amount of investigation, as you may not be aware of everything that’s being administered or modified on a large network. Your Internet Service Provider (ISP) might have made some changes that you’re not aware of, which might be caus- ing the connectivity failures. CHAPTER 11: Network Troubleshooting Tools 522 Analyzing and Responding to a Problem Now that you’ve collected information about the problem, you need to analyze all of it to determine the cause. You should examine every layer in the OSI model starting at Layer 1. Check your physical layer connec- tivity, such as cables, patch panels, wall jacks, and hubs. Work your way up to Layer 2, verifying that any switches or switch ports are configured properly. At Layer 3 you’ll verify that your routers are configured and func- tioning properly, and then move onto troubleshooting the actual application itself at the transport layer and beyond. In almost all cases, it’s best to start at the physical layer and work your way up so that you’re eliminating the lowest common denominator as a potential issue before moving onto more complex troubleshooting problems. If two computers aren’t communicating simply because a cable is unplugged, you can save yourself quite a bit of time by starting with the physical layer and working up from there. You’ll then want to determine the proper troubleshooting tool to use. We’ll spend the majority of this chapter talking about the different tools available for your use, but as a rule you should start with basic connectivity tools like ping, moving on to other tools once you’ve determined that basic connectivity is in place. The reason we start with ping is because it is simple to use and lets you determine at a glance if two nodes on your network are able to communicate with each other at the most basic level. It also very effectively slices the OSI model in half for you in terms of troubleshooting, because ping operates at the network layer. For example, if you are able to ping a remote host but you cannot File Transfer Protocol (FTP) to it, then you know that the issue lies somewhere above the network layer, because otherwise ping would not be successful. If the ping is unsuccessful, then you know that the issue lies in the network, data link, or physical layers. In Exercise 11.1, we’ll look at a common situation where you might use that you’re troubleshooting a connectivity problem between Computer A, with an IP address of 192.168.1.1 and subnet mask of 255.255.255.0, and Computer B with an IP address of 192.168.2.5 and a subnet mask of 255.255.255.0 – this is illustrated in Figure 11.1. These two computers FIGURE 11.1 Connectivity Diagram. ping to investigate a connectivity problem between two computers. Let’s say A Troubleshooting Methodology 523 were able to communicate with each other yesterday, but the two comput- ers haven’t been able to connect because some changes were made on the network. EXERCISE 11.1 Troubleshooting a Connectivity Issue Examine Figure 11.1. The two workstations depicted in the diagram are not able to communicate. They were able to communicate yesterday, but some changes have been made on the network and they are no longer able connect to each other. The first thing you should do is go to Computer A and check 1. things out for yourself. Use Computer A to ping 192.168.2.5, the IP address of Computer B, to confirm that the two computers are unable to communicate. If you don’t receive a response from Computer B, you need to 2. isolate where the failure is taking place. So your next step is to ping the loopback address, 127.0.0.1. You should remember from that the loopback address is a virtual IP address that’s used for troubleshooting the Transmission Control Protocol/Internet Protocol (TCP/IP) installation on a local PC. If you are unable to ping the loopback address, then TCP/IP is either not installed or has become corrupted on the local computer. If this ping is successful, the problem does not lie in the TCP/IP stack of Computer A. Next, try pinging another machine on the same network segment 3. as Computer A, such as 192.168.1.2. If you get a response from another machine on the same segment, you know that your local machine’s TCP/IP stack is functioning properly, and that Computer A is able to connect to other computers on the same subnet – this rules out a malfunctioning NIC or network cable at the physical layer. Next, ping the default gateway for Computer A to determine if the default gateway is functioning. If your default gateway responds, try pinging another host on 4. the same network segment as Computer B, the computer that’s failing to respond. If you get a response from another computer on Computer B’s network segment, you know that there are no problems related to Computer B’s network segment itself. If all of your tests thus far have been successful, but you are still 5. unable to contact Computer B, then you have isolated the problem to CHAPTER 11: Network Troubleshooting Tools 524 Computer B itself. Perhaps the network cable connecting Computer B to the network has gone bad, its network card has failed or needs a new driver installed or its IP configuration is incorrect. By approaching the problem systematically, you were able to trace the network connectivity from one end of the path (Computer A) to the other (Computer B). Testing at each step of the journey allowed you to isolate exactly where the problem was occurring. CONFIGURING AND IMPLEMENTING Prioritizing Multiple Issues Sometimes, you’ll encounter a troubleshooting situ- ation where you have several problems happening all at once. In fact, this is not uncommon because multiple problems will often be created by the same root cause. When multiple problems occur simulta- neously, it’s important to focus on the problem that has the greatest impact on users. For example, if some of your users are reporting a complete inability to access any resources, and others are reporting that their network access is only slightly slow, the two problems may or may not be related. You should troubleshoot the computers that are experiencing a total lack of network access first, because restoring network connectivity is more critical than removing the occasional occurrence of lag on an otherwise working connection. Network Discovery Now, in a perfect world you’ll be administering a network that someone has already created detailed configuration diagrams for, so that you’ll know exactly what you’re working with when you need to troubleshoot a problem. In reality, though, we’re usually not that lucky, and network administrators often find themselves taking over networks that have little or no documen- tation in place, or documentation that hasn’t been kept up to date. Luckily, there are a number of tools that you can use to perform network discovery, which will help you to automatically generate documentation about the devices on your network and how they are configured. These network dis- covery tools will examine a single IP address or an entire subnet and gather as much information about the devices on that subnet as possible, including their IP addresses, Media Access Control (MAC) addresses, what type of operating system the device is running, and even what types of applications are installed on the device if it is a server or a workstation computer. There are a number of products available that will perform network dis- covery for you, though the majority of them are paid commercial software and The OSI Model 525 are not available as free downloads. One such product is Lan MapShot from Fluke Networks and another suite of tools is from SolarWinds that includes an IP Network Browser to perform automatic network discovery, as shown in Figure 11.2. If you are taking over a network that has poor or nonexistent net- work documentation in place, it’s strongly advisable to invest in one of these network discovery tools; the amount of time it will save you in troubleshoot- ing network connectivity issues will more than pay for the cost of the tool. THE OSI MODEL As you have learned, the OSI model creates a framework that defines how networking protocols like TCP/IP communicate. Network packets are passed from the physical layer up to the application layer, with each layer adding its FIGURE 11.2 SolarWinds IP Network Browser. . be related to the computer itself. If it is affecting all computers on a particular subnet or those connected to a particular hub or switch, you can use this information to help you in the. You’ll then use your understanding of networking concepts as well as your knowledge of how your particular network is configured, to isolate the point where the problem is occurring. By eliminating. like a network cable, or a logical component like the Internet Protocol (IP) configuration for a particular network interface card (NIC). You’ll use the information you gather to determine which