gtow

Diagnose your connections like a geek:

A couple of tools that every geek should know how to use.  These are the bread and butter of troubleshooting network issues.  These of course require that you are at least moderately comfortable with the command line on your system.  If you call your ISP or your IT department armed with info from these commands you will not only greatly speed up the solution you will also garner geek points and win a lot of favor - and probably a lot less attitude - from the person on the other end of the phone.

First up - ping.  Ping does two useful things.  First - it will do a dns lookup for the host you are having problems with.  If you type in  "ping www.google.com"  it will first return an IP address.  If it does not and you get an error this narrows down the problem to one of three things 1 you don't have an internet connection at all. 2 your DNS is miss configured or 3 your DNS server is down or un-reachable.

If ping is successful at a DNS lookup it does the second of it's usefull things.  It sends a request (ICMP Echo) to that host to echo back the packet it sent.  If the other host does - you know you have a good connection.  If it does not respond that DOES NOT necessarily mean that you can't reach the system in question.  For example most firewalls will not return pings, and most servers on the internet are behind a firewall.  If you are trying to reach a server on the same network - on your office network for example and it does not return a ping - chances are good that either 1 the system is down or 2 you have no network connection.

Next up - nslookup.  This command is misunderstood and not used often enough.  Nslookup is useful in several ways but mostly to verify that there is a DNS entry for a host.  The two most useful ways of using nslookup are to find the IP address of a host or to find out what the DNS entry for a host is (reverse lookup).  To verify that there is an entry for a host enter the command nslookup with the fully qualified name of the host.  For example:  'nslookup www.google.com'.  On your office network it may be tempting to just enter the name of the host by itself but this will only work if you have DNS on your workstation correctly configured with a default search domain AND the host is on the same domain you are.  So to reiterate:

'nslookup myserver'  - WRONG   'nslookup myserver.mydomain.com' - Correct.

To find the DNS entry for an IP address - or what is called a reverse lookup you do the opposite:  'nslookup 123.123.123.32'  This will return the DNS entry - www.myserver.org for example.

Nslookup also works interactively.  That is if you just type 'nslookup' without anything else it will tell you what server it's currently using (which will by default be the first server configured on your workstation) and go to a prompt where you can try as many queries as you like just by entering the server name or ip.  There are a bunch of other options for nslookup.  It's a pretty powerful tool in the right hands.  If you are interested I suggest reading the man pages for it on *nix or by typing 'nslookup --h' on windows.  (by the way you hit CTRL-C to exit back to a system prompt)

Finally the most useful tool for testing where your packets are going... 

Traceroute, or tracert on windows systems.  When traffic moves accross TCP/IP networks it must pass through routers.  Routers are devices that work alot like telephone exchanges and make sure the packets go where they are supposed to.  Sometimes the instructions (called routes) on these systems get deleted or are miss configured.  To a network engineer the output of a traceroute will tell him precisely the path taken by traffic from your computer and lead him to the router with the faulty or missing route.

Let's say you can't get to www.google.com but you can get to www.yahoo.com.  You attempt a ping and it gets an address but none of your packets are returned.  You have just verified that you have an internet connection (you can get to yahoo and a ping successfully got an answer from your DNS server) so you try a tracert www.google.com.  As you watch it goes about 12 hops and then you start getting lines that look like:

13 * * * * * * *
14 * * * * * * *

Cut and paste this output into an email for your tech support and they will immediately love you.

Output like this usually means that the routes have gone off the rail or that you have gone as far as anything will answer.  Again most firewalls will not respond but if your network engineer looks at it they will know what systems answer and what do not.  Or they will know who to call that will.

Go try out these commands.  You wont hurt anything.  Stick them in your toolkit and become the darling of your IT department.  Ok at least you won't feel stupid when you call.

Posted via email from ninjahippie's (pre) posterous