Daryl's TCP/IP Primer

Addressing and Subnetting on the Near Side of the 'Net

[<--Prev] [Next-->]
[Printable Version] [Daryl's ColdFusion Primer] [About Daryl] Bookmark and Share
Google
 
Daryl's TCP/IP Primer on Facebook

9. Troubleshooting

The second most useful tool in troubleshooting client IP issues is PING. Ping is a low-level method of determining is a specific host is alive.

Step #1: Determine if the IP stack is alive. There is a reserved address 127.0.0.1 called "localhost". A successful ping to 127.0.0.1 means your IP stack is working properly. A ping to localhost doesn't even make it on the wire.

Step #2: Determine if you can talk onto the wire. Ping yourself. If your address is 192.168.1.1, then ping 192.168.1.1. Actually, the packet may or may not actually make it on the wire, depending on your implementation. But it doesn't hurt.

Step #3: See if you can ping anyone else. Ping your default router. Make sure your default router is on your same subnet! The easy way to do this is to refer to the "glossy explanation" of subnetting in Section 4, and to make sure both addresses can exist in the same subnet. If you can't ping your default router, either the router is down (easily checked from another workstation) or there's something wrong at your workstation. Make sure your workstation has the subnet mask set correctly, and that you and the router are using the same frame type. The default frame type for TCP/IP is Ethernet_II on Ethernet LANs, and TOKEN-RING_SNAP on Token-Ring LANs. Cisco routers refer to Ethernet_II as encapsulation type ARPA.

Step #4: See if you ping the far interface of the default router. All routers have more than one interface (or they wouldn't be routers, right?) If you know the interface of the far side of the router, ping that. That verifies that your default route is set properly. If you don't know the address of another router interface, skip to step 5.

Step #5: Ping the address of your name server. Your name server address is given to you by your ISP. If you cannot ping your name server, try to trace your route to it. The UNIX version of the command is "traceroute"; Windows renamed it to "tracert". (In related news, Jason D. has informed me that the traceroute command for OS/2 is "tracerte".) An example:

D:\WINDOWS>tracert ns.orbis.net

Tracing route to ns.orbis.net [205.164.72.2]
over a maximum of 30 hops:

1 1 ms 1 ms 1 ms 192.168.1.254
2 60 ms 61 ms 64 ms 205.164.75.1
3 64 ms 62 ms 65 ms tamino.summit-ops.orbis.net [205.164.72.129]
4 78 ms 77 ms 78 ms ns.orbis.net [205.164.72.2]

Trace complete.

D:\WINDOWS>

Note: if you actually get names, you not only have verified Internet connectivity, but you also know your DNS is properly set up. Congratulations! You are on the Internet. If you have problems at this point, it's time to call your ISP.

Step #6: If you didn't get any names in your route trace, don't panic: Try to ping www.novell.com or www.microsoft.com. If you can ping, by name, either of those addresses, you are set up for Internet access. If you get a message like, "Unable to resolve novell.com" then you need to make sure your DNS is set up properly. If you get a "host unreachable" then you probably are set up OK but the 'net is just a bit congested. (Or you haven't set your workstation's default route properly.)

Typically, I start with step #6, and if that fails, go to step #1.

*Second most useful? Probably the most useful tool for diagnosing connection problems across the Internet is traceroute (or tracert for Windows users.) My absolute favorite utility, and the first program I run when I'm having a problem, is Ping Plotter, which is a GUI traceroute tool that shows graphically the time to each hop along the way to a destination:

Ping Plotter is available at http://www.pingplotter.com/ Both "freeware" and registered ($15) versions are available. And if you end up using it more than once or twice a week, do the Right Thing and register it. It's a more than reasonable price, and maybe then Pete will release enhanced versions on a more regular basis :-)

Next: TCP and UDP Communication


Copyright ©1996-2010 Daryl Banttari. See Disclaimer.