Monday, May 6, 2013

CCIE Voice Lab Strategy Part 5 - Bringing it Home

Time to bring this series to a close. This series started with a background of strategies I used as reference points to build my own strategy. Next, I covered my process for reading through the exam and getting my ducks in a row. Part 3 continues the planning discussion and dives into the first configuration phase. The last installment covers the configuration phases that I try to nail down before lunch. So, what's next? Well,  I am going to wind this down and talk about the afternoon activities.


A Word on Focus

I am not sure about other IE candidates but the pre-lunch activities are a whirlwind. When you go into lunch your head is probably buzzing. I am amped up at lunch time and my synapses are firing off like no tomorrow. You have to exercise some self-control. Don't expend too much energy thinking about the past 3.5 hours. 

You want to calm down (using whatever method that works for you) and you want to focus on what you need to do when you get back in the game. If you have a lingering issue, this is the perfect time to think about how you are going to address it and, more importantly, when. 

Task List

If everything has gone according to plan, my task table looks something like the following.



I have all of my infrastructure device configs done. I have also finished all of the voicemail integration tasks. I essentially have dial plan, SRST, UCCX, CUPS, CUCM features, and troubleshooting to contend with. 

Dial Plan Provisioning

No matter where I am in the overall task plan, I will configure the dial plan right after lunch. I use the "DP" section of my task table and I configure all dial plan features. I typically do NOT need to re-read the lab guide for the basic dial plan tasks as I can use the config notes I took during the read through and build a complete dial plan. If I do need to re-read the config requirements, it will be minimal.

I walk through the dial plan just like anyone else:
  1. Add any SIP trunks / H323 gateways (as required)
  2. Clean up my default route groups to assign the real gateways (remember, I used a dummy gateway to stage device pools)
  3. Add any new route groups
  4. Add route lists
  5. Add translation patterns
  6. Add route patterns
  7. Add transformation pattens
  8. If doing globalization, configure the gateway
For those of you that have gone through the IPExpert training, I use Vik's basic approach to provisioning the dial plan. I don't use E.164 patterns unless I am doing AAR, globalization, or I am told to do so. I do use LRG wherever it fits. Just because I know people may ask, I take about 15 minutes to build out the entire dial plan. 

After I do the dial plan, I will validate all of the basic calls. Ingress and egress. I also test to/from each phone at each site. I use debugs and check displays to ensure I am sending the right ANI/DNIS and TON. I also check call status to ensure I hit the right dial peers and am using the correct codecs. I don't test AAR or circuit failover at this point. I will test globalization if required. 

Some people say you should do validation at the end. I agree with that philosophy for most things but not for dial plan. It is central to a lot of other tasks and I know I need to validate it eventually.

SRST Provisioning

Right after I do the dial plan, I take the SRST configurations I have been saving in notepad and paste them into the devices. After pasting the configs, I do a write mem and put the site in SRST mode immediately. 

I do a full validation of all SRST features and I check all relevant ingress/egress calls again. Ensuring ANI/DNIS/TON are compliant to the requirements. After I finish testing SRST I will restore service and save the configuration once all phones and the gateway are back to normal operation mode. If I have to use CME for SRST, I will check the gateway to see if I am hitting one of the notorious bugs known to plague that feature set. If I suspect an issue, I reboot that device without a second thought.

Once you are done with SRST, don't go back into it again. 


UCCX and CUPS Provisioning


The tasks I have remaining for these applications will depend on how well my morning went. I may have started the integration procedures for one or both applications. In any case,  I will actually start provisioning both applications at the same time as there is work to be done on CUCM.

So, I go back to using my candidate PC to open a web session to CUCM and CUPS. I use the UCCX host to session to itself. I will typically start with CUPS because the first few tasks are of the "click and wait" kind. I edit the topology, check service parameters, enable services. Whenever I click on something, I will toggle over to CUCM of UCCX and start doing what needs to be done there. 

At some point I put all of my focus on CUPS. Configuring the clients (as needed), adding contacts, etc. I will then go ahead and validate the requirements. I then switch over to UCCX and finish up there. I do CUPS prior to UCCX just because there are typically fewer moving parts. No other reason. Completely arbitrary. 


