UNIX Hints & Hacks
Chapter 2: Networking
|
Sections in this Chapter: |
|
|
|
|
|
|
|
|||
|
2.2 Finding the Failure |
|
|
||
|
|
|
|
UNIX Hints & Hacks |
|
|||||||||||||||||||||
|
Chapter 2: Networking |
|
|||||||||||||||||||||
|
Quick hints for troubleshooting basic network problems.
Flavors: AT&T, BSD
Shells: All
Syntax:
ifconfig interface ping address telnet address
Certain steps must be taken when diagnosing network connectivity problems. The problem is either a local issue with the individual computer or a global issue affecting the entire network.
Has everyone in the area lost their connection or is the network problem isolated to one user? If it's everyone in the area, the problem is most likely in the networking hardware, such as the concentrator or the gateway router. If the problem is isolated to a single user, consider the following steps.
Verify that the network interface is up and broadcasting.
# ifconfig hme0 hme0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500 inet 199.45.34.2 netmask ffffff00 broadcast 199.45.34.255
|
Note - This interface is from a Sun SPARC station. The name of your interface is different, but the output is similar. Your interface should be in an up state. |
Verify that there is a route to the gateway or router. The routed daemon should be running or, when executing netstat, a default router entry should appear. If the computer sits on a network and is on a subnet, one of these should be running or defined.
Check to make sure that the routed daemon is running:
% ps -ef | grep routed root 27005 1 0 23:39:15 ? 0:00 /usr/sbin/in.routed
Check to see whether a default route is configured.
# netstat -rn Routing tables Destination Gateway Flags Refcnt Use Interface 127.0.0.1 127.0.0.1 UH 2 2955050 lo0 default 199.45.34.254 UG 5 5592713 hme0 199.45.34.0 199.45.34.2 U 30 10052190 hme0
Only one needs to be running. If neither one displays any results, start the routing by selecting the best configuration for your environment. See section 2.8, "Static Routing or routed?" for more information.
If one of these is there and you still have no connection, possible problem points to look at are the cable, the concentrator, the interface card, and the router.
Try to connect around on the network. Two really good tests to use are the ping and telnet commands. ping uses the ICMP protocol to connect, and telnet uses TCP. Both protocols expect a response from a remote host. Use these commands to attempt a connection to another computer that is on the same subnet.
% ping 199.45.34.10 no answer from 199.45.34.10 % telnet 199.45.34.10 Trying 199.45.34.10 ... telnet: connect: Connection timed out telnet>
If this fails, do the same test to the router or gateway address. In this example 199.45.34.254 is the router.
% ping 199.45.34.254 no answer from 199.45.34.254 % telnet 199.45.34.254 Trying 199.45.34.254 ... telnet: connect: Connection timed out telnet>
If these fail, the problem could be in the cable between the computer and the router, the concentrator, or the network card.
If at all possible, check the Ethernet cable to make sure that it is still plugged in to the wall. The cables sometimes get kicked or come loose if slightly pulled on. If the wall is obstructed with the users' debris or furniture, check the cable as it comes out from the Ethernet port on the computer. There should be a solid green link light when the cable is plugged in to the RJ-45 Ethernet port on the interface card in the computer. Some network cables can plug in to a transceiver box that is connected to the AUI port of the network interface card. These transceiver boxes have solid green link lights on them as well. Some of the new interface cards do not have any lights on them. Look carefully and don't be misled by missing lights.
If there is no link light, the problem is possibly a bad cable, a dead interface card, a dead Ethernet port in the wall jack, or a problem at the concentrator.
If a link light is on, this points directly to a problem with the router, gateway, or route server.
If everything is still failing, there is no link light, and the system configurations look okay, trace the cable back to the concentrator and see whether the cable was unplugged or the port is bad.
If there is no link light on the concentrator, the only possible solution is a bad cable somewhere between the concentrator and the network card in the computer, or, possibly, a bad network card.
If there is a link light on the concentrator and the computer's interface card, the problem is somewhere in the router or route server.
If there are problems with the router, everyone is affected. When routers go down it is often the power supply that dies, or they can sometimes get stuck rebooting over and over. If there is a router server in place for something like an ATM network, disk drives usually go first.
The preceding five steps can help you diagnose a network problem that might suddenly appear. Some administrators have complete access to all the devices discussed. If you don't have access to the networking devices, you should be able to gather enough information to form a conclusion and bring in the right networking reinforcements to help fix the problem.
Network problems are one of the most serious problems that a user can face in a centralized server networked environment. When there is a problem with the network, there are three ways to find out about it.
The first two are the best ways to find out about a problem. By the time the user calls, you should be able to tell them that you already know about the problem and you are working on it. Users tend to think that administrators have some type of sixth sense when this starts happening.
1.A system monitoring program sends a page. If a system drops off the network and you have a pager, set up the system to send you an email notifying you of the problem. If it is a network problem, the email might never get out. Have a backup plan for a modem on the local system that is doing the monitoring, so that the page can be received through the modem. There are commercial products and scripts on the Internet to do this.
2.You're in the system when a network problem develops. Sometimes the opportunity presents itself right on the screen while you are working on other things. This gives you the chance to see first hand what is happening and to be prepared for the phone calls that start coming in.
3.The user calls you. The worst way to discover a problem is to find out from the user. If you are like me, you'll try to discover the problem before the user does.
When I check on a network problem, I talk to everyone and anyone on the way; you never know whether someone might be able to provide some insight into it. Sometimes I find that someone was in the network room messing with cables earlier in the day, or more than one person is experiencing problems. Check all cables and connections before getting started. The problem could be anywhere and it could be hardware, software, or anything in-between. If you can attempt to hit both the hardware and software at once, you can attack the problem from both sides and solve it more quickly.
Man pages:
ifconfig, netstat, ping, telnet
World Wide Web:
Send page-- ftp://ftp.net.ohio-state.edu/pub/pagers
|
UNIX Hints & Hacks |
|
|||||||||||||||||||||
|
Chapter 2: Networking |
|
|||||||||||||||||||||
|
© Copyright Macmillan USA. All rights reserved.