I sat the CCIE security lab on Friday, January 12th. Result was Pass/Pass/Fail. That means overall I failed.
For those who are unaware, there are three sections to the exam; Troubleshooting, Diagnostics, and configuration.
Here’s my interpretation of those sections:
Troubleshooting is like getting a bunch of 2:30am phone calls where something is broken and you need to hop on and fix it now.
Diagnostics is like getting emails at work where a field tech and/or the Helpdesk are stuck on a problem, and you have to figure it out from a couple of screenshots and some log/device output. You do not get to actually touch the devices.
Config is like being a consultant asked to complete a build on an enterprise network where sales severely underbid the required project hours and you’ve got to make it happen.
With that out of the way, I’d like to break down what went well, what went less than well, and what I need to improve on.
What Went Well
I did a lot of self care in the 36 hours leading up to sitting the lab. Mostly breath meditation, and reliving an amazing road trip I took last summer. Looked at photos, listened to a playlist of music I listened to on the trip, closed my eyes and relived moments. That was very effective, it’s amazing what we can draw from those times when we need them.
In the run up my waking and sleeping hours were all over the map in a mad dash to get all the labbing in I could, but I needed to rein that in. About a week prior to lab day I started adhering to a rigid routine of going to bed and getting up early. A week was enough to get my body clock reset.
Structured approach to the exam
Keeping a score card, task list, reading questions multiple times to make sure I’m not overlooking small but critical details, and making notes. Using checklists for long tasks. This all worked very well, no problem there.
Keeping all cli config in notepad
Building everything in notepad makes it dead easy to make updates and corrections, and to refer back to what you did earlier. Its also an exam saver if for some reason you have to reinitialize a device. Little things that I do cli first, I will still transfer those to notepad.
Quickly discovering relevent information
I didn’t have much trouble quickly isolating the relevant area I needed to look at in troubleshooting or diag, that was a good feeling and gave me confidence.
Theory and technology knowledge
I was pleased that my topic knowledge was pretty much up to snuff. All the hard work of learning the technology paid off when I found the tickets straightforward and I never got lost or confused. There is something related to TS I need to improve to save time for config, I’ll touch on that in the next section.
What Did Not Go Well
Slow at verification
This first showed up in tshoot. I was spending more time verifying corrections than I was fixing the issue. I think there were two causes.
1. I have no field experience with some of the technology because I’ve never seen it on a live network. This is a disadvantage of working in enterprise; I have a narrower cross section of exposure.
2, In my final prep I was using fixed topologies and designs that I knew intimately. Consequently I didn’t have to put a lot of effort into verification. On a network you’ve never seen, and you don’t know the underlying details of the routing design other than what’s depicted on the topology diagram, it’s a completely different situation.
These significantly impacted my speed in tshoot and config. Spent way too much time on verification.
Managing Information Overload
I was feeling pretty good coming out of Troubleshooting and Diag. As I started reading through the config section, I did not have that good feeling. Some of the tasks were very long and packed with small details. There are key details that you will only pick up on if you read carefully and understand the technology. This intimidated me and caused me to worry too much.
I spent way too much time double checking and verifying those details. I think you have to trust yourself enough to bang it out, and double check your work at the end of day, otherwise you won’t get enough done.
Not Checking the Preconfigure
There may be stealth faults in the configuration section; not checking the preconfigure can extract a heavy toll in wasted time as you have to reset appliances and clean up the mess. Unfortunately this happened to me. Rookie mistake,
Not enough speed/memorization of cli commands
There is a lot to do in config. You have to be capable generating large blocks of config in notepad and pasting them into the devices error-free for any of the technologies being tested. For gui based task elements, you have to be able zip through the ui and configure whats needed without any poking around. That’s the bar, simple as. Some things I was at that level with, others I was not.
This exam does ask for some knob turning (i.e. advanced requirements). That was a bit of a mixed bag for me. I think these are intended to slow you down more than anything, and that they will if you don’t know where the knob lives.
What I Need To Improve
That means giving it consistent attention and focus
That means being able to create in notepad any tested cli based technology cold….and have it paste in error-free 10x out of 10.
For example if you’re asked to spin up flex mesh, you need to be able to look at the requirements given for it in the task, type it up in notepad, paste it into the routers, and have it come up and work right out of the gate. You may be able to get away with checking cli syntax for some of the knob turning, but at a minimum you need to be able to quickly spin up a basic working configuration from memory without errors.
Add knob turning elements into practice exercises
Knowledge hole patching
Study a couple of small things I wasn’t knowledgeable enough on.
Overall it wasn’t a bad showing, would like to have done a bit better. But the results weren’t terrible. Encouraged that most of what needs to be done is simple repetition to gain speed, rather than correcting issues in fundamental knowledge or approach.
Hopefully I can even the score next time.
Thanks for walking with me.
18 thoughts on “CCIE security lab 1, Steve 0”
Nice write up Steven. I loved your characterization of the CONFIG section. We will wrestle this beast into submission yet. ABL!
Thanks Marvin. Damn straight we will. Always Be Labbing, my fried.
Wow.. such a nice and perfectly spot on description of the hole process..
Is it possible to sent you a message directly?
Thanks Henrik. Pulling for you on your next attempt.
Excellent way of looking at it Steve..You will crack it..
Thanks Khawar. Your bootcamp was on point. Now it’s my job to execute.
Great write up and reflection on your experience. Based on what you have stated, I think this has been an extremely positive experience and the rematch will be just as glorious as Rocky vs Creed II. : )
Thanks David. 🙂
Steven, i just wanted to say thank you for sharing your experience and i wish you the best on the next attempt!
Appreciate the kind words, Zach. Thanks!
By far the best article I have come across on CCIE Security preparatory tips. amazing write-up.
Thanks for the compliment, Vidur. Glad you got something out it my share. Bests, -s
I can only echo the others. A fine post and I know you’ll knock it out of the park in later attempts.
Thanks Jason! Hopefully round two goes my way.
Nice write up, and a very respectable pass/pass/fail on your first go. I am sure you will get it done my friend!
Thanks Joe. Appreciate the kinds words.
Steve, I have been right there with you and I know what it’s like. Great post and it’s right on point. You’re also correct about experience on a live network. Theres no substitution for it. Being in the eye of the storm at a client site is very similar to the eye at the CCIE exam. Keep going and you will make it!
Thanks Mark! Yeah I dropped the ball on verification practice, particularly for the things I don’t work with in my day job. Won’t happen again. Appreciate the kind words.