CCIE Voice Lab Blog

Archive for November, 2007

Those that have configured CUE know that it sometimes responds erratically to changes.  For example, when the IP address is changed.  Often times you will find phones dialing into the pilot number and disconnecting quickly or simply hearing dead air.  Usually this means you need a reset of the CUE module, but I have witnessed situations where it has required two reloads of the module.  The best command I have found to help isolate the problem is the “show call active voice” command.  It will show you all the call legs as well as the target/destination IP addressing for the voip legs.  This information can easily help you determine what IP address CME or CM is using when accessing the CUE module.  Make sure you keep the “dead air” call up to CUE when you issue this command otherwise you will not see the desired information.

As you can see I am fortunate enough to have everything needed for the CCIE Voice lab.  Ebay is a wonderful thing and also I’ve been able to take advantage of partner NFR pricing as well.  It is still a significant investment but like any geek out there, being able to tinker and play with whatever scenario you want is an awesome way to learn.  There is another APC 1500 going in shortly so I can evenly distribute the power load.  When the entire rack is running it draws about 1100watts which isn’t too terrible considering everything running.  Also where I live in Canada the power rates aren’t too ridiculous.  I’ve got everything remotely accessible via VPN through the ASA5505 firewall.  This allows me to remotely control power to every device through the NPS at the top of the rack.  I have found this feature to come in very handy depending on what type of lab I am working on.  For example, if I am working on CUE, I can just have the specific router, switch and terminal server running.  As you can also likely guess, everything that has to do with Callmanager, Unity, IPCC Express, and many other Cisco software products are all running in VMWare ESX 3.0 on the server in the bottom of the rack.  This box is a dual Opteron 2.0ghz with 16GB of ram, 3 Broadcom Gigabit NICs, and 1TB of SATAII and SATA disks.

Sometimes I’ve found it hard to determine certain formulas for Cisco QoS calcuations due to the vast number of documents regarding a certain subset of the large QoS topic.  For the CCIE Voice Lab it is important to understand Cat 6500 QoS.  Within this topic are policers which are made up of either aggregate or microflow.  Part of the aggregate policer configuration is determining the “burst” value.  The best explaination I have found is here.

• Burst = (Rate [bps]) * 0.00025 [sec/interval]) or (maximum packet size [bits]), whichever is greater.

For example, if you want to calculate the minimum burst value needed to sustain a rate of 1 Mbps on an Ethernet network, the rate is defined as 1 Mbps and the maximum Ethernet packet size is 1518 bytes. The equation is:

• Burst = (1,000,000 bps * 0.00025) or (1518 bytes * 8 bits/byte) = 250 or 12144.

The larger result is 12144, which you round to 13 kbps.

Cisco Callmanager > Cisco Unified CallManager Security and Virus Protection Guides > Cisco CallManager TCP and UDP Port Usage > Choose Version

Direct Link found here.

WELCOME!!!  This blog is intended to be used by myself and anyone else out there who happens to stumble upon the site.  There are numerous other sites which are great for the CCIE Voice lab and I plan to reference them whenever possible.  There will be absolutely NO NDA MATERIAL ALLOWED on this blog for obvious reasons.  I have personally taken the CCIE Voice lab once already and have my next attempt booked for March 2008.  I would like this blog to be a useful tool and encourage anyone who has something beneficial to contribute, to do so.  Thanks for stopping by and good luck to all of you who are on this same journey.