Perfection is a myth; there is no such thing as a perfect network
Ah, yes, I remember going onsite to a company and really hoping that I could find some problem with their network -- after all, that would justify the bucks they'd spent on bringing me out there. What if the network was "clean"? What would I do? Just sit in front of the client and say, "Duh… ok… well…. Lookin' good here"? Then write up an invoice and sneak out the back door? My mind reeled with the thought of working on a network that has no error. What a fool, eh?
Undoubtedly, some bozo is going to email me and say that his/her network is "errorless." (If that's you, just stop...
now and take a break, would ya?) The only errorless network has one server and one workstation -- no users, no applications, nothing.
If you think you are working on a network that is completely without errors, you either have a lousy analyzer, blind management system, really strong drugs, or have not looked hard enough at the communications. Look all the way up to the application layer. You'll certainly find some errors roaming about.
The customer is often right
During an onsite analysis visit, I always ask the local IS staff, "What do you think the problem is?" It's amazing how often the local folks know exactly what is going on, but management has chosen not to believe them.
In many cases, I am hired as a "validator" to simply regurgitate what the local IS folks said. In other situations, I am simply gathering packets and presenting the IS staff viewpoint in a graphical format.
Every network has a Fred (user from hell)
I believe that one out of every 10 users on a network is a "Fred, user from hell" (F,UFH). Fred is the user that (intentionally or not intentionally) screws everything up on the network. He typically collects and displays all the networking books, but doesn't read them.
Nowadays, we need to expand the definition of Fred to include the '"tinkering hacker" on the network. You know the one -- the guy that has ping running on his computer in the background all day long and he doesn't know it. In the case of high school interns, you have a little Fred, Jr. on your hands. Be alert!
Note: If you look around you and find that nine other people are NOT Fred…. consider writing up a new resume.
You cannot ignore the damn OSI model
No matter how much you try to live your networking life without the OSI model, you can't. So just buckle down and learn it. There are hundreds of resources around the Net and in textbooks, so just go grab something and lock yourself away for an hour. Pay particular attention to the physical, datalink, network and transport layers. Those are the layers that move data around the network and define the upper layer applications in use.
Packets don't lie
Not to imply that people do, but… It's always best to get solid proof of what is happening on your network. The best way to do this is with a protocol analyzer. Get the packets, print 'em out, build the charts and graphs.
Troubleshooting is like tennis
In troubleshooting, like tennis, there'll always be someone better than you and there'll always be someone worse than you. You can't know it all -- don't try. Build up solid resources; know how to research. Also, try to remember that troubleshooting is an art, not a science. The good troubleshooter has strong people skills and deductive reasoning skills, and showers on a regular basis.
If it feels wrong, it probably is
Trust your intuition. Consider that if you wake up and go to the mirror to find that you have a vegetable growing out of forehead, you've just gotta say to yourself, "No, that's just not right. Something's wrong here." C'mon. It's really frustrating to see how many times people bypass their intuition.
Nothing is automatic
Okay, say this one out loud: Auto configuration is evil! Do you trust the vendors to pick and choose stuff for you? We let the vendors choose simple things (like the MAC address of a station) and that's about as far as that should go. Don't let the vendors choose your frame type or your IP addressing scheme please!
Every network protocol has a personality
It's true. You can tap into the cabling system and find that all types of personalities flying about. Consider the following personalities -- got any on your network?
- Servers that SAP all the time -- they just sit there and broadcast their information (as if we all care what they have to say). Blah, blah, blah…. droning on.
- Applications using UDP and IPX as their transport. Let's face it folks, UDP and IPX don't give a (&*#$&* about your data. Your precious little packets could be headin' out into the ol' ether for all they care. They're connectionless and proud of it.
- Applications using TCP, on the other hand, are quite militant. Salute when you say that, buddy! Formal handshaking and a need for the "Yes, sir!" acknowledgments make TCP the right transport for the mission (mission-critical data, that is).
- Applications that use SPX are militant, but lame. Think of Don Knotts dressed in a sergeant's uniform. (Too young for Don Knotts? Okay, picture Ricky Martin being a tough guy… oh, stop… I'm laughing too hard!)
- Token Ring stations are all just a bunch of whining five year olds -- tattling on each other at the drop of a hat (or token). The problem with this type of network is that you just know these devices aren't ever going to grow up. It's not just a phase.
Picturing your poor little pathetic devices and applications in this way will help in two ways. First, you might begin to feel some pity for them -- they know not what they do! Second, you will realize that you are more than just a network troubleshooter. You are a shrink to these misguided, annoying systems.
IS stands for Inferno of Servitude
Yes, you must have done something really lousy in a past life to be handed a job in IS. Perhaps you were the one who invented high-heeled shoes or ties. Maybe you thought up the idea of panty hose or musical toys for three year olds (without a volume dial or headset jack). In this case, you really deserve your life -- so enjoy it.
Laura Chappell is the Senior Protocol Analyst for the Protocol Analysis Institute. She is the author of numerous books and self-paced courseware available online at www.packet-level.com and www.podbooks.com. Laura also lectures on analysis, optimization and cybercrime. Her course schedule is online at www.packet-level.com.