TROUBLESHOOTING GENERAL CONNECTIVITY PROBLEMS

When troubleshooting TCP/IP, start close to home and work outward—make sure the problem machine is functioning properly, test
the network in general, and then check the Internet connection.
(1) ‰ Determine exactly what has stopped working: client(s), server(s), specific connection(s), entire network?
(2) ‰ Find out the problem's size and scope. Is the problem limited to a single machine or small group of machines, or more
widespread—workgroup, domain, entire floor, whole organization? Is the problem affecting mission-critical systems?
(3) ‰ Notify all affected users as soon as possible once you determine the problem's size and scope.
(4) ‰ Determine what has changed. If a single client PC has stopped responding to the network, ask the user whether new soft-
ware was just loaded or any recent changes have been made to the system, including the installation of service packs and
software updates.
(5) ‰ Check the physical network. The physical topology of your network is most prone to failure. In fact, network
problems are often due to physical layer failures.
(6) ‰ Is it plugged in? Check all network cable connections. Start at the NIC; is there a green light? Check the wiring closet to
© 1995-2004 CNET Networks, Inc. All rights reserved. “TechRepublic” and its logo are trademarks of CNET Networks, Inc. Reproduction of this publication in any form is prohibited.

see if someone "borrowed" a patch cable. Check any relevant hubs, switches, routers, or other network devices to see if the
affected system is linked across the cable.
(7) ‰ Check relevant cabling with a cable tester. Cabling is very susceptible to damage from electricians, cleaning people,
HVAC personnel, and so on.
(8) ‰ Start pinging. Both Windows and Linux have a Ping command. In a typical network, you have this order
(client->gateway->server) or (client->gateway->internet).
First, attempt to ping yourself from the Windows command prompt or use the Linux shell. Your local loopback address
for such testing is 127.0.0.1. Windows users should see a response similar to the one shown in Figure A, while Linux
operators should see the results shown in Figure B. In Linux, note that you must add -c 4 to the command, which
requests four pings. Otherwise, you must stop the test using [CTRL]C.

Figure A Figure B

Ping the loopback module on Red Hat Linux 7.0.

Ping the loopback adapter on Windows XP.

Figure C
(9) ‰ If you do not receive a successful ping from
the machine's loopback adapter, it's likely
the machine's TCP/IP stack is not working.
On Windows machines, try reinstalling the
TCP/IP protocol from the Network Control
Panel. In Linux, see if your Ethernet card is
loading properly by using ifconfig. Figure C
shows the results of ifconfig on a properly
functioning Ethernet card.
By issuing the interface configuration (ifconfig)
program, you will receive a list of your inter-
faces. If the loopback (lo) is not listed, you may
have an incorrectly configured kernel or possi-
ble problems with the loopback module. Try
recompiling/reinstalling to see if that resolves
the problem.

Ifconfig on Red Hat Linux 7

This is a single-user version, and duplication is prohibited. For additional copies, please call 1-800-217-4339.
For best results, use wet-erase overhead/transparency markers.
 TROUBLESHOOTING GENERAL CONNECTIVITY PROBLEMS continued

(10) ‰ If pinging your loopback worked fine, then try pinging someone who is on the same subnet as the problem
machine. In the ifconfig example above, the IP address is set to 204.114.174.173. Thus, in this scenario, you should
attempt to ping 204.114.174.1. Be sure the target IP address being pinged is a valid IP address assigned to a system; oth-
erwise, you'll receive errors. To determine a machine's subnet, use ifconfig on Linux, Winipcfg on Windows 95/98 machines,
as shown in Figure D, and Ipconfig on Windows NT/2000/XP machines, as shown in Figure E.

Figure D Figure E
© 1995-2004 CNET Networks, Inc. All rights reserved. “TechRepublic” and its logo are trademarks of CNET Networks, Inc. Reproduction of this publication in any form is prohibited.

Ipconfig on Windows XP

Winipcfg on Windows 98

