Posts Tagged ‘Cisco’

One of the more tedious parts of any phone system deployment is configuring the access layer switches to support said phones.  The configuration in and of itself isn’t complicated, but every port that may receive a phone needs to be setup correctly.  In Cisco parlance, this is accomplished with the switchport voice vlan <ID> command.  I’ve typed that into the CLI a thousand times and never really knew what it did besides “make the phones work”.  After a little research, I finally found some answers.  I thought I’d share them with you.

In the old days, before the Catalyst 2950, configuring a switch port for use by a phone involved creating an explicit 802.1q trunk.  This made sense from the perspective that it allowed traffic from multiple VLANs to pass on a single link.  It also allowed the 802.1p priority bits for Quality of Service (QoS) tagging to be sent with the frames.  The downside is that it was very difficult for phone mobility.  You either needed to provision every phone-facing switchport in your organization to be an 802.1q trunk or you had to leave the phones were they were.  While the latter is usually the case in most of my deployments, the mobility provided by the ability to plug a phone in anywhere in the network and not worry about extra configuration is key to some clients.  Thankfully, Cisco fixed this starting in the 2950 with a little concept known as the Auxiliary VLAN.

The Auxiliary VLAN (AUX VLAN) is a specialized VLAN that sits beside a regular access VLAN configured on a switch (sometimes called a “normal” VLAN).  The purpose of the AUX VLAN is to allow IP phones to transmit their payloads along with the untagged data coming from a PC that might be plugged into a switchport on the back of the phone.  The AUX VLAN allows these two devices to transmit on the same port without the need to use an explicit trunk on the link.  In addition, since the port is not configured explicitly as an 802.1q trunk, extraneous VLANs will not be flooded over the port.  In essence, the port becomes a two VLAN trunk.  All the phone traffic is tagged with the ID of the AUX VLAN and the PC traffic is untagged.  Curiously, according to this document, the traffic in the AUX VLAN must also carry a Class of Service (CoS) of 5 along with the AUX VLAN ID.  Otherwise, the traffic is dropped.  So how does the phone get the ID of the AUX VLAN so it can start sending the traffic?  Ah, that’s where CDP comes in.

Cisco Discovery Protocol (CDP) is very crucial in the operation of a Cisco IP phone.  It not only provides the AUX (Voice) VLAN ID for the phone to being sending traffic on the AUX VLAN, it also allows the phone to automatically negotiate power settings.  This allows the phone to use less than the maximum 15.4 watts of power under the 802.3af PoE standard.  If you disable CDP on the port facing the phone/PC you will likely start pulling your hair out.  Even though the phone might have already assigned itself in the Voice VLAN, removing CDP from the switchport in question causes it to forget where to find the voice VLAN.  You’ll need to re-enable CDP and reboot the phone.  You could also statically configure an 802.1q trunk to fix the issue, but where’s the fun in that?

One other curious note is that I’ve always been told that the connection between the phone and the switch when switchport voice vlan is configured is a “special 802.1q trunk”.  Not that I’ve ever been able to see that configuration, as show interface trunk seems to think that the port isn’t trunking and show interface switchport says that it’s an access port.  The key is in Cisco’s documentation.  The correct term for a port with switchport voice vlan configured is a “multi-VLAN access port”.  The distinction between the two is that only the two vlans (voice and access) configured on the switchport will be accepted on the link.  If you were to do something silly like, oh I don’t know, plug another switch into the back of the phone and configure an access port on that switch to be in a different VLAN than the voice or PC access VLAN, traffic will not pass through the phone port to the switch.  Once again, that’s because this isn’t a real trunk.  The switch will only accept tagged frames from the Voice (AUX) VLAN.

Thanks Networking Nerd for this article.


Cisco 642-416 Test Prep

Posted: May 22, 2012 in Training
Tags: , ,

The determining factor for whether a gateway registers with a TYPE of VOIP-GW or H323-GW relies entirely on the “allow-connections” commands entered under “voice service voip.” Essentially, if your gateway is functioning as an IP-to-IP gateway, it will display H323-GW.

The commands that make or break this:

voice service voip
allow-connections h t h
allow-connections h t s
allow-connections s t h
allow-connections s t s

After adding or removing these, make sure to bounce your gateway registration with the gatekeeper using “no gateway” and “gateway.”

I just verified this. Here is a snapshot without the commands listed above:

