Posts Tagged ‘help’
And we’re back for an exciting conclusion to the CCIE Troubleshooting series. Just what fate is in store for our heroes? Well, if we’re anything like the Friday the 13th movies, you may need to wait about 20+ years to find out!
You’re probably asking yourself, “With the amount of stuff we’ve gone through already, you’re really telling me there’s more to be concerned about?”
Yup, that’s exactly what I’m talking about. So what next then? How about little unexpected zingers that may just confuse, confound and otherwise astound you?
Have you ever rebooted your router/switch and had it reply to you “Would you like to enter basic management setup?” Of course you have. All the time in practice labs! But what if it happened in the middle of your actual lab exam? You DID save your configuration, right? You didn’t see any error messages pop up did you? Well, how about that?
How about a bit of preventive medicine? When you start the day, in SecureCRT that you’ll be using in the lab, I would click on the Session Options and then on the Emulation (under Terminal in the left-hand pane). See the part about Scrollback buffer. Set that to AT LEAST 5000 lines. Gives you the ability to review things you’ve typed or what the router has said, or recreate your steps in case of an emergency.
But back to this dilemma. What do you do? Run in circles, scream and shout? While that may be entertaining, it would scare everyone else in the room and not be overly helpful to your cause! Whatever you do, DO NOT enter the setup mode. Before completely panicking, just do a “show start” and see whether your config was really saved or not!
If it did not save, go check your scrollback and see what error you missed. Then hope you have enough scrollback to reconstruct your configuration. THEN run in circles, scream and shout!
Thanks for tuning in again! We’re back for more of the excitement known as Troubleshooting! Today we’re going to look at little more at some of the more nefarious (my word for the day) things that may come your way. How simple little commands can certainly change the way your lab is going!
In case you haven’t noticed by now, the CCIE lab is a largely psychological event. Technical knowledge is a very good thing, but if you can’t handle the pressure then it doesn’t help much! I still remember my first lab exam. Or more importantly the weeks leading up to my first lab exam, and I couldn’t make simple things work correctly! Stuff I’d been doing for years. And it was all in my head.
So what kinds of things can be on your lab which may have an impact on this stuff? Some are very simple, some are not.
So in the last post, I mentioned a little about process. The process by which we troubleshoot things (or how we even start our lab) may make a tremendous amount of difference in what our outcome, or at least our psychological state may end up being. Remember, you are there for the proctor’s entertainment. And sometimes they are very entertained!
Let’s take an obvious one. What if “no ip routing” was in one of your routers? “What?” you say… “Something THAT obvious, any CCNA could figure out, that’s just plain (insert appropriate word of shock or exasperation here).”
There are two types of troubleshooting that you’ll run into on the CCIE lab:
1. The “Proctor is Evil” Troubleshooting
2. The “Self-Induced” Troubleshooting
The latter type is by far the more time-consuming but also the most important. Basically you messed something up, therefore you have to fix it! (At least if you want the points) The reason it is the most time-consuming is because it could be ANY silly mistake or combination of silly mistakes along the way, and there is no predicting what kinds of things can be done to mess with your own head!
The most important rule with this kind of troubleshooting is time management. Set a time limit of 15 minutes. If you can’t figure something out in 15 minutes (no, I don’t care how “close” you think you are!) go do something else. Whether this involves a bathroom break, a soda/snack break, standing on your head on the high-quality lab chairs or simply moving on to another “service” or “security” task of your lab makes no difference. The idea is to separate your brain from staring at the same thing over and over.
The longer you stare at something, the more you see what you want and not what’s really there. Most self-induced errors are really small, and fairly inane. You know. Those “DUH!” moments once we figure it out. But time management is the consequence we suffer due to silly mistakes. Avoid it!
Anyway… on to the more exciting things. The unpredictable nature of the “Proctor is Evil” Troubleshooting. Having started my training career specializing in the old CIT (Cisco Internetwork Troubleshooting) class, I can greatly appreciate some of the humorous things that MAY get thrown into lab exams. The question becomes, if I don’t know what they are and there are many different things that could go wrong… What the heck do I do about it?!?!
Excellent question! Process, my dear. It’s all about process.