Thursday, May 2, 2013

CCIE Voice Lab Strategy Part 3 - Planning and Starting the Configuration

This is the third installment of a blog series on my CCIE Voice lab strategy. Part 1: Formulating a Strategy provided some information on strategies I came across when I started down the CCIE trail. These strategies helped me formulate my own specific approach. In Part 2: The Read Through, I went through the "boot strap" process (if you will) of my lab approach. In this third installment, I will begin a walk through of my approach to the lab.  


The Task List

In the last entry I introduced one of the tables I build when doing the lab. I used this table for every lab, whether it was a self-study session in the wee hours of the morning or a real lab attempt. A sample table is provided below:





The above table is commonly associated with the "Device Based Approach", which is discussed in Part 1 of this series: Formulating a Strategy. As was mentioned in Part 2: The Read Through, when building this task list the goal is to make sure you quickly and accurately associate a task to the right host/application. I used labels for the tasks that were meaningful and quick to jot down. For example, "ntp-bb" means NTP to the Backbone, "dhcp-ucm" means use IP Helper, "dhcp" (sans UCM) means use local IOS dhcp, "dhcp-s1" means use static address assignment type 1 (multiple scopes), "dhcp-s2" means use static address assignment type 2 (origin file). FYI, the "type" designation is a Bill-thing not a Cisco-thing. 

Anyway, I think it is a good idea to develop a sort of "shorthand" for your task table and for other note taking devices you use during the read through. You should also have a "base" or "default" config in your mind for most configuration scenarios. Use your shorthand to identify variations from your default config. 

