One major improvement UCM 7.x offers over CCM 4.x is the ability to route local calls in a far more efficient manner. If you are familiar with CCM 4.x you will know about the duplicate configuration that is required to route a local call to a local gateway. Take for example a two site environment- San Jose and Boston. Each site will no doubt be expected to dial Emergency Services and Local calls as well as a whole host of other types of calls which we are not interested in at this moment. The configuration required to achieve this is as follows:

(1)    Add a gateway into the CallManager database for each site. Let’s call them SJC-GW and BOS-GW.
(2)    Add a Route Group at each site containing the appropriate local gateway. Let’s call them SJC-RG and BOS-RG
(3)    Add a Route List at each site containing the appropriate Route Group. Let’s call them SJC-RL and BOS-RL.
(4)    Add a partition for each site called PT-SJC and PT-BOS.
(5)    Add a CSS for each site called CSS-SJC and CSS-BOS each containing the appropriate partition created in step (4). Devices in San Jose and Boston would be assigned the appropriate CSS.
(6)    In the case of routing 911 calls, create two Route Patterns 911/PT-SJC and 911/PT-BOS. Each Route Pattern would point to the appropriate Route List.

So you get the picture- for site specific routing in CCM 4.x we duplicate all the configuration specific for call routing and use the Calling Search Space of the calling devices to determine which RP > RL > RG > GW to use. Now that is for two sites, imagine the inefficiency in the configuration with a much larger installation!

Now this brings me onto how UCM 7.x provides a smarter way to route calls. It’s called the “Local Route Group” feature that has been added and the benefit of it can really be felt by building on the example we have used above. The new configuration that has been added can be seen when you come to step (3) above. Rather that create two Route Lists each containing Route Groups that consist of the respective site’s gateways, we create a single Route List (called RL-LOCAL-GW) which contains a virtual Route Group (called Standard Route Group). The virtual Route Group consists of the Calling Device’s LOCAL gateway determined from the Calling side Device Pool. Take a look at the two new fields which allow the local gateway to be determined on a per call basis:

The screenshot above shows a new Route List being created. Rather than adding a user defined Route Group (there are two shown in the screenshot above- RG-BR1 and RG-HQ) we use the Standard Local Route Group.

The screenshot shown above shows the Device Pool settings for  site called BR1- and the Local Route Group being set as RG-BR1. Obviously each and every Device Pool would contain it’s own specific Route Group that is local for that particular site.

Let’s now compare the configuration necessary to achieve the same thing (routing 911 calls at both San Jose and Boston) as we detailed above:

(1)    Add a gateway into the CallManager database for each site. Let’s call them SJC-GW and BOS-GW.
(2)    Add a Route Group at each site containing the appropriate local gateway. Let’s call them SJC-RG and BOS-RG
(3)    Add a single Route List containing the Standard Local Route Group. Let’s call this RL-LOCAL-GW.
(4)    Add a partition called PT-911 (we could use the default <None> partition to simplify even more).
(5)    Add a CSS called CSS-911 containing the partition created in step (4). Devices in San Jose and Boston would be assigned this CSS.
(6)    Create a single Route Pattern 911/PT-911. Each Route Pattern would point to the Route List created earlier (RL-LOCAL-GW).

Hopefully you see the benefit of the Local Route Group feature- we have far less duplication taking place and the increased efficiency is even more obvious as the number of sites increase.

Tags: CCIE, local route group, standard route group, version 3, virtual route group, Voice

Voice v3 test takers, another lab is upon you. Lab 4A (Config Labs) and 4B (Troubleshooting Labs) are completed and uploaded to IPexpert.com. Also other previous labs have been updated and enhanced, so download them again to be sure you have the latest updates.

Check your IPexpert.com Members area under the ‘My eBooks’ section for the Workbook and Proctor Guide (detailed PDF solutions) and also under the ‘My Configs’ section for the router/switch text file solutions. The corresponding ‘Initial’ and ‘Final’ configs have also been loaded up into the Proctorlabs.com Voice v3 vRack UI as well – and are ready for your use.

