Troubleshooting TCP/IP Issues with Client Utilities, Part 2
Articles and Tips: article
Novell's World Wide Support
01 Sep 2000
Looks at a number of workstation client utilities and commands that can help you troubleshoot TCP/IP issues. These utilities and commands include TRACERT, ARP, and NETSTAT.
We have thus far looked at troubleshooting techniques for TCP/IP networks using various utilities. Last time we looked briefly a few client workstation utilities and how they can be used to troubleshoot IP networking issues. Now let's look at a few more.
The TRACERT Command (Trace Route)
The Trace Route command does just what its name implies: it will trace the route to a specific host and display all the hops that are used to get to that specific host. This can be very useful when working on network-wide TCP/IP problems. If you are having problems getting to certain areas of your network, you can perform a trace route to help determine what networks are presently available to you. Keep in mind that you may not take the same route to a particular network each time you run the Trace Route command, but this depends on your network design. Performing a trace route to the same host multiple times may help you determine this.
To run the Trace Route command, you need to launch DOS and type TRACERT followed by an IP address or a host name (if your network has DNS resolution enabled). For example, Figure 1 displays the output from typing the following:
tracert www.novell.com <Enter>
This provides you with the DNS name and IP address of each of the Routing hops that where used to contact the host specified.
Figure 1: Response from tracing a route to the server whose DNS resolution name is www.novell.com.
If you do not have DNS resolution enabled and if you know the IP address instead of the DNS resolution name, you can type in the address, such as:
tracert 139.15.2.3 <Enter>
The response is similar to the above. Like Ping, you can use the Trace Route utility to see if NDS/DHCP services are available to you, but Ping only uses the ICMP protocol, as opposed to trace route, which uses both UDP and ICMP protocols.
To display all of the available options for the Trace Route command, from a DOS box, type TRACERT <Enter>. You will see options similar to the following:
Usage: tracert [-d] [-h maximum_hops] [-j host-list] [-w timeout] target_name Options: -d Do not resolve IP addresses to host names. -h maximum_hops Maximum number of hops to search for target. -j host-list Loose source route along host-list. -w timeout Wait timeout in milliseconds for each reply. |
The ARP Command
The ARP command allows you to display and modify the ARP cache of the client. The ARP cache of a TCP/IP client is a table of IP addresses-to-MAC addresses. This table is accessed when the client needs to send a packet of data out to another host. TCP/IP needs the destination IP address and the destination MAC address. The sending application provides the IP address and TCP/IP needs to find out the MAC address of the host with that IP address. It does this by sending out ARP packets and requesting the MAC address for a particular IP address. This information is kept in a table that is then referenced in order to reduce the need to send out ARP requests for every packet being sent.
At times it is useful to look at this table. If a client cannot communicate with other clients on the local subnet, you can check the ARP cache by typing ARP -a <Enter> to see if it is corrupt or if it has invalid information in it. If no entry exists for the server you are trying to communicate with, the chances are that cabling problems exist, or that the host that you are trying to communicate with has a different IP address. If the entry exists, make sure that it is the correct MAC address/IP address mapping in case it's been corrupted, or if someone else has responded on behalf of the host (such as a switch or a router that is running proxy ARP).
There are options available to delete entries from the ARP cache or add entries to the ARP cache manually. By typing ARP <Enter> at the DOS prompt, you will see a detailed list of available options and their usage, similar to the following:
ARP -s inet_addr eth_addr [if_addr] ARP -d inet_addr [if_addr] ARP -a [inet_addr] [-N if_addr] -a Displays current ARP entries by interrogating the urrent protocol data. If inet_addr is specified, the IP and physical addresses for only the specified computer are displayed. If more than one network interface uses ARP, entries for each ARP table are displayed. -g Same as -a. inet_addr Specifies an internet address. -N if_addr Displays the ARP entries for the network interface specified by if_addr. -d Deletes the host specified by inet_addr. -s Adds the host and associates the Internet address inet_addr with the Physical address eth_addr. The physical address is given as 6 hexadecimal bytes separated by hyphens. The entry is permanent. eth_addr Specifies a physical address. if_addr If present, this specifies the Internet address of the interface whose address translation table should be modified. If not present, the first applicable interface will be used. Example: > arp -s 157.55.85.212 00-aa-00-62-c6-09 ... Adds a static entry. > arp -a Displays the arp table. |
The NETSTAT Command
The NETSTAT command is the most important troubleshooting utility on the client. This command displays protocol statistics and current TCP/IP network connection information for the host you are running this on. NETSTAT comes with a number of command line options. From a DOS window, type NETSTAT /H <Enter> to see a complete listing of options, similar to the following:
NETSTAT [-a] [-e] [-n] [-s] [-p proto] [-r] [interval] -a Displays all connections and listening ports. -e Displays Ethernet statistics. This may be combined with the -s option. -n Displays addresses and port numbers in numerical form. -p proto Shows connections for the protocol specified by proto; proto may be TCP or UDP. If used with the -s option to display per-protocol statistics, proto may be TCP, UDP, or IP. -r Displays the routing table. -s Displays per-protocol statistics. By default, statistics are shown for TCP, UDP and IP; the -p option may be used to specify a subset of the default. interval Redisplays selected statistics, pausing interval seconds between each display. Press CTRL+C to stop redisplaying statistics. If omitted, the netstat command will print the current configuration information once. One useful function of NETSTAT is the "-e" option. This option displays the client's Ethernet statistics, including discards and errors. If you suspect the LAN card is having a problem, this option helps you diagnose it. |
For the majority of problems, ICMP or TCP statistics will provide useful clues for troubleshooting communication problems. Using the "-s" option in the NETSTAT command displays IP, ICMP, UDP, and TCP statistics to the screen. (ICMP is the error reporting protocol for IP and is therefore worth paying close attention to.)
For connectivity or routing issues, use the NETSTAT command with the "-r" option to dump the routing table. There should always be a default route (0.0.0.0) entry pointing to the local router for your subnet. If this does not exist, communication to remote hosts outside the local subnet will not be possible. It is possible to configure a default route in two ways:
Using the standard TCPIP configuration utility that is found in the Network Control Panel or by right-clicking Network Neighborhood and selecting the TCP/IP Properties page. This ensures that the entry is permanent.
By adding a static route using the ROUTE ADD command. The difference with this method is that once the Windows workstation is shutdown, the static route is lost.
On a more detailed level, the "-a" option displays the active TCP connections along with the port number and the network host that the port is communicating with. If you are looking at a trace of TCP connection activity for the client, you can use this to relate TCP port numbers with the various servers the client is communicating with.
What Should You Do When You Have TCP/IP Problems?
Determine your workstation's IP address and try to ping that address from a DOS box on that host. If you do not get a response pinging your workstation's address, then the client's TCP/IP is not working.
You can also type PING 127.0.0.1 <Enter> at the workstation's DOS prompt. This is the TCP/IP loopback address for your client and is essentially the same as Pinging your workstation's own IP address. You would not get a response to this Ping if the TCP/IP stack did not load, or if it did load, but some error occurred that stopped TCP/IP from working. Possible reasons why TCP/IP would not load could be that TCP/IP is that it is configured wrong on your workstation, you did not get a DHCP-leased address properly from a DNS/DHCP server, the IP address that you are using is already in use on some other client.
Ping an IP address on your local network. If this fails, there a few possible causes to look at, such as the host you are sending the ping to may not be up. There could also be network problems, such as cabling or a bad hub. The TCP/IP software running on your client still could be having a problem. You could try sending a Ping to your client from another client to verify this or check the ARP cache on your client to see if the host you are pinging has an entry.
Ping an IP address on a different network or Ping the routers in your network. If this test fails but the previous tests worked, you are probably having routing problems or the default router configured in your client's TCP/IP is wrong. You can display the routing table to verify this. If you are using DHCP to get a leased IP address, the default router that is configured on the DHCP server may not be improperly configured. Try Pinging clients on different networks to determine what networks you can reach and cannot reach. You could also use the Trace Route command to determine what network paths are working or are not working.
Verify name resolution works within your network. Ping a domain name (such as www.novell.com) that is within your company's network. If this fails, the default DNS server that TCP/IP is configured to use may be invalid or that DNS server may be down. If you are using DHCP, the DNS server that the DHCP server is configured to hand out to the clients may not be properly configured.
Verify name resolution works out to the internet. Ping a host on the internet (such as www.cisco.com). If this fails, your company's DNS server that forwards DNS requests out to the internet is not working or the internet DNS server that your DNS forwards requests to is not working.
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.