jacob200,
IMHO, troubleshooting is more of an art than a science.
Step 0 is always have an understanding how things are supposed to work. This involves knowing how to use the tools you have on hand and knowing what traffic normally looks like on you network. There is nothing worse than trying to figure out how to make a tool do what you want when "all sweat pumps are on-line!"
But after that, how any technician approaches a problem is more of a matter of style than proper procedure.
For example, my particular style I call the "bulldog" method.
Whenever there is a supposedly "network" problem, everybodies problem now seems to be caused by the network. I call it the "tar-baby effect." Every little problem now seem to be being cause by the network and the network gets stuck with even local printer problems. So I usually have many more symptoms to sift through and most of which are not directly related to the real problem.
So, I like to find one network-specific symptom (e.g. this user can't browse the domain) and troubleshoot that one symptom. I'll grab onto that symptom like a bulldog and troubleshoot just that symptom until I find its root-cause.
The fix for that solution may resolve a lot of other symptoms. If there are residule symptoms after the first is cured, I'll grab the next most likely symptom and bulldog it until I find its root-cause. Repeat as necessary...
My $0.02, YMMV!
Patrick
Patrick Bartkus, CCNP, CNX, SCM, RHCT Sr. Network Engineer
GA Dept of Labor IT Network Services
If truth were not absolute, how could there be justice?