Sie sind auf Seite 1von 4

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

Reproduction of this publication in any form is prohibited.     TROUBLESHOOTING GENERAL CONNECTIVITY PROBLEMS
   

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? 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? Notify all affected users as soon as possible once you determine the problem's size and scope. 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. 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. Is it plugged in? Check all network cable connections. Start at the NIC; is there a green light? Check the wiring closet to 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. Check relevant cabling with a cable tester. Cabling is very susceptible to damage from electricians, cleaning people, HVAC personnel, and so on.

(2)

(3)

(4)

(5)

(6)

(7)

(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

stop the test using [CTRL]C. Figure A   Figure B Ping the loopback adapter on Windows
stop the test using [CTRL]C. Figure A   Figure B Ping the loopback adapter on Windows

Ping the loopback adapter on Windows XP.

Ping the loopback module on Red Hat Linux 7.0.

 

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.

Ifconfig on Red Hat Linux 7

Ifconfig on Red Hat Linux 7

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.

 

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
TROUBLESHOOTING GENERAL CONNECTIVITY PROBLEMS continued (10) If pinging your loopback worked fine, then try pinging
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
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
example, the default gateway (0.0.0.0) is
Figure F
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.
© 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.

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.

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

Reproduction of this publication in any form is prohibited.             TROUBLESHOOTING
       
   

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

 
most likely resolve the problem.   Figure G   Ping a host's FQDN. (2) Check the

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

Figure H

 

(5)

(5)

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

the IP address of the DNS server to use.

Nslookup on Windows XP

 

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.

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

Reproduction of this publication in any form is prohibited. TROUBLESHOOTING WHEN A HOST NAME WILL NOT

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

Product Code: T022rev1 Price: $12.95 U.S. funds (Volume discounts available)

Customer Service: 845-566-1866 or toll free 800-217-4339 Visit us online at TechRepublic.com

Technical Editor: Bill Detwiler Technical Contributors: Dave Mays, Scott Lowe, Robert L. Bogue Graphic Artist: Kimberly Wright Copy Editor: Suzanne Thornberry

© 1995-2004 CNET Networks, Inc. All rights reserved. “TechRepublic” and its logo are trademarks of CNET Networks, Inc.

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.

Sept 2004