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 addres (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 serve
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 successtully connect to the target machine, the target machine is probably not the sourd 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 a 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 whic depends on OS.
Mac OS X: to be determined.
Win 95 to Win2K: Start > Run, type winipcfg (Win95/98); ipconfig (NT)
lf 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.