CUCM Feature Provisioning

After CUPS and UCCX are done, I only have CUCM features to provision. By the time I get to this point most of the features are already configured or mostly configured (because of the way I do my base config). If I have a feature that involves doing something with TFTP or music on hold or similar task then I may use UCCX to configure one feature and have a separate browser instance on my candidate PC for other features. Again, I try to avoid any pauses.



Troubleshooting


I always put off the troubleshooting questions until the end of my exam. This is primarily because you have to switch gears. Prior to this point, you are banging out configurations you have practiced over and over again. You should practice troubleshooting but it isn't about speed. It is about using your powers of observation and, to a degree, may involve some critical thinking. 

At a minimum you have to pay very close attention to what is being asked. I tend to re-read the troubleshooting questions multiple times, paying close attention to the wording. You also need to make sure your answer is concise and accurately interprets the evidence you are presenting. I am willing to bet that a lot of people miss points in this section even though they fully understood the issue. 


Validation


The best advice I can give about validation is: make sure you have a plan. You don't want to come this far and start bouncing around your devices randomly testing stuff. My validation strategy starts during the configuration. Up to this point I have already vetted most of the dial plan. I have also validated SRST and QoS. 

So, where do I start? Gateway signaling and the dial plan. Even though I have already tested most of the dial plan, I will run through it again. Of course, this time I am starting with the gateway configurations. I check the controller, the ISDN status, the network clocking, etc. I then do the basic calls again (though, this time I won't test every phone). More importantly, I will test features like AAR, SNR, and circuit failover. These features were NOT validated during the Dial Plan Provisioning phase. 

After I validate the dial plan, I will validate voicemail, UCCX, and CUPS. I make sure I read the questions thoroughly to verify I have hit all requirements. I will test with the most complicated scenarios. For instance, if UCCX is in play I will do calls over the WAN. If I have RSVP, I will call from that WAN site. If the question doesn't dictate a specific call scenario, I'll test all possible scenarios. 

Next I will validate CUCM features. Mobility (MVA), conferencing, transcoding, BLF, intercom, iDivert, whatever. I basically go down the CUCM tasks list. For media resources, I check things like source IP addresses and other config elements that should be considered outside of basic functionality. 

I validate the infrastructure pieces last. I'll start with LAN QoS. I basically check the configuration and use various "show mls qos" commands to make sure I am hitting the target. Moving on, I check vlan configurations, DHCP, phone ports, and NTP. You don't want to assume all is well just because your phones are registered. What if you put the TFTP servers in the wrong order? Things would still work but you would lose points.

Finally, I would check to make sure I haven't left an erroneous configuration in place. I would make sure I have removed any access list configurations I may have used to "break" things. I make sure all interfaces are UP/UP. I turn off debugging. I make sure any files I needed to leave for the proctor are where they are supposed to be. I leave client-side applications in the requested state. This is pretty key. If I don't need to leave a client-side application open then I close it. 

If you have time remaining after all of this then do a walk through. Go question-by-question and triple check yourself. 

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!

5 comments:

  1. Hi Will
    Thank you very much. After reading your articles on tackling ccie voice lab exam, I put forward my plan of attack and strategy to take the lab exam. Finally I passed the lab on second attempt in July. I thank you for opening up my mind to think in a different way.
    Kind Regards,
    Rahm

    ReplyDelete
  2. Rahm,

    That is outstanding news! Congratulations on your achievement and I am glad my musings were of some help.

    -Bill (@ucguerrilla)

    ReplyDelete
  3. Hi William,

    Thank you so much for the blog, yesterday I used this strategies in my attempt, I passed,

    Thanks again,
    Hector.

    ReplyDelete
  4. Hector,

    Excellent! Congratulations and thanks for the feedback. I am glad you found the strategy useful.

    -Bill (@ucguerrilla)

    ReplyDelete
  5. Hi William,

    This is a great series, have taken alot away from it and has helped me alot to construct a strategy

    Thanks

    ReplyDelete