Network Trouble Shooting: IP Network Check

IP Network Check for Client Side and Target Side Troubleshooting

Problems encountered in IP networking can have several sources. Most obvious are those where
either the client's machine or the target machine are mis-configured, malfunctioning or, in the
extreme case, shut down. If the problem is unrelated to either the target or the source machine,
then other possibilities include problems with the Domain Name Services or a variety of forms of
network problems somewhere between the target and source machine.

This set of tests assumes that the client is attempting to connect to a specific target machine via
TCP/IP. Target machines may be web, mail, ftp, news or compute servers or stand-alone telnet
services. This would include any machine accessed by identifying it with an "internet" style address
(e.g., www.ucsc.edu). Administrative Systems (Banner, PPS, etc) use the TCP/IP network and
connections to them will fail along with other TCP/IP target machines if the client's network isn't
working.

Can client load a URL or get an error message from server?

Network failure is indicated by an error message such as "server doesn't exist" or "can't find server."

Error messages of the type "404 Page not found" or "password incorrect" mean the server was
reached, and the network is working.

Can client connect using IP address rather than IP name?

Successful connection via IP address implies a problem either with the Domain Name Server
configuration of the client machine or a problem with our Domain Name Servers. If there are
multiple problem reports of this nature, check Big Brother status of DNSs.

Attempt to Connect from Separate Machine: This assumes that you are in a different location than
the person reporting the problem, for example, an ITS HelpDesk Support Specialist is on the phone
to the person with the problem.

If you can successfully connect to the target machine, the target machine is probably not the source
of the problem. Proceed to client side troubleshooting.

If you can't connect to the target machine either, the target machine or its network are probably at
fault. Proceed to target side troubleshooting.

Check state of the client's network: Every machine with a working network connection has an IP
address beginning with 128.114 (Admin/Academic net) or 169.233 (Resnet). In addition, every
client's machine on a TCP/IP network is configured with the address of its "Gateway" or nearest
router. The address of the gateway router is found in the tcp/ip configuration, the location of which
depends on OS.
Mac OS 9.04 and earlier: Apple Menu > Control Panels > TCP/IP. Read Gateway Address from display.

Mac OS X : to be determined.

Win 95 to Win2K: Start > Run, type winipcfg (Win95/98); ipconfig (NT)

If no gateway address is known to the machine, then either the router is down or something is
misconfigured with client's machine. If you can identify the router's address.

Once the nearest router is identified, check Nocol to see if that router is down. If not, proceed to
client-side troubleshooting. If the router is down, then Network Operations probably already knows.

Client Side Troubleshooting

If the problem appears to be more connected with the machine attempting to make a connection
(the source machine) than with the target machine, further testing is necessary to determine
whether the problem is with a part of the network or the client's machine itself.

Perform Standard Machine Checks and Network Equipment Swap

Don't start down this road until you have eliminated problems with client's cable, jack, and
computer.

Have Client Telnet to Local Router: The client will not be able to do anything useful with the local
router, this is just for testing purposes.

Launch telnet, configure "host" or "remote connection" to the IP address of the Gateway noted in
the TCP/IP configuration.

A successful test is when the router responds with a "Password" prompt.

If the client can sucessfully telnet to the router on the same subnet, that indicates that the client's
network configuration is probably correct At this point it is probably a network problem. Check
Nocol.

If the client cannot connect to the local router, possibly the router or other network equipment is
down, part of the network (the client's cables, jack, hubs, bridges, etc.) on the local subnet is bad or
the client's machine is misconfigured.

Test Client's Local Router from another location. Attempt to telnet to the client's local router from,
e.g. the ITS HelpDesk.
If the support person cannot telnet to the client's local router, then the router or the path to it is
probably down. Check Nocol.

If the support person can connect to the router, then attempt to " ping" the client's machine.

If the support person can ping the client's machine, then it is almost certainly a configuration or
hardware problem on the client's machine. Report to client's coordinator.

If the support person cannot ping the client's machine (or doesn't have an IP address with which to
ping it) then the problem is either with the client's machine or with the network. Check Nocol, and if
nothing is clarified, report to scnet, or the client's coordinator.

Target Side Troubleshooting

If the problem appears to be more connected with the machine to which the client is trying to
connect (the target machine) than it does with the client's (source) machine, further testing is
necessary to determine whether the problem is with a part of the network or the target machine
itself. For these tests, it is useful to know to what subnet the target is physically attached, and what
the router address is for that subnet.

Start with the Obvious: Check to see if there are any announced network or service outages.
Network Operations and ITS HelpDesk routinely send notices when network services or centrally
maintained machines are brought down for service.

Verify Target Information: Often a client will mis-identify the machine to which they are attemping
to connect. For example, some people will use an e-mail address instead of a name when connecting
to a machine, and some campus systems have non-obvious names (e.g., PPS is on
UCCMVSB.ucop.edu).

Check Big Brother and Nocol if the target machine is monitored there.

Try to ping a machine in the target's network. (This is usually hard to do.) If Nocol doesn't indicate
problems, then try to get the active IP address of any machine on the target machine's subnet and
attempt to " ping" it. You can ask the client to find the IP of another neighbor machine if you don't
have an IP address scanning application (and most people don't).

If the support person can ping another machine, then it is almost certainly a configuration or
hardware problem on the target machine.

If the support person cannot ping another machine or doesn't know of any machine to ping, then the
problem is either with the target machine or with the network. Check Nocol, and if nothing is
clarified, report to Network Operations or the client's coordinator with full report of the tests that
have already been performed, and when.

Network

Ordering Service
Pricing & Availability

Troubleshooting

Trouble Reporting

Engineering & Construction

Cable Plant

Domain Name Services

Dynamic Host Configuration Protocol (DHCP)

Policy

Get Help from ITS