Friday, April 19, 2013

CCIE Voice Lab Strategy Part 2 - The Read Through

What started as a single blog entry quickly became two and after finishing Part 2, I am fairly certain there will be one or two more entries to round out this "thought". Before diving into this entry, I'd recommend taking a look at Part 1: Formulate Your Strategy

In Part 2, I am going to talk about my personal strategy a little more and focus on the Read Through phase of taking the lab exam. Not because I think my Read Through is all that fascinating. I just feel that by talking about the Read Through I can further illustrate my actual strategy. 

Overview of My Strategy

Before thinking about how you are going to configure, say MGCP gateways, think about how you work. Are you a methodical person who likes to plan? Or are you one who prefers to get things configured quickly and then tweak/fix things as you go? Do you have a good short-term memory? Or do you need to take copious notes to do your do? Can you multitask? If so, how many different plates can you spin at once?

Do you recall playing video games where you had to pick a character based on a handful of attributes? For example: speed, defense, strength, and agility. You always wanted the character that had all "tens" but that required a cheat code. Well, I see the CCIE lab as a game and your character (unless you are cheating) is strong in some areas and weak in others. Your job is to learn how to exploit the strengths and compensate for the weaknesses. 

You need to get in your own head and figure out what works for you. What worked for me is that I would test out tactics with configuration drills and strategies by doing full mock labs. I kept a detailed journal of my labs and drills, along with a time log for how long it took me to do individual tasks or sections. After a self-study session, I would take notes on what worked, what didn't, what I got wrong, where I was clueless. 

Initially I was just following the methods I picked up from Vik Malhi's bootcamps. Then I started zeroing in on my weaknesses and would start exploring other options. I decided about 3 or 4 months into my prep that I was going to try a couple of different strategies and that I would give each strategy at least two full 8-hour self-study lab sessions. This is how my strategy evolved.

In the end, my strategy was closer to a Device-Based Approach with a healthy smattering of the Tech-Based in-line validation strategy. For the rest of this blog entry, I am going to walk through how I start my exam process. I am hoping to illustrate some of my strategy along the way.

When Starting Your Exam

Read through the exam, in its entirety before dorking around with configurations. 

Have some easy-to-use tables laid out on paper (or in notepad) ready to go before you do the read through.

Quickly pluck out key data points and populate your tables. Don't linger too long on reading the questions. You will have to read them again when you do the config and likely one additional time when you validate. 

Make Sure You are Playing with a Full Deck

The very first thing I do after logging into the candidate PC is to do a quick walk through of the equipment and apply a baseline configuration. Basically, I want to identify any pod issues as soon as possible and get some basic configs in place.

So, I came up with a "pre-flight check" routine that I would practice during every mock lab and use for the real lab. This routine only takes 5 minutes. 

Pre-Flight Checklist:
  • Open console sessions to all IOS gear: Switch, HQ router, Branch 1 router, and Branch 2 router
  • Start with the switch and add baseline configurations:
    • cdp run
    • cdp time 5
    • cdp adv
    • vtp mode server
  • Connect to the HQ router and add baseline (same CDP commands as above). Also, check ip ospf neighbor list and CDP list (show ip ospf nei | show cdp nei)
  • Connect to BR1 and BR2 routers and add baseline
    • cdp run
    • cdp time 5
    • cdp adv
    • vtp mode server
  • Check IP OSPF neighbor list and CDP neighbor list on BR1 and BR2
  • Ping UC application hosts from BR1 and BR2
  • Save running config on all devices
  • Load IE and browse to CUCM pub and verify login
Putting Your Thoughts Together

I put a lot of stock in my read-through of the exam. A lot of people told me how they read through the lab in 10 - 15 minutes and then started to configure things. I honestly don't know how this is possible in the real lab. My goal was to read through the lab in 30 minutes. On my final attempt the read through was 45 minutes. Add in the pre-flight and that is 50 minutes. 

So, what the hell was I doing with all of that time? Well, in my approach, I was trying to capture some key information:
  1. I wanted to capture the IP addresses, interfaces, etc. in a notepad so that I could copy/paste into configs. This avoids stupid typos.
  2. I capture all phone-related configurations in notepad. This includes the text I will use for description/display/alerting, button assignments, CFNA/CFB, services, etc.
  3. I capture all PSTN carrier requirements.
  4. I map out the dial plan
  5. I lay out my "device-based" task table
Items #2 and #4 are the primary black holes for the time I spend doing read through. The reason I want to capture all of the phone and end user info during the read through is because one of my strategic objectives is to fully provision phones and users in one go. IOW, I did not want to go back to phone or user configs multiple times. 

I kept item #4 because I have to do item #3 during read through. You see, I use my PSTN carrier requirements table to generate a full dial-peer configuration which is necessary to hit my strategic objective of having all CUCM/CME devices configured in 3 hours. To get the info to build table 3, I had to read the questions "deep enough" to where I had the dial plan data too. It didn't make sense not to use that data when I read it. 

So, let's look at representative samples of the data I collected.

Base Configuration Notes

I would create a text file (base.txt) on the candidate PC that would look sorta like the following. This file was created during my read through.

!---------> servers


fa 0/1 r1
fa 0/2 ph1
fa 0/3 ph2
fa 0/5 ph3

100   server
102   voice
202   data

!services / params
- legacy idivert: f
- xfer on-hook: t
- moh:g711+729
- ippa, ippm

HQ Phone 1
  b1: 2001   VM CFNA:20 CFB:1
  b2: 2000
