As we’re all painfully aware, the next version (4.0) of the CCIE lab exam goes live this October. For those of us who did not nab a date before the cutover date, we’re looking at a different beast come October. In addition to a number of new technologies (such as MPLS and Zone Based Firewall) and the dread Core Knowledge questions, there will be a brand new addition: troubleshooting. Between the Core Knowledge section and the actual lab exam, there will be a troubleshooting section. While details are still a little vague, here’s what Cisco has said about this section(may require CCO login):
Troubleshooting is allotted two of the eight hours required for the CCIE lab exam. Candidates will be presented with a series of trouble tickets for preconfigured networks and will need to diagnose and resolve the fault or faults. As with previous CCIE labs, the network will need to be up and running for the candidate to receive credit. Candidates who finish the troubleshooting section early can move on to the configuration section, but they will not be allowed to go back to the troubleshooting section.
Here are some additional details culled from a recent Ask The Expert Section:
- The Troubleshooting section will be independent from the Configuration section, i.e., it will be presented on a different scenario.
- Once you finish the Troubleshooting you will move to the Configuration section that will be presented on a new scenario or topology.
- The Troubleshooting section will have a maximum of 2 hours. The candidate will be presented a series of questions or ‘trouble tickets’ for a given scenario or topology. The referred topology will pre-configured.
- Based on the information provided such as IP addressing diagrams, IGP routing diagrams, and so on you will work to identify and fix the issues. You will be given points for working scenarios.
- The Troubleshooting section will have a certain number of trouble tickets and points allocated to the section. You will receive credits for the points you get. Your score on this section will show as, 30%, or 50%, or 80%, and so on.
- You will need to get a minimum of 80% on each section of the exam to pass on the CCIE lab exam.
- Yes, we are planning to post a sample Troubleshooting questions/trouble ticket for study reference.
Internetwork Expert has a poll up asking CCIE candidates which part of the new lab format scares them the most. Troubleshooting is the number one choice.
I’ll admit that when I first heard about the addition of troubleshooting to the lab, I was unconcerned. While I don’t spend any time(outside of practice labs) building complex OSPF networks, I do troubleshoot networks for probably a good 30% – 50% of each workday(not to mention after hours when on call). Plus, I’ve always been pretty good at the initial troubleshooting sections in the vendor labs.
Petr Lapukhov from INE emailed me recently and gave me access to the first couple of labs in the new Internetwork Expert Volume IV workbook. This is INE’s new product covering the troubleshooting section of the lab. I agreed to try the first couple of labs and write my thoughts. My first thought? I vastly underestimated how potentially difficult the new troubleshooting section could be!
While I have spent a considerable amount of time troubleshooting networks over the last ten (sigh) years, they’ve always been MY networks. Well, at least they’ve always been networks with which I was very familiar. So if a server goon bitches about not being able to ping his heart beat IP address, I can quickly re-educate (an exercise in futility) him about the fact that this network exists on a layer-2 only network that is not trunked nor associated with an SVI so he’ll only be able to ping other heart beat IPs sourced from the heart beat IP address on his box. If I was not aware of the design of this network, then I would have to start with the usual battery of pings and traceroutes to (hopefully) get to the same conclusion. In other words, familiarity with the network design will make troubleshooting much easier and quicker. I also overlooked the fact that a good 90% of my daily troubleshooting is really mundane shit like checking speed/duplex, verifying MAC addresses, checking ARP tables, etc. It’s thankfully very rare that I ever troubleshoot any complicated layer 3 issues.
So while I might feel (justified or not) that I have a lot of troubleshooting experience, a lot of that experience will be worthless in a lab scenerio…as I was soon to discover.