Axence NetTools Professional 3.0: The Right Tool for the Job?

Not done the CIT, only ICRC, ACRC, and CID... but its been pretty standard since, well, routing was a server function

We avoided using anything more complex than Pping at 1st line... partially because we couldnt always guarantee 1st line staff could recognise the output, but also because users, are, well... users, and easily confused. Ping provides an easily understood output that provides a yes/no answer... for 99/100 people!

Agree though, TRACERT is a powerful little tool, as is NETSTAT... as you rightly highlight, it all comes down to experience and knowing how to use the tools.

Right out of the CIT course from Cisco...and any engineer's skillset if he/she's worth their salt. I would also recommend in addition to what you've stated that the analytical protocols used be used effectively. Different protocols allow for multi-layer troubleshooting. You can use ping (layer 3)if you want, but i'd elect to go to one that takes you through layer 7 and all the way down to layer 1. TRACERT can provide you several discovery elements in one fell swoop. You get DNS all the way through to physical layer feedback. If you already know that the upper layers are not an issue then you can elect to do divide and conquer. The 3 approaches, top-down, bottom-up, and divide/conquer is a decision you should reach based upon the issue, but, once again, you can accomplish several steps in one step. TRACERT is an economic resolution in that typically the most important factor is time...or should i say "down time". DOS is so often overlooked in its ability to assist you in narrowing down the culprit. Spend a moment and type in NETSTAT /? at a DOS prompt and you'll be amazed how much information you can derive from this simple command. Happy hunting!

Troubleshooting a network issue is more than just a toolset. More importantly, it is a methodology.

Why? Firstly, it provides a common process understood by all, and provides a logical approach to a problem, rather than a shotgun manner which can lead to some avenues being missed.

And a little experience and knowledge of the system tools goes a long way; what happens if a system policy prevents you from using a toolset...

The methodology I use is to trouble shoot from the wire up. Its a basic adage amongst old hands, from the 90's and before, and holds good today. It works for both [remote] 1st line staff taking a fault call, to 3rd line engineers resolving a complex infrastructure fault.

The following example is based on a real world fault call from a few years back. Simple, and serves the point. Lets say a user at PC A cannot access an app on Server Z. Z may be "local" (on the same subnet in the same building, or via a layer 2 bridge), or remote, on a another subnet across one or more network links. In this case, both user and 1st line analyst were remote from each other and the server, and the fault preceeded a real-time NMS system which would have alerted us to the root problem.

The traditional approach is to ping 127.0.0.1, then the NICs IP address, but I eschew that if the user is already logged in - the card and IP already work! Instead, work backwards - ping the IP address of the server. The user was talked through opening a DOS box and how to describe the output of Ping.

Next ping the intermediate routers, working backwards. This identified the reach of the user's visibillity, and narrowed the problem down to a potenital router issue. At the same time, the 1st line analyst ping'ed the app server, then the intermediate routers. The path between the server and the two users differed, but the analyst had visibility of the routers in the users path.

Why does experience and methodology count? Well, my "toolkit" evolved from a few utilities on a disk, to a few on a CD-ROM (which are still usefull) to 4gb USB drive. Not just tools, but also s/w such as AVG Anti-virus, Ad-aware, gfx drivers for a specific customer that day, netstumbler, bluescanner, nmap, and so on. FAT32 ensures it can be read on Win 9x - XP as well as Linux. But just two days ago I was working on a bunch of machines with a group policy that locked out USB drives. Knowing how to open a DOS box and type PING and nslookup (the issue was very slow network performance, slow dns look ups, caused by incorrect DNS configuration). is not an "old hand showing off", but essential. And to be honest, the inbuilt commands (PING, NSLOOKUP, ROUTE and NET) are sufficient to troubleshoot the majority of IP problems, or at least identify where the fault lies.

Ping tests basic network access and reach
nslookup tests dns resolution
route well, the routes/interfaces a PC takes to access a given network
Net - (windows only) for MS network visibility on the local network

This is a bit disjointed and random, but written off top of head. Should really sit down and plan these things out!