Network TroubleShooting: 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.