Troubleshooting has always been a part of the CCIE lab in one form or another. Whether we look back to the days when the lab was a 2-day lab and the 2nd half of the 2nd day was entirely set aside for troubleshooting, or moving to the 1-day format where your own careless mistakes could mean you were in for a world of debugging to see what you did wrong, or even more recently up until now where Cisco began building small inherent errors into your initial configurations and then giving you a heads up with a task and points associated to fixing it. By the way, for you conspiracy theorists out there, they put the errors in before you get to your lab – and NO, they do not perform any ‘live’ error introduction while you are inside of your 8 hours, thus my word “inherent”.
Well moving on from those days till now, we come up against a new blueprint change recently for Voice and Security. This past year at Cisco Live! Networkers ‘08, we got to talking with a few of the Cisco Content Managers for various tracks (mainly Voice and Security) and also listening to their presentations and Q&A time with the crowds after the Techtorials. What we very solidly came to understand was that it is Cisco’s goal moving forward with the CCIE program to largely increase the amount of troubleshooting they request the candidate to perform, hoping to increase the amount of expertise they garner from said candidate while they have them captive in the lab. I mean let’s face it, configuration is absolutely necessary and fundamental – no one is contesting that – but without a solid understanding and ability to troubleshoot, that knowledge only goes so far in the field.
Simply put, the ability for an engineer to be able to troubleshoot effectively in the field is paramount. So now Cisco hopes to certify you ability not only to configure well, but also troubleshoot errors that they might have put there for you. Just the same as if you walked into a situation with a client on a network that you had never seen – you would need to be able to perform there as well.
This is the reason behind our decisions to not only mirror the new v3 blueprints for both Voice and Security, but to breakout each section into sub-sections – A & B. The A part of any given section deals with the configuration of a given technology, but the B part of the given section deals with troubleshooting that technology.
For more of a convincing argument simply take a look at the new v3 Voice blueprint and take a look at every section header. Notice that every section begins with “Implement and Troubleshoot”.
Now candidates may ask themselves if they really have time to debug protocols and look at traces (in the case of Voice) while in the CCIE lab. Many candidates that have gone before and ultimately passed have argued in favor of both views, some that there is time enough, and others that there simply isn’t. The argument for not having enough time has been loudest argued (at least that I have heard) by Voice candidates who, up until now, have had so many menial building-block tasks to accomplish to get to the stage to be able to configure the more complex technologies. While I believe that there was very little time in the previous lab for such a thing, I still think there was in fact time, but believe that in the new format of the lab where much more emphasis (and points) are placed on troubleshooting, that you will be given more time to do so. This might mean that the proctors have prepared a lab for you in which many of the more menial tasks that take up a great deal of time, but don’t necessarily prove expertise (registering phones, assigning line text labels, etc), are already configured for you and built into the “Initial” configuration when you go to sit down and begin the lab. How much time you have for troubleshooting also largely depends on your familiarity and comfort level with debugging and trace output. So if you haven’t found that “comfort” (oxymoron?) with them yet, time to dig in and get comfortable – you’re going to need to be!