Identifying and Troubleshooting Client Connectivity Problems


Client connectivity errors are one of the most common sources of network-related problems. Issues range from plain old user error to more complex protocol and cabling issues. Sometimes, even administrators make mistakes that can impact users! With so many possibilities, it is no wonder that client connectivity persists as one of the biggest network troubleshooting hotspots.

Protocol Errors

The client system must have a protocol assigned or bound to its NIC in order to access resources. You can use various tools to verify that a protocol is being used by the systemfor example, on Windows 2000/XP/2003 systems, you use the ipconfig command; on older Windows client systems, you use the winipcfg command; and on Linux, UNIX, and Macintosh systems, you can use the ifconfig command.

Protocol-Specific Issues

You need to consider a number of factors related to network protocols when you troubleshoot a client connectivity. The following list describes some of the protocol-specific issues you should consider in such a situation:

  • Transmission Control Protocol/Internet Protocol (TCP/IP) For a system to operate on a TCP/IP-based network, it must have at the very least a unique IP address, the correct subnet mask for the network to which it is connected, and (for cross-network connectivity) a default gateway entry. In addition, Domain Name Service (DNS) server addresses might be required.

  • Internetwork Packet Exchange/Sequenced Packet Exchange (IPX/SPX) Each system on an IPX/SPX network must have a unique address, although the addresses are generated and assigned automatically. On older networks, care must be taken to ensure that the correct frame type is being used, although systems are usually able to autodetect the frame type that is in use.

  • Network BIOS Extended User Interface (NetBEUI) Each system on a network that uses NetBEUI must have a unique name to identify the computer on the network. For name resolution between network segments, a network needs either a Windows Internet Naming System (WINS) server or manual name resolution through an LMHOSTS file.

  • AppleTalk Each system on an AppleTalk network must have a unique address. If AppleTalk over TCP/IP is being used, ensure that the system is configured with a valid IP address, subnet mask, and (if needed) a default gateway.

Remember that Windows systems use APIPA. If they are configured to use DHCP but cannot obtain an address from a server, they will self-assign an IP address from the 169.254.x.x range. Non-APIPA systems that cannot obtain an IP address from a DHCP server will typically self assign an IP address of 0.0.0.0.


When protocol settings are correctly configured, protocol problems are infrequent. Unless settings are manually changed, very little can go wrong.

Authentication

Before users can log on to any system, their identities must be verified. By far the most common type of authentication used is the standard username and password combination. When a user account is created, it is good practice for the administrator to set a password. The user should change that password immediately so that the administrator no longer knows it.

With the exception of Novell NetWare, all the operating systems covered in the Network+ exam use case-sensitive passwords.


Most user password problems can be traced to users entering an incorrect password or entering the correct password incorrectly. All common operating systems offer the ability for the administrator to change a user's password, but none offer the capability to determine the user's existing password. Therefore, if a user does forget his or her password, a new one has to be created and issued.

Permissions Errors

Access to applications and data across the network is controlled by permissions. Permissions are responsible for protecting the data on the network and ensuring that only those who should have access to it do.

The first rule of permissions troubleshooting is to remember that permissions do not change themselves. If a user cannot access a file, the first question to the user should always be, "Could you ever access the file?" If the user says, "Yes, but now I can't access the file," you should check server change logs or documentation to see if any changes have been made in the permissions structure.

If no changes have been made, you should verify that the user is in fact allowed access to that file or directory. In large environments, trying to keep track of who should have access to what can be a tricky businessone that is best left to defined policies and documentation.

The following are some other items you should consider when troubleshooting permissions problems:

  • On some operating systems, rights and permissions can be inherited from parent directories or other directories that are higher in the directory structure. A change in the permissions assignments at one level might have an effect on a lower level in the directory tree.

  • File permissions can be gained from objects other than the user's account. Depending on the operating system being used, rights can also be gained from group membership, other network objects, or security equivalence. When you are troubleshooting a permissions problem, be sure that you understand where rights are supposed to originate.

  • File attributes can override file permissions, and they can prevent actions from being performed on certain files. To the uninitiated, this might seem like a file permissions problem, but in fact it is correct operation.

As with many other IT troubleshooting scenarios, you can solve most permissions problems effectively if you fully understand what you are troubleshooting and the factors that affect the situation. Also in common with other troubleshooting scenarios, you need to approach the problem methodically.

Physical Connectivity Errors

Although many of the problems associated with client connectivity can be traced to software-based problems such as configuration, authentication, and permissions issues, physical connectivity is often the root of the problem.

When you are troubleshooting physical connectivity errors, the first place to look is at the network cables. Although it is rare, cables can become loose or disconnected from NICs or from the ports on a hub or switch. Oftentimes, this is the result of other cables being plugged in or unplugged, or of other activity on the connections around the one that is having the problem. Other cable considerations include exceeded maximum lengths, cable breaks, and improperly terminated or made cables, although these are only a consideration in exceptional cases.

Physical connectivity errors also involve the devices used to establish the physical client/server connectivity. This can include hubs, switches, MSAUs, NICs, routers, and connectivity hardware. Although it is possible to have a problem with a single port on one of the aforementioned devices, it is more likely that the entire unit will malfunction. Thankfully, networking devices are very resilient devices that provide many years of service with few or no problems.



    Network+ Exam Cram 2
    Network+ Exam Cram 2
    ISBN: 078974905X
    EAN: N/A
    Year: 2003
    Pages: 194

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net