(11) ‰ If you can ping someone on your local subnet, move on to the next step. If you can't, you're probably experiencing a
physical layer failure. The usual suspects are bad cables or a bad NIC. Try replacing the network card and using a new
patch cable.
(12) ‰ Check the gateway. Get the address of the machine's gateway by using Winipcfg on Windows 9x machines or Ipconfig on
Windows NT/2000/XP. In Linux, run the netstat -rn command, shown in Figure F.
The -rn prints the routing table and puts
everything in numeric format. In this
Figure F
example, the default gateway (0.0.0.0) is
204.114.174.129.
If you don't have a gateway configured,
then one will not show up in Winipcfg or
when using netstat. This is a problem.
In Windows, locate Start | Settings |
Control Panel | Network | TCP/IP |
Gateway and add your gateway. This is
your local interface on your router. In
Linux, use linuxconf or set up a tempo-
rary route using:
Netstat on Red Hat Linux 7.0
route add default gw
gateway_ip_address
where gateway_ip_address is your gateway.
Ping this address; this will prove a solid connection from your PC to the gateway. If you have made it this far, the PC is
working, the cabling is working, and the router (gateway) interface is working. You can skip to the next step.
If you receive no response from the gateway, and you have one configured, your router is probably configured improperly. It
must have a local interface (IP address) on your subnet to listen to the traffic on your network. Check to ensure that there is
one, and add one if there isn't. If it has one that has stopped working, it could mean you're experiencing a router failure, and
others will be affected as well. Conversely, the router may be using an old config; check to make sure this isn't the case.
(13) ‰ The final step is through the gateway. Ping something that is on the other side of the gateway. In an intranet, ping a
printer on a remote subnet. On the Internet, ping Yahoo! (204.71.200.68). If you do so successfully, you should not have a
problem. If you can't get to a particular system in your network or on the Internet, that resource may not be available.

This is a single-user version, and duplication is prohibited. For additional copies, please call 1-800-217-4339.
For best results, use wet-erase overhead/transparency markers.
 TROUBLESHOOTING WHEN A HOST NAME WILL NOT RESOLVE

Whenever you browse the WWW or send an e-mail message, a domain name is used to send or receive information. Uniform
Resource Locators (URLs), such as http://www.techrepublic.com, and e-mail addresses, such as johndoe@email.com, are easy
for users to remember but are almost useless to computers. The Domain Name Service (DNS) is used to map the relationships
between a human-readable host name and the IP addresses associated with that host name. DNS may also be used in reverse,
mapping an IP address to a host name.
(1) ‰ Try to ping the host in question using just the host name and not the host's fully qualified domain name (FQDN).
If this initial test works, then name resolution is working and no further testing is necessary. If the address is not resolved,
then ping the host using its FQDN, as shown in Figure G. If the FQDN works, it is likely that the client does not contain the
correct domain name setting. Changing the domain name will most likely resolve the problem.

Figure G
© 1995-2004 CNET Networks, Inc. All rights reserved. “TechRepublic” and its logo are trademarks of CNET Networks, Inc. Reproduction of this publication in any form is prohibited.

Ping a host's FQDN.