HQ-RTR#show gatekeeper endpoints
GATEKEEPER ENDPOINT REGISTRATION
================================
CallSignalAddr Port RASSignalAddr Port Zone Name Type Flags
————— —– ————— —– ——— —- —–
10.10.202.1 1720 10.10.202.1 58978 Spain VOIP-GW
H323-ID: BR2-RTR
Voice Capacity Max.= Avail.= Current.= 0

After adding the commands listed above:

HQ-RTR#show gatekeeper endpoints
GATEKEEPER ENDPOINT REGISTRATION
================================
CallSignalAddr Port RASSignalAddr Port Zone Name Type Flags
————— —– ————— —– ——— —- —–
10.10.202.1 1720 10.10.202.1 50555 Spain H323-GW
H323-ID: BR2-RTR
Voice Capacity Max.= Avail.= Current.= 0

An intercom line is one of those ‘must-have’ functions that must be available on every PBX. Fortunately, CUCM does have this function, but on the other hand, the documentation explaining how the feature works and its related configuration is not so accurate. Anyway, here’s my attempt at configuring this simple, but very handy feature in CUCM 6.x – 8.x:

Before I begin, I want to mention that an intercom line is represented by a Directory Number (DN) as is the case with any dial-able entity. Now that we have that out of the way, the first thing one needs to understand is how an intercom line works. Simply put, a user (generally a manager) presses an intercom line button on their phone and it dials the intercom line on other user’s (generally an assistant) phone and the call is auto-answered at this user’s end. However, the second user can only listen to the first user’s voice, but their own phone is muted by default. The general idea behind the intercom line is for a manager to speed-dial into a second user’s phone and have it auto-answer at the receiving end in muted mode. This allows the manager to deliver a quick, one-way audio message to the assistant. If the assistant wishes to respond back to the manager, they can hit the intercom line button on their phone and initiate a two-way conversation;  just like a normal phone call.

The intercom line is an additional line on an IP phone that is configured to reach another intercom line on another IP phone. Intercom lines are configured with “Intercom Partitions” and “Intercom Calling Search Spaces” and therefore only intercom lines can reach other intercom lines. When a user presses the intercom line on their IP phone, they can manually (or configure it to automatically) dial the corresponding intercom line on the other IP phone. Generally, a Manager will have an intercom line to their Assistant’s phone, which will be the scenario for our example.

The setup:

A manager would like to have an intercom line to their assistant such that they would simply need to press the line button and have the assistant’s phone auto-answer (in muted mode). The intercom should not work in reverse, that is, the assistant should not be able to speed-dial the manager’s intercom line.

The configuration:

– Create two ‘Intercom partitions’ for the Manager and the Assistant’s intercom DNs by navigating to Call Routing -> Intercom -> Intercom Route Partition. Title the partitions something along the lines of “PT-INTERCOM-MANAGER” and “PT-INTERCOM-ASSISTANT”.

– Create two ‘Intercom CSSs’ for the Manager and the Assistant’s intercom DNs by navigating to Call Routing -> Intercom -> Intercom Calling Search Space. Title the CSSs something along the lines of “CSS-INTERCOM-MANAGER” and “CSS-INTERCOM-ASSISTANT”. Configure the Manager CSS to contain the Assistant’s Intercom partition (PT-INTERCOM-ASSISTANT) so that the Manager’s Intercom CSS will having dialing access to the Assistant’s intercom DN. The Assistants Intercom CSS will also contain the Assistant’s intercom partition only because the CSS cannot be left empty.

You’re probably wondering why we need to set up a CSS for the assistant since they won’t need any dialing privileges on their intercom line, however, both intercom partition and intercom CSSs are mandatory configuration entities for any intercom line regardless of the requirement. Go figure!

– Create an ‘Intercom Directory Number’ for the manager’s phone by navigating to Call Routing -> Intercom -> Intercom Directory Number as show in Figure 1. We will configure 3000 as the Manager’s Intercom DN.

Figure 1 – Intercom Directory Number Configuration for Manager

– Create a second ‘Intercom Directory Number’ for the assistant’s phone as show in Figure 2. We will configure 3001 as the Manager’s Intercom DN.

Figure 2 – Intercom Directory Number Configuration for Assistant

– Add an intercom line to the Manager’s phone by navigating to Device ->Phone and then selecting the phone to which the intercom line will be added. Click on the “Modify Button Items” button as show in figure 3. A small window may pop-up that reads: “Unsaved Changes may be lost! Continue?”. Click on OK and the “Reorder Phone Button Configuration” window will pop-up.

