I thought I'd share some things that I learned during my first CCIE Voice lab attempt this week. First off, I'm not going to break the NDA, and won't tell you anything about what was on it. I didn't receive a passing grade, but learned some (what I think are) very valuable things nonetheless.
CCIE Voice Lab Lesson #1: Fridays are "Fish Fridays" in RTP. Yes, that's right. If you are planning to go to RTP in North Carolina to take your lab.. the food is catered and all of the candidates huddle in a tiny room for 20 minutes and gulp down some grub. Every Friday, it's "Fish Friday" - if you hate fish, perhaps you should plan for another day. We also had salad, water, soft drinks and a dessert.
CCIE Voice Lab Lesson #2: Per the proctor, the CCIE Voice lab takes an average of 3.5 attempts to pass - easily the hardest lab right now. By comparison, the R&S lab runs an average of 2.6 attempts before passing. The proctor also said that she knew of only one person that had passed the CCIE Voice lab with their first attempt (and they work for Cisco). I'm sure that you all have heard of others - but the point here - it's one tough test!
IOS Gateway DSP Farm Configuration
Updated 8/3/2011:
One of the tasks that you should be able to do quickly on the CCIE Voice lab is configuring a DSP Farm and enabling SCCP gateway mode. It's almost certain that you'll need to do that on the lab, and you won't want to waste any time on this task.
DSP Farm Calculations
These calculations are based on the PVDM2 that should be found on routers within the CCIE Voice lab currently.
Each PVDM2-16 = 1 DSP. Each DSP can perform 240MIPS (millions of instructions per second).
There are various functions that consume DSP resources. Voice bearer channels and transcoders are capable of sharing the same DSP. However, the conference bridge resources cannot play nice and share.
Bearer channels and transcoders consume resourced based on the codec complexity:
g711u/g711a = 15 MIPS per call
g729a/g729ab = 30 MIPS per call
g729/g729b = 40 MIPS per call
Conference bridge calls consume 120 MIPS per call, regardless of the complexity.
So, to better understand the maximum sessions possible for each media resource type, lets review some examples:
Assume a PVDM2-32, which has 2 DSPs and capable of 480 MIPs.
dspfarm profile 10 conference
codec g711
codec g729
max sessions 4 ( 4 calls at 120 MIPS each exhausts both DSPs )
OR
dspfarm profile 6 transcode
codec g711u
codec g729r8
max sessions 12 ( assume the worst here, g729r8 = 40 MIPs per call )
OR
NOTE: Gotcha coming here..
When the router makes calculations involving bearer channels, it uses G711 ( 15 MIPS per call ) as the basis for the calculation. However, if G729 calls are used in reality, the DSP resources could be over-subscribed if you do not account for this yourself. Three G729 calls will actually consume 120 MIPs. Which leaves only 120 MIPs on the same DSP for transcoding - not 195 MIPs as the best-case calculation would lead you to believe. The router will let you configure more than 120 MIPs of transcoding, but be aware that this will create problems if G729 is actually used for the bearer lines.
controller t1 0/0/0
pri-group t 1-3 ( assumes best case, G711 or 15 MIPS per call for bearer channels )
DSP Farm Configuration Sample
conf t
!
voice-card 1
no dspfarm
dsp services dspfarm
!
! Note that version 5.0 is needed for an RSVP call agent within MTP
sccp local FastEthernet 0/0
sccp ccm 10.100.1.1 identifier 1 version 5.0
sccp ccm 10.100.1.2 identifier 2 version 5.0
sccp ccm 10.100.1.3 identifier 3 version 5.0
sccp ip precedence 3
sccp
!
sccp ccm group 666
associate ccm 1 priority 1
associate ccm 2 priority 2
associate ccm 3 priority 3
! IOS Enhanced Conference Bridge
associate profile 10 register HQ_CFB000100020003
! IOS Enhanced Transcoder
associate profile 6 register HQ_MTP000100020044
keepalive retries 5
switchover method immediate
switchback method immediate
switchback interval 15
!
dspfarm profile 6 transcode
codec g711ulaw
codec g711alaw
codec g729ar8
codec g729abr8
maximum sessions 4
associate application SCCP
! VERY IMPORTANT, don't forget "no shutdown"
no shutdown
!
dspfarm profile 10 conference
codec g711ulaw
codec g711alaw
codec g729ar8
codec g729abr8
codec g729r8
codec g729br8
maximum sessions 1
associate application SCCP
! VERY IMPORTANT, don't forget "no shutdown"
no shutdown
!
PVDM DSP Usage Tips
Reposted from CCBOOTCAMP Forum,
This is the best summary of DSP tips that I've found yet. Full kudos to CIARF for posting this!
Configuring Enhanced Conferencing and Transcoding and for Voice Gateway Routers
CCBootCamp Forum, CIARF Post
One of the tasks that you should be able to do quickly on the CCIE Voice lab is configuring a DSP Farm and enabling SCCP gateway mode. It's almost certain that you'll need to do that on the lab, and you won't want to waste any time on this task.
DSP Farm Calculations
These calculations are based on the PVDM2 that should be found on routers within the CCIE Voice lab currently.
Each PVDM2-16 = 1 DSP. Each DSP can perform 240MIPS (millions of instructions per second).
There are various functions that consume DSP resources. Voice bearer channels and transcoders are capable of sharing the same DSP. However, the conference bridge resources cannot play nice and share.
Bearer channels and transcoders consume resourced based on the codec complexity:
g711u/g711a = 15 MIPS per call
g729a/g729ab = 30 MIPS per call
g729/g729b = 40 MIPS per call
Conference bridge calls consume 120 MIPS per call, regardless of the complexity.
So, to better understand the maximum sessions possible for each media resource type, lets review some examples:
Assume a PVDM2-32, which has 2 DSPs and capable of 480 MIPs.
dspfarm profile 10 conference
codec g711
codec g729
max sessions 4 ( 4 calls at 120 MIPS each exhausts both DSPs )
OR
dspfarm profile 6 transcode
codec g711u
codec g729r8
max sessions 12 ( assume the worst here, g729r8 = 40 MIPs per call )
OR
NOTE: Gotcha coming here..
When the router makes calculations involving bearer channels, it uses G711 ( 15 MIPS per call ) as the basis for the calculation. However, if G729 calls are used in reality, the DSP resources could be over-subscribed if you do not account for this yourself. Three G729 calls will actually consume 120 MIPs. Which leaves only 120 MIPs on the same DSP for transcoding - not 195 MIPs as the best-case calculation would lead you to believe. The router will let you configure more than 120 MIPs of transcoding, but be aware that this will create problems if G729 is actually used for the bearer lines.
controller t1 0/0/0
pri-group t 1-3 ( assumes best case, G711 or 15 MIPS per call for bearer channels )
DSP Farm Configuration Sample
conf t
!
voice-card 1
no dspfarm
dsp services dspfarm
!
! Note that version 5.0 is needed for an RSVP call agent within MTP
sccp local FastEthernet 0/0
sccp ccm 10.100.1.1 identifier 1 version 5.0
sccp ccm 10.100.1.2 identifier 2 version 5.0
sccp ccm 10.100.1.3 identifier 3 version 5.0
sccp ip precedence 3
sccp
!
sccp ccm group 666
associate ccm 1 priority 1
associate ccm 2 priority 2
associate ccm 3 priority 3
! IOS Enhanced Conference Bridge
associate profile 10 register HQ_CFB000100020003
! IOS Enhanced Transcoder
associate profile 6 register HQ_MTP000100020044
keepalive retries 5
switchover method immediate
switchback method immediate
switchback interval 15
!
dspfarm profile 6 transcode
codec g711ulaw
codec g711alaw
codec g729ar8
codec g729abr8
maximum sessions 4
associate application SCCP
! VERY IMPORTANT, don't forget "no shutdown"
no shutdown
!
dspfarm profile 10 conference
codec g711ulaw
codec g711alaw
codec g729ar8
codec g729abr8
codec g729r8
codec g729br8
maximum sessions 1
associate application SCCP
! VERY IMPORTANT, don't forget "no shutdown"
no shutdown
!
PVDM DSP Usage Tips
Reposted from CCBOOTCAMP Forum,
This is the best summary of DSP tips that I've found yet. Full kudos to CIARF for posting this!
http://www.cisco.com/en/US/prod/collateral/modules/ps3115/ps6024/prod_qas0900aecd8016c6ad_ps5855_Products_Q_and_A_Item.htmlMore Information
PVDM2-16 is one DSP chip (32=2, 48=3, 64=4)
PVDM2-8 is one DSP chip but less processing capacity than the DSP on the 16.
PVDM2-8 contains one TNETV2505GGW DSP;
other PVDM2 modules contain 1 to 4 TNETV2510GGW DSPs (referred to C5510 in command outputs)
High Complexity Codecs
G.723.1, G.728, G.729, G.729b, GSM-EFR and Modem Relay
Medium Complexity Codecs
G.711 (see G711 note), g.729a, G.729ab, G.726, GSM-FR and Fax Relay
You can configure each DSP separately as either medium complexity, high complexity, or flex mode (C5510 only). Configure with voice-card x. Then codec complexity (flex | high | medium). The DSP treats all calls according to its configured complexity, regardless of the actual complexity of the codec of the call. A resource with configured complexity equal or higher than the actual complexity of the incoming call must be available, or the call will fail. For example, if a call requires a high-complexity codec but the DSP resource is configured for medium complexity mode, the call will fail. However, if a medium-complexity call is attempted on a DSP configured for high complexity mode, then the call will succeed and Cisco IOS will allocate a high-complexity mode resource.
Flex mode has an advantage when calls of multiple codecs must be supported on the same hardware because flex mode can support more calls than when the DSPs are configured as medium or high complexity. ***However, flex mode does allow oversubscription of the resources, which introduces the risk of call failure if all resources are used. With flex mode it is possible to have fewer DSP resources than with physical TDM interfaces. ***
G711 Note:
----------
Compared to medium or high complexity mode, flex mode has the advantage of supporting the most G.711 calls per DSP. In medium complexity mode a DSP can support max 8 G.711 calls, while flex mode supports max 16 G.711 calls.
Note IP Phones and Unity support G711 and G729a (no other g729 variant.) Cisco Unity has support for accepting calls with G.729a, but the codec is implemented in software and is CPU-intensive.
PVDM2-8 Signaling
- 8 calls per DSP for G711 (flex mode only)
- 4 calls for other medium and all high complexity codecs.
- 120 MIPS in FLEX Mode
PVDM2-16 - Signaling
- 16 calls for G711 (flex mode only)
- 8 calls for the other medium complexity codecs and g711 in medium complexity mode
- 6 calls per DSP for high complexity codecs
- 240 MIPS in flex mode
- G711 uses 15 MIPS per call (240 MIPS / 15 MIPS per call = 16 calls per DSP)
- The codecs under the High Complexity category use 40 MIPS per call.
- The codecs under the medium complexity category use 30 MIPS per call.
- The D channel doesn't count for resources
- Each FXO or FXS port takes 1 channel.
MTP
- CCM SW MTP is G711 only (all versions including CCM7.x)
- IOS SW MTP
- Supports G711 and any G729 variant. But can choose only one
codec on the dspfarm profile at a time.
- Need the capacities. (500 for a 2811?)
- IOS HW MTP
- 16 G711 sessions per DSP
- 6 G729 sessions per DSP
PVDM2-16 - Conferencing
- IOS 12.4(15)T has new capability for 32 participants per conference. G711 must be only codec in dspfarm profile. Use the maximum conference-participants 8, 16 or 32 command.
- If use 32 participants then only get 2 G711 max sessions (conferences.)
- If use 16 participants, get 4 G711 max sessions
- If use 8 participants, get 8 G711 conferences
- If configure any of the g729s in dspfarm profile (medium or high complexity), get 8 or 16 participants per conference. (if 16, get one session. If 8, get two sessions)
- Each DSP supports 2 conferences (of 8 participants each) if G.729 is CONFIGURED on the dspfarm.
(even if all participants on all conferences are using G.711.) When configured to accept both G.711 and G.729 calls, a single DSP provides 2 conferences because it is also reserving its resources for performing transcoding of streams.
- Can't share conference on DSP with xcode or voice signaling. DSPs that are configured through Cisco IOS as conference resources will load firmware into the DSPs that is specific to conferencing functionality only, and these DSPs cannot be used for any other media feature.
- Config max-sessions for 2 or 8 (depending on configured codec). Doesn't
make sense to configure less--wasting resources. Again, the figures are for a 1 DSP PVDM2-16. Scale it up for others.
PVDM2-16 - Transcoding
- Can share Transcoding with voice signaling.
- 8 Sessions - G711a/u to G729a/ab (must turn off high complexity g729 and g729b to get 8 sessions) in dspfarm profile.
- 6 sessions - G711a/u to G729 / G729b
Universal Transcoding with capacities is given in:
http://www.cisco.com/en/US/docs/ios/12_4t/12_4t15/it_unitr.html
If source phone is g711 to a POTS (or T1 or PRI) it will use 15 credits.
If source phone is g729 to a POTS it will use 30 or 40 credits depending on codec complexity. This includes the source phone locally (could be a SIP Phone doing g729) or a source phone over the WAN at g729r8 doing TEHO. In the later case, no transcoding at HQ or the TEHO location will be used. It just takes more processing power to decode g729 back to analog.
Configuring Enhanced Conferencing and Transcoding and for Voice Gateway Routers
CCBootCamp Forum, CIARF Post
CCIE Voice Lab Strategy
So, its time to take your lab and the clock is about to start. What are you going to do first? What next? Do you have a plan? Passing the CCIE Voice lab is as much about strategy and time management as it is about learning the technologies involved. Keep in mind that the lab will morph over time and its advisable to watch for changes to the program. As of the Cisco Live conference this year, see the most up to date information we have to go on.
Before we go any further - you must watch Vik Malhi's vLecture about the CCIE Voice Lab strategy. It is fantastic and I'm pretty much buying whatever Vik's selling.
Seriously, go back and watch Vik's vLecture. It's 2 hours long - but WELL worth the time.
Troubleshooting in the CCIE Lab
As many of you know already the open ended questions have been removed from the CCIE Voice lab. In it's place, there will be a stronger emphasis on troubleshooting - expect it and don't be surprised.
Per Amy Ryan CCIE# 24677, IP Expert Blog (following the 2010 Cisco Live! Event). More Information.
CCIE Voice Lab Strategy
Enough of that, there are a lot of strategies out there. Many work, and some are able to pass the lab by simply doing the lab tasks in series. That approach does not work for most people, but its possible. You'll need to find what works for you and develop and practice your own style before the real thing.
I've read quite a few opinions and suggestions and have linked many of them at the end of this post. The rest of this post is dedicated to how I am approaching the lab. It's based primarily on the suggestions by Vik and will be addressed in series as they are listed. Depending on the lab, there will be some flexibility - but generally, the flow will be similar to that listed below.
I also like the idea of using different colored pencils to keep track of progress during the lab. Essentially, use a green pencil to make a list of all the sections quickly - then as they are completely finished, cross them off with a red pencil. It may seen simple, but seeing things crossed off can bring closure to those sections in your mind so that you can focus more clearly on other sections AND help you keep a running tally of points that you have earned thus far.
I'd love to get your comments and feedback on this - as I'm sure it will bring to surface many differing viewpoints. I'd love to hear them!
Review the Lab Book First ( 30 Minutes )
Use no more 30 minutes to skim through the lab book. Using notepad, draw the topology and mark out primary features at each site.
For example,
HQ: UCM / H323 GW / GK / SCCP Phones
BR1: UCME / SIP Phones
BR2: UCME / SCCP Phones
Document important information that will be used over and over:
Infrastructure ( 15 Minutes )
Its important to verify that connectivity is good between all of your devices between you proceed any further.
Configure:
QOS ( 20 Minutes )
Pay close attention to whether trusting should be used. Use "auto qos voip" to save time getting the configuration on the router. It's much faster to edit than generate the entire configuration that "auto qos" will do for you.
Registering UCM Endpoints ( 15 Minutes )
Within this section the focus is on getting the UCM services started and the phones registered. Keep in mind that some items can also be configured in the device pool, so its not ultimately critical to get everything set in stone here.
Database Replication ( 15 Minutes )
As a matter of precaution, run the following command to repair any possible replication issues in the background. This will ensure that the pub/sub is in sync and avoid anything unexpected later in the lab.
utils replication repair all
Device Configuration ( 15 Minutes )
In this section, its time to customize each device. Try to configure as much as possible in one pass:
CME Phone Registration ( 15 Minutes )
The focus here is to get all CME phones registered (both SCCP and SIP). If its possible to easily determine feature configurations required, its a good time to get them configured. However, make sure that they are registered before moving forward.
Otherwise, much of the additional configuration will be done in the Call Routing or Everything Else sections later in the plan.
Gateways ( 20 Minutes )
This section is intended to simply get the gateway functionality up and working. The call routing details will be handled in the next section. Ensure that the MGCP and H323 configurations are solid.
MGCP Gateways:
Call Routing ( 60-90 Minutes )
This is the most important section of the lab. As such, verification is of utmost importance.
Create a Verification Table that includes:
Digit Manipulation - Push out to the h323 gateway typically
UCM Call Routing
Transformations Required
Globalization/Localization
High Availability ( 20 Minutes )
AAR
Create a new pt/css
Single AAR Group if using + dialing
Multiple AAR Group if not using + dialing and more than 1 domain
Use BAT to assign AAR Group
CFUR
Create a new pt/css
Must use + dial if >1 dialing domain
SRST
Telphony-service
SRST auto provision all
Media ( 20 Minutes )
This may be interwoven in other sections, so plan on adapting. Below are some high points of Media.
MTP may be implied elsewhere, e.g., gk trunk with CUBE or RSVP Call Agent
Transcoder might be required for branch phones calling CCX
CFB might be required for JOIN / cBARGE
SCCP dspfarms
MoH
PIM dense mode in virtual template
RSVP Call Agent
IP RSVP bandwidth in virtual template
Everything Else ( 4 Hours )
Do what you know best - FIRST. Get the points! If you skip certain sections, keep track of those issue and come back to them when time allows.
The CCIE Voice Lab is a tough lab. Many people fail on their first attempt. In fact most people fail on their first attempt.
Keep in mind that you must get the section fully correct to earn points for that section. If you are 80% correct in every section of the lab, you'll get a final score of 0! Don't confuse the scoring methodology with a measurement of your knowledge. Instead, if you unfortunately do fail, make the best of the experience and identify areas in which you were not completely fluent. Come back when you've addressed your weaknesses and nail it!
More Information
INE CCIE Blog
INE Forum Discussion
IP Expert Blog
Pushkar Bhatkoti's Blog
Ben Ng's Exam Tips I
Ben Ng's Exam Tips II
Ben Ng's Exam Tips III
Before we go any further - you must watch Vik Malhi's vLecture about the CCIE Voice Lab strategy. It is fantastic and I'm pretty much buying whatever Vik's selling.
Seriously, go back and watch Vik's vLecture. It's 2 hours long - but WELL worth the time.
Troubleshooting in the CCIE Lab
As many of you know already the open ended questions have been removed from the CCIE Voice lab. In it's place, there will be a stronger emphasis on troubleshooting - expect it and don't be surprised.
Per Amy Ryan CCIE# 24677, IP Expert Blog (following the 2010 Cisco Live! Event). More Information.
- Troubleshooting is embedded into the configuration tasks of the exam at this point.
- Troubleshooting tasks account for approximately 15% of the points on the CCIE Voice Lab exam.
- Candidates will have to troubleshoot existing configuration which has built-in errors.
- Infrastructure tasks will for the most part be complete and will not be the responsibility of the candidate. However configuration might not be 100% correct!
- Going forward phones will be pre-configured into the UCM database.
- It is the intention to have phones pre-registered with the correct firmware in advance.
- Troubleshooting tasks could potentially include in depth knowledge of the protocols used for establishing call setup. It was mentioned that the candidate may not even have to fix the problem and instead create a text file with the relevant traces/debugs and a suitable explanation. A process not too dissimilar when you create a TAC case.
CCIE Voice Lab Strategy
Enough of that, there are a lot of strategies out there. Many work, and some are able to pass the lab by simply doing the lab tasks in series. That approach does not work for most people, but its possible. You'll need to find what works for you and develop and practice your own style before the real thing.
I've read quite a few opinions and suggestions and have linked many of them at the end of this post. The rest of this post is dedicated to how I am approaching the lab. It's based primarily on the suggestions by Vik and will be addressed in series as they are listed. Depending on the lab, there will be some flexibility - but generally, the flow will be similar to that listed below.
I also like the idea of using different colored pencils to keep track of progress during the lab. Essentially, use a green pencil to make a list of all the sections quickly - then as they are completely finished, cross them off with a red pencil. It may seen simple, but seeing things crossed off can bring closure to those sections in your mind so that you can focus more clearly on other sections AND help you keep a running tally of points that you have earned thus far.
I'd love to get your comments and feedback on this - as I'm sure it will bring to surface many differing viewpoints. I'd love to hear them!
Review the Lab Book First ( 30 Minutes )
Use no more 30 minutes to skim through the lab book. Using notepad, draw the topology and mark out primary features at each site.
For example,
HQ: UCM / H323 GW / GK / SCCP Phones
BR1: UCME / SIP Phones
BR2: UCME / SCCP Phones
Document important information that will be used over and over:
- VLAN IDs
- Server IP Addresses
- Loopback IPs at each site
- E164 Numbering
- Extension Numbers
Infrastructure ( 15 Minutes )
Its important to verify that connectivity is good between all of your devices between you proceed any further.
Configure:
- VLAN
- TFTP
- DHCP
- NTP
QOS ( 20 Minutes )
Pay close attention to whether trusting should be used. Use "auto qos voip" to save time getting the configuration on the router. It's much faster to edit than generate the entire configuration that "auto qos" will do for you.
- WAN QoS (auto qos voip trust, if marking on edge)
- LAN QoS
Registering UCM Endpoints ( 15 Minutes )
Within this section the focus is on getting the UCM services started and the phones registered. Keep in mind that some items can also be configured in the device pool, so its not ultimately critical to get everything set in stone here.
- UCM Services - Start everything relevant
- Check phone registrations, use auto-registration (this avoids MAC address typos). At this point, don't worry about the DN assignment, just make sure that all phones that should register to the CCM are registered. Use auto registration for both SIP and SCCP to get the phones in the database quickly.
- Server (use IP addresses)
- UCM Group
- UCM
- Date/Time Group
- Location
- Region
- Device Pool
- Enterprise Params
Database Replication ( 15 Minutes )
As a matter of precaution, run the following command to repair any possible replication issues in the background. This will ensure that the pub/sub is in sync and avoid anything unexpected later in the lab.
utils replication repair all
Device Configuration ( 15 Minutes )
In this section, its time to customize each device. Try to configure as much as possible in one pass:
- Phone partition (PT-Internal)
- CSS per phone (Use a
- Description
- Device Pool
- CSS
- DN/Partition
- Display Name
- External Number Mask
- Call Fwd Busy/Noan
CME Phone Registration ( 15 Minutes )
The focus here is to get all CME phones registered (both SCCP and SIP). If its possible to easily determine feature configurations required, its a good time to get them configured. However, make sure that they are registered before moving forward.
Otherwise, much of the additional configuration will be done in the Call Routing or Everything Else sections later in the plan.
- Telephony-service
- Voice Register
- Ephone-DN
- Ephone
- Voice Register DN / Pool
- Get CUE Module in steady state, restore factory defaults, appropriate license (show software license)
Gateways ( 20 Minutes )
This section is intended to simply get the gateway functionality up and working. The call routing details will be handled in the next section. Ensure that the MGCP and H323 configurations are solid.
MGCP Gateways:
- ccm-manager config/server
- mgcp bind control loopback0 (add after its registered to CCM)
- FQDN may affect CCM registration
- CSS-Internal
- Significant Digits for Inbound calls
- Three checkboxes, Display IE, etc.
- SRST - be careful here. Plan for with CCM and without CCM in the picture.
- Voice-class codec (allows for multiple codecs on same dial-peer)
- Voice-class H323
- Voice translation profiles on voice-port for Inbound calls
- Inbound Dial-peer (POTS)
- Outbound VoIP dial-peers
- Bind Source address !!
Call Routing ( 60-90 Minutes )
This is the most important section of the lab. As such, verification is of utmost importance.
Create a Verification Table that includes:
- RP/RT
- RL
- Called Num Requirements
- Calling Num Requirements
Digit Manipulation - Push out to the h323 gateway typically
UCM Call Routing
Transformations Required
Globalization/Localization
High Availability ( 20 Minutes )
AAR
Create a new pt/css
Single AAR Group if using + dialing
Multiple AAR Group if not using + dialing and more than 1 domain
Use BAT to assign AAR Group
CFUR
Create a new pt/css
Must use + dial if >1 dialing domain
SRST
Telphony-service
SRST auto provision all
Media ( 20 Minutes )
This may be interwoven in other sections, so plan on adapting. Below are some high points of Media.
MTP may be implied elsewhere, e.g., gk trunk with CUBE or RSVP Call Agent
Transcoder might be required for branch phones calling CCX
CFB might be required for JOIN / cBARGE
SCCP dspfarms
MoH
PIM dense mode in virtual template
RSVP Call Agent
IP RSVP bandwidth in virtual template
Everything Else ( 4 Hours )
Do what you know best - FIRST. Get the points! If you skip certain sections, keep track of those issue and come back to them when time allows.
- Supplemental Services
- Applications
- Messaging
- CCX
- Presence Features
The CCIE Voice Lab is a tough lab. Many people fail on their first attempt. In fact most people fail on their first attempt.
Keep in mind that you must get the section fully correct to earn points for that section. If you are 80% correct in every section of the lab, you'll get a final score of 0! Don't confuse the scoring methodology with a measurement of your knowledge. Instead, if you unfortunately do fail, make the best of the experience and identify areas in which you were not completely fluent. Come back when you've addressed your weaknesses and nail it!
More Information
INE CCIE Blog
INE Forum Discussion
IP Expert Blog
Pushkar Bhatkoti's Blog
Ben Ng's Exam Tips I
Ben Ng's Exam Tips II
Ben Ng's Exam Tips III
Preparing for the CCIE Voice Written Exam
Updated with Version 3 Information Here
Beginning to pursue the CCIE Voice written exam can be daunting. But, I feel it's best approached as an extension of the Cisco CCVP certification. Much of the suggested reading for the CCVP forms the groundwork for the CCIE Voice Written.
The CCVP certification covers Cisco Voice over IP, QoS Principles, and Implementing and Troubleshooting Cisco Unified Communications Systems. Personally, I found that the CCVP gave me a nice introduction - but it did not provide me all that I needed to know in order to competently support Cisco Unified Communications system. For me, there was no substitute for experience.
That said, the CCVP also did not prepare me to pass the CCIE Voice Written exam. The CCIE Voice Written exam requires a much deeper understanding of the CCVP topics - plus many more topics that are not covered within the CCVP - see the blueprint below. In fact, the first time I took the CCIE Voice Written (I passed on my second attempt) - I was really caught off guard at the shear scope of the topics you will need to know for the CCIE Voice written.
Don't make the same mistake - make sure you're prepared!
CCIE Voice Written Blueprint
The following blueprint comes from Cisco's CCIE Voice section of their certification website.
1. CallManager
1. Codecs/Regions
2. Redundancy (CM Groups/Device Pool)
3. Dial Plan: Gatekeeper, SIP Proxy, Route Patterns, Route Groups, Route Lists, Digit Manipulation and Digit Analysis
4. Music On Hold
5. Conferencing (Audio and Video)
6. Transcoding
7. Media Termination Points
8. CM Features: Extension Mobility, IPMA, Attendant Console, Call Park, Pickup
9. Phone Settings
10. CTI, TAPI and JTAPI Interface
2. QoS
1. Link Efficiency: LFI, MLPPP, FRF.12, cRTP, VAD
2. Classification and Marking
3. Congestion Management: Queuing
4. CAC: RSVP, GK
5. Traffic Policing and Shaping
6. LAN QoS
7. CM CAC and GK. Hub and Spoke/Fully Meshed MPLS
3. Telephony Protocols
1. SCCP
2. RTP & cRTP
3. MGCP
4. SIP
5. H323
6. Analog and TDM Signaling
4. Unity
1. Integration
2. MWI, SMDI
3. DPA
4. Call Handlers
5. Unified Messaging
6. VPIM
5. IOS IP Telephony Skills
1. SRST
2. CME
3. CUE
6. IP IVR/IPCC Express
1. Speech Recognition
2. ICD Functions
3. Database Lookups
4. VXML
7. Security
1. DHCP Snooping
2. MCS OS Hardening
3. Phone Authentication and Encryption
4. TCP/UDP Port List
5. Firewalls and Application Layer Gateways (ALG)
6. NAT
8. Infrastructure Protocols
1. DNS
2. TFTP
3. NTP
4. Inline Power: Cisco and 802.3af
9. Application Protocols
1. IP Multicast
2. Video
3. Fax and Modem
10. Operations and Network Management
Suggested Reading for CCIE Voice Written
The following list is from the mouth of Ben Ng (in charge of the Cisco CCIE Voice program), the following books are recommended reading to prepare for the CCIE Voice written exam. This is still current as of today - but an update is in the works.
For the CCIE Voice Written exam, I'd recommend the following (Cisco Press books). And please study it with the written exam blueprint topics in mind.
1. Cisco Voice over IP
, Third Edition (Kevin Wallace)
2. Cisco Voice Gateways and Gatekeepers
(Donohue, Mallory, Salhoff)
3. Voice over IP Fundamentals
, 2nd Edition (Jonathan Davidson, James Peters, Manoj Bhatia, Satish Kalidindi, Sudipto Mukherjee)
4. Cisco IP Communications Express: CallManager Express with Cisco Unity Express
(Danelle Au, Baldwin Choi, Rajesh Haridas, Christina Hattingh, Ravi Koulagi, Mike Tasker, Lillian Xia.)
5. End-to-End QoS Network Design: Quality of Service in LANs, WANs, and VPNs
(Tim Szigeti, Christina Hattingh)
6. SIP Trunking
(Christina Hattingh, Darryl Sladden, ATM Zakaria Swapan)
Sample CCIE Voice Written Questions
So, you think that you're ready to take the CCIE Voice Written exam now? Well, before you shell out $300 for the exam - take the sample exam provided by Cisco below. If it seems completely foreign - I suggest doing some more review!
Also, I'd like to take this opportunity to suggest that you carefully choose your study materials to those that do not violate any Cisco NDA agreements or other legal mumbo jumbo. Hence, I have chosen only the Cisco sample exam questions below.
Cisco Learning Network Exam Practice
Reference:
Ask the Expert Thread
Beginning to pursue the CCIE Voice written exam can be daunting. But, I feel it's best approached as an extension of the Cisco CCVP certification. Much of the suggested reading for the CCVP forms the groundwork for the CCIE Voice Written.
The CCVP certification covers Cisco Voice over IP, QoS Principles, and Implementing and Troubleshooting Cisco Unified Communications Systems. Personally, I found that the CCVP gave me a nice introduction - but it did not provide me all that I needed to know in order to competently support Cisco Unified Communications system. For me, there was no substitute for experience.
That said, the CCVP also did not prepare me to pass the CCIE Voice Written exam. The CCIE Voice Written exam requires a much deeper understanding of the CCVP topics - plus many more topics that are not covered within the CCVP - see the blueprint below. In fact, the first time I took the CCIE Voice Written (I passed on my second attempt) - I was really caught off guard at the shear scope of the topics you will need to know for the CCIE Voice written.
Don't make the same mistake - make sure you're prepared!
CCIE Voice Written Blueprint
The following blueprint comes from Cisco's CCIE Voice section of their certification website.
1. CallManager
1. Codecs/Regions
2. Redundancy (CM Groups/Device Pool)
3. Dial Plan: Gatekeeper, SIP Proxy, Route Patterns, Route Groups, Route Lists, Digit Manipulation and Digit Analysis
4. Music On Hold
5. Conferencing (Audio and Video)
6. Transcoding
7. Media Termination Points
8. CM Features: Extension Mobility, IPMA, Attendant Console, Call Park, Pickup
9. Phone Settings
10. CTI, TAPI and JTAPI Interface
2. QoS
1. Link Efficiency: LFI, MLPPP, FRF.12, cRTP, VAD
2. Classification and Marking
3. Congestion Management: Queuing
4. CAC: RSVP, GK
5. Traffic Policing and Shaping
6. LAN QoS
7. CM CAC and GK. Hub and Spoke/Fully Meshed MPLS
3. Telephony Protocols
1. SCCP
2. RTP & cRTP
3. MGCP
4. SIP
5. H323
6. Analog and TDM Signaling
4. Unity
1. Integration
2. MWI, SMDI
3. DPA
4. Call Handlers
5. Unified Messaging
6. VPIM
5. IOS IP Telephony Skills
1. SRST
2. CME
3. CUE
6. IP IVR/IPCC Express
1. Speech Recognition
2. ICD Functions
3. Database Lookups
4. VXML
7. Security
1. DHCP Snooping
2. MCS OS Hardening
3. Phone Authentication and Encryption
4. TCP/UDP Port List
5. Firewalls and Application Layer Gateways (ALG)
6. NAT
8. Infrastructure Protocols
1. DNS
2. TFTP
3. NTP
4. Inline Power: Cisco and 802.3af
9. Application Protocols
1. IP Multicast
2. Video
3. Fax and Modem
10. Operations and Network Management
Suggested Reading for CCIE Voice Written
The following list is from the mouth of Ben Ng (in charge of the Cisco CCIE Voice program), the following books are recommended reading to prepare for the CCIE Voice written exam. This is still current as of today - but an update is in the works.
For the CCIE Voice Written exam, I'd recommend the following (Cisco Press books). And please study it with the written exam blueprint topics in mind.
, Third Edition (Kevin Wallace) (Donohue, Mallory, Salhoff), 2nd Edition (Jonathan Davidson, James Peters, Manoj Bhatia, Satish Kalidindi, Sudipto Mukherjee) (Danelle Au, Baldwin Choi, Rajesh Haridas, Christina Hattingh, Ravi Koulagi, Mike Tasker, Lillian Xia.) (Tim Szigeti, Christina Hattingh) (Christina Hattingh, Darryl Sladden, ATM Zakaria Swapan)Sample CCIE Voice Written Questions
So, you think that you're ready to take the CCIE Voice Written exam now? Well, before you shell out $300 for the exam - take the sample exam provided by Cisco below. If it seems completely foreign - I suggest doing some more review!
Also, I'd like to take this opportunity to suggest that you carefully choose your study materials to those that do not violate any Cisco NDA agreements or other legal mumbo jumbo. Hence, I have chosen only the Cisco sample exam questions below.
Cisco Learning Network Exam Practice
Reference:
Ask the Expert Thread
CUCME Features: Barge, cBarge, and Privacy
Barge is a feature that allows users of a shared octo-line directory number to join an active call by pressing a soft key on their phone. This effectively converts the call into an ad-hoc conference. This feature uses a hardware conference bridge configured in Cisco Unified CME. When the initiator barges into the call, an ad hoc conference is created between the barge initiator, the target party, and the other party that is already participating in the call. Connected parties hear the barge tone (single beep) after the conference is set up. When a party leaves the conference, a barge leave tone is played to the remaining parties.
NOTE: If a phone that is using the shared line has Privacy enabled, call information does not appear on the other phones that share the line and the call cannot be barged.
NOTE: CME version 7.0 or later is needed for SCCP support, CME version 7.1 needed for SIP support (Barge, cBarge, and Privacy)
Barge uses the built-in conference bridge on the target phone (the phone that is being barged) which limits the number of users allowed to barge. A barge conference supports up to three parties. If more users want to join a call on a SIP shared line, cBarge must be used. The SIP phone requires the built-in conference bridge to use Barge. Barge is supported for SIP shared-line directory numbers only.
cBarge Overview
The cBarge feature uses a shared conference resource which allows more that one person to barge into the call. A cBarge conference supports the maximum number of parties provisioned on the centralized conference resource. The centralized conference resource must be provisioned to use cBarge. cBarge is supported on SCCP shared octo-line directory numbers and SIP shared-line directory numbers.
When any party releases from the call, the call remains a conference call if at least three participants remain on the line. If only two parties remain in the conference, they are reconnected as a point-to-point call, which releases the conference bridge resources. When the target party parks the call or joins the call with another call, the barge initiator and the other parties remain connected.
Privacy
The privacy feature enables phone users to block other users who share a directory number from seeing call information, resuming a call, or barging into a call on the shared line. When a phone receives an incoming call on a shared line, the user can make the call private by pressing the Privacy feature button, which toggles between on and off to allow the user to alter the privacy setting on their phone. The privacy state is applied to all new calls and current calls owned by the phone user. Privacy is supported on SCCP octo-line directory numbers and SIP shared-line directory numbers.
Privacy is enabled for all phones in the system by default. You can disable privacy globally and enable it only for specific phones, either individually or through an phone template. You can also enable the privacy button on specific phones. After a phone with the privacy button enabled registers with Cisco Unified CME, the line feature button on the phone gets labeled "Privacy," a status icon displays, and if the button has a monitor lamp, it lights when privacy is active. For Extension Mobility phones, you can enable the privacy button in the user profile and logout profile.
The Privacy on Hold feature prevents other phone users from viewing call information or retrieving a call put on hold by another phone sharing the directory number. Privacy on Hold is disabled for all phones in the system by default. You can enable Privacy on Hold globally for all phones. To disable Privacy on Hold on individual phones, you must disable Privacy on those phones.
The Privacy feature applies to all shared lines on a phone. If a phone has multiple shared lines and Privacy is enabled, other phones cannot view or barge into calls on any of the shared lines.
SCCP Sample Configuration: cBarge Soft Key
Note: the cBarge softkey is enabled in its default state, however, use the following config to change the order of the soft ke displayed during the "remote-in-use" state.
ephone-template 1
softkeys remote-in-use CBarge Newcall
softkeys hold Resume Newcall Join
softkeys connected TrnsfVM Park Acct ConfList Confrn Endcall Trnsfer Hold
max-calls-per-button 3
busy-trigger-per-button 2
!
ephone 12
no phone-ui speeddial-fastdial
ephone-template 1
mac-address 000C.1234.5678
type 7960
button 1:8 2:4
SIP Sample Configuration: Barge and cBarge Softkeys
Note: the Barge and cBarge softkey is enabled in its default state, however, use the following config to change the order of the soft ke displayed during the "remote-in-use" state.
voice register template 1
softkeys hold Resume Newcall
softkeys connected Trnsfer Park Hold
softkeys remote-in-use cBarge Barge
!
voice register pool 120
id mac 000C.1234.5678
type 7962
number 1 dn 12
template 1
SCCP Sample Configuration: Turn on Privacy on Hold and Privacy
The following example disables privacy globally, but enables it on ephone 8.
telephony-service
no privacy
privacy-on-hold
max-ephones 80
max-dn 200
timeouts transfer-recall 60
voicemail 5999
max-conferences 8 gain -6
transfer-system full-consult
fac standard
!
ephone 8
privacy on
privacy-button
max-calls-per-button 3
busy-trigger-per-button 2
mac-address 000C.1234.5678
type 7960
button 1:4 2:8
SIP Sample Configuration: Enabling Privacy on Hold and Privacy
The following example disables privacy globally, and enables it on an individual phone.
voice register global
mode cme
privacy-on-hold
no privacy
max-dn 200
max-pool 100
voicemail 5999
!
voice register pool 130
id mac 000C.1234.5678
type 7941
number 1 dn 8
privacy ON
privacy-button
More Information
Configuring Barge and Privacy
NOTE: If a phone that is using the shared line has Privacy enabled, call information does not appear on the other phones that share the line and the call cannot be barged.
NOTE: CME version 7.0 or later is needed for SCCP support, CME version 7.1 needed for SIP support (Barge, cBarge, and Privacy)
Barge uses the built-in conference bridge on the target phone (the phone that is being barged) which limits the number of users allowed to barge. A barge conference supports up to three parties. If more users want to join a call on a SIP shared line, cBarge must be used. The SIP phone requires the built-in conference bridge to use Barge. Barge is supported for SIP shared-line directory numbers only.
cBarge Overview
The cBarge feature uses a shared conference resource which allows more that one person to barge into the call. A cBarge conference supports the maximum number of parties provisioned on the centralized conference resource. The centralized conference resource must be provisioned to use cBarge. cBarge is supported on SCCP shared octo-line directory numbers and SIP shared-line directory numbers.
When any party releases from the call, the call remains a conference call if at least three participants remain on the line. If only two parties remain in the conference, they are reconnected as a point-to-point call, which releases the conference bridge resources. When the target party parks the call or joins the call with another call, the barge initiator and the other parties remain connected.
Privacy
The privacy feature enables phone users to block other users who share a directory number from seeing call information, resuming a call, or barging into a call on the shared line. When a phone receives an incoming call on a shared line, the user can make the call private by pressing the Privacy feature button, which toggles between on and off to allow the user to alter the privacy setting on their phone. The privacy state is applied to all new calls and current calls owned by the phone user. Privacy is supported on SCCP octo-line directory numbers and SIP shared-line directory numbers.
Privacy is enabled for all phones in the system by default. You can disable privacy globally and enable it only for specific phones, either individually or through an phone template. You can also enable the privacy button on specific phones. After a phone with the privacy button enabled registers with Cisco Unified CME, the line feature button on the phone gets labeled "Privacy," a status icon displays, and if the button has a monitor lamp, it lights when privacy is active. For Extension Mobility phones, you can enable the privacy button in the user profile and logout profile.
The Privacy on Hold feature prevents other phone users from viewing call information or retrieving a call put on hold by another phone sharing the directory number. Privacy on Hold is disabled for all phones in the system by default. You can enable Privacy on Hold globally for all phones. To disable Privacy on Hold on individual phones, you must disable Privacy on those phones.
The Privacy feature applies to all shared lines on a phone. If a phone has multiple shared lines and Privacy is enabled, other phones cannot view or barge into calls on any of the shared lines.
SCCP Sample Configuration: cBarge Soft Key
Note: the cBarge softkey is enabled in its default state, however, use the following config to change the order of the soft ke displayed during the "remote-in-use" state.
ephone-template 1
softkeys remote-in-use CBarge Newcall
softkeys hold Resume Newcall Join
softkeys connected TrnsfVM Park Acct ConfList Confrn Endcall Trnsfer Hold
max-calls-per-button 3
busy-trigger-per-button 2
!
ephone 12
no phone-ui speeddial-fastdial
ephone-template 1
mac-address 000C.1234.5678
type 7960
button 1:8 2:4
SIP Sample Configuration: Barge and cBarge Softkeys
Note: the Barge and cBarge softkey is enabled in its default state, however, use the following config to change the order of the soft ke displayed during the "remote-in-use" state.
voice register template 1
softkeys hold Resume Newcall
softkeys connected Trnsfer Park Hold
softkeys remote-in-use cBarge Barge
!
voice register pool 120
id mac 000C.1234.5678
type 7962
number 1 dn 12
template 1
SCCP Sample Configuration: Turn on Privacy on Hold and Privacy
The following example disables privacy globally, but enables it on ephone 8.
telephony-service
no privacy
privacy-on-hold
max-ephones 80
max-dn 200
timeouts transfer-recall 60
voicemail 5999
max-conferences 8 gain -6
transfer-system full-consult
fac standard
!
ephone 8
privacy on
privacy-button
max-calls-per-button 3
busy-trigger-per-button 2
mac-address 000C.1234.5678
type 7960
button 1:4 2:8
SIP Sample Configuration: Enabling Privacy on Hold and Privacy
The following example disables privacy globally, and enables it on an individual phone.
voice register global
mode cme
privacy-on-hold
no privacy
max-dn 200
max-pool 100
voicemail 5999
!
voice register pool 130
id mac 000C.1234.5678
type 7941
number 1 dn 8
privacy ON
privacy-button
More Information
Configuring Barge and Privacy
CUCME Features: Automatic Line Selection
By default, when you are using a multiline IP phone, lifting the handset will automatically answer the first ringing line on the phone. Furthermore, if no line is in a ringing state, it will select the first available line for an outgoing call instead.
Sometimes, you may not want this behavior. For example, you may want to make an outgoing call while one of the phone lines is ringing. Or, it may simply become a matter of user preference. Luckily, within Cisco Unified CME, there are options.
The Automatic Line Selection feature allows you to specify the behavior of the phone when the handset is lifted. This is a per-phone setting.
Automatic Line Selection Options
Automatic Line Sample Configuration
The following example assigns no automatic line selection to phone 1, the default automatic line selection behavior to phone 2, and assigns automatic line selection for incoming calls only to phone 3:
ephone 1
mac-address 1111.2222.3333
button 1:1 2:3 3:21
no auto-line
!
ephone 2
mac-address 4444.5555.6666
button 1:4 2:3 3:21
!
ephone 3
mac-address 7777.8888.9999
button 1:6 2:3 3:21
auto-line incoming
The following example enables automatic selection of line button 1 when the handset is lifted to answer incoming calls or to make outgoing calls.
ephone 1
mac-address 1111.2222.3333
type 7960
auto-line 1 answer-incoming
button 1:1 2:2 3:3
More Information
Configuring Automatic Line Selection
Sometimes, you may not want this behavior. For example, you may want to make an outgoing call while one of the phone lines is ringing. Or, it may simply become a matter of user preference. Luckily, within Cisco Unified CME, there are options.
The Automatic Line Selection feature allows you to specify the behavior of the phone when the handset is lifted. This is a per-phone setting.
Automatic Line Selection Options
- auto-line : Picking up the handset answers the first ringing line or, if no line is ringing, selects the first idle line. (default)
- no auto-line : Pressing the Answer soft key answers the first ringing line, and pressing a line button selects a line for an outgoing call. Picking up the handset does not answer calls or provide dial tone.
- auto-line incoming : Picking up the handset answers the first ringing line, but if no line is ringing, it does not select an idle line for an outgoing call. Pressing a line button selects a line for an outgoing call.
- auto-line button-number : Picking up the handset for an outgoing call selects the line associated with the button-number argument. If a button number is specified and the line associated with that button is unavailable (because it is a shared line in use on another phone), no dial tone is heard when the handset is lifted. You must press an available line button to make an outgoing call. Incoming calls must be answered by pressing the Answer soft key or pressing a ringing line button.
- auto-line answer-incoming : Pressing the Answer soft key or picking up the handset answers an incoming call on the line associated with the specified button. Picking up the handset for outgoing calls selects the line associated with the specified button.
Automatic Line Sample Configuration
The following example assigns no automatic line selection to phone 1, the default automatic line selection behavior to phone 2, and assigns automatic line selection for incoming calls only to phone 3:
ephone 1
mac-address 1111.2222.3333
button 1:1 2:3 3:21
no auto-line
!
ephone 2
mac-address 4444.5555.6666
button 1:4 2:3 3:21
!
ephone 3
mac-address 7777.8888.9999
button 1:6 2:3 3:21
auto-line incoming
The following example enables automatic selection of line button 1 when the handset is lifted to answer incoming calls or to make outgoing calls.
ephone 1
mac-address 1111.2222.3333
type 7960
auto-line 1 answer-incoming
button 1:1 2:2 3:3
More Information
Configuring Automatic Line Selection
Enabling the GUI in the Cisco Unified CME
This post will explain how to enable the CUCME graphical user interface for administrators and users alike. While a lot of network administrators cringe at the thought of using anything but the CLI, there is a definite benefit to giving a customer administrator and/or phone users access to make changes.
The Cisco Unified CME GUI provides a web-based interface to manage most system-level and phone-based features. In particular, the GUI facilitates the routine additions and changes associated with employee turnover, allowing these changes to be performed by nontechnical staff. The GUI provides three levels of access to support the following user classes:
The CUCME GUI files must be on the router's flash already. See this Cisco document for details if you have not done so already.
To use a phone user account in the Cisco Unified CME GUI to configure speed dials on a phone that is enabled for Extension Mobility, Cisco Unified CME GUI 4.2.1 or a later version must be installed on the Cisco router.
GUI files are version-specific, they must match the version of Cisco Unified CME that is installed.
Sample Configuration to Enable CUCME GUI
conf t
!
ip http server
ip http path flash:
ip http authentication enable (variety of auth options here)
!
telephony-service
web admin system name cmeadmin 0 cmepasswd
dn-webedit (enables creation of DNs via the GUI)
time-webedit (only use this if network NTP source is not available)
end
!
Accessing the CUCME
http://router_ip/ccme.html
For example:
http://192.168.10.1/ccme.html
Note: Only the Internet Explorer browser (version 5.5 and later) is supported
Enable GUI Access for Customer Administrators
Creating an account for customer administrators can be done via the GUI or CLI. The CLI example is shown below.
conf t
!
telephony-service
web admin customer name JoeCust password JCPwd
end
!
Enable GUI Access for Phone Users
Creating an account for phone users can be done via the GUI or CLI. The CLI example is shown below. Keep in mind that the "JoeUser" account will only have access to modify aspects ephone 1001.
conf t
!
ephone 1001
username JoeUser password JPswd
end
!
More Information
Cisco Unified Communications Manager Express System Administrator's Guide
The Cisco Unified CME GUI provides a web-based interface to manage most system-level and phone-based features. In particular, the GUI facilitates the routine additions and changes associated with employee turnover, allowing these changes to be performed by nontechnical staff. The GUI provides three levels of access to support the following user classes:
- System administrator—Able to configure all system-level and phone-based features. This person is familiar with Cisco IOS software and VoIP network configuration.
- Customer administrator—Able to perform routine phone additions and changes without having access to system-level features. This person does not have to be familiar with Cisco IOS software.
- Phone user—Able to program a small set of features on his or her own phone and search the Cisco Unified CME directory. In Cisco Unified CME GUI 4.2.1 and later versions, phone users can use the GUI to set up personal speed dials for an Extension Mobility phone. The same credential for logging into an Extension Mobility phone can be used to log into the Cisco Unified CME GUI.
The CUCME GUI files must be on the router's flash already. See this Cisco document for details if you have not done so already.
To use a phone user account in the Cisco Unified CME GUI to configure speed dials on a phone that is enabled for Extension Mobility, Cisco Unified CME GUI 4.2.1 or a later version must be installed on the Cisco router.
GUI files are version-specific, they must match the version of Cisco Unified CME that is installed.
Sample Configuration to Enable CUCME GUI
conf t
!
ip http server
ip http path flash:
ip http authentication enable (variety of auth options here)
!
telephony-service
web admin system name cmeadmin 0 cmepasswd
dn-webedit (enables creation of DNs via the GUI)
time-webedit (only use this if network NTP source is not available)
end
!
Accessing the CUCME
http://router_ip/ccme.html
For example:
http://192.168.10.1/ccme.html
Note: Only the Internet Explorer browser (version 5.5 and later) is supported
Enable GUI Access for Customer Administrators
Creating an account for customer administrators can be done via the GUI or CLI. The CLI example is shown below.
conf t
!
telephony-service
web admin customer name JoeCust password JCPwd
end
!
Enable GUI Access for Phone Users
Creating an account for phone users can be done via the GUI or CLI. The CLI example is shown below. Keep in mind that the "JoeUser" account will only have access to modify aspects ephone 1001.
conf t
!
ephone 1001
username JoeUser password JPswd
end
!
More Information
Cisco Unified Communications Manager Express System Administrator's Guide
Configuring Class of Restrictions (COR) in SRST and CUCME
Often times in a unified communications environment, a lot of time is spent ensuring that IP phones are place within the proper partitions and calling search spaces to ensure that users are restricted to only authorized types of calls when they are registered to the corporate call-manager cluster. For example, the marketing director will be able to make international calls while perhaps the facilities engineer can only make local and long distance calls.
What happens when the phone cannot reach the call manager (for any reason really)? Well, hopefully there is some fault tolerance built into your design. The IP phone likely has an SRST gateway defined and will loyally register to the SRST gateway in the event that it cannot reach the call-manager.
By default, what kind of call can the user place from an SRST-registered IP Phone? Well, if you have not implemented any kind of restrictions - they can call ANYWHERE.
Imagine a fiber cut that is going to take the local provider a couple of days to restore. This cut has prevented your IP Phones from reaching your call-manager. Luckily, you have a functioning SRST gateway local to the phones. Unluckily, even your lobby phones can now make international calls! Your phone just rang and your manager's manager wants to know how to stop this!
Class of Restrictions (COR) Overview
Class of Restrictions (COR) is a Cisco voice gateway feature that enables Class of Service (COS) or calling privileges to be assigned. It is most commonly used with Cisco Survivable Remote Site Telephony (SRST) and Cisco CallManager Express but can be applied to any dial peer.
COR is often described as a lock and key mechanism. Locks are assigned to dial peers with an outgoing COR list. Keys are assigned to dial peers with an incoming COR list.
The COR feature provides the ability to deny certain call attempts based on the incoming and outgoing CORs provisioned on the dial-peers. COR is required only when you want to restrict the ability of some phones to make certain types of calls but allow other phones to place those calls.
COR is used to specify which incoming dial-peer can use which outgoing dial-peer to make a call. Each dial-peer can be provisioned with an incoming and an outgoing COR list. The corlist command sets the dial-peer COR parameter for dial-peers and the directory numbers that are created for Cisco IP phones associated with the Cisco CallManager Express router. COR functionality provides the ability to deny certain call attempts on the basis of the incoming and outgoing CORs that are provisioned on the dial-peers.
If the COR applied on an incoming dial-peer (for incoming calls) is a super set or equal to the COR applied to the outgoing dial-peer (for outgoing calls), the call goes through.
WARNING, WARNING: By default, an incoming call leg has the highest COR priority and the outgoing COR list has the lowest COR priority. This means that if there is no COR configuration for incoming calls on a dial-peer, then you can make a call from this dial-peer (a phone attached to this dial-peer) going out of any other dial-peer, irrespective of the COR configuration on that dial-peer.
Class of Restriction (COR) Configuration
With this configuration:
dial-peer cor custom
name emergency
name local_call
name call1800
name call1900
!
dial-peer cor list Manager
member emergency
member local_call
member call1800
member call1900
!
dial-peer cor list Facilities
member emergency
member local_call
member call1800
!
dial-peer cor list Guest
member emergency
member local_call
!
dial-peer voice 1 voip
destination-pattern 408….
session target ipv4:1.1.1.1
corlist outgoing calllocal
!
dial-peer voice 2 voip
destination-pattern 1800…
session target ipv4:1.1.1.1
corlist outgoing call1800
!
dial-peer voice 3 pots
destination-pattern 1900…
port 1/0/0
corlist outgoing call1900
!
dial-peer voice 4 pots
destination-pattern 911
port 1/0/1
corlist outgoing emergency
!
dial-peer voice 5 pots
destination-pattern 316….
port 1/1/0
!
ephone-dn 1
number 1001
cor incoming Manager
!
ephone-dn 2
number 1002
cor incoming Facilities
!
ephone-dn 3
number 1003
cor incoming Guest
!
ephone-dn 4
number 1004
More Information
Configuring Class of Restrictions
What happens when the phone cannot reach the call manager (for any reason really)? Well, hopefully there is some fault tolerance built into your design. The IP phone likely has an SRST gateway defined and will loyally register to the SRST gateway in the event that it cannot reach the call-manager.
By default, what kind of call can the user place from an SRST-registered IP Phone? Well, if you have not implemented any kind of restrictions - they can call ANYWHERE.
Imagine a fiber cut that is going to take the local provider a couple of days to restore. This cut has prevented your IP Phones from reaching your call-manager. Luckily, you have a functioning SRST gateway local to the phones. Unluckily, even your lobby phones can now make international calls! Your phone just rang and your manager's manager wants to know how to stop this!
Class of Restrictions (COR) Overview
Class of Restrictions (COR) is a Cisco voice gateway feature that enables Class of Service (COS) or calling privileges to be assigned. It is most commonly used with Cisco Survivable Remote Site Telephony (SRST) and Cisco CallManager Express but can be applied to any dial peer.
COR is often described as a lock and key mechanism. Locks are assigned to dial peers with an outgoing COR list. Keys are assigned to dial peers with an incoming COR list.
The COR feature provides the ability to deny certain call attempts based on the incoming and outgoing CORs provisioned on the dial-peers. COR is required only when you want to restrict the ability of some phones to make certain types of calls but allow other phones to place those calls.
COR is used to specify which incoming dial-peer can use which outgoing dial-peer to make a call. Each dial-peer can be provisioned with an incoming and an outgoing COR list. The corlist command sets the dial-peer COR parameter for dial-peers and the directory numbers that are created for Cisco IP phones associated with the Cisco CallManager Express router. COR functionality provides the ability to deny certain call attempts on the basis of the incoming and outgoing CORs that are provisioned on the dial-peers.
If the COR applied on an incoming dial-peer (for incoming calls) is a super set or equal to the COR applied to the outgoing dial-peer (for outgoing calls), the call goes through.
WARNING, WARNING: By default, an incoming call leg has the highest COR priority and the outgoing COR list has the lowest COR priority. This means that if there is no COR configuration for incoming calls on a dial-peer, then you can make a call from this dial-peer (a phone attached to this dial-peer) going out of any other dial-peer, irrespective of the COR configuration on that dial-peer.
Class of Restriction (COR) Configuration
With this configuration:
- dn 1001 can call all numbers
- dn 1002 can call all number except "call1900"
- dn 1003 can call only emergency and local calls
- dn 1004 can call all numbers (has no corlist applied)
dial-peer cor custom
name emergency
name local_call
name call1800
name call1900
!
dial-peer cor list Manager
member emergency
member local_call
member call1800
member call1900
!
dial-peer cor list Facilities
member emergency
member local_call
member call1800
!
dial-peer cor list Guest
member emergency
member local_call
!
dial-peer voice 1 voip
destination-pattern 408….
session target ipv4:1.1.1.1
corlist outgoing calllocal
!
dial-peer voice 2 voip
destination-pattern 1800…
session target ipv4:1.1.1.1
corlist outgoing call1800
!
dial-peer voice 3 pots
destination-pattern 1900…
port 1/0/0
corlist outgoing call1900
!
dial-peer voice 4 pots
destination-pattern 911
port 1/0/1
corlist outgoing emergency
!
dial-peer voice 5 pots
destination-pattern 316….
port 1/1/0
!
ephone-dn 1
number 1001
cor incoming Manager
!
ephone-dn 2
number 1002
cor incoming Facilities
!
ephone-dn 3
number 1003
cor incoming Guest
!
ephone-dn 4
number 1004
More Information
Configuring Class of Restrictions
Max-Ephones Command Behavior in CUCME
The max-ephones command within CUCME has been upgraded as of CUCME version 4.3 (and later). So, if you've had some experience with this command on some of the older CUCME versions, you will want to pay close attention to how this command works in the most recent release(s). This translates to roughly IOS version 12.4(15)XZ and later.
Cisco Unified CME and Cisco IOS Compatibility Matrix
Download CME Software (requires CCO account and authorized contract)
Prior to the CUCME 4.3 Release
Prior to Cisco Unified CME 4.3, the max-ephones command specified both the maximum number of SCCP phones that can be registered AND configured.
What Changed?
In Cisco Unified CME 4.3 and later versions, the max-ephones command is enhanced to set the maximum number of SCCP phones that can register to Cisco Unified CME, without limiting the number that can be configured.
Also, the number of SCCP phones that can be configured is no longer limited to the maximum number that can be registered. Also, it is not limited to the hardware platform. This change expands the maximum number of phones that can be configured to 1000.
However, the maximum number of phones that can register to CUCME is still dependent on the number of phones supported by the hardware platform and is limited by the max-ephones command.
This enhancement supports features such as Extension Assigner that require you to configure more phones than can register. For example, if you set the max-ephones command to 40 and configure 80 ephones, only 40 phones can register to Cisco Unified CME, one at a time in random order. The remaining 40 phones cannot register and an error message displays for each rejected phone. This enhancement also allows you to assign ephone tags that match the extension number of the phone, for extensions up to 1000. (Yes, I agree. That would be a fun router config to deal with.)
What Happens If I Change Max-Ephones?
If you reduce the value of the max-ephones command, currently registered phones are not forced to unregister until a reboot. If the number of registered phones, however, is already equal to or more than the max-ephones value, no additional phones can register to Cisco Unified CME. If you increase the value of the max-ephones command, the previously rejected ephones are able to register immediately until the new limit is reached.
What is Extension Assigner?
Extension Assigner is a feature that gives installation techs the ability to assign extension numbers without needing administrative access to the Cisco Unified CME, typically during the installation of new phones or the replacement of broken phones. However, before the feature can be used, the system administrator must first configure Cisco Unified CME to allow specific extensions to be assigned. The system administrator must also provide the installation technician with the information necessary for assigning extension numbers to phones. The installation technician can then assign extension numbers to phones with access to only the phones themselves and with no further intervention from the administrator.
Extension Assigner Details
More Information
Cisco Unified Communications Manager Express System Guide
Cisco Unified CME and Cisco IOS Compatibility Matrix
Download CME Software (requires CCO account and authorized contract)
Prior to the CUCME 4.3 Release
Prior to Cisco Unified CME 4.3, the max-ephones command specified both the maximum number of SCCP phones that can be registered AND configured.
What Changed?
In Cisco Unified CME 4.3 and later versions, the max-ephones command is enhanced to set the maximum number of SCCP phones that can register to Cisco Unified CME, without limiting the number that can be configured.
Also, the number of SCCP phones that can be configured is no longer limited to the maximum number that can be registered. Also, it is not limited to the hardware platform. This change expands the maximum number of phones that can be configured to 1000.
However, the maximum number of phones that can register to CUCME is still dependent on the number of phones supported by the hardware platform and is limited by the max-ephones command.
This enhancement supports features such as Extension Assigner that require you to configure more phones than can register. For example, if you set the max-ephones command to 40 and configure 80 ephones, only 40 phones can register to Cisco Unified CME, one at a time in random order. The remaining 40 phones cannot register and an error message displays for each rejected phone. This enhancement also allows you to assign ephone tags that match the extension number of the phone, for extensions up to 1000. (Yes, I agree. That would be a fun router config to deal with.)
What Happens If I Change Max-Ephones?
If you reduce the value of the max-ephones command, currently registered phones are not forced to unregister until a reboot. If the number of registered phones, however, is already equal to or more than the max-ephones value, no additional phones can register to Cisco Unified CME. If you increase the value of the max-ephones command, the previously rejected ephones are able to register immediately until the new limit is reached.
What is Extension Assigner?
Extension Assigner is a feature that gives installation techs the ability to assign extension numbers without needing administrative access to the Cisco Unified CME, typically during the installation of new phones or the replacement of broken phones. However, before the feature can be used, the system administrator must first configure Cisco Unified CME to allow specific extensions to be assigned. The system administrator must also provide the installation technician with the information necessary for assigning extension numbers to phones. The installation technician can then assign extension numbers to phones with access to only the phones themselves and with no further intervention from the administrator.
Extension Assigner Details
More Information
Cisco Unified Communications Manager Express System Guide
Cisco CUCM NTP Configuration
Properly configuring your CUCM server to get time from a valid time source via NTP is an easily overlooked CUCM configuration step. You can inherit all kinds of problems down the road if you do not synchronize all of the network and voice devices within your solution.
This post is intended to give you a quick walk-through on how to configure CUCM to use an external NTP server to synchronize it's time.
Note: Do not confuse this with "Phone NTP References". You can optionally configure phone Network Time Protocol (NTP) references in Cisco Unified Communications Manager Administration to ensure that a phone that is running SIP gets its date and time from the NTP server. If you choose not to do so, SIP phones will get time from the 200 OK SIP messages they receive.
Cisco CUCM NTP Configuration Steps
CUCM NTP Verification
From the CLI, use the utils ntp status command as shown below. In the example shown, the CUCM server is synchronized to NTP server (171.68.10.80) at stratum 3.
You can run this on each server within the cluster and you should see that the CUCM Publisher is synchronized with the NTP server entered above.
All other servers in the cluster will be synchronized with the CUCM Publisher.
Related Posts:
Cisco IOS NTP Overview
Cisco IOS NTP Configuration
This post is intended to give you a quick walk-through on how to configure CUCM to use an external NTP server to synchronize it's time.
Note: Do not confuse this with "Phone NTP References". You can optionally configure phone Network Time Protocol (NTP) references in Cisco Unified Communications Manager Administration to ensure that a phone that is running SIP gets its date and time from the NTP server. If you choose not to do so, SIP phones will get time from the 200 OK SIP messages they receive.
Cisco CUCM NTP Configuration Steps
- Access the "Cisco Unified OS Administrator" on the CUCM Publisher.
- Settings > NTP Servers
- NTP Server Settings: [ enter the IP Address of the NTP server here ]
CUCM NTP Verification
From the CLI, use the utils ntp status command as shown below. In the example shown, the CUCM server is synchronized to NTP server (171.68.10.80) at stratum 3.
admin:utils ntp status
ntpd (pid 30521) is running...
remote refid st t when poll reach delay offset jitter
===========================================================
ntpd (pid 30521) is running...
remote refid st t when poll reach delay offset jitter
===========================================================
*171.68.10.80 10.81.254.131 2 u 780 1024 377 49.199 -1.620 0.456
synchronised to NTP server (171.68.10.80) at stratum 3
time correct to within 45 ms
polling server every 1024 s
Current time in UTC is : Thu May 27 16:59:47 UTC 2010
Current time in America/Chicago is : Thu May 27 11:59:47 CDT 2010
synchronised to NTP server (171.68.10.80) at stratum 3
time correct to within 45 ms
polling server every 1024 s
Current time in UTC is : Thu May 27 16:59:47 UTC 2010
Current time in America/Chicago is : Thu May 27 11:59:47 CDT 2010
You can run this on each server within the cluster and you should see that the CUCM Publisher is synchronized with the NTP server entered above.
All other servers in the cluster will be synchronized with the CUCM Publisher.
Related Posts:
Cisco IOS NTP Overview
Cisco IOS NTP Configuration
Cisco IOS NTP Configuration
Maintaining time synchronization across all of your network (and telephony) devices is absolutely critical to properly maintain (and troubleshoot) the overall solution. However, there is quite a bit of variety in how NTP can be configured. This post contains a list of the various features, and sample configurations for each.
Poll-Based NTP Association
Devices on your network can configured to obtain time information in a two basic ways: by polling host servers or by listening for NTP broadcasts. This section discusses the poll-based association mode.
Router(config)# ntp server ip-address [version number] [key keyid] [source interface] [prefer]
When a networking device is operating in the client mode, it polls its assigned time serving hosts for the current time. The networking device will then pick a host from all the polled time servers to synchronize with. Because the relationship that is established in this case is a client-host relationship, the host will not capture or use any time information sent by the local client device. This mode is most suited for file-server and workstation clients that are not required to provide any form of time synchronization to other local clients. Use the ntp server command to individually specify the time-serving hosts that you want your networking device to consider synchronizing with and to set your networking device to operate in the client mode.
Router(config)# ntp server ip-address [version number] [key keyid] [source interface] [prefer]
When a networking device is operating in the symmetric active mode, it polls its assigned time serving hosts for the current time and it responds to polls by its hosts. Because this is a peer-to-peer relationship, the host will also retain time-related information about the local networking device that it is communicating with. This mode should be used when a number of mutually redundant servers are interconnected via diverse network paths. Most stratum 1 and stratum 2 servers on the Internet adopt this form of network setup. Use the ntp peer command to individually specify the time serving hosts that you want your networking device to consider synchronizing with and to set your networking device to operate in the symmetric active mode.
Router(config)# ntp peer ip-address [normal-sync] [version number] [key keyid] [source interface] [prefer]
Note: CUCM will not synchronize NTP with another device that is stratum 10 or greater.
Broadcast-Based NTP Associations
Broadcast-based NTP associations should be used when time accuracy and reliability requirements are modest and if your network is localized and has more than 20 clients. Broadcast-based NTP associations are also recommended for use on networks that have limited bandwidth, system memory, or CPU resources.
When a networking device is operating in the broadcastclient mode, it does not engage in any polling. Instead, it listens for NTP broadcast packets transmitted by broadcast time servers. Consequently, time accuracy can be marginally reduced because time information flows only one way.
Router(config-if)# ntp broadcast [version number]
Router(config-if)# ntp broadcast client
Use the ntp broadcast client command to set your networking device to listen for NTP broadcast packets propagated through a network. In order for broadcastclient mode to work, the broadcast server and its clients must be located on the same subnet. The time server that is transmitting NTP broadcast packets will also have to be enabled on the interface of the given device using the ntp broadcast command.
Router(config)# ntp broadcastdelay microseconds
The above command is used to manually set the estimated round-trip delay between the device and the NTP broadcast server.
Note: You will see the "ntp clock-period" command added automatically to your IOS configuration. This simply reflects the constantly changing correction factor used when NTP synchronizes the time. Do not try to manually change this value.
Disable NTP On An Interface
By default, NTP is disabled on all interfaces by default. However, once any NTP commands are entered into the IOS configuration, NTP will be enabled on all interfaces.
To selectively disable the router's ability to accept an NTP packet on a specific interface:
Router(config-if)# ntp disable
Selecting the Source IP Address Used to Send NTP
Normally, when the system sends an NTP packet, it uses the interface from which the packet is being sent. If you'd like to manually configure the address that is used to source all NTP packets egressing the router (perhaps to allow remote systems to configure a common access-list):
Router(config)# ntp source interface
Establish the Router as an Authoritative NTP Source
If an authoritative public NTP server cannot be reached by your network devices, you'll want to specific a device or two within your network to be authoritative for the rest of the network.
Keep in mind that a very low stratum value could potentially cause the new NTP master to override other devices that can reach a valid public authoritative NTP Source. The default stratum is 8.
Router(config)# ntp master [stratum]
Update the Hardware Clock
For devices that have system calendars (hardware clocks), it is advisable to have the NTP-learned software clock update it periodically. The software clock will be more accurate over time than a hardware clock.
Router(config)# ntp update-calendar
Monitoring NTP Associations
These commands will give you an indication of how your NTP service is performing on the router. To see if an NTP client is properly synchronizing with a peer, use the show ntp associations command. If however, you'd like to get a general status of NTP, use the show ntp status command.
Router# show ntp associations [detail]
Router# show ntp status
NTP Sample Configurations
In the following example, a router with a system calendar has server associations with two other systems, transmits broadcast NTP packets, and periodically updates the calendar:
clock timezone PST -8
clock summer-time PDT recurring
ntp update-calendar
ntp server 192.168.13.57
ntp server 192.168.11.58
interface Ethernet 0/0
ntp broadcast
In the following example, a router with a system calendar has no outside time source, so it uses the calendar as an authoritative time source and distributes the time via NTP broadcast packets.
clock timezone MET 2
clock calendar-valid
ntp master
interface fddi 0/0
ntp broadcast
Relevant Posts
Cisco CUCM NTP Configuration
Cisco IOS NTP Overview
More Information
Cisco IOS Network Management Configuration Guide, Release 12.4
Poll-Based NTP Association
Devices on your network can configured to obtain time information in a two basic ways: by polling host servers or by listening for NTP broadcasts. This section discusses the poll-based association mode.
Router(config)# ntp server ip-address [version number] [key keyid] [source interface] [prefer]
When a networking device is operating in the client mode, it polls its assigned time serving hosts for the current time. The networking device will then pick a host from all the polled time servers to synchronize with. Because the relationship that is established in this case is a client-host relationship, the host will not capture or use any time information sent by the local client device. This mode is most suited for file-server and workstation clients that are not required to provide any form of time synchronization to other local clients. Use the ntp server command to individually specify the time-serving hosts that you want your networking device to consider synchronizing with and to set your networking device to operate in the client mode.
Router(config)# ntp server ip-address [version number] [key keyid] [source interface] [prefer]
When a networking device is operating in the symmetric active mode, it polls its assigned time serving hosts for the current time and it responds to polls by its hosts. Because this is a peer-to-peer relationship, the host will also retain time-related information about the local networking device that it is communicating with. This mode should be used when a number of mutually redundant servers are interconnected via diverse network paths. Most stratum 1 and stratum 2 servers on the Internet adopt this form of network setup. Use the ntp peer command to individually specify the time serving hosts that you want your networking device to consider synchronizing with and to set your networking device to operate in the symmetric active mode.
Router(config)# ntp peer ip-address [normal-sync] [version number] [key keyid] [source interface] [prefer]
Note: CUCM will not synchronize NTP with another device that is stratum 10 or greater.
Broadcast-Based NTP Associations
Broadcast-based NTP associations should be used when time accuracy and reliability requirements are modest and if your network is localized and has more than 20 clients. Broadcast-based NTP associations are also recommended for use on networks that have limited bandwidth, system memory, or CPU resources.
When a networking device is operating in the broadcastclient mode, it does not engage in any polling. Instead, it listens for NTP broadcast packets transmitted by broadcast time servers. Consequently, time accuracy can be marginally reduced because time information flows only one way.
Router(config-if)# ntp broadcast [version number]
Router(config-if)# ntp broadcast client
Use the ntp broadcast client command to set your networking device to listen for NTP broadcast packets propagated through a network. In order for broadcastclient mode to work, the broadcast server and its clients must be located on the same subnet. The time server that is transmitting NTP broadcast packets will also have to be enabled on the interface of the given device using the ntp broadcast command.
Router(config)# ntp broadcastdelay microseconds
The above command is used to manually set the estimated round-trip delay between the device and the NTP broadcast server.
Note: You will see the "ntp clock-period" command added automatically to your IOS configuration. This simply reflects the constantly changing correction factor used when NTP synchronizes the time. Do not try to manually change this value.
Disable NTP On An Interface
By default, NTP is disabled on all interfaces by default. However, once any NTP commands are entered into the IOS configuration, NTP will be enabled on all interfaces.
To selectively disable the router's ability to accept an NTP packet on a specific interface:
Router(config-if)# ntp disable
Selecting the Source IP Address Used to Send NTP
Normally, when the system sends an NTP packet, it uses the interface from which the packet is being sent. If you'd like to manually configure the address that is used to source all NTP packets egressing the router (perhaps to allow remote systems to configure a common access-list):
Router(config)# ntp source interface
Establish the Router as an Authoritative NTP Source
If an authoritative public NTP server cannot be reached by your network devices, you'll want to specific a device or two within your network to be authoritative for the rest of the network.
Keep in mind that a very low stratum value could potentially cause the new NTP master to override other devices that can reach a valid public authoritative NTP Source. The default stratum is 8.
Router(config)# ntp master [stratum]
Update the Hardware Clock
For devices that have system calendars (hardware clocks), it is advisable to have the NTP-learned software clock update it periodically. The software clock will be more accurate over time than a hardware clock.
Router(config)# ntp update-calendar
Monitoring NTP Associations
These commands will give you an indication of how your NTP service is performing on the router. To see if an NTP client is properly synchronizing with a peer, use the show ntp associations command. If however, you'd like to get a general status of NTP, use the show ntp status command.
Router# show ntp associations [detail]
Router# show ntp status
NTP Sample Configurations
In the following example, a router with a system calendar has server associations with two other systems, transmits broadcast NTP packets, and periodically updates the calendar:
clock timezone PST -8
clock summer-time PDT recurring
ntp update-calendar
ntp server 192.168.13.57
ntp server 192.168.11.58
interface Ethernet 0/0
ntp broadcast
In the following example, a router with a system calendar has no outside time source, so it uses the calendar as an authoritative time source and distributes the time via NTP broadcast packets.
clock timezone MET 2
clock calendar-valid
ntp master
interface fddi 0/0
ntp broadcast
Relevant Posts
Cisco CUCM NTP Configuration
Cisco IOS NTP Overview
More Information
Cisco IOS Network Management Configuration Guide, Release 12.4
Cisco IOS NTP Overview
Proper management and operation of a Cisco Unified Communication solution requires that a common time source is used throughout all systems. This is ultimately necessary so that log, traces, debugs, etc., can be compared between devices to aid in troubleshooting and accurate statistical gathering.
Keep in mind that you will want your Cisco Unified Communication servers and equipments to have a synchronized time source with the underlying network equipment. This primer should get your understanding of NTP juices flowing. I will touch on configuring an NTP time source within CUCM in a later post.
Most Cisco routers have two clocks: a battery-powered hardware clock (referenced in CLI commands as the "calendar") and a software clock (referenced in CLI commands as the "clock"). These two clocks are managed separately.
The primary source for time data on your system is the software clock. This clock runs from the moment the system starts up and keeps track of the current date and time. The software clock can be set from a number of sources and in turn can be used to distribute the current time through various mechanisms to other systems. When a router with a hardware clock is initialized or rebooted, the software clock is initially set based on the time in the hardware clock. Your software clocks can therefore be coordinated using a valid NTP source.
The software clock keeps track of time internally based on Coordinated Universal Time (UTC), also known as Greenwich Mean Time (GMT). You can configure information about the local time zone and summer time (daylight saving time) so that the time is displayed correctly relative to the local time zone. However, if you have any plans to deploy routers across multiple time zones, I'd recommend that you use UTC/GMT as a basis throughout your solution.
NTP Overview
The NTP is a protocol designed to time-synchronize a network of machines. NTP runs over UDP port 123, which in turn runs over IP. NTP Version 3 is documented in RFC 1305.
An NTP network usually gets its time from an authoritative time source, such as a radio clock or an atomic clock attached to a time server. NTP then distributes this time across the network. NTP is extremely efficient; no more than one packet per minute is necessary to synchronize two machines to the accuracy of within a millisecond of one another.
NTP uses the concept of a "stratum" to describe how many NTP "hops" away a machine is from an authoritative time source. A "stratum 1" time server typically has an authoritative time source (such as a radio or atomic clock, or a Global Positioning System (GPS) time source) directly attached, a "stratum 2" time server receives its time via NTP from a "stratum 1" time server, and so on.
NTP has two ways to avoid synchronizing to a machine whose time may not be accurate. First, NTP will never synchronize to a machine that is not in turn synchronized itself. Second, NTP will compare the time reported by several machines, and will not synchronize to a machine whose time is significantly different than the others, even if its stratum is lower. This strategy effectively builds a self-organizing tree of NTP servers.
See the stratum(st) displayed for each ntp association below:
show ntp associations;
address ref clock st when poll reach delay offset disp
+~1.11.12.55 125.220.128.123 2 970 1024 377 -0.0 -0.42 0.3
+~1.11.12.56 125.220.128.123 2 74 1024 377 -0.0 -0.01 0.2
*~1.11.12.57 125.220.128.123 2 619 1024 377 -0.0 1.85 0.1
~1.11.12.58 125.220.128.123 2 74d 1024 0 -0.0 -0.64 16000.
* master (synced), # master (unsynced), + selected, - candidate, ~ configured
The Cisco implementation of NTP does not support stratum 1 service; in other words, it is not possible to connect to a radio or atomic clock (for some specific platforms, however, you can connect a GPS time-source device). We recommend that time service for your network be derived from the public NTP servers available in the IP Internet.
What If A Public NTP Server Cannot Be Reached?
If the network is isolated from the Internet, the Cisco implementation of NTP allows a machine to be configured so that it acts as though it is synchronized via NTP, when in fact it has determined the time using other means. Other machines can then synchronize to that machine via NTP. "Other machines" here includes CUCM, Unity, and other Cisco Unified Communications servers.
A number of manufacturers include NTP software for their host systems, and a publicly available version for systems running UNIX and its various derivatives is also available. This software also allows UNIX-derivative servers to acquire the time directly from an atomic clock, which would subsequently propagate time information along to Cisco routers.
The communications between machines running NTP (known as "associations") are usually statically configured; each machine is given the IP address of all machines with which it should form associations. Accurate timekeeping is made possible by exchanging NTP messages between each pair of machines with an association.
However, in a LAN environment, NTP can be configured to use IP broadcast messages instead. This alternative reduces configuration complexity because each machine can simply be configured to send or receive broadcast messages. However, the accuracy of timekeeping is marginally reduced because the information flow is one-way only.
The time kept on a machine is a critical resource, so we strongly recommend that you use the security features of NTP to avoid the accidental or malicious setting of incorrect time. Two mechanisms are available: an access list-based restriction scheme and an encrypted authentication mechanism.
When multiple sources of time (VINES, hardware clock, manual configuration) are available, NTP is always considered to be more authoritative. NTP time overrides the time set by any other method.
Related Posts
Cisco IOS NTP Configuration
Cisco CUCM NTP Configuration
More Information
Cisco IOS Network Management Configuration Guide, Release 12.4
Keep in mind that you will want your Cisco Unified Communication servers and equipments to have a synchronized time source with the underlying network equipment. This primer should get your understanding of NTP juices flowing. I will touch on configuring an NTP time source within CUCM in a later post.
Most Cisco routers have two clocks: a battery-powered hardware clock (referenced in CLI commands as the "calendar") and a software clock (referenced in CLI commands as the "clock"). These two clocks are managed separately.
The primary source for time data on your system is the software clock. This clock runs from the moment the system starts up and keeps track of the current date and time. The software clock can be set from a number of sources and in turn can be used to distribute the current time through various mechanisms to other systems. When a router with a hardware clock is initialized or rebooted, the software clock is initially set based on the time in the hardware clock. Your software clocks can therefore be coordinated using a valid NTP source.
The software clock keeps track of time internally based on Coordinated Universal Time (UTC), also known as Greenwich Mean Time (GMT). You can configure information about the local time zone and summer time (daylight saving time) so that the time is displayed correctly relative to the local time zone. However, if you have any plans to deploy routers across multiple time zones, I'd recommend that you use UTC/GMT as a basis throughout your solution.
NTP Overview
The NTP is a protocol designed to time-synchronize a network of machines. NTP runs over UDP port 123, which in turn runs over IP. NTP Version 3 is documented in RFC 1305.
An NTP network usually gets its time from an authoritative time source, such as a radio clock or an atomic clock attached to a time server. NTP then distributes this time across the network. NTP is extremely efficient; no more than one packet per minute is necessary to synchronize two machines to the accuracy of within a millisecond of one another.
NTP uses the concept of a "stratum" to describe how many NTP "hops" away a machine is from an authoritative time source. A "stratum 1" time server typically has an authoritative time source (such as a radio or atomic clock, or a Global Positioning System (GPS) time source) directly attached, a "stratum 2" time server receives its time via NTP from a "stratum 1" time server, and so on.
NTP has two ways to avoid synchronizing to a machine whose time may not be accurate. First, NTP will never synchronize to a machine that is not in turn synchronized itself. Second, NTP will compare the time reported by several machines, and will not synchronize to a machine whose time is significantly different than the others, even if its stratum is lower. This strategy effectively builds a self-organizing tree of NTP servers.
See the stratum(st) displayed for each ntp association below:
show ntp associations;
address ref clock st when poll reach delay offset disp
+~1.11.12.55 125.220.128.123 2 970 1024 377 -0.0 -0.42 0.3
+~1.11.12.56 125.220.128.123 2 74 1024 377 -0.0 -0.01 0.2
*~1.11.12.57 125.220.128.123 2 619 1024 377 -0.0 1.85 0.1
~1.11.12.58 125.220.128.123 2 74d 1024 0 -0.0 -0.64 16000.
* master (synced), # master (unsynced), + selected, - candidate, ~ configured
The Cisco implementation of NTP does not support stratum 1 service; in other words, it is not possible to connect to a radio or atomic clock (for some specific platforms, however, you can connect a GPS time-source device). We recommend that time service for your network be derived from the public NTP servers available in the IP Internet.
What If A Public NTP Server Cannot Be Reached?
If the network is isolated from the Internet, the Cisco implementation of NTP allows a machine to be configured so that it acts as though it is synchronized via NTP, when in fact it has determined the time using other means. Other machines can then synchronize to that machine via NTP. "Other machines" here includes CUCM, Unity, and other Cisco Unified Communications servers.
A number of manufacturers include NTP software for their host systems, and a publicly available version for systems running UNIX and its various derivatives is also available. This software also allows UNIX-derivative servers to acquire the time directly from an atomic clock, which would subsequently propagate time information along to Cisco routers.
The communications between machines running NTP (known as "associations") are usually statically configured; each machine is given the IP address of all machines with which it should form associations. Accurate timekeeping is made possible by exchanging NTP messages between each pair of machines with an association.
However, in a LAN environment, NTP can be configured to use IP broadcast messages instead. This alternative reduces configuration complexity because each machine can simply be configured to send or receive broadcast messages. However, the accuracy of timekeeping is marginally reduced because the information flow is one-way only.
The time kept on a machine is a critical resource, so we strongly recommend that you use the security features of NTP to avoid the accidental or malicious setting of incorrect time. Two mechanisms are available: an access list-based restriction scheme and an encrypted authentication mechanism.
When multiple sources of time (VINES, hardware clock, manual configuration) are available, NTP is always considered to be more authoritative. NTP time overrides the time set by any other method.
Related Posts
Cisco IOS NTP Configuration
Cisco CUCM NTP Configuration
More Information
Cisco IOS Network Management Configuration Guide, Release 12.4
Subscribe to:
Posts (Atom)