Troubleshooting Connectivity of WAN

· Troubleshooting with Diagnostic Utilities

· The Trace Route Utility (tracert/trace route)

· ping

· The Destination Host Unreachable Message

· The Request Timed Out Message

· The Unknown Host Message

· The Expired TTL Message

· Troubleshooting with ping

· ARP

· The net stat Command

· net stat e

· net stat -a

· net stat -r

· net stat s

· nbtstat

· The ipconfig Command

· ifconfig

· The winipcfg Command

· nslookup

· dig

· Interpreting Visual Indicators

· LEDs on Networking Devices

· LEDs on NICs and Other Devices

· Troubleshooting Remote Connectivity

· Troubleshooting Physical Connectivity

· DSL

· Cable Troubleshooting Procedures

· Home Satellite Troubleshooting Procedures

· Wireless Internet Access Troubleshooting Procedures

· POTS Troubleshooting Procedures

· Modem-Specific Troubleshooting

· Troubleshooting Authentication Failure

· Troubleshooting Protocol Configuration Problems

· Troubleshooting Small Office/Home Office Router

· Configuration

· Troubleshooting

· Identifying and Troubleshooting Client Connectivity Problems

· Protocol Errors

· Protocol-Specific Issues

· Authentication

· Permissions Errors

· Physical Connectivity Errors

· Troubleshooting Checklists

· Troubleshooting Cabling Problems

· Troubleshooting Operating System Connectivity

· Troubleshooting Network Printing

· Troubleshooting Data Access

· Troubleshooting NICs

Troubleshooting Connectivity

For anyone working with TCP/IP networks, troubleshooting connectivity is something that is simply going to have to be done. This tutorial identifies the tools that are used in the troubleshooting process and identifies scenarios in which these tools can be used.

Troubleshooting with Diagnostic Utilities

Many utilities can be used when troubleshooting TCP/IP. Although the actual utilities available vary from platform to platform, the functionality between platforms is quite similar. Table 1 lists the TCP/IP troubleshooting tools along with their purpose.

Table 1 Common TCP/IP Troubleshooting Tools and Their Purpose
Tool	Purpose
tracert/trace route	Used to track the path a packet takes as it travels across a network. tracert is used on Windows systems, trace route is used on UNIX, Linux, and Macintosh systems.
Ping	Used to test connectivity between two devices on a network.
Arp	Used to view and work with the IP address to MAC address resolution cache.
Net stat	Used to view the current TCP/IP connections on a system.
Nbtstat	Used to view statistics related to NetBIOS name resolutions, and to see information about current NetBIOS over TCP/IP connections.
Ipconfig	Used to view and renew TCP/IP configuration on a Windows system.
Ifconfig	Used to view TCP/IP configuration on a UNIX, Linux or Macintosh system.
Winipcfg	Graphical tool used to view TCP/IP configuration on Windows 95, 98, and Me.
nslookup/dig	Used to perform manual DNS lookups. nslookup can be used on Windows, UNIX, Macintosh, and Linux systems. dig can only be used on UNIX, Linux, and Macintosh systems.

The following sections look in more detail at these utilities and the output they produce.

The Trace Route Utility (tracert/trace route)

The trace route utility does exactly what its name implies it traces the route between two hosts. It does this by using Internet Control Message Protocol (ICMP) echo packets to report information back at every step in the journey. Each of the common network operating systems provides a trace route utility, but the name of the command and the output vary slightly on each. Table 2 shows the trace route command syntax used in various operating systems

Table 2 Trace Route Utility Commands
Operating System	Trace Route Command Syntax
Windows Server 2000/2003	tracert <IP address>
Novell NetWare	iptrace
Linux/UNIX	trace route <IP address>
Macintosh	trace route <IP address>