Figure 3 – “Modify Button Items” under the Phone Configuration window

– Highlight the ‘Intercom [1] – Add a new intercom’ option under the “Unassigned Associated Items” box on the right side of the window and press the “<” button to move the intercom line into the left box (Associated Items). Rearrange this option and place it in the line position where it will appear on the phone as shown in Figures 4 and 5. Note: The number of options in the left box must correspond to the number of lines on the phone. Hence, one of the unused lines may have to be moved over into the right box before the intercom option can be moved here. If this hasn’t been done and the user attempts to add an intercom line to the left box, the following error will be received: “Must Remove An Item From Associated List Before This Operation is Allowed”.

Figure 4 – Reorder Phone Button Configuration window Step 1

Figure 5 – Reorder Phone Button Configuration window Step 2

– Click on “Save” and then “Close”.

– Under the second line (where the intercom was configured) will now read: “Intercom [1] – Add a new Intercom”. Click on this link and on the next page enter the DN (3000 in our example) in the ‘Intercom Directory Number’ field and hit “tab”. The remaining fields will be automatically pulled from the Intercom Directory Number settings configured earlier as illustrated in Figure 6.

– The following fields may be entered if desired (Shown in Figure 6):

Display (Internal Caller ID)

ASCII Display (Internal Caller ID)

Line Text Label

ASCII Line Text Label

Figure 6 – Intercom Directory Configuration Window

– The “Speed Dial” field will set the intercom to dial this number (3001 in our example) as soon as the Intercom line button on the IP phone is pressed. This is illustrated in Figures 7 and 8.

Figure 7 – Normal State

Figure 8 – After Pressing the “Intercom Line”

Please feel free to post any questions or comments. I hope this post was helpful!

As of IOS 12.4(23)T you no longer need to rely on a “reload in” command to save you from potentially locking yourself out of a remotely managed router.

You can enter configure mode with “config terminal revert time x” and IOS will save the running configuration to a backup file on flash to revert to after x minutes.

When your changes are successful and you want to cancel the revert you simply exit configuration mode and feed the router “config confirm” to commit your changes persistently. Though obviously you will still need to write your running configuration to NVRAM as per usual!

What is the advantage of this? Well for one you don’t have to wait  for the router to reload to get access again and secondly any other services this router is providing eg Voice gateway, transcoding etc will be unaffected.

 

Lets take a look at how this behaves on the CLI:

 

Enable Configuration archiving

 

Router(config)#archive
Router(config-archive)#path flash:backups
Router(config-archive)#maximum 14
Router(config-archive)#exit
Router(config)#exit

 

Enter Configure mode with a reversion timer

Router#conf terminal revert timer 2

 

Rollback Confirmed Change: Backing up current running config to flash:backups-0

Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#
*Apr 11 02:38:30.571: %ARCHIVE_DIFF-5-ROLLBK_CNFMD_CHG_BACKUP: Backing up current running config to flash:backups-0

*Apr 11 02:38:30.5711: %ARCHIVE_DIFF-5-ROLLBK_CNFMD_CHG_START_ABSTIMER: User: console: Scheduled to rollback to config flash:backups-0 in 2 minutes

 

Make a configuration change

Router(config)#host
Router(config)#hostname RevertMe
RevertMe(config)#

 

Take note of reversion warnings

*Apr 11 02:39:30.571: %ARCHIVE_DIFF-5-ROLLBK_CNFMD_CHG_WARNING_ABSTIMER: System will rollback to config flash:backups-0 in one minute. Enter “configure confirm” if you wish to keep what you’ve configured

 

 

Reversion takes place

Rollback Confirmed Change: rolling to:flash:backups-0

 

 

Total number of passes: 1
Rollback Done

*Apr 11 02:40:30.571: %ARCHIVE_DIFF-5-ROLLBK_CNFMD_CHG_ROLLBACK_START: Start rolling to: flash:backups-0
*Apr 11 02:40:30.575: Rollback:Acquired Configuration lock.
*Apr 11 02:40:33.091: %PARSER-6-EXPOSEDLOCKRELEASED: Exclusive configuration lock released from terminal ’0′ -Process= “Policy Manager”, ipl= 0, pid= 21

Router(config)#

 

 

Alternatively Commit your changes

Router(config)#hostname RevertMe
RevertMe(config)#exit
*Apr 11 02:46:08.615: %SYS-5-CONFIG_I: Configured from console by consoleonf
RevertMe#configure confirm
*Apr 11 02:46:10.899: %ARCHIVE_DIFF-5-ROLLBK_CNFMD_CHG_CONFIRM: User: console: Confirm the configuration change
RevertMe#copy running-config startup-config
Building configuration…
[OK]
RevertMe#

