Troubleshooting Remote Connectivity Errors
Given a troubleshooting scenario involving a remote connectivity problem (e.g., authentication failure, protocol configuration, physical connectivity) identify the cause of the problem.
As networks have moved away from single locations and telecommuting has increased in popularity, a new world of troubleshooting has opened up: that of remote connectivity errors. Remote connectivity errors are bugs that prevent you from dialing in to the office, remotely dialing in to your home computer, or logging on to your ISP. People have come to rely on the ability to remotely access the office, and the Internet has become so closely integrated with modern business that many organizations come to a standstill without it.
Although many means and methods are available for establishing remote connectivity, network administrators can focus their attention on three hot spots when troubleshooting errors: authentication failure, protocol configuration problems, and physical connectivity problems.
Troubleshooting Authentication Failure
Authentication problems are typically the first place to look when a user is experiencing remote connectivity errors. All forms of remote connectivity should require some form of authentication to confirm that those trying to access the remote resources have permission to do so. Most of us are aware of authentication in the form of usernames and passwords.
As a network administrator, you can expect to become very familiar with authentication troubleshooting. Quite often, authentication errors result from users incorrectly entering usernames and/or passwords. As you might expect and hope, when this happens, users are unable to access the network. Many systems use case-sensitive passwords; when you are troubleshooting authentication failure, be sure you know whether case-sensitive passwords are required.
Authentication issues can also arise as a result of permissions changes in users' accounts. In all kinds of networks, network administrators need to sometimes make changes to accounts. Whether due to security reasons, network maintenance, or an accident, at some point accounts change. When incorrect changes to accounts are made, it is the responsibility of the network administrator to correct them before the user tries to log on, or at least to notify the user of a potential problem. If you're troubleshooting remote connectivity and you have confirmed that the correct username and password are used, you should confirm that everything is as it should be with the user's account.
EXAM TIP
Caps Lock If you're troubleshooting authentication failure, you should ensure that Caps Lock is turned off on the keyboard.
The third and perhaps least likely cause for authentication failure is a downed authentication server. If the server providing the authentication for the remote access goes down, then no one who is authenticated through that server will be able to log on. In such a circumstance, you are likely to receive numerous calls regarding authentication difficulty—not just one or two.
NOTE
Authentication Example Scenario Suppose you are employed to provide telephone support for a large ISP. A customer calls, complaining that she is unable to dial in to your ISP service and access the Internet.
Authentication Example Solution When isolating remote connectivity errors, you should first determine whether customers are using the correct authentication information. In this case, it would be necessary to confirm that the correct username and password are being used. If you are using an authentication system that is case sensitive, you should ensure that the correct case is being used.
Troubleshooting Physical Connectivity Problems
When you're troubleshooting remote connectivity errors, it is often easy to forget the most basic troubleshooting practices. By this we mean ensuring that all the physical connections are in place. When you suspect a physical connectivity problem, here are a few key places to look:
Faulty cable— Either through accident or by wear and tear, sometimes cables break. If you suspect a faulty cable as the cause of a connectivity error, replace the cable with one that is known to be working to confirm your suspicion.
Improperly connected cable— Troubleshooting a connectivity issue might be as simple as plugging in a cable. You should ensure that all cables are securely attached to the correct ports.
Incorrect cable— If you are troubleshooting a new connection, you should make sure the correct cable is being used.
Faulty interface— A faulty network card can stop data flow in a hurry.
Faulty networking devices— Hubs, switches, and routers may be the sources of your problem; just because the lights are on, don't assume that a device is working correctly. If possible, substitute the device for one that is known to be working so that you can eliminate it from your inquiries.
NOTE
Physical Connectivity Example Scenario One of your company's remote users calls you and is angry that he is unable to dial in and access the local network from his remote location. He insists he is using the correct username and password.
Physical Connectivity Example Solution When you receive calls for remote connectivity errors, try to think of problems that are associated with physical connectivity. If the user is accessing a remote location using a modem, confirm that the modem is correctly cabled both in the computer and into the phone jack. If the user requires a network card to access remote services, ensure that the network cable is installed correctly. You can also try a different jack and phone cable.
You should also try these troubleshooting measures:
Use observation techniques and connectivity tools— You should approach physical connectivity problems in a methodical manner and use tools such as ping to locate problems. Most networking devices have indicator LEDs that you can use to determine the status of the device.
Be aware of EMI and crosstalk— As discussed in Chapter 2, you must be aware of the effects of electromagnetic interference (EMI) and crosstalk on network media. If you have an intermittent or hard-to-trace problem, you should certainly consider this factor.
Troubleshooting Protocol Configuration Problems
Many, but not all, of the problems you encounter with remote connectivity can be addressed with the measures listed previously. You might encounter a time when you have confirmed that the network user is using the correct username and password combination, that no changes have been made to the user's account information, that all physical connections are in place, and that the user still cannot establish a remote connection.
The next most likely client connectivity problem is protocol configuration. Protocol configuration issues are usually on the client side of the network. Each client computer must have a unique address in order to participate on the network. Failure to obtain addressing information could indicate a problem with a DHCP server. You should check the DHCP server to make sure it is functioning and that addresses are available for assignment.
NOTE
Unauthorized Configurations Some operating systems are better at protecting against unauthorized configuration changes than others. Windows 2000 and Linux, for example, require special rights to change network configurations. Windows 95 and Windows 98, on the other hand, do not. If you are working on an operating system that does not control reconfigurations, be sure to check carefully for changes.
One of the most frustrating troubles to deal with as an administrator is duplicate IP addresses. This problem is usually is the result of manually assigning IP addresses or improperly configuring subnet assignments on multiple DHCP servers. As mentioned earlier in this chapter, you can use the arp command along with the ping utility to find MAC addresses that have the same IP address.
Administrators should also be aware of whether the network operating system will automatically assign private IP addresses when the DHCP server cannot be located. On a Windows 2000 network, if the client runs ipconfig and reports an IP address beginning with 169, then you know the client has been provided with a private IP address, and this means the DHCP server is either down, unreachable, or has run out of available IP addresses for assignment.