Troubleshooting TCP/IP Issues with Client Utilities

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.

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:

1. 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.
2. 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?

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

2. 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.
3. 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.
4. 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.
5. 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

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019