The thought of attaining a CCIE in Collaboration might seem like a daunting task. After passing the CCIE Voice Lab (the predecessor to the CCIE Collaboration Lab), I remember making the statement that it was the hardest thing I had done in my professional career.
If you’re on the journey to your CCIE Collaboration certification, I want you to know two facts:
This posting is the third in my CCIE Collaboration Lab Lessons series. If you missed the first two, you can get them here:
To be successful in your lab, you need to be both strategic and tactical. While the first two lessons I shared with you were very tactical, this one is strategic.
To make your CCIE Collaboration Lab studies more manageable, I’ve created a framework around which all of your preparation revolves. I’m going to be referencing this framework over and over in the upcoming training I’ll be sharing with you, but I wanted to give you a peek now. So, here it is.
Notice the framework is based on four foundational directives:
Getting ready for the CCIE Collaboration Lab will have a massive impact on your life. Personally, I studied for over 1500 hours before passing (on my second attempt). Between October 2011 and the end of March 2012, I studied every single day except Christmas.
Before you even start the journey, be sure you’re committed to following through on your commitment to pass the lab. Decide in advance what you’re going to do when it’s harder than you thought it would be.
Unless commitment is made, there are only promises and hopes… but no plans. -Peter Drucker
A huge chunk of your preparation time will be spent here. The CCIE Collaboration Lab blueprint lists a plethora of technologies you need to know, at a deep level. When I was preparing, I used three tools to help me master the technology.
Imagine that you look through the tasks in your lab book at the beginning of your lab day, and think to yourself, “I know how to do all of this stuff!” Well, while that’s great to start off with that confidence, you’ll probably misconfigure something, or maybe an IP phone is not acting like you anticipated. When that happens, you need strong troubleshooting skills, which can largely be categorized into three areas:
And if troubleshooting your own issues weren’t enough, Cisco injects multiple troubleshooting issues into your lab topology before you even start. So, not only are you fixing things that you did less than perfectly, you’re trying to carefully sidestep the traps laid for you in the lab.
Even if you know how to do everything in your lab book, you might still run out of time. When I went into my lab, I did so armed with a collection of strategies that I’d practiced over and over again. Here are just four examples of those strategies:
A couple of nights before my lab, as I lay in bed in that ethereal state between being asleep and awake, I was thinking about my upcoming lab. Then, for whatever reason, I got a mental image of a video game I played as a teenager. It was a driving game called Pole Position. In the game, you navigate a formula race car around a track. You learn very early in the game that you need to really slow down as you negotiate tight turns. However, you floor the gas on the straightaways.
It occurred to me, that playing Pole Position was a lot like taking a CCIE lab, because there are parts of the lab where you slow down and really think through what your doing (e.g. doing UCCX scripting or creating a complex Voice Translation Rule). In other parts of the lab, though, you go as fast as you can (while still being accurate in your configuration). These times include doing some of the basic things you ALWAYS do when going through one of your practice labs (e.g. configuring specific Service Parameter and Enterprise Parameter settings). Knowing when to go fast and when to go slow in the lab is key to time management.
As just one example, when creating a Voice Translation Rule, I usually make one rule that can be used for both calling (i.e. ANI) and called (i.e. DNIS) information. Check it out:
voice translation-rule 2
rule 1 /^4...$/ /444\0/ type any subscriber plan any isdn
rule 2 // // type any subscriber plan any isdn
voice translation-profile LOCAL
translate calling 2
translate called 2
Notice the first rule in Voice Translation Rule #2 is used to prepend a local prefix to outgoing DNIS information, and set the Type of Number (TON) information to Subscriber. The second rule is then used to set the TON for the outgoing ANI information. We accomplished both tasks with a single Voice Translation Rule. Again, that’s just one of the Time Warp strategies I want to share with you.
If you’re on the CCIE Collaboration path, I sincerely hope this posting has been helpful. Also, please keep an eye open for the CCIE Collaboration video course I’ll be releasing in November, where I’ll take you step-by-step through a complete mock lab, showing you EXACTLY what you do on lab-day. Plus, I’ll have lots of other bonus training that goes along with that, including a video showing you how to build your own home CCIE Collaboration Lab!
For now though, I want wanted to let you know about a great offer I negotiated with my friend Vik Malhi, over at CollabCert. Vik agreed to give my readers/viewers 10 percent off his all his CCIE Collaboration training products, which include:
Vik was one of my instructors when I was getting prepared for my lab, and I’m sure you’ll be thrilled with the quality of his materials. Just enter the code KWCOLLAB when you checkout at collabcert.com to get your 10 percent discount.
Enjoy your studies!
Kevin Wallace, CCIEx2 (R/S and Collaboration) #7945, CCSI 20061
P.S. If you enjoyed this article, you might also want to subscribe to my podcast:
Please submit your information below to receive updates from Kevin Wallace Training: