By lack of time and access to my lab (it’s a busy week), I’ve done no interesting discoveries and configurations lately. Instead, I’ve been focussing on the theoretical part of TSHOOT.

I may have limited experience as an actual network engineer, but I’ve done plenty of troubleshooting on past jobs, and in my daily life. If there’s one thing I learned, it’s that there are some basic skills never mentioned in any book that can get you a long way. Some may call it talent, but I’m convinced these are mostly learned skills. In my conversations with other certified people so far, I’ve noticed the people who were best at their job were those that used these skills, sometimes even unaware of it themselves. In the spirit of my upcoming TSHOOT exam, here they are:

Gather information. One of my beginner’s mistakes was to start working towards a solution without properly checking all information. An application isn’t working – wait, can you even ping? No ping – wait, is there ARP information? One can do a lot of troubleshooting before noting the cable is unplugged, for example.

Ask questions. A stressed end-user wanting a solution for his application rarely gives all the needed information right away. Ask what you need and want to know (he’s stressed anyway, just nudge him some more). In return, don’t get stressed when they don’t know anything – Questions are mandatory, answers optional. At least you tried.

No assumptions. If you’re assuming stuff without knowing for sure, reread the above two statements.

Try it. The theoretical discussion can be fun sometimes to see who is right, but in the end, the only way to know for sure is to try out a method.

Consult documentation. Don’t know how to do something? Check it in your books, on Google, or the official documentation. Since nearly all commands are listed there, one can often find some forgotten issue.

Best-practices are often best-practices for a reason. Everyone wants to be the first to find a better method to do something, but a best-practice that’s been around for years usually indicates many engineers have tried and failed to find a better method for many years. When in doubt, stick to the trusted solutions.

Things fail. That’s reality for you. End-users often exclaimed to me: ‘But it worked yesterday!’ Well, today it doesn’t. That’s the very definition of a problem. Just something to keep in mind as a troubleshooter: stuff will go wrong, and sometimes there’s no clear cause at first (or even after it’s fixed). Just accept that and work towards a solution.

Accept advice. Someone may have encountered a certain problem before, or know more than you do. Either way, not accepting advice, usually mixed with ignoring best-practices, and making assumptions, is a great cocktail for both failure and no trust from your peers.

For most of you, reading this will be nothing more of a confirmation of known facts, but even then, it’s good to keep them in mind. If some of these things sound new to you, spend time to get familiar with them. They’re worth the (saved) trouble.

Advertisement