Friday, April 19, 2013

CCIE-V Lab Strategy Part 1 - Formulate Your Strategy

I know what you are thinking, yet another blog on CCIE-V test taking strategy. Well, of course I would do that. It is almost a right of passage. An obligatory first step for any who have passed the exam. It is a glorious sign that you have arrived! Right? Not really. It is actually a sign that you have nothing better to do and are struggling with how to burn through the huge amount of free time that now lay in front of you! 

So, yes I am going to talk about test taking strategy. This started as just a single blog entry and then I realized it was becoming a little too long for just one blog. I wouldn't really go as far as saying this will be a series but it is certainly going to be more than one entry. 

For part 1, I wanted to walk through a couple strategies I came across as I was trying to determine my own path. I also want to discuss some of the factors you should account for when coming up with your own, personal strategy. You see, I believe that a well-prepared candidate will have a strategy that is unique to them. Even if that strategy borrows heavily from other approaches. You don't want to blindly follow someone else's strategy just because they appear to know what they are talking about. Listen, learn, and form your own opinion. 

The Series

This wound up being a 5 part series. I break my strategy down as follows:

Part 1: Formulate Your Strategy discusses the more well-known configuration strategies that can be used to successfully achieve the CCIE

Part 2: The Read Through focuses on the first read through of the lab and the custom notes, tables, etc. that you may develop as part of the read through

Part 3: Planning and Starting the Configuration walks through the planning and first hour or two of provisioning the lab solution

Part 4: Morning Configuration Strategy focuses on the configuration tasks that should be knocked out before lunch

Part 5: Bringing it Home focuses on the afternoon configuration tasks, how to adapt to issues, and how to validate your solution

Various Approaches

So, let's start diving into some of the approaches for organizing lab tasks that you should consider when forming your personal strategy. These are just the approaches I came across when starting my own journey.

Linear Approach

So, one approach is to tackle the questions in a linear fashion. Starting at the first question and progressing through to the end. I won't spend any time on this one because it is an absolutely horrendous way to attack this exam. Just don't do it. 

Technology-Based Approach

It has been suggested that there is no difference between the Linear Approach and the Technology-Based Approach. I disagree. In my opinion, the linear approach is taking each question as a separate task without any consideration on tasks yet to be executed. Whereas, the Tech-Based approach logically organizes tasks by their technology area and does take into account other, related tasks. Execution via the Tech-Based approach is not linear. You layer the solutions from infrastructure, to phone registration, to application integration, and feature provisioning

I also think of the Tech-Based Approach as one that lends itself to embedded validation. You execute some tasks and then validate before moving to the next "chunk" of Tech-Based tasks. I like to think of this as a "milestone-based" approach because you are inserting validation steps in-line with your lab at key transition spots. There is a danger with embedded or in-line validation. So, be wary of that.


Beginning of time? Just kidding. I actually don't know if you can pinpoint an origin for this approach. I first came across the term "Technology-Based Approach" when people were drawing comparisons to the "Device-Based Approach". In my opinion, the training I received from IPExpert follows a "Tech-Based Approach". Which, when you think about it makes sense. Companies like IPExpert and INE are primarily focused on teaching their students the technology. Yes, they do provide tips on test taking strategies, but that is secondary. 

Device-Based Approach

Taken in its purest form, the "device-based approach" follows a philosophy of executing all lab tasks associated with a single lab device in one sitting. Like all good strategies, this approach starts with the effectiveness of your initial read through of the exam and how you document the tasks you need to complete.

What differentiates the device-based approach is that you execute all tasks for a given device or application before proceeding to the next device. For lab requirements that have dependencies across multiple lab devices (such as MGCP, media resources, RSVP, QoS, etc.) you will have partial configs while you are progressing your way through the various devices.

This approach puts off validation until the end of the exam. Adopters of this approach assume that they will bang out configurations correctly the first time and won't need to enter commands more than once. For this approach to be effective, you need both speed and accuracy.


Based on conversations with some lower-numbered voice IEs, I believe the origins of this approach started with version 2.0 of the CCIE voice blue print. In that blue print you had a lot of terminal sessions you needed to churn through and a much smaller workspace (the monitor was smaller). So, executing all configurations on a single device and not worrying about going back to that device was very practical. Makes sense to me.

However, as far as I can tell, Matthew Berry is the one who came up with or at least popularized the modern version of this approach. You can watch a 5-minute video on the topic here: Device Based Approach.

"Modified" Device-Based Approach

Technically speaking, any individual adoption of the Device-Based Approach is going to be a "Modified" Device-Based Approach. However, in this blog I am referring to the formally defined approach from Kevin Wallace

Kevin's approach follows the standard Device-Based Approach in that you focus your attention on one device at a time. However, certain tasks get special treatment. Namely, tasks that rely on another device to be fully configured. For example, WAN QoS involves at least two devices. In Kevin's approach, when you hit your WAN QoS question(s) on the HQ router, you also configure QoS on the peer device.

Another example is MGCP. When you hit MGCP you "wait" to configure MGCP until you get to the appropriate point in your CUCM configuration.


I attribute this approach to Kevin Wallace. Kevin has a strategy that he calls "CCIE Voice Alchemy". You can read more about it on the IPExpert blog site: CCIE Voice Alchemy. The video is worth the time. 

Coming into Your Own

I probably can't successfully teach anyone how to devise their own strategy in a single sitting. Hopefully some of my thought process makes it through to this and other blogs in the series. Maybe there will be a nugget of info that inspires? At a minimum, I hope not to waste your time! So, let's get to it.

Strategy vs. Tactics