Overview

One of the concepts that many junior voice engineers struggle with is the class of control features of Partitions and Calling Search Spaces. I remember feeling like I was banging my head against a wall repeatedly until I hit that Ah-hah moment and it all made sense.

Now there are many great explanations out there on the inter webs that are all technically correct and great. Some use the Lock + Key analogy like the CIPT1 Study guide and some use a White Pages/Directory Analogy. In my opinion these can leave people without a whole lot of voice experience more confused than when they started.

Purpose – What are Partitions and Calling Search Spaces used for anyway?

In my opinion Partitions and Calling Search Spaces are primarily used as a way to find “things” in the phone system. They are used so endpoints (Phones, Gateways, Trunks) can dial resources (Directory Numbers, On-net Route Patterns, Off-net Route Patterns, Translation Patterns). From an end-users perspective these resources are generally represented by a number. Because you can use these Dial Plan constructs to limit what resources an endpoint can find, it allows you the ability to implement Class of Service.

Sure, you could just put everything in the none partition and be done with it all together but Tom Hollingsworth has already told us why this is a bad idea over at his blog networkingnerd.net

Yeah, Ok. But you still haven’t told me what Partitions and Calling Search Spaces do!

Hold your horses. This is the part you’ve all been waiting for….< Insert Drum Roll > Here it is:

  • Partitions contain “things”
  • Calling Search Spaces find “things”

That’s it. I really believe this is the simplest way to think of how these two constructs work and behave.

Partitions

So we know that partitions can contain “things” but what exactly can they contain? A partition will only contain one or more of the following things:

  • Directory Numbers – These Directory Numbers represent other numbers in the Phone System that can be associated to Devices.
  • Route Patterns – Route Patterns represent off-net and on-net destinations and control how a call is routed to a destination. Route Patterns use Route Lists and Route Groups to send calls over a trunk or a gateway.
  • Translation Patterns –  I consider Translations Patterns an intermediate step to either matching a Directory Number or a Route Pattern. They are used to Transform the Calling or Called Party Information before using a Calling Search Space to find a suitable match. It is also worth noting that a Translation Patten can also be set to Block instead of route which can be useful when using the Line/Device Approach for implementing Class of Service
  • Transformation Patterns – Transformation Patterns are similar to Translation Patterns except they are not part of the CUCM’s routing construct. They are used for modifying Calling or Called Party Information for purposes of presentation but do not affect call routing. When you are using Transformation Patterns you should use dedicated Partitions and Calling Search Spaces for this function.

Calling Search Spaces

So if partitions contain “things” and Calling Search Spaces find “things”, what do they look in too find them? Well they look in partitions of course.

The following constructs use Calling Search Spaces to find things:

  • Devices – Phones use a CSS to find available patterns. This is generally referred to as the Device Calling Search Space
  • Directory Numbers – Directory Numbers also use a CSS to find available patterns. This is referred to as the Line Calling Search Space.
  • Trunks
  • Gateways
  •  Translation Patterns

This list was by no means exhaustive and there is a vast number of features that require Calling Search Spaces to be defined to control access to DN’s/Patterns for that feature. Things like Time of Day Routing, Presence, Call Forward Settings etc

When a Calling Search Space is looking through a series of ordered partitions it doesn’t work like an ACL in Cisco IOS that searches sequentially through the available partitions top-down until it finds a suitable match. No, It processes all listed partitions and matches on the best or longest match. The only time in which the order of the partitions matter is when you have equally specific patterns, in which the pattern in the partition closer to the top of the CSS list will win as a tie-breaker.

OK – So I think I get it, but I’ve noticed my Phone and my Directory Number both have a CSS. What’s up with that?

Well CUCM is flexible in that you could choose to set a CSS on just one of these elements and leave the other blank.  When you have both a Device and a Line CSS the CUCM combines the two into a single CSS with Line CSS above the Device CSS.

There is a good reason to use both. In order to effectively use features like extension mobility but enforce local dialling habits at remote offices it is recommended to set the Device CSS as too allow full access to the Dial Plan and then use the Line CSS to restrict unauthorised patterns from being dialled. The Partitions in your Line CSS should contain Translation Patterns that are set to block the restricted patterns and also have the “Urgent Priority” flag checked (It is on by default).