Lab 5A and 5B are under way and should be available very shortly, so stay tuned!

Tags: 3.0 blueprint, CCIE Lab Workbook, version 3, Voice

… giving you more features that is! (Seriously – ask my wife if you think that statement isn’t true. She often asks me if I even have the ability to separate work from home life. Many props to Sarah for giving me up almost altogether these last two weeks!)

Well – we thought long and hard about it (well maybe not that long :)) and decided we hadn’t given you enough features long ago in our last ProctorLabs vRack upgrade. So we decided since it had been so long, we decided we that we just had to give you a few more. A few of these are nice if you just want to practice with these technologies and will most certainly be used in later labs of ours. One of these is a must have that honestly, I am not sure how we (or you) lived without until now.

We have always given you the ability to change your PSTN BR2 E1 from E1-PRI to E1-R2 CAS or back from E1-R2 CAS to  E1-PRI with these buttons pictured: 

But now we are giving you two new functions regarding the PSTN simulator (router): The ability to change your PSTN HQ T1 from T1-PRI to T1-CAS with FGD or back from T1-CAS to  T1-PRI with these buttons pictured: 

And also the ability to change your PSTN BR1 T1 from T1-PRI to T1-CAS with FGD-EANA or back from T1-CAS to  T1-PRI with these buttons pictured: 

And finally, saving the best for last, we are giving you the ability to throw your vRack’s BR1 site (and all of it’s devices/functions) into SRST mode. This might sound simple, and in the real lab you might simply shut down your BR1 Serial link and all would be grand. However, in our vRacks, your BR1 Serial link connects your BR1 router back to your HQ router and then back to your EzVPN (hardware or software) IP Phones, and so you can’t really just shut it down or else those phones can’t connect to the BR1 router and register in SCCP (or SIP now:)) to the Call-Manager-Fallback a.k.a. SRST. You also have the challenge that if the lab you are working on happens to have you configure the BR1 router as a MGCP gateway, or even if it has you register DSPs in the BR1 router using SCCP to the UCMs, that those devices need to “stop talking” to the UCMs in order to do any sort of fallback (such as MGCP Fallback to H323 mode thus releasing a PRI or CAS trunk). 

So what we have done is create a simple button to do all of this on your vRack web UI. Here it is:

One thing to note: All of these functions are only available for the new Voice v3 blueprint’d vRacks.

Now if you are one who has your own hardware, you of course can do all of this manually yourself in your own lab. However I do have to say to any of you considering whether to rent a vRack for your Voice studies or build your own rack, I remember back to when I was studying for my Voice exam, and had my own lab, and honestly how much time I wasted (no seriously – wasted) trying to not only get my lab setup in the first place, but then deal daily with getting servers reset, re-building PSTN files, dialplans, etc, etc, and how if I had something like the vRacks and the incredibly simple interface and between session automatic revert and extensive error checking logic that we offer at ProctorLabs, how much more time I would have had for actual studies that mattered. Oh well – I didn’t – but you do! Capitalize on it!

Also to note – on my last post regarding the vRack updates, in the comments section, one person asked about if a few new features were possible mainly regarding localizing PL rack rental timezone information based on where you are (or preferences chosen in your account settings) and also about if the “Load Lab Configs” function could give the ability to you to choose with a checkbox which devices to load or not to load on a given Initial or Final config. Well the simple answer to his question – I wanted to be a rather public one – and that is that ALL of this functionality and more is on the horizon. We haven’t even come close to showing you all of the Spades up our sleeve and ready to show the Straight Flush we have once the River card is played. (sorry couldn’t resist the Hold ‘Em reference) So be a little patient with us – we are continuing to develop in the background – I can assure you!

Cheers and Happy Labbing!

-Mark