Hopefully the coming rant won't bore you, but I feel we have to draw some lines when discussing strategy. When talking about a strategic approach, you need to make sure you understand the difference between strategy and tactics. A strategy is your master plan that, when applied correctly, allows you to walk away with a passing grade. Your strategy is comprised of a finite and well defined set of strategic objectives that you must meet to achieve the final goal. Tactics are actions that you apply to successfully meet a particular strategic objective. Whether that tactic is designed to move you forward or to avoid a pitfall.

Why is the distinction important? It is important because for any given aspect of this exam, you will have choices on how you attack the problem. You have a limited budget of time and resources at your disposal. Therefore, your choices on how you execute specific tasks should be heavily guided by how well they support the strategic objective(s) you are trying to achieve. Yes, I am suggesting that your strategy starts well before you step into the testing center. It has to. 

That said, I am going to cut to the chase and focus on the "lab day". That is what most people will care about. Not to mention, if you are reading this then your strategy is already pretty well defined. You have invested far too much time to take it back to formula now. 

Let's illustrate strategy vs. tactics with a simple example and then move on. One of my strategic objectives was to have all device and application integration complete before lunch. By "device integration", I am referring to provisioning and registering phones, gateways, media resources, etc. to their respective call processing agent. Application integrations refer to CUC, CUE, UCCX, CUPS, etc. 

To ensure I hit my objective, I incorporated several tactics in my attack plan:
  1. Capture all pertinent end user and station information during the read through phase of my lab (first 30 - 45 min, for me)
  2. Complete all infrastructure tasks first (e.g. VLAN, NTP, DHCP, etc.)
  3. Start CUE initialization early and check often
  4. Execute NTP changes on CUCM as soon as NTP sync is achieved on reference host
  5. Identify/resolve any DB replication issues prior to doing CUCM baseline config
  6. Complete CUCM baseline config (date/time, location, region, VM profiles, MRGL, PT/CSS, etc.) before phone customization and prior to registering non-phone devices
  7. Auto-reg phones as soon as feasible, prior to baseline
  8. Fix CUC Integration, Fix UCCX integration
  9. Start CUPS provisioning, work to getting services activated -- cleanly
  10. Build phone button templates, softkey templates, and phone services prior to phone provisioning
  11. Remove unallocated/unassigned DNs and create DNs for phone use prior to creating/provisioning phones
  12. Leverage SQL and BAT to complete phone provisioning
  13. Wait on SRST configurations (do them in notepad, do not apply)
  14. Wait on QoS WAN until all devices are registered (Do LAN QoS if it takes less than 5 minutes)
When you are practicing and preparing for your lab attempt, you should make sure you have a clearly defined order of operations. You want to make choices that will streamline your process, help you establish a healthy rhythm, and directly benefit your strategic objectives. You will need to be willing to adjust your tactics on the fly and you need to understand the affect of adjustments on your strategic objectives. This is pretty important because you are going to be under a lot of time pressure and you want to ensure you are able to make informed decisions quickly.

Case in point. On my last attempt, I hit a hiccup with a piece of gear. It cost me time and was threatening to throw off my rhythm. I checked the clock and knew I couldn't address everything I wanted to address before lunch. So, I had to ditch WAN QoS until later in the day. That was not a problem because WAN QoS wasn't a critical part of hitting my strategic objective of having all devices and applications integrated to call processing agents before lunch. It could wait. 

A Word on Rhythm

In a recent thread, there was a fellow candidate who asked about lab strategy. A lot of people gave some really excellent responses. Most of the responses focused on speed. I concur, speed is absolutely critical. However, I feel that rhythm is more important than speed. I also feel that tapping into your rhythm is what is going to make your particular strategy different than mine and anyone else's. 

I define "rhythm" as being the tempo  that is derived from how you arrange tasks and manage transitions between tasks. It is one of the reasons why I "float" QoS tasks and why I focused a decent portion of my preparation on managing the transition between IOS config tasks and CUCM config tasks. 

Speed is important, but rhythm is king. 


I suppose I could go through the pros and cons of each strategy but that isn't a worthwhile exercise, in my opinion. The strategy someone adopts to help them pass this exam is a very personal choice. Any critique I would put on the table would be very subjective. I borrowed bits from Matthew, Kevin, Vik Malhi, and others. When I read or heard something that I thought was viable, I would test it. 

Maybe that is the most important piece of advice I can offer: don't blindly follow someone else's strategy. I suspect that the people who share their strategies are just trying to say "this is what worked for me" and they are implying that "your mileage may vary". You have to take the time to test and determine what is the best fit for you.

I'd recommend coming up with a handful of strategic objectives. Broad stroke milestones that you need to hit to walk away with a passing score. Then devise your tactics, your configuration approach, based on how well they facilitate your objectives. Don't compromise. Don't let others influence you too heavily. 

Listen, learn, and form your own opinion. 

Thanks for reading. If you have time, post a comment!


  1. Hi William,

    Congratulationss on passing the exam and thank you for sharing your strategy and tips.

    How long will it take usually to finish the first part "device and application integration" before lunch? As you know, the lunch time is different from a CCIE location to another?

    1. Mohamed,

      I cover that topic in this blog entry:

      If everything is going "well" and you have already pre-staged the device pool/region/etc. configs then I'd budget 30 - 45 min for getting:

      -GWs registered
      -Media Resources registered
      -Phones registered and configured
      -end users staged

      Then another 20 - 30 for VM apps integration. If time permits, I start the CUPS/UCCX integration. For VM apps I am getting users imported and fully configured. However, for CUPS/UCCX I am only focused on getting the pre-requisite items out of the way before lunch. For example: with CUPS I focus on changing the server in topology view to use IP address, changing the SIP proxy, activated servers, specifying/checking CUCM, adding a SIP trunk in CUCM. For UCCX I work on getting the CTI integration "healthy".

      -Bill (@ucguerrilla)