(2) ‰ Check the hosts file. Open the hosts file in %SYSTEMROOT%\system32\drivers\etc on Windows. In this file, look for a line
that begins with an IP address and is followed by the host name or FQDN of the host you are testing. If the entry is in the
file and the name is still not resolving, there is an internal client software problem that is preventing it from working correctly.
It may be necessary to remove and reinstall the network adapter and/or TCP/IP. This used to be a rather common issue with
Windows 95/98, but it very rarely occurs with Windows 2000 or Windows XP. The bottom line is that it will sometimes occur
when there is some sort of an internal disconnection in Windows with regard to name resolution, which is frequently
resolved by removing and reinstalling TCP/IP.
(3) ‰ The next step is to determine what fully qualified DNS servers are being used and test connectivity with each one.
This is most easily done by typing ipconfig /all at a command prompt and copying down all of the DNS servers that are
returned (if you are on a UNIX host, this information is located in /etc/resolv.conf). Then, each DNS server should be pinged
to verify basic connectivity.
(4) ‰ If you are unable to ping a DNS server, there are a Figure H
few likely causes that you will need to investigate.
The first potential cause is that you are unable to commu-
nicate beyond your local network. It is possible that your
IP configuration does not allow you to communicate
beyond the local network because of a default gateway or
subnet mask configuration problem. The second potential
cause is that the administrator has somehow blocked the
ICMP packets needed for Ping to work at a firewall or at
the host itself. The third potential cause is that the system
you are trying to reach is down or is not responding.
(5) ‰ Although it is possible for name resolution to work
when only one DNS server is available, it is much
better to ensure that all DNS servers listed in the
client configuration can be reached. If you can estab-
lish basic connectivity with a DNS server, then it is time
to test the actual DNS server's resolution. This is done
with the Nslookup command. This command allows you
to select a specific DNS server to be queried and gives
a visual indication of the exact error returned. To start
Nslookup, just type nslookup at a command prompt, as
shown in Figure H. The prompt will change, indicating
that Nslookup is running. Before the prompt, you will be
told which server is being used. You should manually
change to the first server listed in the DNS configuration
by typing server <IP Address>, where <IP Address> is
Nslookup on Windows XP
the IP address of the DNS server to use.

This is a single-user version, and duplication is prohibited. For additional copies, please call 1-800-217-4339.
For best results, use wet-erase overhead/transparency markers.
 TROUBLESHOOTING WHEN A HOST NAME WILL NOT RESOLVE continued

(5 cont.) The next step is to type only the last two parts of the FQDN of the host, followed by another period. For
www.techrepublic.com, you would type techrepublic.com. This prevents the Nslookup tool from accidentally appending your
current domain name to the request and searches to make sure that the top-level domain is present. If the answer is that
the host is a nonexistent domain, then the DNS server cannot locate the domain of the host. This can happen for a few rea-
sons. First, it is possible that the domain is not properly registered and the root naming servers do not know how to reach
the domain. It is also possible that none of the naming servers for the domain are operational.
Before continuing, research the cause of this problem. While still in the Nslookup tool, type set type=ns. This will cause the
Nslookup tool to try to locate naming servers instead of trying to completely resolve the name. At this point, you can type in the
last two sections of the name and a trailing period; for example, techrepublic.com, as shown in Figure H. This time you will
either get a response that includes a few naming servers or the nonexistent domain answer. If you get a list of naming
servers, then you know that the DNS server you are using is functioning properly and the domain is properly registered on
the Internet, but none of the naming servers are operational.
If you need to determine whether the problem is with your DNS server or with the root registration, you can switch the serv-
er that you are testing by typing server <IP Address>, where <IP Address> is an address of another naming server.
Obviously, if another DNS server is able to resolve the address, your DNS server has a configuration problem.

Troubleshooting intermittent host name problems

Perhaps the most difficult problems to resolve are those that are inconsistent: those problems that seem to work when you test
them, but appear randomly from time to time just to annoy you. Perhaps the greatest cause of intermittent host name resolution
problems is multiple DNS servers that are not properly synchronizing between themselves. DNS servers operate using a concept of
© 1995-2004 CNET Networks, Inc. All rights reserved. “TechRepublic” and its logo are trademarks of CNET Networks, Inc. Reproduction of this publication in any form is prohibited.

a master DNS server for a zone, called a primary DNS server, and a slave DNS server, called a secondary DNS server. The
secondary servers routinely perform a zone transfer to download the zone information from the primary server. The idea is that, in
this way, the secondary servers are brought up to date with the primary server. This works fine in theory, but connectivity problems
between the primary server and the secondary servers can lead to secondary servers that are not always available.
The tool of choice for diagnosing host name resolution problems is Nslookup. Because it can be directed to use a specific naming
server, you can check the same name query with each individual naming server to locate the one that does not return the answer
that you would expect.

Flushing your DNS cache

