Introduction
The CCIE Voice lab is unique in the sense that it requires you to configure diverse number of applications sharing little in common with each other. For example, you will have to use GUI to configure Call Manager and CLI to configure SRST. On top of that, it’s hard to break the Voice lab into “core” and “non-core” parts, since you are required to configure a lot of different things (e.g. register phones, add gateways, set up dial-plan, configure dial-peers) in order to place an end-to-end call and test “connectivity”. All that makes the Voice lab tougher than any other CCIE lab.Lab Strategy Overview
Generally, we can subdivide strategy into the following sections:I) Order of Operations. The way you want to follow through configuring the lab. Almost certainly you dont want to configure tasks in linear, sequential fashion, as it is not the fastest way possible. Speed is number one priority in any CCIE exam, and it’s especially vital in the Voice lab.
II) Time Management. The thing you definitely need to control is the amount of time you spend on each task. While this part seems so obvious, most people cant resist the urge to troubleshoot one single task for “another five minutes”. “Don’t get stuck!” should be your motto here.
III) Stress Management. Huge stress is what differentiates the real lab exam from any practice lab you’ve done. Remember, stress is your enemy and your friend at the same time – it boosts your strengths and concentration but makes you flaky. Take in account the impact of stress on your accuracy and speed.
IV) Dealing with wildcard scenarios. You cant possible learn all the voice technologies out there. So there is still a chance you can meet something scary and unfamiliar (or simply badly worded) in your real lab. Or maybe, you would face a rack or initial configuration issue. All this has to deal a lot with sections (II) and (III) of the strategy, but you should be prepared to meet the unexpected. Never panic, and try to isolate the wildcard situation as soon as possible.
V) Verifications. Many people believe they dont need a verification plan, as the verification ideas will come out by themselves. Basically if they see something working, they become assured it would last till the end of the exam. Do not make this mistake, and develop a thorough verification plan for your solutions, as stress and time can play bad jokes with you.
Lab Exam Topics Outline.
Before coming up with an order of operations, let’s make a short outline of the current (2008) CCIE Voice lab exam:I) Infrastructure. Voice & Data VLANs, switchports. DHCP for IP address allocation, NTP for time synchronization. Other advanced tasks, pertaining to switching infrastructure (e.g. DHCP snooping).
II) Station Devices. Register ephones with CME and assign extensions. Auto-register IP and Analog endpoints with the CallManager and assign extension numbers. Phones Presentation settings (display layout, softkeys, buttons, calling number masks). Users and Directory Services.
III) Gateways & Trunks. Configure ISDN PRI settings in the routers. Register MGCP gateways (analog/digital PRI backhaul). H.323 gateways and Gatekeeper. Gatekeeper registration. SIP Trunk and IP to IP gateway.
IV) Call Routing. Plan the dialing patterns and Classes of Restriction. Create Partitions and CSSes in the CallManager, Route Groups and Route Lists. Call Hunting Constructs in CCM and CME.
V) CAC & Codecs. Regions, Locations, Gatekeeper admission, dial-peer settings, voice-class, CCM global codec settings, DTMF-relay.
VI) Media Resources. Registering NM-HDV/NM-HDV2/6608 with the CallManager. Transcoders and Conference Bridges. Software Media Resources. Music on Hold Servers, Multicast Music on Hold. Media Resource Groups and Lists, order of allocation.
VII) Applications & Services. Call Forward/Transfer, Park/Pickup/Extended Functions. Cisco IP Phone Services. IPMA (Proxy/Shared), Attendant Console, Extension Mobility. B-ACD for CME.
VIII) High Availability. AAR and SRST. HSRP/VRRP (advanced topics). Call Backup.
IX) QoS. FRTS (legacy/MQC) and CBWFQ. Link Efficiency: FRF.12 and MLPPPoFR, cRTP. LAN QoS: Classification/Policing and Marking. WRR and PQ. Marking in the gateways (IOS, ATA, VG248).
X) Voice Mail. Unity integration with CCM/CME via SCCP. CUE Integration with CME via SIP. Unity Subscribers, CallHandler, CallRouting, Schedule, Recording. CUE Groups and Subscribers, AvT. Redirecting Calls to a Voicemail system.
XI) CRS. Integration with CCM. ICD Script customization, CRS Editor.
Order of Operations
The most import part of you plan – essentially this is the core of your strategy.Step 1: Planning (20 – 25 mins)
It’s the beginning of your lab exam. You are probably all excited and nervous, and open your lab workbook. Take a couple of deep breaths and locate the lab diagrams. You will probably have a topology diagram and supplementary drawings/tables describing your connectivity and PSTN/WAN settings. Redraw the major diagram real quick – you will enhance your drawings as you read through the lab after that. Also, drawing will probably calm you down a little bit. Next start with reading through the whole lab. You heard that before, now it’s time to hear it again
Do not underestimate the importance of reading the lab as a whole. This will give you all the connections between the tasks, and probably insights on possible issues. As you read through the lab, locate the following information and put it on your diagram: Extension Numbers, Site DID patterns, WAN settings (CIRs, port speeds), IP addressing (servers, loopbacks, voice vlan subnets). Dont spend too much time on the Call Routing/Dialplan sections for the CallManager, and don’t stick with analyzing advanced Call Routing tasks like call backup, TEHO etc. However, locate the dialing pattern for CallManager Express and SRST systems (if you have them in your lab). Spot whether you will need a gatekeeper in your configuration, and whether it’s a backbone device you your internal pod router.
Using “show cdp neighbor” command verify that you see all your IP Phones. Record the last four digits of each MAC address and draw it next to the respective phone on your diagram. At the same time, perform a quick connectivity test to ensure your equipment is set up properly, and you can reach the CallManager and Unity servers.
As you finished with reading over, unbind the paper sheets, and re-arrange them in the order you find comfortable.
Step 2: IOS and CLI configurations (1,5 – 2 hours)
This is the part where you configure all IOS-relevant applications, starting with infrastructure and finishing with CME/CUE and SRST (if needed). As much as you can, try to type all your configurations in notepad first and than paste into command line. This requires a lot of practice, but it really worth it. Remember to use consistent names: I recommend using all uppercase separated by underscores like “class-map VOICE_BEARER”.Infrastructure
Start with configure VLANs and switchports, DHCP servers (IOS/Windows) and NTP. Ensure all devices obtain IP addresses (check the DHCP bindings) and are pingable (A small side-step will be required to configure Windows DHCP server, but it’s OK). Set up NTP if required, and synchronize the CallManager time if they ask for that. Ensure your time is synchronized. If you get some small issues like devices not getting IP addresses, don’t spend more than 5 minutes trying to troubleshoot it. Take note if it fails, and go on.
Multicast & QoS
Configure multicast routing if needed for multicast MoH later. Verify multicasting by joining groups on routers and pinging end-to-end. Configure FRTS and CBWFQ in routers per the requirement of your QoS section. If you have LAN QoS requirements, apply the most basic configs here (trusting, basic CoS->DSCP remarking) but don’t spend a lot of time coping, editing and pasting long crazy QoS configurations from the DocCD here. You can do that later in the exam if you have enough time, and your goal right now is speed. If you really hate LAN QoS, just disable “mls qos” and move on here. It wont probably cost you many points, but will win you a lot of time and nerves.
CallManager Express and CUE
You first big task. Set up CallManager Express phones – register them and configure buttons/layout/call-forwarding/transferring. Set up all necessary telephony-service settings here (dialplan-pattern if needed, time-zone, etc) . Set up the basic dial-plan to reach PSTN destinations. Call between PSTN phone and CME Phones to validate your configuration. If you have any other tasks in your lab pertaining CME (like B-ACD, call-hunting, local-directory etc) do them all here.
If required by the lab, reset the CUE module, and perform integration with the CallManager Express system. Don’t forget to enable HTTP server in the CME and perform the CUE web-init dialog. Create subscribers and complete advanced CUE tasks. Take care if they ask you to route VoIP calls to CUE, as you will need the transcoder registered with the CME.
SRST, PVDMs, Gatekeeper and MGCP PRI backhaul
If required by your scenario, configure all MGCP PRI backhaul in IOS routers right now. Although you will configure gateways in the CallManager later, it makes sense to complete all IOS stuff right now. Configure NM-HDV to register with the CallManager if your scenario requires this as well.
If you they ask you to do SRST, configure the respective router. Set up everything, including the dialplan and incoming calls handling for SRST. Verify SRST to CME calling by using “csim start” command in SRST and “debug isdn q931” command in both CME and SRST systems.
If you need to set up a gatekeeper in a routers inside your pod, and/or register with a backbone gatekeeper, do it now as well. If needed, register CME system with the gatekeeper too. Use “debug h225 asn1” for advanced debugging.
When you’re done with Step 2, you should have almost all IOS parts configured. Endpoints obtained IP addresses, switches impose marking, CME/CUE integration works and you should be able to test basic calling. By now you probably have 30mins-1hour gap before the lunch break.
Step 3: CallManager Setup (1 hour)
Follow the Top-Down, Left-to-Right approach with the CallManager set up.System Settings
You should already know your time-zone, presentation settings, regions, locations and device pool requirements. Start by configuring the CCM servers, replacing names with IP addresses everywhere, adding regions, AAR groups, locations (if required). Always rename the default entities (like default Date/Time Group, default Device pool) and re-use them. Try to stick with consistent naming scheme mentioned above. For example, use “DP_HQ, DP_BR1” names for device pools, “REG_HQ”, “REG_BR1” for regions, “LOC_HQ” for locations etc. Make the names self-explaining and keep the number of device pools minimal. As you’ve done with “System” settings, start the CallManager services, if they are not started already. Ensure you don’t start unnecessary services, like IPMA/EM, if they are not mentioned in your scenario. Less services means less worries!
Media Resources
As you finished with basic system settings, proceed to media resources configuration. Configure the software media resources first. Ensure you set the proper codec’s for MoH and assigned a location/device pool to MoH servers. You may need a separate device pool for MoH servers to control codec’s precisely. Set up Multicast MoH settings in servers and sources. Ensure you have Annunciators and MTPs running on both servers. As you’ve finished with the Software Resources, proceed to transcoders and conference bridge registration. Add the respective devices that you probably already configured in the IOS systems. Complete your Media Resources configuration by creating MRGs and MRGLs and assigning the latter to device pools created before.
Gateways and Trunks
Before you start this section, create a partition for all internal extensions (e.g. “PT_INTERNAL”) and a default CSS for each site. Default CSS is the one which will be mostly used by your respective site internal devices. Give it a name like (“CSS_HQ_DEFAULT” or “CSS_BR1_DEFAULT”). Now proceed with creating gateways in the CallManager (H.323, MGCP, SIP). Assign a proper device pool, incoming CSS and other settings per your PSTN requirements. If you have a gatekeeper in your scenario, add a gatekeeper to the CallManager and create a Gatekeeper-controlled Trunk. Ensure the CallManager registers with the Gatekeeper.
Station Devices & Users
If needed, create new softkey template and button template before you start with the phones. Then, perform auto-registration for all IP and Analog Endpoints. This is probably the most time-consuming section, which requires a lot of accuracy. Pickup up the default CSS, Partition and External Phone Number Mask for auto-registration carefully, to minimize the number of changes later. Ensure all your endpoints registered (you may need to lift handsets on the VG248 devices or switch it to manual enable mode). List all the phones registered with the CallManager and configure them all, starting with VG248 and ATA186 phones, since they are easy to spot on the screen. For all other phones, use your diagram with the last 4 digits of the MAC addresses to spot the phones. Don’t forget to set up Display ID, External Phone Number Mask, AAR Group, AAR CSS, Softkey/Button template, Directory Number, etc. As you’ve done, check the phones layout and try calling between phones real quick.
After that, create users in Global Directory (if needed) and associate them as required per your lab scenario. To finish with basic verifications, call internal phones from the PSTN phone. Do not attempt to configure any advanced CallManager applications here
Step 4: Unity Integration (20 – 30 minutes)
Set up Unity side first and then run the integration wizard in the CallManager. Ensure you can reach the Unity General Greeting. Take in account possible AAR requirements when configuring integration, as you should have AAR groups created already. Account for any subscribers calling from the PSTN. Create Subscribers (disable self-enrollment dialog, set simple password etc) per the requirements of your lab. Ensure you can send and receive messages, and MWI is working. Since Unity is usually simple, complete all other Unity tasks here as well (CallHandlers, Live Recording etc).Step 5: CallManager Applications (20 – 30 minutes)
Configure IPMA, EM, AC and other CallManager application here, if required by your lab scenario. Remember you should start any advanced configuration only after you’ve done with all the basic configurations. Test your applications and assess the current situation. If you feel like you have enough time, proceed to IPCC Express Integration and script customization. If not, skip directly to Call Routing section.Step 6: CRS/IPCCX (20 – 30 minutes)
IPCCX is not a big part of the lab exam, but it requires considerable amount of time to complete and verify. So start working on this part only if you are feeling sure about yourself and want to earn some “hard” points. Integrate IPCCX with the CallManager and verify the default script. You may want to configure IPPA single-sign on to ease the verification process. Skip the script part if you don’t know how to do it, just complete and verify that your integration is “IN_SERVICE”.Step 7: Call Routing (40 minutes – 1 hour)
This is probably the next (after Auto-Registration) most time consuming part of the lab. To accomplish it, read the Call Routing section of the lab scenario now. Outline the dialing patterns, classes of restriction and corresponding partitions and Calling Search Spaces. Use consistent and self-explaining names like “PT_HQ_PSTN_DEFAULT”, “PT_BR1_PSTN_RESTRICTED” and “CSS_HQ_PREMIUM” to outline the classes of restriction used in your scenario. It’s useful to type all patterns and corresponding partitions in the notepad first, to get better understanding of the Call Routing. Take special care with respect to presentation settings (CLIDs, Calling Names) and other additional requirements.Create route groups for all your gateways (e.g. “RG_HQ”, “RG_BR1” etc) and a route-list for each type of call-routing behavior. Again, stick with names which make sense, like “RL_HQ_INTL_GW_HQ_BAK_GW_BR1” – attempt an international call from HQ using the local gateway and using BR1 gateway as a backup. Create all your route-lists first, and design DDIs as required per your scenario. Prefer to implement DDIs inside Route Lists and not at pattern level.
Next, create the additional partitions required and start adding dialing patterns one by one. As you add each pattern, use “debug isdn q931” where possible to trace the paths your call is taking. Call the PSTN phone or any other site’s phone as appropriate to verify each pattern. Start with basic dialing (e.g. 911, Local calls) and end with more complex routing rules like TEHO and calls across the gatekeeper. Be very accurate with each pattern, since it doesn’t take much to make a mistake here. This is why it’s crucial to verify every piece while you progress.
You may also need to implement additional dialing rules in the IOS routers (e.g. in the CME system). Use the same step-by-step approach and verify every a new pattern as soon as you configure it.
Verifications
You should be able to finish your lab in 5-6 hours and have about 2 hours to verify everything you’ve done. Now for verification part, you need to check the followinga) SRST & AAR
b) PSTN Phone can Call everyone
c) Every Phone adheres to it’s class of restriction
d) Calls between sites work
e) Voice Mail works (Unity and CUE)
f) Applications work (e.g. IPMA/EM, B-ACD etc)
g) Media Resources Work (MoH, Transcoding, Conferencing)
h) QoS Marking and Enforcement
i) Time synchronization and other infrastructure stuff
k) Redundancy: CCM Subscriber disabled, everything falls to the Publisher
Remember, it’s vital to have a clear verification plan in mind, as well as practice it during your preparations. As you progress with verifications, mark each section of the lab as “verified”. It never hurts to do verification twice, but be careful and don’t do any drastic changes to your configurations even if you think this should fix the situation. Always apply small changes – one change at time.
Stress Management
There is a lot of things to say about stress management. The idea is: there is no easy way to defeat stress and anxiety in the day of your lab, unless you are prepared to face the stress. Build your stress tolerance through the whole process of preparations. Observe strict day regiment, go to bed and wake up at the same time every day. Try not to work at nights, as this way is against your body physiology. Don’t forget regular physical exercises – if you cant afford everyday trainings, at least try to make short breaks during your work and get a walk around. Eat healthy food and avoid cold drinks and food that is hard to digest. All those things are plainly about physiology and body functions, but you’ll be surprised to see how much does it help. If feel like it, learn any meditation or relaxation technique (usually breathing exercises) – it really helps to deal with sleep issues and helps you combating anxiety. And last, but probably most important advice (quite obvious too) – the best thing to reduce stress in the day of the lab is to be well prepared..The day before your lab, try to forget all your worries and relax. Get a life, walk around have fun – don’t think about your exam, just try to spend a good day. Try to walk a lot, to make your body physically tired. Do not take any sleeping pills the day before your lab, as they can affect you alertness the next day. This is the last day before your exam – there is nothing you can do to improve your skills now. You should have had plenty of time to do that in ahead
The day of the lab, try no to overload yourself with caffeine. It’s OK as long as you keep the amount reasonable, but can make you jittery if consumed in large amounts. Also, during the lunch, try to relax as much as possible and eat some warm, liquid food – it generally makes you feel energized.
Time Management
It’s quite simple to understand, but hard to implement. Have a plan in your head; know the time you need to spend on each section, and execute you plan. Build a habit of not sticking with any task for more than 15 minutes, unless you’re doing a big and complex task like IPMA. But if you got something not working, don’t spend desperate minutes trying to troubleshoot it for 30 minutes. During the preparations, I found it really useful to run a widget playing chimes every 15 minutes – just to keep me on track. Another benefit of time management – seeing your lab progressing in accordance with the amount of time planned in advance generally helps you reduce the level of stress.Wildcard Scenarios
There are different types. First, and most harmless – you get an unfamiliar topic in the lab. Skip it the first time, and then refer to the DocCD if you have enough time left in the end of your lab. No big deal, unless you think most of the tasks are unfamiliar to you
Usually that means you were preparing to a different exam. OK, so the next wildcard – hardware and software issues in your rack. This is a type of issue you should battle with proctor – just make sure those are real issues. If that didn’t help much – prepare a complain letter to Cisco, and ask for a free lab attempt – and it’s no joke! 
Proctor is yet another wildcard. They are merely humans, so you can’t expect 100% courteous service all the time; occasionally, you can meet an unhappy or unfriendly guy, so be prepared to use all your social skills. The last and most uncommon wildcard – some accidental situations like building fire or earthquake. But those are the things you need to worry less about.The things you should probably take care of are unexpected issues with your health. Like a cold flu, or sudden headache, or something of that kind. Ensure you have minimal amount of medicine necessary to suppress pain and other unpleasant syndromes for the duration of the lab exam.
0 comments:
Post a Comment