T022 Trbl Win Linux

8/8/2019 T022 Trbl Win Linux

1/4

When troubleshooting TCP/IP, start close to home and work outwardmake sure the problem machine is functioning properly, testthe 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 morewidespreadworkgroup, 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 andsoftware updates.

(5) Check the physical network. The physical topology of your network is most prone to failure. In fact, networkproblems 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 tosee if someone "borrowed" a patch cable. Check any relevant hubs, switches, routers, or other network devices to see if theaffected 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 addressfor such testing is 127.0.0.1. Windows users should see a response similar to the one shown in Figure A, while Linuxoperators should see the results shown in Figure B. In Linux, note that you must add -c 4to the command, whichrequests four pings. Otherwise, you must stop the test using [CTRL]C.

(9) If you do not receive a successful ping fromthe machine's loopback adapter, it's likelythe machine's TCP/IP stack is not working.On Windows machines, try reinstalling the

TCP/IP protocol from the Network ControlPanel. In Linux, see if your Ethernet card isloading properly by using ifconfig. Figure Cshows the results of ifconfig on a properlyfunctioning 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 mayhave an incorrectly configured kernel or possi-ble problems with the loopback module. Tryrecompiling/reinstalling to see if that resolvesthe problem.

19952004CNETNetworks,Inc.Allrightsreserved

.TechRepublic

anditslogoaretrademarksofCNETNe

tworks,Inc.Reproductionofthispublicationinanyformisprohibited.

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

Figure A

Ping the loopback adapter on Windows XP.

Figure B

Ping the loopback module on Red Hat Linux 7.0.

Figure C

Ifconfig on Red Hat Linux 7


2/4

1995-2004CNETNetworks,Inc.Allrightsreserved.TechRepublicanditslogoaretrademarksofCNETNetworks,Inc.Reproductionofthispublicationinanyform

isprohibited.


(10) If pinging your loopback worked fine, then try pinging someone who is on the same subnet as the problemmachine. In the ifconfig example above, the IP address is set to 204.114.174.173. Thus, in this scenario, you shouldattempt 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.

(11) If you can ping someone on your local subnet, move on to the next step. If you can't, you're probably experiencing aphysical layer failure. The usual suspects are bad cables or a bad NIC. Try replacing the network card and using a newpatch cable.

(12) Check the gateway. Get the address of the machine's gateway by using Winipcfg on Windows 9x machines or Ipconfig onWindows NT/2000/XP. In Linux, run the netstat -rn command, shown in Figure F.

The -rn prints the routing table and putseverything in numeric format. In thisexample, the default gateway (0.0.0.0) is204.114.174.129.

If you don't have a gateway configured,then one will not show up in Winipcfg orwhen using netstat. This is a problem.

In Windows, locate Start | Settings |Control Panel | Network | TCP/IP |Gateway and add your gateway. This isyour local interface on your router. InLinux, use linuxconf or set up a tempo-rary route using:

route add default gw

gateway_ip_addresswhere gateway_ip_addressis 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 isworking, 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. Itmust have a local interface (IP address) on your subnet to listen to the traffic on your network. Check to ensure that there isone, and add one if there isn't. If it has one that has stopped working, it could mean you're experiencing a router failure, andothers 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 aprinter on a remote subnet. On the Internet, ping Yahoo! (204.71.200.68). If you do so successfully, you should not have aproblem. If you can't get to a particular system in your network or on the Internet, that resource may not be available.

Figure F

Netstat on Red Hat Linux 7.0

Figure D

Winipcfg on Windows 98

Figure E

Ipconfig on Windows XP

TROUBLESHOOTING GENERAL CONNECTIVITY PROBLEMS continued


3/4

Whenever you browse the WWW or send an e-mail message, a domain name is used to send or receive information. UniformResource Locators (URLs), such as http://www.techrepublic.com, and e-mail addresses, such as [email protected], are easyfor users to remember but are almost useless to computers. The Domain Name Service (DNS) is used to map the relationshipsbetween 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.

(2) Check the hosts file. Open the hosts file in %SYSTEMROOT%\system32\drivers\etc on Windows. In this file, look for a linethat 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 thefile 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 withWindows 95/98, but it very rarely occurs with Windows 2000 or Windows XP. The bottom line is that it will sometimes occurwhen there is some sort of an internal disconnection in Windows with regard to name resolution, which is frequentlyresolved 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 /allat a command prompt and copying down all of the DNS servers that arereturned (if you are on a UNIX host, this information is located in /etc/resolv.conf). Then, each DNS server should be pingedto verify basic connectivity.

(4) If you are unable to ping a DNS server, there are afew 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 yourIP configuration does not allow you to communicatebeyond the local network because of a default gateway orsubnet mask configuration problem. The second potentialcause is that the administrator has somehow blocked theICMP packets needed for Ping to work at a firewall or atthe host itself.The third potential cause is that the systemyou are trying to reach is down or is not responding.

(5) Although it is possible for name resolution to workwhen only one DNS server is available, it is much

better to ensure that all DNS servers listed in theclient configuration can be reached. If you can estab-lish basic connectivity with a DNS server, then it is timeto test the actual DNS server's resolution. This is donewith the Nslookup command. This command allows youto select a specific DNS server to be queried and givesa visual indication of the exact error returned. To startNslookup, just type nslookupat a command prompt, asshown in Figure H. The prompt will change, indicatingthat Nslookup is running. Before the prompt, you will betold which server is being used. You should manuallychange to the first server listed in the DNS configurationby typing server , where isthe IP address of the DNS server to use.

1995-2004CNETNetworks,Inc.Allrightsreserved

.TechRepublicanditslogoaretrademarksofCNETNe

tworks,Inc.Reproductionofthispublicationinanyformi

sprohibited.


TROUBLESHOOTING WHEN A HOST NAME WILL NOT RESOLVE

Figure G

Ping a host's FQDN.

Figure H

Nslookup on Windows XP


4/4

Documents

T022 Trbl Win Linux