Tags: CCIE, Proctorlabs, v3 blueprint, version 3, Voice, vRacks

By now most studying for the new blueprint of Voice and Security CCIE, have checked their IPexpert.com Members Area and found the most recent installment of the new Volume 1 materials. Remember to check both the Members My eBook Section for your Workbooks and Proctor Guides, and also the Members My Configs Section for your text based configuration files and diagrams.

I want to take a brief moment and describe to you the new format of both of these Tracks’ Workbooks. In fact it will be a very brief moment since little description is necessary, and common sense kicks in that this, of course, is the most logical way to do it. We re-arranged our chapters quite a bit from the old format. Basically it boils down to the fact that we now have one chapter (called labs of course) for every section that Cisco has in that track’s blueprint. So since the Security 3.0 Blueprint has 8 sections to it – so does our Security Volume 1 Workbook. Since the Voice 3.0 Blueprint has 13 sections to it – so does our Voice Volume 1 Workbook. This accomplishes a number of things. One is that you know that everything in the blueprint is covered in our workbook, merely by taking a look at the table of contents structure. Two it gives CCIE candidates a great way to go back and quickly identify, then proceed to study in remediation, any specific section that you may have, God forbid, actually gotten less than say around 80% when you sat the actual Lab Exam last. The third, and I personally think maybe the most important, is it gives us the ability to break each section out, not just by configuration techniques for every technology listed, but also by troubleshooting techniques for every technology. You see, if you happened to be fortunate enough to go to Cisco Live: Networkers last year in Orlando, then surely you heard some of the various Proctors and Content Managers talking quite a bit about troubleshooting and that while it had only been a small part of the lab previous to that time, how moving forward with the advent of the new blueprints it would become a much heavier focused on and tested topic. This makes good sense seeing that we have all heard of a few (not many, but a few) candidates out there who managed to learn the commands to configure everything and pass the lab, but didn’t have a thorough enough understanding of the technology to apply it in the real world. It also helps to cut down on the possibility of the previously mentioned candidates succeeding if they had been in fact cheating by possibly memorizing any of the actual test questions. In this fashion (as in the real world) the candidate has to really know well the technology to be able to not only configure it, but also troubleshoot problems that could have been introduced by the Proctor before the candidate sat down to take the actual lab exam (Bear in mind that I am not at all suggesting that the proctors might be causing problems during your lab exam, only that there will be existing erroneous configurations introduced before you sit down to the exam, and that you would most likely be given some general technology to expect to see them appear in). So that being said – both tracks of our new workbooks have every Lab section broken down into two sub-sections, A and B to reflect configuration and troubleshooting respectively.

Read Full Entry »

Tags: CCIE, hardware, Pods, Proctorlabs, Security, updates, v3 blueprint, version 3, Voice, vRacks

Thought I would drop everyone a note letting you know that I just finished the final draft of a BOM and sent it off to Cisco to procure all new hardware we will need for v3 of the new CCIE Security Blueprint. All 16 of ProctorLabs’ Security vRacks are due to receive new IPS 4240s and 3560s. We have already been running ISRs in all of our vRacks for many years now – so your experience doing a ‘wr’ or a ’sh run’ or a ‘reload’ has always and will continue to be a fast one, as well as up to date for what the new lab will test on. 

Some of you I have already talked to recently have stated that you are at the beginning of your studies for the lab and are therefore choosing to focus solely on the new v3 blueprint. For those of you in this category, you of course not only need the new hardware, but also need the ISR routers upgraded to 12.4(xx)T, your ASAs upgraded to v8.x, the ACS server upgraded to v4.1, and new VPN clients on the XP workstation. Stay tuned as we will very shortly (possibly as soon as next week) be announcing a clever way to dynamically upgrade your vRack’s software for this new blueprint based on what you tell us you are studying for.

So stay tuned!

Tags: blueprint, CCIE, ccie lab, CCIE Security, changes, Cisco, Mark Snow, Security, v3, version 3