The art of troubleshooting.
Troubleshooting. An artform in itself.
I have been doing trouble-shooting labs for the last week and its not going the way i want it to.
In all fairness, its very good practice! having all the components in one lab, with all sorts of technologies interconnected really makes life interesting.
The most valuable thing i have learned so far, is to calm down and not rush into a “maybe-this-works” sort of solution.
The best way for me, is to verify the problem, write down important things from the troubleshooting ticket (such as what to reach and from what).
Once i have verified the problem, start from layer 1 and go up the protocol stack. Theres no point in starting fixing an EIGRP adjacency if you have no L1/L2 reachability.
Time! my arch-enemy in this troubleshooting section. You have 2 hours allocated to fixing the trouble-shooting tickets. Im guessing in average 12 tickets. That is 10 minutes per ticket.
On some of the tickets i have encountered so far, i have spent 30-60 minutes fixing them. This is not a promising sign. However, im writing down the issue that i faced, and how i resolved it.
This approach makes me learn from the general problem i faced and hopefully when i encounter something similar in the future, i know the exact process (not the exact solution) to fix it.
Understanding the question thats being asked is a key component in fixing the problem. If you dont really understand what the question is asking you to do, you are by default going to implement the wrong solution.
Let me give you an example:
“R1 has a problem with unreachable telnet connections.”
“Make it so router R1 will not accept unreachable telnet connections.”
From this i thought i was asked to make R1 not accept any connections from an unreachable host, this means implementing uRPF checks.
What was really asked of me, was to make sure that R1 would not keep idle telnet connections hanging. That meant implementing “service tcp-keepalives”. Two completely different things!
Im hoping that the wording in the real exam is very precise and they make sure you are going in the right direction.
Right now im taking a break from troubleshooting and watching Marko’s vLecture on multicasting: Multicast vLecture.
Check it out.
Anyways, thats what i have been up to lately, now back to Marko.