I had the pleasure of attending the CCIE Wireless tectorial at Cisco Live in San Diego this year. One of the topics discussed was the new diagnostic section of the lab. Jerome Henry gave us insights into what the section would look like as well as some examples of the types of things that we can expect in the section. I wanted to pass on some of that information along with a few insights about how you should prepare for this section since it’s quite different than what we’ve seen before in the lab.
What is the Diagnostic section?
Starting in v3 of the wireless lab, each lab will begin with a 1-hour diagnostic section. This section has no configuration task associated with it. Instead, you will be playing the role of TAC, or a senior level engineer. Your job is to look at information gathered from a client by a first-level engineer and analyze it so that you can answer questions related to troubleshooting an issue.
It sounds like you can expect maybe 3-4 separate troubleshooting scenarios with approximately 10 questions to answer across those 3-4 scenarios. So that means there will probably be 2-4 questions per scenario. All questions will have set answers to choose from (multiple choice style).
There will be a minimum score that you must achieve in the diagnostic section in order to pass the lab. If you do fail the diagnostic section, you still get to proceed to the main lab configuration section. You won’t even know if you passed or failed the diagnostic section until you receive your overall lab results.
We were told that if you finish the diagnostic section before the 1-hour time limit, you might be able to start the configuration section early (this is still to be determined). But you will definitely NOT gain any extra time to be used in the configuration section. You always have 7 hours for the configuration section. So there is no incentive to ending the diagnostic section early other than being able to finish your day sooner.
What can you expect to see in the Diagnostic section?
Each troubleshooting scenario will have a number of separate documents to view. There will typically be an email chain between the client and the first-level engineer that describes the issue along with some general information gathered by the engineer. Then there will be also documents that contain things like running configs of devices, show/debug command outputs, a basic topology diagram, and maybe something like a packet capture. Somewhere in those documents will be the information needed to answer the questions.
What types of questions will there be?
While there could be many different types of questions, here are some examples of questions that you may see.
- Which device is causing the issue?
- How could you solve the issue?
- Which command on which device was the most helpful in identifying the cause of the issue?
The way that they did the questions definitely makes up for the inherent increased simplicity of the multiple-choice format. For instance, maybe you run into a scenario that you aren’t 100% sure about. But thanks to the process of elimination, you might be able to answer one of the questions correctly. For instance, maybe you could figure out the solution to the issue. But unless you really understand what’s happening, it’s very unlikely that you could use the same process to pick which command on which device gave the primary clue. So it’s not something that you can fake your way through.
How can you prepare for this section?
Our classic methods of preparing for the lab will definitely still apply to the diagnostic section. Troubleshooting has been built into the lab in previous versions. So we’ve needed to be able to diagnose and fix issues in the past. What makes this different is that you are being forced into a particular method of troubleshooting that may not be your standard method. So your natural troubleshooting methodology may not be sufficient to answer the diagnostic questions. In other words, just because you could solve the problem your way doesn’t mean that you’ll be able to solve the problem their way.
For example, I personally never relied much on debugging or looking at the CLI running configuration of WLCs. I was always able to troubleshoot fairly effectively using other methods. But in the diagnostic section, it seems to favor CLI-based output. So you will be presented with running configurations (of all different types of devices), show command outputs, and debugging command outputs. If you aren’t used to looking at those, that can be a problem.
What this means from a preparation standpoint is that you must force yourself to become much more familiar with CLI-based configurations and common debugging outputs. It doesn’t means that you necessarily need to learn how to configure everything through the CLI from memory. But you at least must be able to comfortably interpret CLI-based configurations. You need to know what any given thing should look like in the CLI so that you can spot mistakes, which could include wrong lines of configuration or even missing lines of configuration.
You will need to practice using debugs of common actions like client authentications and AP joins. Know what things should look like when they work correctly as well as what they look like when they don’t. This is going to have to be intentional. You may need to learn more about how these different processes work so that you actually understand what you are seeing in the debug.
Thoughts about the Diagnostic section
I think that the inclusion of the diagnostic section was a good move on Cisco’s part. It sounds like every track will eventually have it. It’s probably one of the better methods to try and curb the effects of brain dumps. While the configuration section will be slow to change (which brain dumps use to their advantage), the diagnostic section can be developed at a much faster pace. The section is long enough and has enough questions to be a fair gauge of skill. Also, the use of multiple choice rather than essay takes any human element out of the grading. So there is no subjectivity in the grading.
This section is also going to force candidates to expand their troubleshooting arsenal beyond what they may have developed without it. While that will increase the learning curve and require more time to prepare, in the end we’ll have much more effective and knowledgeable engineers as a result. I am looking forward to being pushed out of my comfort zone as I work on creating materials to help students tackle this section.