When you believe that you have resolved the problem, the final step is to tell the client to dump any caching that was done so you
can verify that the name resolution process is working as it should. This is done by entering ipconfig /flushdns at a command
prompt. This command will cause the internal resolver cache to be discarded, forcing all names to be re-resolved. It should be noted
that some programs, such as Internet Explorer, sometimes cache name resolution internally as well. All programs should be
completely stopped and restarted before being used to perform additional testing.
If you changed a setting that was not local to the client's DNS server, then the cache for the DNS server that the client is using should
be cleared as well. This can be done via the DNS MMC Snap-in by right-clicking on the server name and selecting Clear Cache.

TCP/IP TROUBLESHOOTING COMMANDS QUICK REFERENCE

Ipconfig – Windows
{System root}\system32
Displays and modifies Internet Protocol (TCP/IP) configuration.
ipconfig [/all] [/displaydns] [/flushdns] [/registerdns]
[/release [adapter]] [/renew [adapter]] [/setclassid
adapter [classID]] [/showclassid adapter]
No parameters: Displays the IP address, mask, and gateway
for each local adapter.
[/all]: Displays all of the available TCP/IP information for all
installed adapters.
[/displaydns]: Displays the contents of the local DNS cache.
[/flushdns]: Flushes the contents of the local DNS cache.
[/registerdns]: Manually registers the names and IP
addresses of the local machine in DNS.
[/release [adapter]]: When specified without [adapter],
releases all DHCP-provided IP addressing information
resulting in these adapters being disabled for this purpose.
Specify an adapter to release information just for it.
[/renew [adapter]]: When specified without an [adapter],
renews all TCP/IP information for DHCP-enabled adapters.
Specify an adapter to renew just its information.
[/setclassid adapter [classID]]: Specify the DHCP class IDs
for any DHCP-enabled adapters in the system.
[/showclassid adapter]: Shows the DHCP class for DHCP-
enabled adapters.
Ping – Windows
{System root}\system32
ping [-a] [-f] [-i TTL] [-l size] [-n count] [-r count]
[-s count] [-t] [-v TOS] [{-j hostlist | -k hostlist}]
[-w timeout] target
[-a]: Enables name resolution on the target IP address.
[-f]: IPv4 only: Sends the requests without fragmenting the
packets.
[-i TTL]: Sets the time to live for each request. The default
is 255.
[-l size]: Sets the size of the request packets. The default
size is 32 bytes and the maximum size is 65,527 bytes.
[-n count]: The number of requests to send. The default
is 4.
[-r count]: IPv4: Sets the IP header to record the path
taken. Can be a value from 1 to 9.
[-s count]: Indicates that the timestamp option in the header is
used to record the time of arrival. Can be a value of 1 to 4.
[-t]: The ping process will continue until a break is issued.
[-v TOS]: IPv4 only: A decimal value from 0 (default) to
255 indicating the type of service.
[{-j hostlist | -k hostlist}]: Each option takes a host list of
up to nine IP addresses separated by spaces. -j indicates
that loose source routing will be used while -k indicates
that strict source routing will be used.
[-w timeout]: The number of milliseconds to wait for a
reply. The default is 4000ms.
target: Specifies the IP addresses of the computers to ping.
ifconfig – Linux
Configures network interfaces. Must be logged in as root.
ifconfig interface [aftype] options | address ...
Inet: TCP/IP.
Inet6: IPV6.
ax25: AMPR Packet Radio.
ddp: Apple Talk.
iPX: IPX.
netrom: AMPR Packet Radio.

ISBN: 1-932509-23-2 Customer Service: 845-566-1866 Technical Editor: Bill Detwiler © 1995-2004 CNET Networks, Inc.
Product Code: T022rev1 or toll free 800-217-4339 Technical Contributors: Dave All rights reserved. “TechRepublic”
Price: $12.95 U.S. funds Visit us online at Mays, Scott Lowe, Robert L. Bogue and its logo are trademarks of
(Volume discounts available) TechRepublic.com Graphic Artist: Kimberly Wright CNET Networks, Inc.
Copy Editor: Suzanne Thornberry

This is a single-user version, and duplication is prohibited. For additional copies, please call 1-800-217-4339. Sept 2004
For best results, use wet-erase overhead/transparency markers.