For the rest of this installment, I am going to start a walk through of how I like to execute tasks and my decision making process. Not because I feel I have the magic formula (I don't believe there is such a thing) but because I hope that by explaining my thought process I can help readers get in touch with their own strategy.

Have a Plan of Attack

The aforementioned table is built on paper while you are doing your read through. So, you are placing tasks in cells as you come across them. This shouldn't necessarily dictate the order you execute things. Instead, your strategy should dictate your plan of attack. 

While it would be nice to take the time re-organize your table to fit your attack plan, you won't have time for that. If you are so inclined, you could look at customizing a table that suits your particular needs. I went through the process of tweaking the table and trying different configurations. I quickly concluded that it was easier to stick with a simple table structure and just mentally organize tasks. 

Strategic Objectives

So, your table holds the task list organized by device and your strategy is going to help you decide order of execution. In my personal approach to this exam, my strategy was comprised of the following objectives. 
  1. Ensure that your read through is efficient and captures key data. I spent a lot of time on my read through (average 45 minutes). I tried different approaches to shorten this time element but I eventually determined that 45 minutes worked for my approach.
    • Capture key infrastructure data so you can copy/paste things like IP addresses
    • Capture user/phone data so that you can provision phones and users in one go
    • Capture PSTN requirements for the purposes of configure H323/SRST dial-plans without having to re-read instructions
    • Capture an abbreviated version of the dial plan
  2. Provision end users and phones so you don't need to go into those config pages more than once.
  3. Have all devices (phones, gateways, media resources) fully provisioned and registered before lunch.
  4. Touch CUE early and often. Whether the integration is CUCM-CUE or CME-CUE, ensure that the final reboot is completed before lunch.
  5. Manage key transitions efficiently, organize your plan to optimize your rhythm and avoid stalls.
  6. Perform in-line validation where it makes sense. "In-line" validation means that I paused configuration and executed some validation tests. For me, I used in-line validation for the following:
    • Basic dial plan (ingress/egress) NOT AAR, SNR, MVA, failover, etc.
    • SRST and associated features like CFUR and VM integration during failover (test SRST once and only once)
    • WAN QoS (test phone registration, cRTP, full-duplex audio, etc.)
  7. Target completing all configuration tasks in 6 or 6.5 hours and have a structured validation routine. Execute the validation quickly. Focus on "high value" targets first. Try to leave time to do a question-by-question walk through. 

Base Infrastructure Tasks

Following my read through, I start directly in on executing my Base Infrastructure Tasks. While Infrastructure from the blue print perspective encompasses things like NTP, DHCP, etc. I also lump other IOS device configurations into this category. The following image highlights the configuration tasks I lump into Base Infrastructure.



This is a healthy set of tasks and will eat up a decent chunk of time. Fortunately, this is all CLI work and you can really optimize for speed here. You will need to look at your question guide as you go. For some tasks, I found that my annotations were enough to drive the configuration (i.e. I didn't need to look at the question a second time). For other tasks, I needed to revisit the question to make sure I addressed all of the requirements.

CLI Configurations and Notepad

Probably the best advice I can give concerning configuration on any CLI-based device is to use notepad. I built all of my configurations in notepad and then pasted them into the devices. This methodology saved a LOT of time. Your goal should be to pump out commands without looking at context sensitive help. In fact, I came to the conclusion that typing commands directly into the CLI was a handicap. When you have the ability to hit the tab key to complete commands, you tend to do it. Like a bad habit. All those tabs are extra key strokes and extra key strokes means extra time. Silly? I don't think so, shaving minutes where you can adds up.

Settling on using notepad to build your configurations is a good study tool, too. When you are practicing for the lab, you can do "configuration drills" in notepad. You don't need a gateway or switch. I used Evernote to build a list of drills where I took questions from my IPExpert workbooks, forums, my study group, and stuff I just made up. Then I would build configs in notepad. Later on I may paste the configs into a device to check myself. About 7 months into studying, I didn't need to check configs. So, I just focused on speed. 

The benefits of practicing with notepad carry over into a real lab attempt. You can type out a config without the annoying CLI responses (like when ports are added to vlans or when CUE pitches a fit about its new found IP address). You can also see your entire config before pasting it into a device, which is a form of validation. Finally, you can copy/paste "like" configs between notepads. Reducing overall typing time.


Delayed Tasks

There are a few CLI configuration that I would build out in notepad but would wait before applying them to the device. One such config task is MGCP. I used "ccm-manager config" for all MGCP gateways. Which meant that I had to wait until I configured the MGCP device in CUCM before I customized the IOS configuration. I would also ALWAYS remove the "ccm-manager config" commands after the initial provisioning. This was true whether the PRI was a full T1/E1 or not. 

I also delayed tasks like applying SRST configurations. I would start building out the SRST configuration in notepad. I wouldn't apply configs until after all of the phones were provisioned in CUCM. For more complex SRST configurations, I may start other tasks and do the config in parallel. It really depended on what the proctor gave me. 

Obviously, I delayed all troubleshooting tasks until I had a more complete system-wide configuration set. No sense in troubleshooting MGCP, H323, etc. until I have the gateways configured in CUCM and phones that can be used for the purpose of completing the task. 


Shoot and Scoot

It is critical that you move quickly through the Base Infrastructure phase of your action plan. This phase gives you the opportunity to relax and get into a good rhythm. It is possible that you will hit a task you are unfamiliar with or perhaps you will hit a task that is complicated or "tricky". If this happens to you, stay calm. Stay calm and don't linger on the question too long. 

My LAN QoS approach provides a decent example of how I would handle this situation. I would read the LAN QoS question and if I thought it could be executed in less than 5 minutes I would do it as part of the base infrastructure configuration. Otherwise, I would flag it with a "(w)" which meant to wait until I did WAN QoS. 

If you hit a question that is going to slow you down in the first 2-3 hours of the exam then flag it for later. Don't mess up your rhythm out of the gate. You eventually have to do everything and if you are well prepared for this exam then you will have time to go back. 


Managing Transition

After configuring the Base Infrastructure you need to transition to configuring the CUCM. This transition was a tough one for me because it disrupted my rhythm. There is really no way around the "problem". For the first hour or so you are banging away in notepad (or the CLI) and then you go to a clunky GUI. Bleh! What I did was manage the transition by multi-tasking. The transition started when I hit the CUE module.


In the Base Infrastructure config phase I tackle the gateway with the CUE module (Branch 2 in our example) last. I configure the IP address info for CUE and then session into the module. I decide, based on the current CUE state, whether I need to reset the module. I won't spell out all of the variants here (maybe in another blog entry, but not here). Suffice it to say I start the CUE tango. Which is a process that involves doing a handful of things and coming back 10 - 15 minutes later to do more things, then repeat one or more times.

While CUE is doing its thing, I start preparing for some multi-tasking. I point my candidate PC's web browser to CUCM's platform portal (OS). I also RDP into the UCCX server, login, and load IE. I already have console connections to all of the infrastructure gear and my config notepads. I actually arranged windows in a specific way that facilitated my workflow.

As I transition to the CUCM configuration phase, I am focusing on the following tasks:

  • NTP for CUCM
  • SRST configs (in notepad)
  • Watching CUE and pushing it along when the module is ready for input
  • Provisioning CUCM service and enterprise parameters

This transition usually concluded with auto registering phones. After that point I could focus my attention on provisioning my base CUCM configuration. Stacking my tasks for the transition from the Base Infrastructure to the Base CUCM was one of the more interesting personal break throughs during my exam prep. 

Others may think I am over-emphasizing this and maybe that is true. All I know for sure is that  when I focused solely on speed, I wasn't finishing the self-study labs as quickly as I thought I should. When I changed my focus to organizing tasks so I had a fluid rhythm and made speed a secondary thought, I could finish labs quicker. Moreover, I also found that I could adapt to different labs and have more consistent results (in terms of execution time). 

I think this is enough writing for now. I'll continue with the Base CUCM configuration phase in the next installment.  Thanks for reading!

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 comment:

  1. Very good article Will. I failed my first attempt and I am in the process of coming up with a strategy to tackle the lab. Your 3 blogs really helped to think seriously about the strategy and tactics for the lab.
    Rahm

    ReplyDelete