Trace route provides a lot of useful information, including the IP address of every router connection it passes through and, in many cases, the name of the router (although this depends on the router's configuration). Trace route also reports the length, in milliseconds, of the round-trip the packet made from the source location to the router and back. This information can help identify where network bottlenecks or breakdowns might be. The following is an example of a successful tracert command on a Windows 2000 system:

C:\>tracert 24.7.70.37

Tracing route to c1-p4.sttlwa1.home.net [24.7.70.37] over a maximum of 30 hops:

1 30 ms 20 ms 20 ms 24.67.184.1

2 20 ms 20 ms 30 ms rd1ht-ge3-0.ok.shawcable.net [24.67.224.7]

3 50 ms 30 ms 30 ms rc1wh-atm0-2-1.vc.shawcable.net [204.209.214.193]

4 50 ms 30 ms 30 ms rc2wh-pos15-0.vc.shawcable.net [204.209.214.90]

5 30 ms 40 ms 30 ms rc2wt-pos2-0.wa.shawcable.net [66.163.76.37]

6 30 ms 40 ms 30 ms c1-pos6-3.sttlwa1.home.net [24.7.70.37]

Trace complete.

Similar to the other common operating systems, the tracert display on a Windows-based system includes several columns of information. The first column represents the hop number. You may recall that 'hop' is the term used to describe a step in the path a packet takes as it crosses the network. The next three columns indicate the round-trip time, in milliseconds, that a packet takes in its attempts to reach the destination. The last column is the hostname and the IP address of the responding device.

Of course, not all trace route attempts are successful. The following is the output from a tracert command on a Windows Server 2003 system that doesn't manage to get to the remote host:

C:\>tracert comptia.org

Tracing route to comptia.org [216.119.103.72]

Over a maximum of 30 hops:

1 27 ms 28 ms 14 ms 24.67.179.1

2 55 ms 13 ms 14 ms rd1ht-ge3-0.ok.shawcable.net [24.67.224.7]

3 27 ms 27 ms 28 ms rc1wh-atm0-2-1.shawcable.net [204.209.214.19]

4 28 ms 41 ms 27 ms rc1wt-pos2-0.wa.shawcable.net [66.163.76.65]

5 28 ms 41 ms 27 ms rc2wt-pos1-0.wa.shawcable.net [66.163.68.2]

6 41 ms 55 ms 41 ms c1-pos6-3.sttlwa1.home.net [24.7.70.37]

7 54 ms 42 ms 27 ms home-gw.st6wa.ip.att.net [192.205.32.249]

8 * * * Request timed out.

9 * * * Request timed out.

10 * * * Request timed out.

11 * * * Request timed out.

12 * * * Request timed out.

13 * * * Request timed out.

14 * * * Request timed out.

15 * * * Request timed out.

In this example, the trace route request only gets to the seventh hop, at which point it fails; this failure indicates that the problem lies on the far side of the device in step 7 or on the near side of the device in step 8. In other words, the device at step 7 is functioning but might not be able to make the next hop. The cause of the problem could be a range of things, such as an error in the routing table or a faulty connection. Alternatively, the seventh device might be operating 100%, but device 8 might not be functioning at all. In any case, you can isolate the problem to just one or two devices.

The trace route utility can also help you isolate a heavily congested network. In the following example, the trace route packets fail in the midst of the tracert from a Windows Server 2003 system, but subsequently are able to continue. This behavior can be an indicator of network congestion:

C:\>tracert comptia.org

Tracing route to comptia.org [216.119.103.72]over a maximum of 30 hops:

1 96 ms 96 ms 55 ms 24.67.179.1

2 14 ms 13 ms 28 ms rd1ht-ge3-0.ok.shawcable.net [24.67.224.7]

3 28 ms 27 ms 41 ms rc1wh-atm0-2-1.shawcable.net [204.209.214.19]

4 28 ms 41 ms 27 ms rc1wt-pos2-0.wa.shawcable.net [66.163.76.65]

5 41 ms 27 ms 27 ms rc2wt-pos1-0.wa.shawcable.net [66.163.68.2]

6 55 ms 41 ms 27 ms c1-pos6-3.sttlwa1.home.net [24.7.70.37]

7 54 ms 42 ms 27 ms home-gw.st6wa.ip.att.net [192.205.32.249]

8 55 ms 41 ms 28 ms gbr3-p40.st6wa.ip.att.net [12.123.44.130]

9 * * * Request timed out.

10 * * * Request timed out.

11 * * * Request timed out.

12 * * * Request timed out.

13 69 ms 68 ms 69 ms gbr2-p20.sd2ca.ip.att.net [12.122.11.254]

14 55 ms 68 ms 69 ms gbr1-p60.sd2ca.ip.att.net [12.122.1.109]

15 82 ms 69 ms 82 ms gbr1-p30.phmaz.ip.att.net [12.122.2.142]

16 68 ms 69 ms 82 ms gar2-p360.phmaz.ip.att.net [12.123.142.45]

17 110 ms 96 ms 96 ms 12.125.99.70

18 124 ms 96 ms 96 ms light.crystaltech.com [216.119.107.1]

19 82 ms 96 ms 96 ms 216.119.103.72

Trace complete.

Generally speaking, trace route utilities allow you to identify the location of a problem in the connectivity between two devices. After you have determined this location, you might need to use a utility such as ping to continue troubleshooting. In many cases, as in the examples provided in this chapter, the routers might be on a network such as the Internet and therefore not within your control. In that case, there is little you can do except inform your ISP of the problem.

ping

Most network administrators are very familiar with the ping utility and are likely to use it on an almost daily basis. The basic function of the ping command is to test the connectivity between the two devices on a network. All the command is designed to do is determine whether the two computers can see each other and to notify you of how long the round-trip takes to complete.

Although ping is most often used on its own, a number of switches can be used to assist in the troubleshooting process. Table 3 shows some of the commonly used switches with ping on a Windows system.

Table 3 ping Command Switches
Option	Description
ping -t	Pings a device on the network until stopped
ping -a	Resolves addresses to hostnames
ping -n count	Specifies the number of echo requests to send
ping -r count	Records route for count hops
ping -s count	Timestamp for count hops
ping -w timeout	Timeout in milliseconds to wait for each reply

ping works by sending ICMP echo request messages to another device on the network. If the other device on the network hears the ping request, it automatically responds with an ICMP echo reply. By default, the ping command on a Windows-based system sends four data packets; however, using the -t switch, a continuous stream of ping requests can be sent.

ping is perhaps the most widely used of all network tools; it is primarily used to verify connectivity between two network devices. On a good day, the results from the ping command will be successful, and the sending device will receive a reply from the remote device. Not all ping results are that successful, and to be able to effectively use ping, you must be able to interpret the results of a failed ping command.

The Destination Host Unreachable Message

The Destination Host Unreachable error message means that a route to the destination computer system cannot be found. To remedy this problem, you might need to examine the routing information on the local host to confirm that the local host is correctly configured, or you might need to make sure that the default gateway information is correct. The following is an example of a ping failure that gives the Destination host unreachable message:

Pinging 24.67.54.233 with 32 bytes of data:

Destination host unreachable.

Destination host unreachable.

Destination host unreachable.

Destination host unreachable.

Ping statistics for 24.67.54.233:

    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Approximate round trip times in mille-seconds:

    Minimum = 0ms, Maximum = 0ms, Average = 0ms

The Request Timed Out Message

The Request Timed Out error message is very common when you use the ping command. Essentially, this error message indicates that your host did not receive the ping message back from the destination device within the designated time period. Assuming that the network connectivity is okay on your system, this is typically an indicator that the destination device is not connected to the network, is powered off, or is not configured correctly. It could also mean that some intermediate device is not operating correctly. In some rare cases, it can also indicate that there is so much congestion on the network that timely delivery of the ping message could not be completed. It might also mean that the ping is being sent to an invalid IP address or that the system is not on the same network as the remote host, and an intermediary device is not configured correctly. In any of these cases, the failed ping should initiate a troubleshooting process that might involve other tools, manual inspection, and possibly reconfiguration. The following example shows the output from a ping to an invalid IP address:

C:\>ping 169.76.54.3

Pinging 169.76.54.3 with 32 bytes of data:

Request timed out.

Ping statistics for 169.76.54.3:

Packets: Sent = 4, Received = 0, Lost = 4 (100%

Approximate round trip times in mille-seconds:

Minimum = 0ms, Maximum = 0ms, Average = 0ms

During the ping request, you might receive some replies from the remote host that are intermixed with Request timed out errors. This is often a result of a congested network. An example follows; notice that this example, which was run on a Windows Me system, uses the -t switch to generate continuous pings:

C:\>ping -t 24.67.184.65

Pinging 24.67.184.65 with 32 bytes of data:

Reply from 24.67.184.65: bytes=32 time=55ms TTL=127

Reply from 24.67.184.65: bytes=32 time=54ms TTL=127

Reply from 24.67.184.65: bytes=32 time=27ms TTL=127

Request timed out.

Reply from 24.67.184.65: bytes=32 time=69ms TTL=127

Reply from 24.67.184.65: bytes=32 time=28ms TTL=127

Reply from 24.67.184.65: bytes=32 time=68ms TTL=127

Reply from 24.67.184.65: bytes=32 time=41ms TTL=127

Ping statistics for 24.67.184.65:

Packets: Sent = 11, Received = 8, Lost = 3 (27% loss),

Approximate round trip times in mille-seconds:

Minimum = 27ms, Maximum = 69ms, Average = 33ms

In this example, three packets were lost. If this continued on your network, you would need to troubleshoot to find out why packets were being dropped.

The Unknown Host Message

The Unknown Host error message is generated when the hostname of the destination computer cannot be resolved. This error usually occurs when you ping an incorrect hostname, as shown in the following example, or try to use ping with a hostname when hostname resolution (via DNS or a HOSTS text file) is not configured:

C:\>ping www.comptia.ca

Unknown host www.comptia.ca

If the ping fails, you need to verify that the ping is being sent to the correct remote host. If it is, and if name resolution is configured, you have to dig a little more to find the problem. This error might indicate a problem with the name resolution process, and you might need to verify that the DNS or WINS server is available. Other commands, such as nslookup or dig, can help in this process.

The Expired TTL Message

The Time to Live (TTL) is an important consideration in understanding the ping command. The function of the TTL is to prevent circular routing, which occurs when a ping request keeps looping through a series of hosts. The TTL counts each hop along the way toward its destination device. Each time it counts one hop, the hop is subtracted from the TTL. If the TTL reaches 0, the TTL has expired, and you get a message like the following:

Reply from 24.67.180.1: TTL expired in transit

If the TTL is exceeded with ping, you might have a routing problem on the network. You can modify the TTL for ping on a Windows system by using the ping -I command.

Troubleshooting with ping

Although ping does not completely isolate problems, you can use it to help identify where a problem lies. When troubleshooting with ping, take the following steps:

Ping the IP address of your local loopback, using the command ping 127.0.0.1. If this command is successful, you know that the TCP/IP protocol suite is installed correctly on your system and functioning. If you are unable to ping the local loopback adapter, TCP/IP might need to be reloaded or reconfigured on the machine you are using.

The Loopback Address

The loopback is a special function within the protocol stack that is supplied for troubleshooting purposes. The Class A IP address 127.X.X.X is reserved for the loopback; although convention dictates that you use127.0.0.1, you can use any address in the 127.X.X.Xrange, except for the network number itself (127.0.0.0) and the broadcast address (127.255.255.255). You can also ping by using the default hostname for the local system, which is calledlocalhost (for example, ping local host).

Ping the assigned IP address of your local network interface card (NIC). If the ping is successful, you know that your NIC is functioning on the network and has TCP/IP correctly installed. If you are unable to ping the local NIC, TCP/IP might not be bound correctly to the NIC or the NIC drivers might be improperly installed.

Ping the IP address of another known good system on your local network. By doing so, you can determine whether the computer you are using can see other computers on the network. If you can ping other devices on your local network, you have network connectivity.

If you cannot ping other devices on your local network and you were able to ping the IP address of your system, you might not be connected to the network correctly.

After you've confirmed that you have network connectivity for the local network, you can verify connectivity to a remote network by sending a ping to the IP address of the default gateway.

If you are able to ping the default gateway, you can verify remote connectivity by sending a ping to the IP address of a system on a remote network.

Using just the ping command in these steps, you can confirm network connectivity on not only the local network, but also on a remote network. The whole process requires as much time as it takes to type in the command, and you can do it all from a single location.

If you are an optimistic person, you can perform step 5 first. If that works, all the other steps will also work, saving you the need to test them. If your step 5 trial fails, you can go back to step 1 and start the troubleshooting process from the beginning.

ARP

The Address Resolution Protocol (ARP) is used to resolve IP addresses to MAC addresses. This is important because on a network, devices find each other using the IP address, but communication between devices requires the MAC address.

When a computer wants to send data to another computer on the network, it must know the MAC address of the destination system. To discover this information, ARP sends out a discovery packet to obtain the MAC address. When the destination computer is found, it sends its MAC address to the sending computer. The ARP-resolved MAC addresses are stored temporarily on a computer system in the ARP cache. Inside this ARP cache is a list of matching MAC and IP addresses. This ARP cache is checked before a discovery packet is sent on to the network to determine if there is an existing entry.

Entries in the ARP cache are periodically flushed so that the cache doesn't fill up with unused entries. The following code shows an example of the ARP command with the output from a Windows 2000 system:

C:\>arp -a

Interface: 24.67.179.22 on Interface 0x3

Internet Address Physical Address Type

24.67.179.1 00-00-77-93-d8-3d dynamic

As you might notice in the previous code, the type is listed as dynamic. Entries in the ARP cache can be added statically or dynamically. Static entries are added manually and do not expire. The dynamic entries are added automatically when the system accesses another on the network.

As with other command-line utilities, there are several switches available for the arp command. Table 4 shows the available switches for Windows-based systems.

Table 4 ARP Switches
Switch	Description
-a or -g	Displays both the IP and MAC addresses and whether they are dynamic or static entries
inet_addr	Specifies a specific internet address
-N if_addr	Displays the ARP entries for a specified network interface
eth_addr	Specifies a MAC address
if_addr	Specifies an Internet address
-d	Deletes an entry from the ARP cache
-s	Adds a static permanent address to the ARP cache

The net stat Command

The net stat command displays the protocol statistics and current TCP/IP connections on the local system. Used without any switches, the net stat command shows the active connections for all outbound TCP/IP connections. In addition, several switches are available that change the type of information net stat displays. Table 5 shows the various switches available for the netstatutility.

Table 5 net stat Switches
Switch	Description
-a	Displays the current connections and listening ports
-e	Displays Ethernet statistics
-n	Lists addresses and port numbers in numerical form
-p	Shows connections for the specified protocol
-r	Shows the routing table
-s	Lists per-protocol statistics
interval	Specifies the length of time to wait before redisplaying statistics

The net stat utility is used to show the port activity for both TCP and UDP connections, showing the inbound and outbound connections. When used without switches, the net stat utility has four information headings.

· Proto Lists the protocol being used, either UDP or TCP.

· Local address Specifies the local address and port being used.

· Foreign address identifies the destination address and the port being used.

· State specifies whether the connection is established.

In its default usage, the net stat command shows outbound connections that have been established by TCP. The following shows a sample output from a net stat command without using any switches:

C:\>netstat

Active Connections

Proto Local Address          Foreign Address        State

  TCP    laptop: 2848            MEDIASERVICES1:1755    ESTABLISHED

  TCP    laptop: 1833            www.test.com:80 ESTABLISHED

  TCP    laptop: 2858            194.70.58.241:80       ESTABLISHED

  TCP    laptop: 2860            194.70.58.241:80       ESTABLISHED

  TCP    laptop: 2354            www.test.com:80 ESTABLISHED

  TCP    laptop: 2361            www.test.com:80 ESTABLISHED

  TCP    laptop: 1114            www.test.com:80 ESTABLISHED

  TCP    laptop: 1959            www.test.com:80 ESTABLISHED

  TCP    laptop: 1960            www.test.com:80 ESTABLISHED

  TCP    laptop: 1963            www.test.com:80 ESTABLISHED

  TCP    laptop: 2870            localhost: 8431         TIME_WAIT

  TCP    laptop: 8431            localhost: 2862         TIME_WAIT

  TCP    laptop: 8431            localhost: 2863         TIME_WAIT

  TCP    laptop: 8431            localhost: 2867         TIME_WAIT

  TCP    laptop: 8431            localhost: 2872         TIME_WAIT

Like any other command-line utility, they are often used with switches. The following sections provide a brief explanation of the switches and a sample output from each.

Net stat e

The net stat -e command shows the activity for the NIC and displays the number of packets that have been both sent and received. An example of the net stat -e command is shown here:

C:\WINDOWS\Desktop>netstat -e

Interface Statistics

Received Sent

Bytes 17412385 40237510

Unicast packets 79129 85055

Non-uncast packets 693 254

Discards 0 0

Errors 0 0

Unknown protocols 306

As you can see, the net stat -e command shows more than just the packets that have been sent and received:

Bytes the number of bytes that have been sent or received by the NIC since the computer was turned on.
Unicast packets Packets sent and received directly to this interface.
Non-unicast packets Broadcast or multicast packets that were picked up by the NIC.
Discards the number of packets rejected by the NIC, perhaps because they were damaged.
Errors The errors that occurred during either the sending or receiving process. As you would expect, this column should be a low number. If it is not, it could indicate a problem with the NIC.
Unknown protocols the number of packets that were not recognizable by the system.

Net stat -a

The net stat -a command displays statistics for both TCP and User Datagram Protocol (UDP). Here is an example of the net stat -a command:

C:\WINDOWS\Desktop>netstat -a

Active Connections

Proto Local Address Foreign Address State

TCP laptop: 1027 LAPTOP: 0 LISTENING

TCP laptop: 1030 LAPTOP: 0 LISTENING

TCP laptop: 1035 LAPTOP: 0 LISTENING

TCP laptop: 50000 LAPTOP: 0 LISTENING

TCP laptop: 5000 LAPTOP: 0 LISTENING

TCP laptop: 1035 msgr-ns41.msgr.hotmail.com:1863 ESTABLISHED

TCP laptop: nbsession LAPTOP: 0 LISTENING

TCP laptop: 1027 localhost: 50000 ESTABLISHED

TCP laptop: 50000 localhost: 1027 ESTABLISHED

UDP laptop: 1900 *:*

UDP laptop: nbname *:*

UDP laptop: nbdatagram *:*

UDP laptop: 1547 *:*

UDP laptop: 1038 *:*

UDP laptop: 1828 *:*

UDP laptop: 3366 *:*

As you can see, the output includes four columns, which show the protocol, the local address, the foreign address, and the state of the port. The TCP connections show the local and foreign destination addresses and the current state of the connection. UDP, however, is a little different; it does not list a state status because as mentioned throughout this book, UDP is a connectionless protocol and does not establish connections. The following list briefly explains the information provided by thenetstat -a command:

Proto The protocol used by the connection.
Local Address the IP address of the local computer system and the port number it is using. If the entry in the local address field is an asterisk (*), it indicates that the port has not yet been established.
Foreign Address the IP address of a remote computer system and the associated port. When a port has not been established, as with the UDP connections, *:* appears in the column.
State the current state of the TCP connection. Possible states include established, listening, closed, and waiting.

Net stat -r

The net stat -r command is often used to view the routing table for a system. A system uses a routing table to determine routing information for TCP/IP traffic. The following is an example of thenetstat -r command from a Windows Me system:

C:\WINDOWS\Desktop>netstat r

Route table

===========================================================================

===========================================================================

Active Routes:

Network Destination        Net mask          Gateway       Interface Metric

          0.0.0.0          0.0.0.0      24.67.179.1      24.67.179.22     1

     24.67.179.0     255.255.255.0      24.67.179.22     24.67.179.22     1

     24.67.179.22    255.255.255.255       127.0.0.1     127.0.0.1        1

     24.255.255.255  255.255.255.255    24.67.179.22     24.67.179.       1

        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0         1

        224.0.0.0        224.0.0.0     24.67.179.22      24.67.179.22     1

   255.255.255.255   255.255.255.255     24.67.179.22             2       1

Default Gateway:       24.67.179.1

===========================================================================

Persistent Routes:

  None

Net stat s

The net stat -s command displays a number of statistics related to the TCP/IP protocol suite. Understanding the purpose of every field in the output is for your reference, sample output from the net stat -s command is shown here:

C:\>netstat -s

IP Statistics

  Packets Received                   = 389938

  Received Header Errors             = 0

  Received Address Errors            = 1876

  Datagram’s Forwarded                = 498

  Unknown Protocols Received         = 0

  Received Packets Discarded         = 0

  Received Packets Delivered         = 387566

  Output Requests                    = 397334

  Routing Discards                   = 0

  Discarded Output Packets           = 0

  Output Packet No Route             = 916

  Reassembly Required                = 0

  Reassembly Successful              = 0

  Reassembly Failures                = 0

  Datagram’s successfully Fragmented = 0

  Datagram’s Failing Fragmentation    = 0

  Fragments Created                  = 0

ICMP Statistics

                            Received    Sent

  Messages                  40641       41111

  Errors                    0           0

  Destination Unreachable   223         680

  Time Exceeded             24          0

  Parameter Problems        0           0

  Source Quenches           0           0

  Redirects                 0           38

Echo’s                     20245       20148

  Echo Replies              20149       20245

  Timestamps                0           0

  Timestamp Replies         0           0

  Address Masks             0           0

  Address Mask Replies      0           0

TCP Statistics

  Active Opens                        = 13538

  Passive Opens                       = 23132

  Failed Connection Attempts          = 9259

  Reset Connections                   = 254

  Current Connections                 = 15

  Segments Received                   = 330242

  Segments Sent                       = 326935

  Segments Retransmitted              = 18851

UDP Statistics

  Datagram’s Received    = 20402

  No Ports              = 20594

  Receive Errors        = 0

  Datagram’s Sent        = 10217

nbtstat

The nbtstat utility is used to view protocol statistics and information for NetBIOS over TCP/IP connections. nbtstat is commonly used to troubleshoot NetBIOS name resolution problems. Because nbtstat provides the resolution of NetBIOS names, it's available only on Windows systems.

A number of case-sensitive switches are available for the nbtstatcommand. Table 6 summarizes these switches.

Table 6 nbtstat Switches
Switch	Description
nbtstat -a	(Adapter status) Outputs the NetBIOS name table and MAC addresses of the card for the specified computer
nbtstat -A (IP address)	(Adapter status) Lists the remote machine's name table given its IP address
nbtstat -c (cache)	Provides a list of the contents of the NetBIOS name cache
nbtstat -n (names)	Lists local NetBIOS names
nbtstat -r (resolved)	Lists names resolved by broadcast or WINS
nbtstat -R (Reload)	Purges and reloads the remote cache name table
nbtstat -S (Sessions)	Summarizes the current NetBIOS sessions and their status
nbtstat -s (sessions)	Lists sessions table converting destination IP addresses to computer NetBIOS names
nbtstat -RR (Release Refresh)	Sends Name Release packets to WINS, and then starts Refresh
nbtstat Remote Name	Remote host machine name
nbtstat IP address	Dotted decimal representation of the IP address
nbtstat interval	Redisplays selected statistics, pausing interval seconds between each display. Press Ctrl+C to stop redisplaying statistics

As an example, the following is the output from the nbtstat –n command:

C:\>nbtstat -n

Lana # 0:

Node IpAddress: [169.254.196.192] Scope Id: []

                NetBIOS Local Name Table

       Name               Type         Status

    ---------------------------------------------

    LAPTOP         <00>  UNIQUE      Registered

    KCS            <00>  GROUP       Registered

    LAPTOP         <03>  UNIQUE      Registered

The ipconfig Command

The ipconfig command is a technician's best friend when it comes to viewing the TCP/IP configuration of a Windows system. Used on its own, the ipconfig command shows basic information such as the name of the network interface, the IP address, the subnet mask, and the default gateway. Combined with the /all switch, it shows a detailed set of information, as you can see in the following example:

C:\>ipconfig /all

Windows 2000 IP Configuration

   Host Name . . . . . . . . . . . . : server

   Primary DNS Suffix  . . . . . . . : write

   Node Type . . . . . . . . . . . . : Broadcast

   IP Routing Enabled. . . . . . . . : Yes

   WINS Proxy Enabled. . . . . . . . : No

   DNS Suffix Search List. . . . . . : write

                                       ok.anyotherhost.net

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix. : ok.anyotherhost.net

Description . . . . . . . . . . . : D-Link DFE-530TX PCI Fast Ethernet

Physical Address. . . . . . . . . : 00-80-C8-E3-4C-BD

DHCP Enabled. . . . . . . . . . . : Yes

Auto configuration Enabled . . . . : Yes

IP Address . . . . . . . . . . . . : 24.67.184.65

Subnet Mask . . . . . . . . . . . : 255.255.254.0

Default Gateway . . . . . . . . . : 24.67.184.1

DHCP Server . . . . . . . . . . . : 24.67.253.195

DNS Servers . . . . . . . . . . . : 24.67.253.195

                                    24.67.253.212

Lease Obtained.. . . . : Thursday, February 07, 2002 3:42:00 AM

Lease Expires . . . . . : Saturday, February 09, 2002 3:42:00 AM

As you can imagine, you can use the output from an ipconfig /all command in a massive range of troubleshooting scenarios. Table 7 lists some of the most common troubleshooting symptoms, along with where to look for clues about solving them in the ipconfig /all output.

Table 7 Common Troubleshooting Symptoms That ipconfig Can Help Solve
Symptom	Field to Check in ipconfig Output
User is unable to connect to any other system.	Make sure the TCP/IP address and subnet mask are correct. If the network uses DHCP, make sure DHCP is enabled.
User is able to connect to another system on the same subnet but is not able to connect to a remote system.	Make sure the default gateway is correctly configured.
User is unable to browse the Internet.	Make sure the DNS server parameters are configured correctly.
User is unable to browse across remote subnets.	Make sure the WINS or DNS server parameters are configured correctly, if applicable.

Using the /all switch might be far and away the most popular, but there are a few others. These include the switches listed in Table 8.

Table 8 ipconfig Switches
Switch	Description
?	Displays the ipconfig help screen
/all	Displays additional IP configuration information
/release	Releases the IP address of the specified adapter
/renew	Renews the IP address of a specified adapter

Ifconfig

Ifconfig performs the same function as ipconfig, but on a Linux, UNIX, or Macintosh system. Because Linux relies more heavily on command-line utilities than Windows, the Linux and UNIX version ofifconfig provides much more functionality than ipconfig. On a Linux or UNIX system, you can get information about the usage of the ifconfig command by using ifconfig --help. The following output provides an example of the basic ifconfig command run on a Linux system:

Eth0      Link encap:EthernetHWaddr 00:60:08:17:63:A0

Inet addr: 192.168.1.101 Bcast: 192.168.1.255 Mask:255.255.255.0

          UP BROADCAST RUNNING MTU: 1500 Metric: 1

          RX packets: 911 errors: 0 dropped: 0 overruns: 0 frame: 0

          TX packets: 804 errors: 0 dropped: 0 overruns: 0 carrier: 0

Collisions: 0 txqueuelen: 100

          Interrupt: 5 Base addresses: 0xe400

Lo        Link encap: Local Loopback

Inet addr: 127.0.0.1 Mask: 255.0.0.0

          UP LOOPBACK RUNNING MTU: 3924 Metric: 1

          RX packets: 18 errors: 0 dropped: 0 overruns: 0 frame: 0

          TX packets: 18 errors: 0 dropped: 0 overruns: 0 carrier: 0

Collisions: 0 txqueuelen: 0

Although the ifconfig command displays the IP address, subnet mask and default gateway information for both the installed network adapter and the local loopback adapter, it does not report DCHP lease information. Instead, you can use the pump s command to view detailed information on the DHCP lease including the assigned IP address, the address of the DHCP server, and the time remaining on the lease. The pump command can also be used to release and renew IP addresses assigned via DHCP and to view DNS server information.

The winipcfg Command

On a Windows 98 Second Edition and Windows Me systems, thewinipcfg command is used in addition to the ipconfig command. The difference between the two utilities is that winipcfg is a graphical utility.

In basic mode, winipcfg shows information including the Media Access Control (MAC) address and IP address of the interface, the subnet mask, and the default gateway. For detailed information, similar to that produced with ipconfig /all, a More Info button allows you to switch into a much more detailed screen.

The same troubleshooting scenarios, with the same solutions, apply to winipcfg as to ipconfig. Table 9 lists some solutions to common problems.

Table 9 Common Troubleshooting Problems That winipcfg Can Help Solve
Symptom	Field to Check in winipcfg Output
User is unable to connect to any other system.	Check that the TCP/IP address and subnet mask are correct. If using DHCP, make sure DHCP is enabled.
User is able to connect to other system on the same subnet, but is not able to connect to a remote system.	Check that the default gateway is correctly configured.
User is unable to browse the Internet.	Make sure the DNS server parameters are configured correctly.
User is unable to browse across remote subnets.	Make sure the WINS or DNS server parameters are configured correctly (if applicable).

Nslookup

Nslookup is a utility used to troubleshoot DNS-related problems. Using nslookup, you can, for example, run manual name resolution queries against DNS servers, get information about the DNS configuration of your system or specify what kind of DNS record should be resolved.

When nslookup is started, it displays the current hostname and the IP address of the locally configured DNS server. You will then see a command prompt which allows you to specify further queries. This is known as 'interactive' mode. The commands you can enter in interactive mode are listed in Table 10.

Table 10 nslookup Switches
Switch	Description
all	Prints options, as well as current server and host information
[no]debug	Prints debugging information
[no]d2	Prints exhaustive debugging information
[no]defame	Appends the domain name to each query
[no]recourse	Asks for recursive answer to query
[no]search	Uses domain search list
[no]Vic	Always uses a virtual circuit
domain=NAME	Sets default domain name to NAME
schist=N1[/N2/.../N6]	Sets domain to N1 and search list to N1, N2, and so on
root=NAME	Sets root server to NAME
retry=X	Sets number of retries to X
timeout=X	Sets initial timeout interval to X seconds
type=X	Sets query type (for example, A, ANY, CNAME, MX, NS, PTR, SOA, or SRV)
query type=X	Same as type
class=X	Sets query class (for example, IN [Internet], ANY)
[no]mixer	Uses MS fast zone transfer
ixfrver=X	Current version to use in IXFR transfer request
server NAME	Sets default server to NAME, using current default server
exit	Exits the program

Instead of using interactive mode, you can also execute nslookuprequests directly at the command prompt. The following listing shows the output from nslookup when a domain name is specified to be resolved.

C:\>nslookup comptia.org

Server:  nsc1.ht.ok.shawcable.net

Address:  64.59.168.13

Non-authoritative answer:

Name:    comptia.org

Address:  208.252.144.4

As you can see from the output, nslookup shows the hostname and IP address of the DNS server against which the resolution was performed, along with the hostname and IP address of the resolved host.

Dig

Dig is used on Linux, UNIX or Macintosh system to perform manual DNS lookups. Dig performs the same basic task as nslookup, but with one major distinction: The dig command does not have an interactive mode and instead uses only command-line switches to customize results.

Dig is generally considered a more powerful tool than nslookup, but in the course of a typical network administrator's day, the minor limitations of nslookup are unlikely to be too much of a factor. Instead, dig is often simply the tool of choice for DNS information and troubleshooting on UNIX, Linux, or Macintosh systems. Likens lookup, dig can be used to perform simple name resolution requests. The output from this process can be seen in the following listing:

; <<>>Dig 8.2 <<>> xyz.com

; Res options: init recurs defnamdnsrch

; got answer:

; ->>HEADER<<- epode: QUERY, status: NOERROR, id: 4

; Flags: qrrdra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

; QUERY SECTION:

;    xyz.com, type = A, class = IN

; ANSWER SECTION:

xyz.com.        7h33m IN A    63.240.93.157

; AUTHORITY SECTION:

xyz.com.        7h33m IN NS    usrxdns1.ABC.com.

xyz.com.        7h33m IN NS    oldtxdns2.ABC.com.

; Total query time: 78 mess

; FROM: localhost.localdomain to SERVER: default -- 209.53.4.130

; WHEN: Sat Oct 16 20:21:24 2004

; MSG SIZE  sent: 30  rcvd: 103

As you can see, dig provides a number of pieces of information in the basic output more so than nslookup. There are three key areas of the output from which network administrators can gain information. These are the 'Answer Section,' the 'Authority Section,' and the last four lines of the output.

The Answer Section of the output provides the name of the domain or host being resolved, along with its IP address. The A in the results line indicates the record type that is being resolved.

The Authority Section provides information on the authoritative DNS servers for the domain against which the resolution request was performed. This information can be useful in determining whether the correct DNS servers are considered authoritative for a domain.

The last four lines of the output show how long the name resolution request took to process and the IP address of the DNS server that performed the resolution. It also shows the date and time of the request, as well as the size of the packets sent and received.

Interpreting Visual Indicators

One of the easiest ways to spot signs of trouble on a network or with a network component is to look at the devices' LEDs. Many of the devices used in modern networks such as hubs, routers, switches, and even NICshave these small indicator lights that let you know what, if anything, is going wrong. The following sections examine some of the common networking devices and what you can learn from their LEDs.

LEDs on Networking Devices

If you have seen a hub or a switch, you have no doubt noticed the LEDs on the front of the device. Each RJ-45 connector has one or two dedicated LEDs. These LEDs are designed to provide the network administrator with a quick idea of the status of a connection or a potential problem. Table 11 provides some examples of link-light indicators functioning on a typical hub or switch.

Table 11 Example Link-Light Indicator LED States for a Network Hub or Switch
LED State	Meaning
Solid green	A device is connected to the port, but there is no activity on the device.
Blinking green	There is activity on the port. The connected system is sending or receiving data.
No LED lit	There is no detectable link. Either there's a problem with the connection between the device and the hub (such as an unplugged cable), or the remote system is powered down.
Fast continuous blinking for extended periods	This often indicates a fault with the connection, which can commonly be attributed to a faulty NIC.
Blinking amber	There are collisions on the network. A few orange LEDs flashing intermittently are okay, but continuously blinking amber LEDs indicate a problem.

Note that the LEDs' sequencing and meanings vary among the different hub manufacturers and therefore might be different from those listed in Table 11.

In addition to link-light indicators, some hubs and switches have port-speed LEDs that, when lit, indicate the speed at which the connected device is functioning. Some also have LEDs that indicate whether the link is operating in full-duplex mode.

By understanding the function of the lights on networking devices, you can tell at a glance the status of a device and the systems connected to it. You should take the time to familiarize yourself with the indicator lights on the network devices you work with and with their various states.

LEDs on NICs and Other Devices

In addition to hubs and switches, most other networking devices have LEDs that provide a variety of information. Most NICs have at least one LED that indicates whether there is a link between the system and the network into which it is plugged. The link light operates at a physical level; in other words, it should be lit when the PC is on, regardless of whether the networking software is loaded, the network configuration is correct, or the user is logged on to the network. In addition to the link light LED, many NICs have additional lights to indicate the speed at which the network connection is established and/or when there is network activity on the link.

LEDs are also included on cable modems and DSL modems, which are commonly used in small or home office implementations for Internet connectivity. The number of LEDs and their functionality depends on the device. For example, one cable modem might have four LEDs: one indicating that the modem is online, a Send indicator, a Receive indicator, and one labeled Message. In contrast, a DSL modem might have six LEDs. One shows that the device is powered, and one flashes to indicate that the device is operating normally. Then there is a link light for both the local network and the DSL connection, and another LED for each interface that flashes to indicate activity on those links.

The usefulness of LEDs in troubleshooting scenarios cannot be overstated. LEDs provide an instant, visual indicator about the state of a network link. In some cases, as with collision lights, they can even alert you to problems on the network. Understanding how to interpret information provided by LEDs is important for the real world.

Imagine a scenario in which a user who is working at workstation A calls and tells you she is unable to access the Internet. The Internet connection could be down, but by connecting to the Internet yourself, you determine that it is working correctly; therefore, it is safe to assume that the problem is at the user's end rather than with the Internet connectivity. Next, you decide to visit the user's workstation to see whether you can ping the Internet router. Before you begin the ping test, you look at the back of the system and see that the link LED on the NIC is not lit. At this point, you can be fairly sure that the ping test will not work because without the link light, there is no connectivity between the NIC and the switch.

Now you have narrowed the problem to one of a few sources. Either the NIC or the cable is faulty, the switch to which the user is connected is not functioning, or the port on the switch to which the user is connected is faulty.

The easiest way to test whether the cable is the problem is to borrow a known working cable from workstation B or C and swap it with the cable connecting workstation A to the hub, switch, or wall port. When you try this, if the link light does not come on, you can deduce that the NIC is faulty. If the light does come on, you can deduce that either the port on the switch or a cable is faulty. The next step is to swap the cable out or try the original cable in another switch port.

Whatever the actual problem, link lights play an important role in the troubleshooting process. They give you an easy method of seeing what steps do and don't work.

Troubleshooting Remote Connectivity

Remote connectivity errors are bugs that prevent you from connecting to the office network, from remotely dialing in to your home computer, or from logging on to your ISP and subsequently the Internet.

Although many means and methods are available for establishing remote connectivity, network administrators can focus their attention on some common hot spots when troubleshooting errors, including authentication failure, protocol configuration problems, and physical connectivity.

Troubleshooting Physical Connectivity

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

· Improperly connected cable

· Incorrect cable

· Faulty interface

· Faulty networking devices

Now that we have looked at some of the more generalized considerations of remote connectivity troubleshooting from a physical perspective, we'll focus specifically on some of the commonly used remote access technologies.

DSL

Troubleshooting DSL is similar to troubleshooting any other Internet connection. The following are a few things to check when users are experiencing problems with a DSL connection:

· Physical connections

· The NIC installed in the computer system

· Network card drivers

· Protocol configuration

· LEDs on the DSL modem

Cable Troubleshooting Procedures

In general, cable Internet access is a low-maintenance system with very few problems. When problems do occur, you can try various troubleshooting measures:

· Check the physical connections.

· Ensure that the protocol configuration on the system is valid.

· Check the indicator lights on the cable modem.

· Cycle the power on the cable modem, and on the system.

If you are sure that the connectors are all in place and the configuration of the system is correct, the next step is to call the technical support line of the cable provider.

Home Satellite Troubleshooting Procedures

Your ability to troubleshoot satellite Internet connections might be very limited. The hardware associated with home satellite remote access installations are very specialized, and equipment providers often prefer that you let them do the hardware troubleshooting. Given this limitation, calls to technical support occur very early in the troubleshooting process.

Wireless Internet Access Troubleshooting Procedures

Troubleshooting wireless access is normally confined to ensuring that the adapter is functioning correctly and configured properly.

The main factors that can affect wireless access are environmental conditions and outside interference. Many people who live in areas that often have fog or other damp conditions experience poor performance (or none at all) from wireless Internet service.

Here are some specific things you should check when troubleshooting a wireless connection:

Check the configuration of the wireless interface.
Move the computer around to find out if it's in a dead spot.
Check with other people to see if there is a problem with the service, rather than just your system.

If you are sure that everything is configured correctly, you might have to contact the wireless provider to see if anything is amiss

POTS Troubleshooting Procedures

Troubleshooting a dial-up connection problem can be tricky and time-consuming because you must consider many variables. In fact, of the remote connectivity mechanisms discussed in this chapter, you are far more likely to have problems with a POTS connection than any of the others. The following are some places to start your troubleshooting under various conditions.

If the user is unable to dial out, try the following:

· Check physical connections.

· Check that there is a dial tone on the line.

If the user can dial out but can't get a connection, try the following:

· Make sure that the user is dialing the correct number.

· Call the ISP to determine whether it is having problems.

· Determine if Call Waiting is enabled on the line, or there is some other telephone provider service interfering with communications.

If the user can dial out and can get a connection but is then disconnected, try the following:

· Ensure that the modem connection is configured correctly.

· Check that the username and password are correct.

· Verify that the connection settings are correct.

Modem-Specific Troubleshooting

If you are confident that a modem is installed and configured correctly, but it's still not working properly, you can test and configure it by using special commands from the AT command set. Table 12 lists some of the most commonly used AT commands.

Table 12 Commonly Used AT Commands
AT Command	Result
ATA	Sets the modem to auto-answer
ATH	Hangs up an active connection
ATD	Dials a number
ATZ	Resets the modem
ATI3	Displays the name and model of the modem

In general, getting the modem to respond to an ATZ command is a good enough indicator that the modem is functioning.

Troubleshooting Authentication Failure

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. 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.

Authentication issues can also arise as a result of permissions changes in users' accounts. If you're troubleshooting remote connectivity and you have confirmed that the correct username and password are used, you should confirm that the user has the appropriate permissions to access the network.

The third and perhaps least likely cause for authentication failure is a downed authentication server. In such a circumstance, you are likely to receive numerous calls regarding authentication difficulty not just one or two.

Troubleshooting Protocol Configuration Problems

Many, but not all, of the problems you encounter with remote connectivity can be addressed with the measures listed previously. However, you might encounter a problem 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 cause of a client connectivity problem is protocol configuration. Protocol configuration issues are usually on the client side of the network. On a TCP/IP network, each client computer must have a unique address in order to participate on the network. Failure to obtain addressing information automatically could indicate a problem with a DHCP server. You should check the DHCP server to make sure that it is functioning and that addresses are available for assignment.

Beyond basic protocol issues such as addressing, remote connectivity troubleshooting also brings with it the additional considerations of authentication protocols. There is one basic rule that applies to all such issues. If a client in a remote connectivity solution is configured to use one type of authentication protocol, and the server to which he is connecting does not support that protocol, the connection will be refused.

Troubleshooting Small Office/Home Office Router

As more people choose to use broadband Internet connectivity methods such as cable and DSL, the use of compact hub/router and switch/router combinations has become commonplace.

Most SOHO routers are, in fact, more than routers. Most are also Ethernet hubs or switches, making it possible to share an Internet connection with other systems on the network. They also typically provide basic firewalling capabilities and, in many cases, DHCP server functionality.

Configuration

The most common configuration method for SOHO routers is through a browser interface, though some models also use a custom application for this purpose. Configuration is generally straightforward, as SOHO routers are designed to be home user friendly.

Troubleshooting

Because a SOHO router is a network device, the rules and procedures that apply to other troubleshooting scenarios are valid. If you are experiencing Internet connectivity issues on a network with a SOHO router, the first step is to ensure that the SOHO router is powered on and that all the network connections are complete and secure. Also, familiarize yourself with the diagnostic LEDs on your SOHO router so that you can interpret the information they provide accordingly.

One of the easiest ways to test whether the SOHO router is the cause of a problem is to remove it from the communications chain and plug a PC directly in to the broadband interface (be that cable or DSL). If the PC is configured to obtain an IP address automatically, it should be able to get an IP address from the ISP just as easily as it would from the SOHO router. If the system subsequently works fine and can access the Internet, you know that the problem lies with the SOHO router and not the configuration of the system.

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 system for 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 theifconfig command.

Protocol-Specific Issues

You need to consider a number of factors related to network protocols when you troubleshoot 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.

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.

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 business one 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.

Troubleshooting Checklists

In a real-world networking environment, you will be expected to be able to troubleshoot client connectivity in many different areas. The following sections provide some troubleshooting checklists that can help you review some of the various troubleshooting areas.

Troubleshooting Cabling Problems

Cable accounts for a great many of the problems on a network. There are many places to look when you suspect a cable-related problem. If you suspect that cable is at the bottom of your network troubles, consider the following areas:

Loose connections you need to verify that cables are securely attached and that they are attached to the correct ports.
Poorly crimped or bent cable sometimes a chair running over a cable or a cable that has a poor crimp can cause problems.
Incorrect cable length Recall from that cables cannot exceed a specified maximum length.
Cable placement Care must be taken when cables are run too closely to strong electrical devices. If cables are run too closely to electrical devices, you need to ensure that they are designed for the task.

Troubleshooting Operating System Connectivity

If you are struggling with operating system connectivity issues, consider the following:

· Username/password Make sure that users are logging on to the network with the correct username/password combination.

· Configuration It might be necessary to confirm that the network settings on the client computer have not changed.

· Account activity you need to verify that the user has an active account on the network and that it has the correct permissions set. Log on with a known working account from the client's system, which will allow you to isolate the problem to the computer or the user account.

· Physical connections you should check to see if a cable has come unplugged from the client's system.

· NIC to confirm that a card is working; you might need to swap out the card with one that is known to be working.

Troubleshooting Network Printing

Printing is one of the services that network users expect to be working, and it is the administrator's job to make sure that it is available. When trying to get printing back up and running on the network, confirm the following:

· Printer online status you should confirm that the printer is online and ready to go. If there is a problem with the printer itself, the printer might display error messages on an LCD panel or use LEDs to indicate a problem.

· Printers functioning nearly all printers have a test print feature. You can use it to make sure that the printer itself is functioning correctly.

· Printer connectivity Verify that the printer is visible to the network. If the printer is connected directly to the network using TCP/IP, for instance, you can ping the printer to test for connectivity.

· Client configuration Ensure that the computers that are trying to access the printer are configured correctly to use that printer.

· Permissions On many operating systems, it is possible to set permissions to allow or deny users access to a printer. You need to verify that the correct permissions have been set.

· Check logs Network operating systems log printer activity. Monitoring printer logs can often provide clues as to the source of a problem.

· Driver software if you are having problems isolating a printing issue, consider reinstalling or replacing the printer driver.

Troubleshooting Data Access

The inability to access data is not always a result of connectivity errors. If a user is unable to access data, there are a few key areas to verify:

· Proper network login Sometimes people use a shortcut or try to access data without being properly logged on to the network. You should verify that users are correctly logged on to the network and that any necessary network drives are connected.

· Permissions when you are troubleshooting data access ensure that the permissions are set correctly.

· Connectivity you need to verify that the system that maintains the data is available. You need to confirm that the server is available. What can seem like a problem accessing a file can mask a potentially larger problem such as a disk or server failure.

· Data integrity Sometimes data itself can be corrupt. This is the worst-case scenario, and the robust nature of today's file systems ensures that it occurs rarely. This is when you need backups.

· Viruses In some cases, viruses might be your problem. You can use a virus-checking program to determine if indeed this is the problem.

Troubleshooting NICs

When NICs are configured correctly and verified to be working, very little goes wrong with them. When you are troubleshooting a NIC, you should consider the following:

· Resource settings NICs require specific computer resources in order to operate. After you install a card or add new devices, you should check for device conflicts.

· Speed settings If you are not getting the expected speed from the NIC, you should confirm the speed settings and, if applicable, the duplex settings.

· Protocols In order for the NIC to work on the network, it must have a valid protocol assigned to it, and all addressing information needs to be in place.

· Faulty card Some NICs are faulty when they ship from the manufacturer, and some are damaged through poor handling. To test for this, you can swap the card with one that is known to be working.

Search

Sunday, 24 February 2019

Troubleshooting of Connectivity issue of WAN