Continuing a couple of posts based on my experience of earning my CCIE, I thought I’d share some Q&A that I came up with. Upon earning my number, I posted a “thank you” email to the IPExpert On-Line Study List to thank members of that list for helping me along the way. I received a number of questions in response to the news, and I wrote up a Q&A based on those questions. I’m reposting that information here for those that may find it of interest.
Was this your first attempt?
No, my first lab attempt was in July 2012. On that attempt I passed TS but was far too slow and poorly organized for the config section. This was my second attempt. After taking about 2 months easy after my first attempt I got back to serious prep for this attempt in mid-October.
How did you feel going into the lab. Did you know that you knew how to configure everything or were there still questions in your mind about it?
Not *everything,* no. I knew there were topics that I was weaker on and topics I was stronger on. I had tried to make sure I’d configured just about every feature I’d seen in any workbook at least once, and recently I’d gotten much more familiar with the DocCD so I could start finding things quickly, even if I hadn’t seen them before. Still, I did run across a couple features in my lab that I hadn’t seen before, but I was able to quickly find them and at least get an idea of how I think I was supposed to configure them.
What was your process of labbing? Tech labs then full labs or did you hit the full labs first and go back and practice on what you got stuck on the full lab?
Before my first attempt, I had been spending months alternating between reading and doing technology labs (“Volume 1” material). In the couple of weeks leading up to my lab I focused just on trying to do as many full labs as possible, often without enough emphasis on improving my technique but rather just doing more. This time, I had been revisiting certain specific features and working largely on core topic speed. Then in early February I switched to full labs, hoping it would suddenly refresh me on the many topics I hadn’t touched in months. Still, just a few days before my lab date, I realized I was doing well on core topics, but that losing LOTS of time and points on services and security sections. I made a last-minute course correction and went back to (INE) Volume 1 for those areas and hit them hard for 3 days before the lab. I did one last full lab 2 days before the real exam, focusing on trying to read every task carefully and not make the silly mistakes that usually cost me. I did very well on it and that gave me a huge confidence boost. On the day before the exam I make sure to lab up about a half-dozen topics that I knew I had a good chance to run into (PPPoE, MST, etc) and also re-labbed all the topics I’d struggled with on my first lab.
On the exam, does each test have a IGP highlighted diagram like the IPExpert and 360 practice labs give? Or are you not allowed to say?
You’re given all the documentation you need, and for the most part it is pretty clear. Don’t be afraid to press the proctor for some clarification if a diagram seems incomplete. I did that in one case on this attempt and the proctor’s assurance that the diagram was “not missing anything” made me choose a specific course of action that I think was pretty insightful. I’d love to expand on that, but I cannot.
What practice labs did you use to study? IPexpert/INE/360?
I used a multi-vendor approach. Not saying that was the best, but I felt I got a well-rounded preparation. I am planning a future article to compare/contrast these materials since I’ve used most of the major vendors at this point.
How many [IPExpert] Vol 2 labs did you do? People suggest to focus more on Vol 1.
I actually did none of IPExpert’s Vol 2. I did all of Vol 1 and most of Vol 3. The Vol 3 was actually before my first attempt. I used materials from INE’s Volumes 1, 2, 3, and 4 before this attempt. I didn’t complete any of those workbooks in full, but did select labs from each. You have to focus on where you’re weak. Weak on speed? Work on speed labs. Weak on security; security labs. The lab will expose your greatest weaknesses, so minimize them. Each of the INE workbooks focuses on a specific skill set, so I found value in each of them.
Would GNS3 with two 3550s and two 3560s do for CCIE lab preparation?
95% of my labbing was done on my hybrid rack which is primarily Dynamips routers and real switches. I eventually settled my lab out with 3×3560 and 1×3550 but I think you could do just fine with two of each. In fact, INE and Narbik’s topologies assume two of each and the startup configs need tweaking if you have anything other than that. I did add 3 1841’s to my lab to act as R1, R7, and R8 in IPExpert’s topology so that I had a couple real routers to use for things like BFD that can’t be done on Dynamips routers. The 1841’s weren’t critical but were a nice addition. I strongly recommend using 7200 models in Dynamips rather than 3700s. I had many more emulation-related problems with the 3700s, like funky multicast, stalled serial interfaces, LSA corruption, etc.
Note that I will be doing a whole series of posts on my home lab setup in the near future.
What worked for you in terms of time/point management for both TS and Config?
TS: Fly. Just fly. Don’t waste a second. 10-12 minutes for a fast read through and note-taking pass. Then I would look back over the tickets and mark on my score sheet the order I wanted to do the first 4-5 in based on the ones that looked like easy wins. That put me in a good rhythm and helped me build a time advantage. I found in practice and the real labs that once I solved about half the tickets, the rest started to fall into place as I got a feel for that topology and the kinds of issues I was hitting. My goal was that by 20 minutes into TS, I’d completed my read-through, prioritization, and solved my first ticket. Any longer than that and in my opinion I was behind.
For config, the thing that saved me this time was a technique I’d been working on in practice labs of doing my read through and marking tasks that I didn’t have a very good idea of how to completely accomplish as a candidate for skipping either for later, or completely. I also marked tasks that were absolutely critical for connectivity, so I’d know that if I couldn’t get them working within a tight timeframe I’d have to “cheat” them and just make them work regardless of task requirements so I could move on.
In this particular case, my lab had a heavy component for a feature that I had not studied in great detail for some reasons I don’t want to mention because it would “give it away,” but the important thing is when I saw that I had a good chunk of points related to that topic I immediately decided to write those tasks off completely and spend all the time allocated for those tasks making sure I was kicking the rest of the lab’s ass. I knew that if I was very nearly perfect on the rest of the lab I could afford to write those tasks off. That’s what I did, and it worked. Not sure I’d recommend that path for everyone, but the important point there is that I knew my limitation, I knew what a waste of time it would be just “messing around” trying to get one of those tasks working, and I made a tactical decision based on what it would take to pass the section with the hand I was dealt. You do not have time to “play around” trying to get something working if you don’t have a very good idea of exactly what you need to do. You must be absolutely ruthless with your time management, which is why you have to know the material cold.
Speaking of tracking points, I developed a pretty good note-taking and point-tracking score sheet that I used religiously in practice labs. It looked roughly like this:
Not so different than many other examples I’ve seen, but I made a few tweaks. I used it like so:
- OK: Checked this when I thought I had the task complete. A second check meant a second verification pass. An O meant I had skipped it.
- Tkt/Tsk: Obviously this was the task or ticket number. I made a separate grid for each section. This cell is where I’d mark with a little “up” or “down” arrow to indicate a relatively higher or lower priority task. High priority meant it had to work for full connectivity. Low priority meant a “stub” task with no downstream dependencies that I could bag if I really had to.
- Pts: This was the point value of the item. This helped with a quick tally and also knowing where to focus my efforts when time got tight.
- Topic: This was just a word or three regarding what I thought the topic was about. “BGP filtering,” “Mcast,” “RIP,” or “PPPoFR” for example. Again, just a means to mentally filter the task list. This was filled out during my read-through.
- Devices: I used this more in TS to mark the device or devices that I thought were in the trouble path. For larger config items I left it blank, although any task that explicitly stated to configure “R4” or whatever I did mark it so that I had an additional check that I was doing my config in the right place.
- Time: For TS I used the “time remaining” when I had completed the ticket. For Config, I marked the clock time. As I moved on to the next task, I could easily keep an eye on how long since I’d last finished a task. If I was getting on toward 10-12 minutes on a ticket, or maybe 15 minutes for a larger task, I knew it was time to make some notes and move on.
- Notes: Pretty self-explanitory. If I had to skip a task, I’d make a quick note here. Also, in Config I would note dependencies on other tasks here, or if I thought I had an idea of how to do something beyond the “Topic” phrase I’d jot it down here, such as “adv-map for prefix; set med on injection”
What made the difference for you, this time compared to your previous x attempts?
- Experience of going to the lab. Looking around the waiting area and seeing the candidates who were clearly there for their first attempt, I realized just how bad the nerves can be. I actually felt pretty calm waiting to start as I knew how the lab intro would go and I was fairly confident for the TS section.
- More technical development and more, more, more lab time. 7 months of additional study, and by my tally well over 250 hours of additional lab time since July. I improved my speed a lot, and from doing all the practice lab work got better at picking out those keywords that steer a solution one way or another.
- Better strategy and tactical plan for attacking the lab and focusing on how to pass Config, not how to do every task on Config. This is the part where you don’t let dignity get in the way of ruthless time management. Can’t get some “easy” feature working in a reasonable period of time? Make a note, swallow your pride about the fact that you couldn’t get PPP authentication working, and move on. Come back later if you can.
- I took it a little easy on the day before the lab. I still spent about 6 hours at the terminal, but it was mostly labbing up some topics I expected I might see, and also going over all the items I was stuck on from my first lab. After my first attempt, I’d made copious notes in the car as soon as I finished so that I could try to figure out where I went wrong. I finally dug back into each of those items and made very sure that I understood them thoroughly. I was reviewing, not trying to learn anything new. Not challenging myself, but instead building confidence. I think this was a good move for that last day.
- Also, something that I did have last time as well as this time, but that I think is just critically important, is unwavering support from my employer and my spouse. I’d had a lot of time off leading up to this attempt, and much of that time off from work I actually spent living in my mother’s basement, labbing 18 hours a day while my wife acted as a single parent for our two small children. Having and maintaining a good support structure is just so important — I literally can’t imagine how someone can tackle the CCIE without it.
Herding Packets 
Excellent write up Bob and congratulations! This has given me some inspiration and also others I am sure that this is a journey and that you should treat a failed attempt as a learning experience, and you obviously drew on that and nailed it the 2nd time.
Thanks Roger! If you didn’t see the write-up I did after my first fail (http://packetpushers.net/how-to-fail-the-ccie-lab-exam/), that’s worth a read too (IMHO…). I discuss my failure, and the lessons I learned from it.
Thanks also for the link on your blog! I appreciate the help in getting some exposure to my posts.
Cheers!
Thanks for the Post. This is very motivational, hopefully I can take from your experience and use what you have learn for my benefit when the time come to take the TEST.