The term network support refers to providing network services to end users. It involves tasks such as installation, maintenance, and troubleshooting. Network and system administrators, helpdesk staff and network technicians work together to provide maximum availability and seamless operations of network services. The objective is to minimize interruptions in regular work due to network downtimes. This section covers a study of troubleshooting utilities and techniques for supporting computer networks.
Network troubleshooting is an essential part of the responsibilities of a network technician. A network technician is expected to have knowledge and skills to use appropriate troubleshooting utilities to diagnose problems and find solutions. This section provides an overview of commonly used troubleshooting utilities available for troubleshooting network connectivity problems.
The tracert or traceroute utility is used to trace the route to from one host to another in a TCP/IP network. All major operating systems include this utility in one form or another. The name of the utility might differ, but the purpose is the same: to find out the path between two TCP/IP hosts. The output format of this utility differs from one operating system to another. It uses the Internet Control Message Protocol (ICMP) echo packets to trace the route to a specific destination host and reports back the results at every hop on the path.
The syntax of the traceroute command in different operating systems is as follows:
Windows operating systems: tracert <Hostname> or tracert <IPAddress>
Unix/Linux and MAC OS: traceroute <Hostname> or
traceroute
<IPAddress>
NetWare: iptrace
The traceroute utility offers very useful information when diagnosing connectivity problems. It provides the IP address of every router (hop) that it passes through and reports the time it takes from one hop to another. This is helpful in diagnosing the exact location of the network bottleneck or congestion.
The following example shows the output of the tracert utility when used to trace the route to the web site www.oreilly.com:
C:\ >tracert www.oreilly.com Tracing route to www.oreilly.com [208.201.239.37] over a maximum of 30 hops: 1 1 ms <1 ms <1 ms 192.168.1.1 2 65 ms 91 ms 88 ms 72.138.64.129 3 25 ms 59 ms 49 ms 10.1.65.129 4 52 ms 50 ms 65 ms gw01.hnsn.phub.net.cable.rogers.com [66.185.80.25] 5 47 ms 61 ms 57 ms gw02.mtnk.phub.net.cable.rogers.com [66.185.81.94] 6 68 ms 137 ms 63 ms igw01.ny8th.phub.net.cable.rogers.com [66.185.81.13] 7 * * * Request timed out. 8 95 ms 76 ms 55 ms so-2-1-0.cr1.ord1.us.nlayer.net [69.22.142.106] 9 116 ms 112 ms 128 ms so-2-3-0.cr1.sfo1.us.nlayer.net [69.22.142.78] 10 152 ms 155 ms 108 ms ge2-7.hr2.sfo1.us.nlayer.net [69.22.143.26] 11 158 ms 161 ms 137 ms sonic.ge2-3.hr2.sfo1.us.nlayer.net [69.22.130.62 12 131 ms 121 ms 120 ms 0.at-1-0-0.gw4.200p-sf.sonic.net [64.142.0.186] 13 159 ms 141 ms 118 ms 0.ge-0-1-0.gw.sr.sonic.net [64.142.0.197] 14 146 ms 143 ms 166 ms gig49.dist1-1.sr.sonic.net [209.204.191.30] 15 166 ms 148 ms 115 ms ora-demarc.customer.sonic.net [64.142.122.36] 16 153 ms 164 ms 146 ms www.oreillynet.com [208.201.239.37] Trace complete.
It is easy to interpret the results of the tracert utility. The first column shows the hop number, which is the network device that responds to the ICMP echo request. The next three columns show the roundtrip time in milliseconds that the packet takes. The next column shows the hostname and the IP address of the responding device.
In some situations, the network is congested. This is shown
as Request Timed Out in the output. This may be due to a misconfigured
router at the seventh hop. But the trace continues to the next hop
until it reaches the destination. Once the problem device is
identified, you may use some other utility, such as
ping, to pinpoint the source of the
issue.
The following is an example of an unsuccessful attempt to trace route to the web site comptia.org. Notice that after tracing the route up to 13 hops, the ICMP echo request is being timed out. In other words, the tracert utility has failed to get a response from the next hop device.
C:\ >tracert comptia.org Tracing route to comptia.org [208.252.144.4] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms 192.168.1.1 2 30 ms 29 ms 29 ms 72.138.64.129 3 24 ms 29 ms 29 ms 10.1.65.129 4 28 ms 29 ms 29 ms gw01.nmkt.phub.net.cable.rogers.com [66.185.80.109] 5 27 ms 29 ms 29 ms gw01.mtpk.phub.net.cable.rogers.com [66.185.81.213] 6 28 ms 27 ms 29 ms 66.185.80.46 7 41 ms 35 ms 40 ms igw01.chcrmk.phub.net.cable.rogers.com [66.185.80.201] 8 51 ms 54 ms 53 ms so-4-3-0.mpr1.ord7.us.above.net [64.124.11.21] 9 56 ms 57 ms 60 ms above-oc12.ord.ALTER.net [64.125.12.246] 10 59 ms 59 ms 62 ms 0.so-5-2-0.XL2.CHI2.ALTER.NET [152.63.68.6] 11 68 ms 60 ms 64 ms 0.so-7-0-0.XL2.CHI1.ALTER.NET [152.63.64.137] 12 64 ms 58 ms 60 ms POS7-0.GW4.CHI1.ALTER.NET [152.63.68.233] 13 224 ms 226 ms 219 ms Comptia-chi-gw.customer.ALTER.NET [157.130.102.146] 14 * * * Request timed out. 15 * * * Request timed out. 16 * * * Request timed out. 17 * * * Request timed out.
The ping utility is used to test connectivity between two TCP/IP hosts. Like the tracert utility, it also uses ICMP echo requests to the destination host. This utility is a part of the TCP/IP protocol suite and is installed by default on all TCP/IP devices. Ping can quickly determine whether the host is connected or not and how long it takes for the request to take the roundtrip. Aside from testing connectivity, the ping command can also be used to test whether the name resolution is working.
On Windows XP/2000/2003 computers, the ping command sends out four ICMP echo packets by default. The following is an example of a successful ping command:
C:\ >ping www.google.com
Pinging www.l.google.com [72.14.207.99] with 32 bytes of data:
Reply from 72.14.207.99: bytes=32 time=20ms TTL=246
Reply from 72.14.207.99: bytes=32 time=24ms TTL=246
Reply from 72.14.207.99: bytes=32 time=19ms TTL=246
Reply from 72.14.207.99: bytes=32 time=22ms TTL=246
Ping statistics for 72.14.207.99:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 19ms, Maximum = 24ms, Average = 21msThe ping command supports a number of parameters for increased functionality. Some of the common parameters and their functions are listed in Table 8-20.
Table 8-20. ping command parameters
Parameter | Function |
|---|---|
| Resolves and displays the given IP address to the hostname. |
| Specifies the number of echo requests to be sent. By default, four messages are sent in Windows OS. |
| Specifies that the count hops be recorded. The Count must be a number between 1 and 9. |
| Specifies that the timestamp be used to record echo request messages. The Count must be a number between 1 and 4. |
| Specifies the Time-To-Live (TTL) value for echo request messages. For Windows operating systems, the value of TTL must be less than 255. |
| This parameter forces the ping command to continue sending echo messages until manually stopped. |
| Specifies the timeout value in milliseconds for each echo reply. |
When you use the ping utility to diagnose network problems, you must be able to interpret the output correctly in order to find out the exact cause of the problem. The following are some of the common output messages that you must be able to understand:
A Request Timed Out message indicates that the echo request message did not get any response from the destination host. The destination device might not be connected to the network, be powered down, or configured correctly. It may also mean that the destination host does not exist, and you might be using an incorrect address with the ping command. Some intermediate device on the path may also not be functioning. The code that follows is an example of this message.
Pinging 192.168.0.2 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 192.168.0.2:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0msThe Destination Host Unreachable error message appears in the ping output when the host you are trying to ping is not found. Check that the local host is correctly configured with the IP address of the default gateway. The following is an example of this error message. Note that the ping statistics are similar to the Request Timed Out message.
Pinging 192.168.0.2 with 32 bytes of data:
Destination host unreachable.
Destination host unreachable.
Destination host unreachable.
Destination host unreachable.
Ping statistics for 192.168.0.2:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0msThe Unknown Host error message means that the specified hostname could not be resolved. This problem is associated with the DNS. Check that the DNS server address is correctly configured on the local host and the DNS server is online and connected to the network. This may also mean that the HOSTS file is not correctly configured on the local host. In this situation, you might need to use another utility, such as nslookup or dig, to find out the exact problem. The following is an example of this message:
C:\>ping www.mydomain.com
Unkown host www.mydomain.caEach ping command is executed with a default Time-To-Live (TTL) value. Each time the ping echo message encounters a network device, the TTL value is subtracted by 1. The purpose of the TTL is to prevent the echo message from looping around different network devices. The TTL Expired error message means that the echo message sent to the destination could not get a response, and the TTL value is reduced to 0. This indicates a routing problem on the network. On Windows operating systems, you can use the ping -i command to increase the TTL value to a maximum of 255. The following is an example of this message:
Reply from 192.168.0.2: TTL Expired in transit.
ping is one of the most frequently used troubleshooting utilities, which is available in all implementations of the TCP/IP networks. When diagnosing a connectivity problem with ping, the following steps should be taken:
ping the local loopback address 127.0.0.1. A successful ping to this address verifies that the TCP/IP is correctly installed and working on the local host. If the request times out, you might need to reinstall the TCP/IP on the local host.
ping the IP address configured on the network interface of the local host. If this is successful, the TCP/IP is correctly installed and configured on the network interface. If the request times out, the interface might not be correctly bound to TCP/IP, or it may not be using a correct driver.
ping the IP address of another host on the local network segment. If this is successful, the local host can connect to other hosts on the local segment. If the request times out, you might need to check the network connections on the local host, or on the hub or switch.
ping the IP address of the default gateway configured on the local host. If this is successful, the local host can connect to remote hosts located in other network segments. If this command fails, verify that the default gateway is correctly configured and that it is operational on the network.
Finally, when the ping to the default gateway is successful, you can try to ping the IP address of a remote host.
If these steps do not resolve the problem, you might have to use other TCP/IP diagnostic utilities.
The arp is used to resolve an IP address to the MAC address. The arp is a command-line utility that can be used to diagnose address resolution problems. Hosts on TCP/IP networks use IP addresses to communicate to each other. IP addresses are further resolved to their MAC addresses in order to deliver IP packets to the correct host. These MAC addresses are temporarily stored on the local host in the ARP cache. The ARP cache is a table that maps recently resolved IP addresses and their corresponding MAC addresses. It is periodically refreshed with newer entries, and older entries are deleted. Whenever a host needs to send a packet to another host, it first checks its local ARP cache before sending a broadcast message on the local network.
There are two types of entries in the ARP cache: dynamic and static. The dynamic entries are created automatically as the local host resolves IP addresses. The static entries are added manually using the arp -s command. You can check the ARP cache of the local computer anytime by using the arp -a command the arp -g command. Here is an output of this command on a Windows XP computer:
C:\ >arp -a Interface: 192.168.1.100 --- 0×10003 Internet Address Physical Address Type 192.168.1.1 00-40-f4-e4-48-50 dynamic
The arp command supports several parameters, as listed in Table 8-21.
Table 8-21. arp command parameters
Parameter | Function |
|---|---|
| Displays the ARP cache entries. |
| Specifies a MAC address. |
| Specifies the Internet address. |
| Specifies a particular network interface. |
| Deletes an entry from the ARP cache. |
| Adds a static entry in the ARP cache. |
The netstat utility is used to display the protocol statistics and current active TCP/IP connections on the local host. When used without using any parameters, this utility displays all inbound and outbound TCP/IP connections, as shown in the following output.
C:\ >netstat Active Connections Proto Local Address Foreign Address State TCP pkb:1038 phx.gbl:1863 ESTABLISHED TCP pkb:1049 209.123.81.160:http CLOSE_WAIT TCP pkb:1050 209.123.81.160:http CLOSE_WAIT TCP pkb:1054 209.123.81.167:http CLOSE_WAIT TCP pkb:1055 209.123.81.167:http CLOSE_WAIT TCP pkb:4064 qb-in-f99.google.com:http ESTABLISHED TCP pkb:4065 qb-in-f99.google.com:http ESTABLISHED TCP pkb:4078 ns-vip2.hitbox.com:http ESTABLISHED TCP pkb:4080 208.252.144.4:http ESTABLISHED TCP pkb:4081 208.252.144.4:http ESTABLISHED TCP pkb:4083 qb-in-f99.google.com:http ESTABLISHED TCP pkb:4084 206-5.amazon.com:http ESTABLISHED TCP pkb:4085 209.123.81.153:http ESTABLISHED TCP pkb:4086 209.123.81.166:http ESTABLISHED
The output includes columns such as protocol, local address and port number; foreign address (destination) and its port number; and the current state of the connection. The netstat utility includes several parameters that can be used to correctly pinpoint a specific problem with the TCP/IP connections. Table 8-22 lists different parameters available with this command.
Table 8-22. netstat command parameters
Parameter | Function |
|---|---|
| Displays all current connections and listening ports. |
| Displays Ethernet
statistics. You may combine this with the |
| Displays addresses and port numbers in numerical form. |
| Displays statistics for the specified protocol. |
| Displays the routing table. |
| Displays per-protocol statistics. By default, statistics are shown for IP, ICMP, TCP, and UDP. |
| Redisplays the
selected statistics and pauses between each display by the
time specified by |
The following examples explain how the netstat utility can be used to display the current TCP/IP activities on the local host using various parameters. While interpretation of all output statistics is beyond the scope of the Network+ exam, most of the outputs are self-explanatory.
You can also use the netstat -s command to display detailed statistics of different protocols such as IP, ICMP, TCP, and UDP, as shown in the following output:
C:\ >netstat -s
IPv4 Statistics
Packets Received = 172706
Received Header Errors = 0
Received Address Errors = 8624
Datagrams Forwarded = 0
Unknown Protocols Received = 0
Received Packets Discarded = 0
Received Packets Delivered = 166185
Output Requests = 147800
Routing Discards = 0
Discarded Output Packets = 0
Output Packet No Route = 0
Reassembly Required = 0
Reassembly Successful = 0
Reassembly Failures = 0
Datagrams Successfully Fragmented = 0
Datagrams Failing Fragmentation = 0
Fragments Created = 0
ICMPv4 Statistics
Received Sent
Messages 289 20
Errors 32 1
Destination Unreachable 253 19
Time Exceeded 3 0
Parameter Problems 0 0
Source Quenches 1 0
Redirects 0 0
Echos 0 0
Echo Replies 0 0
Timestamps 0 0
Timestamp Replies 0 0
Address Masks 0 0
Address Mask Replies 0 0
TCP Statistics for IPv4
Active Opens = 3110
Passive Opens = 114
Failed Connection Attempts = 80
Reset Connections = 383
Current Connections = 5
Segments Received = 130377
Segments Sent = 111391
Segments Retransmitted = 1507
UDP Statistics for IPv4
Datagrams Received = 35498
No Ports = 6811
Receive Errors = 1
Datagrams Sent = 34941The activities of the network interface card can be displayed using the netstat -e command, as shown in the following output:
C:\ >netstat -e
Interface Statistics
Received Sent
Bytes 127209366 46129918
Unicast packets 164016 147614
Non-unicast packets 8591 191
Discards 0 0
Errors 0 0
Unknown protocols 0The statistics for TCP and UDP can be displayed using the netstat -a command, as shown in the following output:
C:\ >netstat -a Active Connections Proto Local Address Foreign Address State TCP pkb:epmap pkb:0 LISTENING TCP pkb:microsoft-ds pkb:0 LISTENING TCP pkb:1025 pkb:0 LISTENING TCP pkb:netbios-ssn pkb:0 LISTENING TCP pkb:1038 phx.gbl:1863 ESTABLISHED TCP pkb:1049 209.123.81.160:http CLOSE_WAIT TCP pkb:1050 209.123.81.160:http CLOSE_WAIT UDP pkb:microsoft-ds *:* UDP pkb:isakmp *:* UDP pkb:1028 *:* UDP pkb:1031 *:* UDP pkb:1045 *:* UDP pkb:ntp *:* UDP pkb:netbios-ns *:* UDP pkb:netbios-dgm *:* UDP pkb:10891 *:* UDP pkb:45762 *:* UDP pkb:57838 *:*
The routing table of the local host can be displayed using the netstat -r command, as shown in the following output:
C:\ >netstat -r
IPv4 Route Table
===========================================================================
Interface List
0×1 ........................... MS TCP Loopback interface
0×10003 ...00 0b 6a 0b 71 d8 ...... VIA Rhine II Fast Ethernet Adapter
===========================================================================
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.100 20
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.1.0 255.255.255.0 192.168.1.100 192.168.1.100 20
192.168.1.100 255.255.255.255 127.0.0.1 127.0.0.1 20
192.168.1.255 255.255.255.255 192.168.1.100 192.168.1.100 20
224.0.0.0 240.0.0.0 192.168.1.100 192.168.1.100 20
255.255.255.255 255.255.255.255 192.168.1.100 192.168.1.100 1
Default Gateway: 192.168.1.1
===========================================================================
Persistent Routes:
NoneThe nbtstat utility is exclusive to Windows operating systems. It is used to display the NetBIOS over TCP/IP connection statistics. In case there is a problem with NetBIOS name resolution, the nbtstat utility comes in handy to diagnose it. Table 8-23 lists common parameters available for this command and their functions.
Table 8-23. nbstat command parameters
Parameter | Function |
|---|---|
| Displays the NetBIOS name table of a remote host given its name. |
| Displays the NetBIOS name table of a remote host given its IP address. |
| Displays the name table of the remote host. |
| Displays local NetBIOS names. |
| Displays the NetBIOS names resolved using WINS. |
| Purges the NetBIOS cache of the specified remote host. |
| Sends name release packets to WINS and then begins again. |
| Displays sessions table with only IP addresses. |
| Displays sessions table converting destination IP addresses to NetBIOS names. |
nbtstat RemoteName | Displays the machine name of a remote host. |
nbtstat IPAddress | Displays the IP address in a dotted decimal notation. |
nbtstat Interval | Redisplays selected statistics pausing the number of seconds, as specified in the Interval parameter, between each display. |
The parameters available with the nbtstat utility are case-sensitive. For example, the function of nbtstat -a is different from the nbstat -A function. Similarly, the functions -s and -S parameters and, -r and -R parameters are not the same. This is different from most other Windows commands, which are not case-sensitive.
The following is a sample output of the nbtstat command when used with the -n parameter. The output lists the entries in the local NetBIOS name cache.
C:\ >nbtstat -n Local Area Connection: Node IpAddress: [192.168.1.100] Scope Id: [] NetBIOS Local Name Table Name Type Status --------------------------------------------- PKB <00> UNIQUE Registered WORKGROUP <00> GROUP Registered PKB <20> UNIQUE Registered WORKGROUP <1E> GROUP Registered WORKGROUP <1D> UNIQUE Registered
The ipconfig utility is used in
Windows operating systems to display the TCP/IP configuration of
the local host. It is commonly used with the /all parameter to display the configuration of all
network adapters installed on the system. The following is a
sample output of the ipconfig /all command:
C:\ >ipconfig /all Windows IP Configuration Host Name . . . . . . . . . . . . : pkb Primary Dns Suffix . . . . . . . : Node Type . . . . . . . . . . . . : Unknown IP Routing Enabled. . . . . . . . : No WINS Proxy Enabled. . . . . . . . : No Ethernet adapter Local Area Connection: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : VIA Rhine II Fast Ethernet Ada pter Physical Address. . . . . . . . . : 00-0B-6A-0B-71-D8 DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes IP Address. . . . . . . . . . . . : 192.168.1.100 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.1.1 DHCP Server . . . . . . . . . . . : 192.168.1.1 DNS Servers . . . . . . . . . . . : 192.168.1.1 Lease Obtained. . . . . . . . . . : Monday, October 02, 2006 12:40:09 PM Lease Expires . . . . . . . . . . : Monday, October 02, 2006 1:40:09 PM
Table 8-24 lists the parameters and their functions available with the ipconfig command.
Table 8-24. ipconfig command parameters
Parameter | Function |
|---|---|
| Displays the TCP/IP configuration of all network adapters on the local host. |
| Releases the DHCP supplied TCP/IP configuration of the network adapter. |
| Renews DHCP supplied TCP/IP configuration of the network adapter. |
On Windows XP, Windows 2000, and Windows Server 2003 operating systems, the ipconfig utility also includes the following parameters:
/flushdnsUsed to clear the DNS cache on the local host.
/displaydnsUsed to display the entries in the local DNS cache.
/registerdnsUsed to register the name of the local host with the DNS server.
ipconfig is very useful in troubleshooting configuration problems on a TCP/IP host. The output of the ipconfig /all command can reveal one or more problem areas, and an administrator can take necessary corrective action to resolve the problem. For example, if the output does not show a valid IP address, the ipconfig /release and ipconfig /renew commands can renew the IP address of the host with the DHCP server. On a Windows XP/2000/2003 system, if the host is unable to resolve DNS names, the ipconfig /flushdns can be used to clear the DNS cache. Similarly, if the host is not able to connect to any remote hosts, the default gateway address should be checked in the output of the ipconfig command.
The ifconfig command is the
Unix/Linux and MAC OS X equivalent of the Windows
ipconfig command. Unlike the limited features
of ipconfig, this command has
much more advanced diagnostic features. Typing ifconfig help at a Unix host command prompt gets you all the
parameters and other information about how this command could be
used.
The winipcfg command was used on Windows 95, Windows 98, and Windows Me computers to display the current TCP/IP configuration settings. Unlike other TCP/IP utilities, this is a graphical utility that displays all information in a window. The output of the winipcfg command includes the following information:
The MAC address of the network adapter.
The IP address and the subnet mask assigned to the computer.
The IP address of the default gateway.
The IP address of the configured DHCP server.
The IP addresses of the primary and secondary WINS servers.
Information about when the current lease was obtained and when it is due to expire.
The output of the winipcfg command can be analyzed to correctly diagnose a connectivity problem on Windows 95/98/Me computers. For example, if the computer is not able to connect to any other computer on a remote network, the IP address of the default gateway might be incorrect, or it may not be online. Similarly, if the computer is not able to connect to any other computer on the local network segment, the local computer might have an incorrect IP address or subnet mask. If the computer is not able to browse the network, the WINS IP addresses may be incorrect.
The nslookup utility is used to diagnose problems related to the DNS services. In other words, it is used to resolve name resolution problems. This utility can be used to perform name resolution queries against a specified DNS server or to display information about currently configured DNS servers on a local host.
Unlike other commands discussed in this section, the nslookup command can be executed in either interactive mode or noninteractive mode as explained in the following paragraphs:
The non-interactive mode is useful when you need to run the command with one or two pieces of information. For example, you can use the following command to resolve a specific hostname:
nslookup hostname
You can also specify a DNS server to resolve the hostname, as shown in the following example:
nslookup hostname -dns_server
If you do not specify the DNS server, the DNS server configured on the local host is used by default to resolve the query.
In interactive mode, just type nslookup and press the Enter key.
The command will display the information about the current
hostname and the IP address of the configured DNS server
along with a prompt. You can then enter other
nslookup subcommands on this prompt. To
exit the interactive mode, type Exit and press the Enter key.
The interactive mode includes a number of subcommands.
On Windows systems, you can type ? at the interactive prompt to get
more information on the syntax and usage of these. Table 8-25
lists some of the commonly used parameters and their
functions.
Table 8-25. nslookup subcommands
Parameter | Function |
|---|---|
| Prints information about options, the current DNS server, and the host. |
| Prints debugging information. |
| Prints exhaustive debugging information. |
| Appends a domain name to each query. |
| Asks for a recursive answer to each query. |
| Uses a domain search list. |
| Always uses a virtual circuit. |
| Sets the default
domain name to |
| Sets the domain to N1 and the search list to N1, N2, etc. |
| Sets the root
server to |
| Sets the domain to N1. |
| Sets the initial timeout to x seconds. |
| Sets the query type (for example, A, ANY, CNAME, MX, NS, PTR, SOA, or SRV). |
| Same as |
| Sets the server
name to |
| Exits the interactive mode. |
The following example shows how the nslookup command can be used to resolve a hostname using the non-interactive mode:
C:\ >nslookup www.oreilly.com Server: localhost Address: 192.168.1.1 Non-authoritative answer: Name: www.oreilly.com Addresses: 208.201.239.36, 208.201.239.37
In case you need to resolve a hostname using a specific DNS server, you can use the following command instead:
C:\ >nslookup www.oreilly.com 192.168.1.5
You can also use nslookup to resolve IP addresses to hostnames, as shown in the following example.
C:\ >nslookup 208.201.239.36 Server: localhost Address: 192.168.1.1 Name: www.oreillynet.com Address: 208.201.239.36
The dig command is used on Unix/Linux and MAC OS X systems to perform DNS queries. It is more versatile than the nslookup command. This command does not work in interactive mode, and all command-line parameters have to be supplied at the main prompt. When used without any parameters, this command searches the root DNS server. The following is the basic syntax of a standard dig command:
dig @server name type
The following are standard parameters of the dig command:
Specifies the name of the DNS server to query.
Specifies the hostname to be resolved.
Specifies the type of query such as A, ANY, MX, etc. The default query type is A.
The dig command supports a number of options for extended functionality. These options are beyond the scope of the Network+ exam. The output of a standard dig query includes the following three main sections:
This section displays the type and class of the DNS query.
This section displays the name of the host and its IP address for which the query is being performed.
This section displays information about authoritative DNS servers for the domain against which the query is performed.
In addition to the above sections, the output also includes information on the total time taken to resolve the query, the time when the query was resolved, and the size of the message.
When troubleshooting network connectivity problems, one of the easiest methods is to check the visual indicators on network devices. Almost every network device has some form of visual indicator that can help find out whether the device is working or not. Network interface cards, hubs, switches, and routers all have light emitting diodes (LEDs) that indicate whether the device is functioning properly or not.
Some network devices have LEDs that change color according to the condition of the device or of an interface of the device. For example, hubs and switches have LEDs on every port; the color of the LED on a port indicates the port's condition. Similarly, NICs have small LEDs that can be helpful in detecting the source of a connectivity problem.
The following list provides guidelines for diagnosing a connectivity problem depending on the status of the LED lights. Note that these status lights may vary from one manufacturer to another.
The device or the port is not in operation. It is either not connected or is faulty.
The device or port is connected, but there is no activity on the port.
The device or the port is functioning properly. It is transmitting and receiving data as expected.
The network is congested and collisions are occurring on the network media.
Certain devices provide separate LEDs for power, activity, and network collisions. Each of these LEDs can be a good indicator of the connectivity problem. Depending on the type and vendor of the network device used, the documentation of the device may be very helpful in understanding the meaning of LED status lights.
Remote connectivity problems include problems with connecting to a corporate network using Remote Access Services, VPN, and the Internet. When resolving remote connectivity problems, you will need to make certain basic checks to identify the problem and then find an appropriate resolution. The issue might be due to physical connectivity, permissions, authentication, incorrect protocol settings, or some device such as the wireless router. A logical approach to resolving a given problem will lead you to find a suitable corrective action. In this section, I will discuss some basic problem areas related to remote access.
The main purpose of remote access is to connect to the company network and get access to network resources. When the remote connection is established, users might need to access file and print services in order to continue with the work for which they have connected to a remote network. If users report problems accessing or using shared resources located on the company network, you should check that they have appropriate permissions on the specific resources. Even when the RAS server has granted access to the network, access to file and printing services may be restricted or may vary from one user to another.
Every client/server network environment, including the RAS server, requires some form of authentication. In smaller networks, the RAS server itself is configured to grant remote access to clients. In larger networks however, special servers, such as the RADIUS server, are configured to process authentication requests from multiple remote access clients. If a single client is reporting a logon problem, you should make sure that the client is authorized to connect remotely to the network. If multiple remote users are complaining of logon problems, the problem might lie with the remote access server or the authentication server. Even when the remote clients are granted remote access, permissions on network resources such as files and folders may still be restricted and vary from one shared resource to another.
Problems related to RAS protocol configurations usually rest with client computers. On a typical TCP/IP network, you should make sure that all remote clients are using the correct IP address, default gateway, and DNS addresses. In large networks, a DHCP server usually assigns these settings to clients. In smaller networks, the RAS server itself may be configured to assign IP addresses to remote clients. Both the client and the server should support at least one common authentication protocol. You must also make sure that both ends are using similar settings for the authentication protocol. For example, if the RAS server is requesting an EAP-based authentication protocol and the client does not support it, communications between the client and the RAS server cannot be established.
Remote access connectivity problems start with physical connections involving dial-up modems, routers, cables, and connectors. Telephone lines, DSL modems, and broadband cable may also cause connectivity problems. The following is a list of some quick checks that you can make so you are able to identify the cause of the problem and take an appropriate corrective action:
Make sure that there is a dial tone when you dial a number.
Make sure that the correct number is being dialed.
Make sure that the call-waiting feature is turned off. Call waiting causes dial-up connections to drop when a call is received.
Make sure that the modem connections and settings are correct.
Make sure that the correct username and password are used.
If everything seems to be in order, call the ISP to find out whether the problem lies at the other end.
Check that the DSL cables are connected properly to the DSL modem and the computer.
Check to make sure that the network interface is using correct driver software.
Check that the LED indicators on the DSL modem and the network interface are communicating.
Make sure that the correct username and password are used.
If everything seems to be in order, call the ISP to find out whether the problem lies at the other end.
Check that the coaxial cable is properly attached to the cable modem, and that the modem is properly attached to the computer.
Check to make sure that the network interface is using the correct driver software.
Check that the LED indicators on the DSL modem and the network interface are communicating.
Make sure that the correct username and password are used.
If everything seems to be in order, call the ISP to find out whether the problem lies at the other end.
Check the connection status indicators on the wireless router.
Check the physical connections of the wireless interface and wireless router.
If the computer is experiencing intermittent connectivity problems, check that it is located within the range of the wireless router. If possible, move the computer a bit closer to the wireless router.
In this section, we will discuss issues related to network connectivity. Network connectivity is provided through several components of the network infrastructure. These components essentially include network services, devices, and media. We will also discuss how problems related to network topology can be resolved. Finally, we will take a look at the logical steps involved in identifying, isolating, and resolving a given network problem.
A network requires several services to function properly. These services are run on one or more network servers and include DNS, DHCP, and WINS. Network services are critical to the functioning of the entire network. Addition of, removal of, or changes made to these services have network-wide effects. You must understand how these services affect the network users if any change is made. In this section, we will discuss the effects of problems with network services.
The DHCP service is used to dynamically assign IP addresses and related configurations to TCP/IP hosts in a network. The addresses assigned by the DHCP server are valid for a certain period of time called a lease. When 50 percent of the lease period expires, the DHCP clients attempt to renew their lease with the DHCP server. When clients are added or removed from the network, the DHCP server takes care of IP address assignments.
When a DHCP client boots up for the first time, it searches for a DHCP server that can assign it an IP address configuration. Any available DHCP server can service the request. The network traffic generated by the DHCP clients and servers is negligible and is not of much concern. The longer the lease duration, the less DHCP traffic is generated by clients. In other words, if network congestion is a problem, you might consider increasing the lease duration.
If a new DHCP server is added to the network, the DHCP clients might need to be reconfigured so that they contact the right DHCP server to obtain and renew their IP addresses. On the other hand, removing the DHCP server will affect almost every client in the network. Clients will not able to obtain or renew their IP addresses. This simply means that the clients will not be able to connect to the network. If it is a small network, the clients can be configured with static IP addresses. For a large network, you might have to make an alternate DHCP server available to continue normal network functions.
The DNS service is used in a network to resolve hostnames to IP addresses. Users connect to remote hosts using their easy-to-remember names instead of IP addresses that are hard to remember. Without the DNS service, users may not be able to connect to the remote hosts using their names. For example, if a client is able to connect to a remote host using its IP address but not by using the hostname, there might be a problem with the DNS server.
On client computers, the DHCP server dynamically assigns the DNS configuration. It may also be entered manually on each computer. DNS resolutions can also be performed using a local text file named HOSTS that keeps a mapping of hostnames to IP addresses.
Adding, removing, or making changes to the DNS server requires advanced skills. These skills depend on the network operating system being used on the network. As far as the Network+ exam is concerned, you must remember that unavailability of DNS service in the network mainly leads to name resolution problems.
The WINS service is used to resolve NetBIOS names to IP addresses. The WINS service helps reduce broadcast traffic on networks that may cause network congestion. It is exclusively used in Windows networks where NetBIOS names are used. Every time a Windows client needs to connect to a remote computer or browse the network, the WINS server is contacted to resolve the computer name to its IP address.
If the WINS server is not available, the computer might attempt to resolve the computer names using the broadcast method. Network broadcasts are not preferred in large networks as they create significant network traffic and might cause network congestion. Besides this, most routers do not forward broadcast messages in order to prevent the local broadcast traffic to cross over to other network segments. It is important to note that the WINS service itself does not generate much network traffic but instead is helpful in reducing network traffic.
As an alternative to a WINS server, Windows client computers may also use a text file named LMHOSTS to resolve NetBIOS names. Windows client computers are dynamically configured with a preferred and alternate WINS server through the DHCP server. It is also possible to manually configure client computers with WINS addresses in small networks.
It is obvious that WINS is helpful in reducing network broadcast traffic. Before removing a WINS server from the network, you must either plan to install an alternate WINS server or configure the LMHOSTS file manually on each Windows client.
When troubleshooting a network connectivity problem, the first thing you need to know is which network topology is in use. Depending on the topology, the troubleshooting methods will also vary. The following sections explain common troubleshooting methods for bus, star, ring, and mesh topologies.
Networks with physical bus topology are hardly in use these days due to the popularity of twisted pair cabling and star topology. However, there are still chances that you will find quite a few old networks that use coaxial cable and bus topology. The following are some of the common points to remember when troubleshooting connectivity problems in a bus network:
Breaks in coaxial cables are hardest to locate in a bus network. If the cable breaks, all computers will be disconnected from the network.
The two ends of the bus network must be terminated with a 50-Ohm terminator. Even if one of the terminators is missing, the network segment will be down.
One end of the bus network cable must be grounded. If the cable is not grounded, users will report intermittent connectivity problems.
Addition or removal of computers from the bus network usually causes interruptions in network connectivity. When a computer is added or removed from the network, make sure that BNC T-connectors are properly attached.
If the network interface on one of the computers in the network fails, it will also cause network failures.
Star topology is the most widely used network topology these days. In a star network, a central device called a hub or a switch provides a point-to-point connection to all devices in the network segment. The length of the cable used to connect a single device depends on the type of cable. The following are some of the common points to remember when troubleshooting connectivity problems in a star network:
Hubs and switches have visual indicators (LEDs) to indicate the status of different ports. Depending on the make and model of the hub/switch, the light of the LED might be helpful to determine whether the problem is with one port or with all ports. LEDs can help you determine whether a port is connected or disconnected, or whether there are collisions on the media.
Remember that in a star network, the hub or switch is the single point of failure. If several users on a network segment are reporting connectivity problems, you should check whether the hub or switch has failed.
If only a single user is reporting a connectivity problem, you might have to trace the cable from his computer to the hub/switch and check the status indicator on that port. If it shows a disconnected cable, although it is connected, the port may not be working or the cable may be faulty. First, try to plug the cable into a different port. If that does not help, try replacing the cable.
Sometimes, a few new computers are added to a star network, but none of them can connect to the network. In such a situation, you should verify that correct cable type and length is used. Make sure that patch panels and patch cables are attached properly.
Ring networks are, in fact, installed as physical star networks but function as a logical ring. Like the bus networks, ring networks are also hard to find these days. The central device used in ring networks is the Multi-Station Access Unit (MSAU), or the Media Access Unit (MAU). The cables in use may be fiber optic or twisted pair. The following are some of the common points to remember when troubleshooting connectivity problems in a ring network:
The central device or the MSAU is a single point of failure in a ring network. If the MSAU is not working or if a single port on the MSAU is not working, all users on the network will report connectivity problems.
When installing or replacing an MSAU, make sure that the Ring-In (RI) and Ring-Out (RO) are properly connected and configured.
In order to have a completely working ring network, you must verify that all network interface cards are operating at the same speed.
Verify that the cable used to connect network devices is not broken. If a single cable breaks, the ring will be broken and the network will be down.
When adding or removing network cables and connectors, and when adding new workstations or printers, to a ring network make sure that the cables and connectors are of correct specifications.
A mesh network provides the best fault tolerance of all network topologies. Every device (computer or printer) is connected to every other device. Even if one or two cables are broken, an alternate connection is always available. Although a mesh network provides the best performance and fault tolerance, it may be the most difficult network to troubleshoot. This is due to the number of connections and the number of cables involved in setting up the network. Connectivity problems in a mesh network do not appear unless all connections to a device are broken. Mesh networks are rarely implemented in organizations these days due to the cost involved. This type of network is used only in areas of high availability.
The network infrastructure includes almost every component of the network. For example, hubs, switches, routers, cables, connectors, terminators, and wireless access points are all part of the network infrastructure. Although servers that provide network services such as DNS, WINS, DHCP, and RAS are also part of the network infrastructure, this section deals with troubleshooting only the physical components of the network. Given a network problem scenario, you must have a troubleshooting strategy in place.
The cables and connectors used to interconnect network devices are often the cause of a network connectivity problem. Some of the key points to remember while troubleshooting network media are as follows:
Troubleshooting bad connectors involves verifying that the correct type of connector is used and that it is properly attached. For example, in a bus network, a loose connector or a loose terminator may result in all users being unable to communicate on the network segment. For fiber optic cabling, you must ensure that devices and connectors are compatible with each other.
A correct cable type should be used. For example, if a crossover UTP cable is used where a straight cable is required, connectivity problems will arise. In a star network, a single broken cable usually affects only a single workstation.
Media range refers to the specified range of network cable or the range of a wireless access point. The total length of a cable used to connect devices must not exceed the specifications. Similarly, the wireless devices must be located within the range of the access point in wireless networks.
Wireless networks are susceptible to electromagnetic and radio frequency interferences (EMI and RFI). Wireless access points should not be located near areas of high interference.
Unshielded twisted pair (UTP) cables are also prone to interference generated by crosstalk and electromagnetic interference. UTP cables should not be run in areas of high EMI, such as near transformers and beside high-voltage electric cables. For ceilings and ducts, a special type of cable known as plenum-rated cable must be used.
The following are some of the common problems with network devices:
If a hub fails, all computers connected to the hub will experience connectivity problems. Check that the hub is powered on and try to resolve the problem by recycling the power. If the problem is not solved, you might have to replace the hub.
A failed switch results in connectivity problems to all the computers in the network segment. Check that the switch is powered on and try to resolve the problem by recycling the power. If the problem is not solved, you might have to replace the switch.
Bridges are used to connect network segments. A failed bridge results in computers in one network segment being unable to connect to computers in another segment.
Routers are used to connect network segments, but the function of the router is much more advanced than the bridge. If a router fails, computers on one of the network segments will not be able to connect to any other network segment. If the router is connected to the Internet, then no one will be able to access the Internet. You can test the router connectivity using TCP/IP troubleshooting utilities such as ping or tracert/traceroute.
WAPs are used to provide network connectivity to wireless clients. They are also used to connect the wired network to a wireless network. If all the users on the wireless network are experiencing connectivity problems, the WAP may not be working. You may need to recycle power on the WAP or replace it if it is faulty.
The following list provides a quick review of the factors that may affect the wireless networks:
Wireless signals degrade as they travel away from a wireless signal-generating device, such as the access point. This degradation or attenuation of signals is caused by several environmental factors, such as EMI, RFI, or walls. The weakening of wireless signals can be prevented, to some extent, by careful location of wireless antennae, the use of signal boosters, and correct placement of wireless access points. It is good to know the maximum range of the wireless access points used in the network.
Wireless devices come in different makes and models and conform to several standards. You must make sure that the wireless devices—such as wireless routers, access points, and adapters—all support the standards used on the network. Incompatibility of wireless standards causes connectivity issues.
The Service Set Identifier (SSID) enables wireless clients to connect to a wireless access point and access network resources. If a wireless client is reporting connectivity problems, wireless configuration should be checked to make sure that the client is using the correct SSID. Remember that both the access point and the wireless client should be configured with the same SSID.
In large corporate networks, security is a prime concern, and most administrators configure certain authentication mechanisms to prevent unauthorized access to confidential company data. If a user cannot log on to a wireless network, make sure that he has sufficient permissions to log on. Additionally, confirm that the encryption and authentication settings are configured correctly on his computer. Wireless networks use WEP protocol, which supports both 64- and 128-bit encryption. Make sure that the client is configured to use the correct WEP encryption standard.
Wireless access points are like hubs or switches for the wired network. They have a limited coverage area. All wireless clients must be located within the coverage area to properly transmit and receive signals. When troubleshooting wireless client problems, you should consider factors such as the distance of the wireless client from the access point and signal attenuation due to environmental factors. Wireless repeaters and signal boosters can be used for clients who are located in distant places.
Troubleshooting network problems requires that you follow some basic logical steps. The troubleshooting process should start with identifying the problem symptoms, isolating the affected area, and so on. Following a logical procedure not only makes troubleshooting easy, but it also reduces the time it takes to resolve the problem.
The Network+ exam expects you to understand the following basic steps in resolving a network problem:
Identify the symptoms and potential causes.
Identify the affected area.
Establish what has changed.
Select the most probable cause.
Implement an action plan and solution, including potential affects.
Test the results.
Identify the results and effects of the solution.
Document the solution and process.
These steps are explained in the following sections.
It is important that you memorize the steps given in this section to correctly answer questions related to network troubleshooting. You must be prepared to face one or two questions on the Network+ exam asking you to pick a correct step based on a given troubleshooting scenario. You may also be asked to select the correct order of actions to resolve a given problem.
The first step in troubleshooting is to identify the symptoms of the problem. This is critical and involves gathering related information. If a user has reported the problem, you might need to ask questions to identify the symptoms. In case the problem has occurred on an unattended desktop or server, the system event logs and error messages are very helpful. In any case, you will need to have a good understanding of the operating system in use. You will also need to show good communication skills when talking to the user about the problem. When you have gathered sufficient information, you may well have identified the symptoms of the problem.
Once you have identified the symptoms of the problem, it's time to check how many users have been affected. The problem may lie with a single computer affecting just one user, or it may be affecting several computers, a single network segment, or the entire network. Problems reported by a single user often end on a single desktop itself. You will need to verify exactly how many users and which network segments have been affected.
The next step is to check whether anything has been changed on the computer that is experiencing the problem. For example, a user may report a problem with connectivity to a mail server. You will need to check whether the user has made any changes to the email settings on his computer. Some problems start when a computer's network configuration is changed. Another potential reason for a problem could be that the user has installed new applications or a new service pack, hotfix, or an update.
Based on the information you have gathered so far, you will certainly have identified one or more causes of the problem. You will now need to find out the most probable cause. This is usually done by the elimination process and short-listing the ones that seem to have caused the problem. The reason that does not seem to be logical is eliminated. This will lead you to identify the correct cause.
Once you have identified the reason behind the network problem, you need to decide on a corrective action. But before you do anything, you will need to find out what effects the corrective action might have on the network. For example, you might have to disconnect a critical server from the network or you might have to take it offline for necessary repairs. In such a situation, you will need to find out how this will affect network users. You might also have to report this to one of your senior administrators. Be prepared to state how long it will take to get the job done.
This is a critical step in network troubleshooting—applying your planning skills to resolve the problem as quickly and as effectively as possible. You might have to reinstall certain applications, apply a hotfix, or replace a faulty component in a server. In some situations, the problem might not be resolved with a single action. You must be careful to try just one solution at a time. For example, if you need to replace two defective parts in a server, replace one first and then replace the second.
Once you have identified the effects of the corrective action you are going to take, you will need to test the results. Sometimes, one solution gives rise to another problem. In some cases, an incorrect solution leads to multiple problems. This is particularly important when the solution has to be applied to multiple computers on the network. For example, a small change in permissions on a mail server may result in several users complaining of "access denied" problems. Hence, it is important that you test the results of the solution thoroughly before you finally apply it.
Once the solution has been applied, you will need to identify the results and effects of it. Sometimes, the solution will have a negative and cascading effect on other parts of the network. Some solutions cause multiple-layered problems. Actions such as adding or deleting users, changing permissions, and replacing critical network components such as a switch or a hub affect several users and multiple network segments. You must be able to foresee any possible problems that may occur due to the solution you have applied.
When the problem has been resolved and everything seems to be okay, you should create a document stating all the steps that you have taken to get to the final solution. The documentation is important because it may be referred to at a later date if the same or a similar problem occurs again. The documentation is also helpful in tracking down a person who resolved the problem.
The following are some of the important components of troubleshooting documentation:
The date the problem occurred.
Why did the problem occur? What were the symptoms?
What was done to resolve the problem?
What were the results or effects of the problem?
Who resolved the problem and prepared the documentation?