Troubleshooting TCPIP Addressing
Troubleshooting TCP/IP Addressing
For this objective, you are responsible for knowing how to troubleshoot basic client-based TCP/IP issues. This means that you must know all the things that can go wrong on a client workstation based on IP addressing and the ways to isolate these problems as well as to resolve them. You have to know basic TCP/IP troubleshooting techniques as well as ways to figure out whether the problem is DHCP based. Troubleshooting Client Computers
When troubleshooting client-based TCP/IP problems, you really need to develop a good troubleshooting methodology; otherwise , you will just be wasting your time. You have to know what to check in what order, based on certain triggers you are looking for. For example, if a user tells you that she cannot log in to the network, that information is a trigger for a troubleshooting methodology. If the user cannot log on, you should then think about what the problem could be. Is only one user unable to log on, or are more users having the same problem? I usually ask this question first because if all the users are unable to log on, it's a big problem. Assuming only this user is unable to log on, you may be prompted to ask whether she keyed in the proper password, whether she had Caps Locks on, or whether she entered her password wrong a few times and locked herself out. If none of these are the case, your troubleshooting usually warrants a walk down to the user's desk for some investigation. From that trigger, you find out that not everyone has this problem; it is isolated to just this user. You also figure out that this is not a problem with a server; it is a problem with the client workstation. The user checked to make sure that she had the PC powered on and that she was, in fact, at the login screen and could not log in, even after checking to see whether she had used Caps Locks. Now, you have a problem. When you get to the user, you can try to repeat her steps first, then check her password again, and so on. After you move past these common problems, you can turn your attention to the network connection. You look at the back of the PC to check the link lights on the NIC and find that they are not on. You then check the cable plugged into the back of the PC, directly into the NIC. Lastly, you move to the wall jack where the cable plugs into the wall to find it dislodged. Somehow it became unplugged. After you plug it back in and check the link lights on the NIC, the user is able to log on to the network a few seconds later. The whole point behind this story is that a problem triggered a chain of responses from you to solve that problem. Let's look at an IP-based issue now. If you have a server that cannot get on the network, and you are able to isolate the problem down to the bottom two layers (Network Access or Physical and Data Link), your only other option is to start troubleshooting layer three. So, how would you troubleshoot? First, look at any client that cannot access the network and for which you have isolated a layer three problem. What would you do? You can use the ping command as follows from the workstation to see what the problem could be: C:\> Ping 10.10.10.1 with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for 10.10.10.1: Packets: Sent = 4, Received = 0, Lost = 4 <100% loss>, Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average= 0ms C:\> Ping 10.10.5.1 with 32 bytes of data: Reply from 10.10.5.1: bytes=32 time=10ms TTL=255 Reply from 10.10.5.1: bytes=32 time=10ms TTL=255 Reply from 10.10.5.1: bytes=32 time=10ms TTL=255 Reply from 10.10.5.1: bytes=32 time=10ms TTL=255 Ping statistics for 10.10.5.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 10ms, Maximum = 10ms, Average = 10ms Here, you can see the output of a simple ping command run to test the default gateway of a LAN. The ping tool is used to test IP connectivity to other hosts on the network. You use ping (which uses Internet Control Message Protocol, or ICMP, echo-based error reporting) to get an idea of what may be wrong. In this case, the ping to a default gateway timed out. You ping this device because you need to see whether the network has IP connectivity. As you can see from this output, it does not. This example also pings another host on the network, which is a mainframe in the same VLAN. As you can see, the problem doesn't have anything to do with the workstation, which you may have assumed. The problem lies with the default gateway, which is bad. This result means something may be wrong with the router. Are you beginning to understand how troubleshooting works? Problems can go many ways, so the best way to arm yourself is to memorize not only the tool, but also the methodology behind it to isolate and resolve problems, and to identify the triggers you get from others that help you to reduce your troubleshooting time. You can, of course, use other tools such as ipconfig . Typing this command at the command prompt provides a great deal of information, as you can see here: Windows 2000 IP Configuration Ethernet adapter Local Area Connection: Connection-specific DNS Suffix . : rsnetworks.net IP Address. . . . . . . . . . . . : 192.168.2.100 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.2.1 EXAM TIP ipconfig questions Be prepared to look for questions with an ipconfig output like the example shown here. You may be shown an ipconfig screen with an IP address of 192.168.2.100 and a topology map that shows you trying to communicate on a subnet of 192.168.1.0. It should be obvious to you now that you are not able to communicate if you are not on the same subnet. The ipconfig command returns your IP address, DNS domain, subnet mask, and default gateway. All this information is very important to troubleshooting client computers. If you do not see the proper information (such as an IP address of 0.0.0.0), you likely have some sort of problem. There are a host of switches that can be used with the ipconfig command. Here, we cover only the /all switch. This switch, when used in conjunction with ipconfig , gives you even more TCP/IP-based information. We looked briefly at the use of this switch earlier in the chapter; remember that this switch provides more detailed information, such as DHCP, DNS, and WINS servers used, as well as your physical address and DHCP lease information. Understanding this command is important not only for the exam, but also for your job because you will be using it all the time. We cover the ipconfig command further in the following sections, where we cover more switches as they relate to DHCP and DNS. Troubleshooting DHCP Server Issues
Working through DHCP client-based issues is actually easy. The available scope either doles out an IP address to you, or it doesn't. It's that easy. You know if a client is configured to accept an IP address by using the ipconfig /all command. The results show a DHCP-enabled column with either Yes or No selected. If you see Yes, and you don't have an IP address assigned, you can try a few options. Always start with the easiest option first. You should consider ipconfig your tool of choice when trying to troubleshoot IP-based problems on clients and servers alike. When you want to troubleshoot a DHCP server issue, you can simply use one of the following two ipconfig switches: ipconfig/ release ipconfig/ renew The release switch releases the IP address for the specified adapter, and likewise, the renew switch asks the DHCP server to renew the lease and to get your IP address back so you can participate on the network. If you do not receive an answer from your DHCP server, you may have one of a few different problems. You may not have client connectivity, so you must make sure that you do. You cannot ping anything because you do not have an IP address, and you need that to communicate to the other host via ICMP. You can statically assign an IP to verify connectivity. You can also see whether you are on a segment with a DHCP server. If not, you may need an IP helper address assigned to the router; the helper agent is also known as a DHCP relay agent , which pushes the DHCP-based broadcasts over the router and points them to the DHCP server on the appropriate segment where it is located. If this relay agent is not configured, your client more than likely will not get a DHCP address. These are the most common issues you are likely to see on the 70-293 exam, and also in production environments. |
EAN: 2147483647
Pages: 151