HQ Phone 2
  b1: 2002   VM CFNA:20 CFB:1
  b2: 2102
  b5: IPPA
HQ Phone 3
  b1: 2003   VM CFNA:20 CFB:1
  b2: 2000

So, the basic.txt file was my "go to" info dock. I put a lot of info in there and I was constantly copying values from the text file and pasting them into other config notepads. You can see that I capture all info for the phones. This helped me bang out the phone provisioning in one go. I also capture service parameter "tweaks" that pop out at me during the read through. I have a default set of service parameters that I modify and I only note those that aren't in my default list.

PSTN and Dial Plan Configurations

I capture dial plan and PSTN requirement information during my initial read through. I tried a lot of different methods in the effort to optimize this section. It actually wasn't until 2 weeks before my final attempt that I came up with an approach that totally clicked for me. 

I build two tables. Both of these are put on the scratch paper the proctor provides at the beginning of the lab.

PSTN Requirements Table

I use the PSTN requirements table to capture all data that is relevant to the T1/E1 PRIs and egress call presentation. An example:

There isn't really anything special about this table. It is similar to others I have seen. I did re-arrange things a tad because I am building this table on scrap paper and I want to minimize how much space I use (they only give you a couple of sheets). In the "Type of Call" column the "FO - HQ" means Fail Over for HQ and the "TEHO - HQ" means Tail-End Hop Off for HQ. Pretty self explanatory. Note that I capture specifics on the PRI config such as number of channels and channel presentation order. I'd also capture "binding" information here.

One of the less obvious aspects of my approach is that I have a default config option for most things and I only note requirements that are different. For instance, I bind my voice signaling protocols to the loopback interface by default. If a requirement said use VLAN 101 then I'd note that. Same is true for calling name display. I display by default and only note where CLID should be restricted.

This table is fairly simple but also very handy. Probably the most useful "tool" in the arsenal. It helps guide the dial plan provisioning process, I can build a full H323 GW config from this table in like 5 minutes, and it is invaluable when it comes to validating your dial plan. 

Call Routing Table

Are you bored yet? I hope not because this is just getting good. First and foremost, my approach to dial plan provisioning in the lab is simple. I do not leverage SLRG unless I am required to do so. I don't try to minimize the number of route lists or patterns. I only leverage full E.164 patterns as needed. It isn't because I am afraid of SLRG. Quite the contrary, in my production designs I use it heavily. 

I just think that dorking around with SLRG is unnecessary and provides no additional value or time savings. I tried a few labs using the SLRG approach and I didn't notice any noteworthy time savings. If anything, energy for configuration is merely shifted to another menu in the CCMAdmin interface. Just my opinion.

I tinkered with a lot of ways to document the dial plan on paper (or notepad) as part of my read through. What I eventually settled on was quick and dirty. For example:

Notice that I don't put full patterns. I use 9[2-9](6) to represent 9[2-9]XXXXXX. I also don't record route list names or route group names. I used to grab and document all of that info. I then had an epiphany: I only need enough bits to remind me of the full picture. Take the 91408 pattern next to HQ for example. I know this is for HQ. I know that there will be 7-Digits following the NPA and I know the LRG for HQ is HQ_RG. I don't record DDI here because the PSTN routing rules table gives me the data bits I need for that decision. I only noted DDI info when I needed to do something with the pattern or if I was sending the call to a fictitious ITSP (or gatekeeper).

Task Tracking (aka Master Blaster)

We all need a master task list. Something that organizes our tasks in accordance with our strategy. I found that I really liked the tables I saw Matthew Berry and Kevin Wallace provide as examples. I consolidated a few things but the elements are basically the same. 

The quick tour, just in case you haven't seen this table (or something like it) before. While you are reading through your exam, you will have questions with specific IDs. Your goal is to quickly read through a question and identify what applications or hosts you need to touch to address the requirements of the question. Then you note the question ID in the appropriate table cell. 

My table is very similar to examples I have seen floating around. I added a little "DP" section under CUCM. This is primarily done to facilitate a more efficient dial plan configuration because DP requirements can be made outside of the call routing section. I also noted media resource management (MRM) configs in the CUCM section. I used this during my base configuration of the CUCM. We'll talk about that later.


At this point, this is getting quite lengthy and I am going to stop here. I do want to cover the strategy I used for executing tasks but that will have to be in a separate installment. Thanks for reading and hopefully this information has been somewhat useful.

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

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


  1. Mr. Guerrilla,

    I have read a couple of these blogs, and have to say this one has helped me the most. Your txt file of IP/phone/vlan info is something I am going to begin using, and I think I may try flipping the route plan 90 degrees as you did.

    My first attempt was really getting to know the testing environment, and losing a bunch of time learning my way around the handcuffs they use on the workstation. Knowing what I know now, and after reading this strategy entry, boosts my confidence for the next attempt.

    Thanks for all the time you are putting into this and keep up the good work!

    Nick Pappas

  2. Nick,

    Thanks for the feedback, it means a lot and I am glad if my sharing helps. I have plenty of notes I want to work into this blog, so stay tuned!

    Thanks again for reading!

    -Bill (@ucguerrilla)

  3. Thank you your blog has been a great help. I have shared this link with my friends also who are preparing for CCIE-V. I will be looking forward to more posts from you. Thanks again.

  4. Bill,
    Like your blog entries. Any chance of publishing the full "base.txt" file? If there are any exam related values, you can replace with generic section. Example. DHCP Scope is thru 50, can be replaced by DHCP Scope for Site D.