Afew weeks ago, I made a blog post for those of you working towards your CCIE Collaboration certification. It covered how to configure a Cisco Unified Communications Manager Express (CUCME) router to register a SIP-speaking Cisco 9971 IP Phone. If you missed it, you can read it HERE.

This installment in my CCIE Collaboration Lab Lessons series is more strategic than technical. Specifically, it’s a strategy for how to approach your lab tasks. I’d heard a variation on this strategy a couple of times from different instructors as I was going through my studies. It was called the Device-Based Approach, and I’ve have modified it just a bit. That is what I want to share with you – the Modified Device-Based Approach.

First, let’s discuss what the Device-Based Approach says about tackling our tasks on lab day. If you go into the lab , open up your lab book, and say, “There’s task 1.1 – I’ll do that first. Then I am going to do Task 1.2. Then I will do Task 1.3, then 2.1, 2.2. . .,” then you’re taking a linear approach to the lab. If you take a linear approach, if you just do task after task after task, the theory is you’re being very inefficient, and I would agree with that. I think you are not being efficient with your time if that is how you approach your lab, and you are dramatically reducing your odds of passing. The main reason is, you’re having to jump back and forth between different pieces of equipment.

In order to complete a particular task, you might have to do something on a Cisco Catalyst Switch, and then suddenly, you’re jumping over to a router. Then, you’re jumping over to a Cisco Unified Communications Manager Server.  Then, maybe you’re jumping over to a Cisco Unity Express module.

All that jumping back and forth is not a good use of your time. This is something that I’ve been saying for years, but just recently, I read a book that debunked the myth of multitasking. That book (which I recommend as a must read) is, The One Thing – The Surprisingly Simple Truth Behind Extraordinary Results.

In the book, the authors talk about how inefficient multitasking (i.e. attempting to simultaneously work on independent tasks) can be. The reason they say it’s inefficient is, when you leave one task to go to another task, there is a switchover time. And then when you get to that next task, you have to reorient yourself as to, “what’s going on here?” Then, when you want to go back to your original task, you have to switch over to that original task, and then reorient yourself again.

Think about this on the CCIE Collaboration Lab. Perhaps you’re doing something on a router, and you need to go do something on a Cisco Unified Communications Manager Server at that site. To do that, you might have to minimize your terminal window, and then you open up your browser. You might then have to log back into your Cisco Unified Communications Manager server. You ask yourself, “Alright, what was I doing here? I think I’ve already done this, and now I need to do this other thing.” You do the task, and now you want to go back to your original device; so you minimize the browser. You open up the terminal window, and once again, you reorient yourself, asking, “What was I doing on this device?”

This switchover time and the reorientation time is wasted time. It’s time that you don’t have to spare in the lab. Remember, time is your most valuable resource on the lab. You want to use it wisely. So, what can the Device-Based Approach do for you?

With the Device-Based Approach, you’re going to take some scratch paper that they give you at the beginning of the day, and you’re going to make a table. This table is going to be broken down into different blocks. You’re going to have a block for every device that we’ll be configuring. You can check out an example of such a table here:

You’re going to have a block for your Cisco Catalyst switch. You are going to have a block for each of your routers. You’re going to have a block for your Cisco Unified Communication Manager servers. You are going to have a block for Cisco Unity Connection. There will be a block for Cisco Unity Express. There will be a block for Cisco Unified Contact Center Express. Also, you’ll need a block for the Cisco IM and Presence server.

Then, as you are quickly skimming through your lab tasks, based on your experience, based on all the time you’ve put in studying, you’re going to be able to look at a task and realize that part of the task has to be done on this switch; part of the task has to be done on this router; or maybe part of the task has to be done on a Cisco Unified Communications Manager server.

What you’re going to do on this table that you’ve made is jot down in each box what tasks need to be performed on the device represented by the box. For example, let’s say that Task 1.1 was Configuring VLANs (e.g. setting up the IP address spaces and VLAN numbers for your Voice and Data VLANs).

Well, where do you have to perform that? You’ve got to do it on your switch. You’ve got to do it on your routers, remembering that some of your routers might have EtherSwitch modules in them. So, what I would do, for example, is jot down in that switch block on my table, Task 1.1 – VLANs. And I would write that down for each of my routers. That way, when I got to that particular device to configure it, I realize I’m going to do something with Task 1.1, dealing with VLANs.

Just as an example, let’s say I’ve got Task 1.1 VLANs that has to be performed on my Cisco Catalyst switch.  And then later in the lab, let’s say I’ve got Task 7.1, and that deals with the quality of service (QoS) configuration on that Cisco Catalyst switch. I also write that down in the box. Here is an example of a completed task table:

Let’s just imagine that those are the only two tasks where I have to be touching the Cisco Catalyst switch. What if I did both tasks without ever leaving that switch? That way, I’m 30 minutes into my day. I have skimmed through the entire lab. I’ve mapped out my game plan for the day, and I’ve done everything that I have to do on that switch. I don’t have to go back and touch it for the rest of the day. Then, I move on to the next device and do everything on the Headquarters Router, for example. Then, I move on to the next device and the next, until I’ve crossed off all tasks under all devices in the chart.

Now obviously, you don’t want to start out your study using this approach, because you want to understand everything involved with completing a specific task. If you are asked to set up a hardware conferencing resource, I want you to understand that part of that has to be done on the router, and part of that has to be done on the Cisco Unified Communications Manager server.

But after you’ve gone through your practice labs a couple of times, I invite you to try this out. Try out the Device-Based Approach, where you’re going to go to each device and do everything on that device before moving to the next device.

But I said I was using a Modified Device-Based Approach. Here’s what I mean by Modified. I suggest that there are going to be some exceptions to the rule of doing everything on a device before moving on to the next device. For example, if I’m setting up an MGCP Gateway, my personal preference for setting that up is to use the auto-configuration approach to download an initial MGCP configuration from a Communications Manager server, and then break the tie that binds it to the Communications Manager, so that I can do subsequent configuration locally on the router.

In order to do that, I have to have the MGCP gateway defined on my Communications Manager server before the router can pull down its configuration. As a result, when I get to router BR2, for example, if I’ve not yet configured the gateway on the Communications Manager server, I’ll make a note saying that I need to wait on this task until later.

Another modification that I might make to the Device-Based Approach is when I’m setting up something that is really complex on a router, which might involve entering lots of commands (e.g. setting up a DSP resource). If you’ve ever set up a transcoder or a conference bridge or an MTP resource on a router, you realize there are several required commands. Maybe, in your initial read through of the lab, you discovered that you’ve got to set up a conferencing resource on one router, and you need to set up a transcoding resource on another router.

What I suggest is you open up Microsoft Notepad, which is available to you on the lab, and type out the DSP Farm configuration for one of the routers (maybe the conferencing router). Then, make a copy of that configuration. Copy and paste it into another Notepad document, and modify the configuration such that it’s now a transcoding configuration, allowing you to paste these fairly complex DSP configurations from your Notepad documents into your router configurations. When you’re in the mindset of setting up your DSP resources, why not leverage that focus you have in the moment to do both configurations?

One other modification I like to make to the Device-Based Approach is I want to always be doing something. For example, if I’m rebooting a Cisco Unity Express module, because I just reset it to factory default settings, it’s going to take about three to five minutes to reboot. I don’t want to just sit there and wait and rest during that reboot time. I want to be actively doing something else.

However, that something else should not be overly mentally taxing. You’re focused on your Unity Expressed (CUE) module. Let’s not get bogged down in setting up a bunch of voice translation rules at this time.  Fortunately, there are some things that I do every single time I go through one of my practice labs. I remove DNS reliance from my Communication Manager servers. I give specific Service Parameter settings and specific Enterprise Parameter settings. I suggest that while the CUE module is rebooting, you can go do some of those repetitive tasks that you don’t have to think much about. That way, you’re not wasting time during the reboot.

And that’s a look at my Modified Device-Based Approach. If you were to ask me, “Kevin, what is the best piece of advice you could give me for tackling the CCIE Collaboration Lab?” It would be this. It would be, master the Modified Device-Based Approach.

As mentioned earlier, I’m doing a full-blown CCIE Collaboration self-study video course (due out in November of 2015), where I’ll walk you through an entire mock lab that I have created. You’ll see exactly how you can tackle lab day, what steps you take, and in what sequence you do those steps.

As always, you can check my current collection of video training at: kwtrain.com/products

In fact, I just recently released the CompTIA Network+ Complete Video Course. So, if you or a co-worker is interested in getting your CompTIA Network+ certification, you might want to check that out HERE. It’s about 17 and a half hours of video training that I do, showing you everything you need to be successful on the CompTIA Network+ exam.

However, if the CCIE Collaboration Lab is in your future, I certainly hope that this blog posting has been valuable to you. Also, be on the lookout for more CCIE Collaboration Lab topics coming over the next few weeks.

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:

iTunes: http://kwtrain.com/podcast

RSS: http://kwtrain.com/rss