Sunday, December 29, 2013

Cisco CUCM: The new Location model in CUCM 8 and above

Hi Guys!

Been ages since I have done a post on VOIP stuff for you guys, I am going to talk about the new locations in CUCM 8 and above in this blog post.

Just a quick refresher: Locations in CUCM are a form of Call Admission Control (CAC) that is  used in CUCM to protect VOIP traffic from itself, sounds funny right? Let's see how it's applicable.

Let's say you have a 512kbps location, and you dedicate let's say 128 kilobits of that to VOIP calls, this is a simple example, that might not be the right amount, you need to take into account IP Overhead, etc. etc. But for our purposes let's use this example.

OK, So how do we normally QoS our VOIP Calls? We Prioritze them right? We use the priority keyword: priority 128 or something to that effect  in our QoS behaviour.

So now we are guaranteeing that VOIP traffic will be put to the front of the queue in times of congestion and will get highest priority. What we are ALSO doing, is not allowing that traffic during times of congestion to get MORE than 128kilobits per second, So not only are we prioritizing, we are policing as well. Remember this is ONLY during times of congestion: if the link is not congested, we can run as much VOIP traffic as we like.

So, let's say we have two calls to this location, two calls, G.711 we are getting 64kilobits per second for each call so a total of 128, even if this link gets congested: no problem,  we have our priority queue taking care of it. But suppose a third call is attempted while this link is congested: Now we have three calls, totalling 192 kilobits per second of bandwidth fighting for 128 kilobits of available bandwidth and being policed down so dropping packets indiscrimentley, leading not only to a bad quality voice call for the new VOIP caller but for all VOIP callers!

So now you understand the purpose of CAC. Let's talk quickly about the methods we can use to control it.

First of all, a standards-based protocol to deal with this problem, called RSVP, was created. This protocol uses a reservation system (Hence RSVP) to reserve bandwidth on a link at the time of call. RSVP has the main advantage of being dynamic: meaning it responds to changes in the network topology such as links going up or down to determine bandwidth, if implemented properly RSVP works quite well, the main issue with RSVP is that it is quite complicated to setup. So a simpler method was created within CUCM called locations.

Locations are configured per-site in CUCM by specifying the maximum amount of bandwidth allowed for that location, calls that would exceed this total are denied and are redirected using AAR (Automatic Alternative Routing) which uses a local PSTN breakout to complete the call.

The problem with locations is the exact opposite of RSVP: It is static, meaning it can't take into account changes in the topology.

These two methods of performing CAC are known as "Topology Aware" (RSVP) and "Topology Unaware" (Locations)

CUCM 8 and 9 introduced a few methods to get around this problem, and that will be the focus of our article.

Location Basics

When you first login to CUCM 8 and above you will notice three default locations that will already exist, it's important that we go through each of them.

Hub_None - This location has been around for a while and is basically a location with unlimited bandwidth for audio and video. No Restrictions are made with this location. This is the default and you will also notice that if you are creating a new phone etc, this hub_none location is selected by default, so does that mean your phone will use this location instead of that in the device pool? NO! The hub_none location is only used on a phone if a device pool location is not specified so keep that in mind.

Shadow - The shadow location is a new location created as part of Enhanced Location CAC (more on this later) and is only used on the SIP intercluster trunks that you configure when doing intercluster CUCM. If you where to assign this to anything other than a intercluster SIP Link, the location is ignored and the device treated as if it was in the hub_none location.

Phantom - This location is used for intercluster trunks. This location is set on InterCluster Trunks and allows the calling and called party to exchange an Information Element (IE) reflecting their own location. This helps with a hairpin situation.

Let's say you have Phone A and Phone B in one Cluster, Cluster A, which is attached to Cluster B. For some reason your call routing is configured so that the call goes from Phone A to Phone B Via the Intercluster Trunk, This would mean that you would reduce bandwidth twice: 1 for the inbound call and one for the outbound call to those locations even though Phone A and Phone B are in the same location! The Phantom Location allows you to have the real location transferred as part of the call and therefore the correct amount of bandwidth will be removed from the locations.

So the only one of the locations we might use in a single cluster environment as per the above is the hub_none location. Phantom and Shadow are useful for inter-cluster situations.

Let's continue to look at locations.

The screenshow below shows the settings we have to add a location:


Let's go through each of the options.

First of all we can specify the amount of bandwidth to other locations, the Audio Bandwidth controls the maximum bandwidth for all audio calls, video for video calls and finally Immersive Video Bandwidth is used for most telepresence endpoints to have their CAC bandwidth treated diffierently to standard video. An endpoint can not be configured to either use immersive video or normal video locations but rather this is a fixed configuration decided by Cisco as they release endpoints (Does the endpoint qualify as "Immersive" Is entirely up to them)

Tuesday, December 24, 2013

CCIE Rants Christmas Special: SSH Keys with IOS Routers

Hi Guys

Recently got myself a Mac Book Pro Retina, Most things I like, some things annoy me. The things I like are normally related to the underlying Unix in the OS, including SSH.

If your anything like me 99 percent of the time you log into routers etc you use a username and password, but Linux guru's (like my friend at  have long been using SSH keys to create secure connections to there linux servers without having to enter a password every time.

We can do the exact same thing on IOS routers and it's relatively straightforward.

First, I will show you how to generate a ssh key in Mac OS X, I am sure that this process can be done with Putty, and in fact I think there is a putty program specifically geared for this exact reason called puttygen.

I will show the Mac-OS X commands, should be easy enough to figure it out for windows as i mentioned above.

OK, so first of all you need to generate the key, this is quite straightforward:

On your mac terminal, simply enter ssh-keygen and you can then accept most of the defaults, you will want to make sure you back up the private key somewhere (you can always regenerate the public key)

The Passphase is highly recommended: This means that if someone gets a copy of your private key they will still need this password, it also means that you will run a special bit of software called a "SSH Agent" that, when you first use the private key will prompt you for the pass phase to use it, it will only do this once per desktop login session (so if you shut your mac down or log out, next time you SSH in to a host your using SSH key authentication you will need to enter this key phase, but after that you won't have to enter that pass phase again. So pick something secure!

So, as per below enter the ssh-keygen command, choose a path to store the key, enter a pass phase.

Peters-MacBook-Pro:~ peterrevill$ ssh-keygen

Generating public/private rsa key pair.
Enter file in which to save the key (/Users/peterrevill/.ssh/id_rsa)
Created directory '/Users/peterrevill/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /Users/peterrevill/.ssh/id_rsa.
Your public key has been saved in /Users/peterrevill/.ssh/
The key fingerprint is:

5b:11:d1:1d:2f:a6:2a:13:b3:09:6c:cd:f8:60:34:0c peterrevill@Peters-MacBook-Pro.local

OK next, cd to the directory and look at your new public key.

Peters-MacBook-Pro:.ssh peterrevill$ cd /Users/peterrevill/.ssh
Peters-MacBook-Pro:.ssh peterrevill$ cat 
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDrjoyJeKI/zqt446ntMihqzuHJV9F1Nh9pE+NiZS4khlWl2epnrxGvPIHEfF/P12OsCRMmHUggY1AmKxiQH/styVIGn+FC5y/GWlPwZe7ZDPMUDeoJJCOP5TZWQoIBnF2S+07rKTxlBxtm2BTlJzx+IteQHwA+G/hWLtQL24nWO3/g/urrttD5mTgncHPtTNkc4CiVrr3Av64eO3QlU8ZuGYYFBTrL4nuYHIIywtHT91UAFokB/oddk7vFwwbIpjddkmAvnkUlxHR0719CfxAXjFRVQmCqiVy9ewosUhDZiBXm/NJWvi0CXl/ZVWlsYAqg0CpZ4s5u+V5E0R6/MnKv peterrevill@Peters-MacBook-Pro.local

We need to paste the output of our cat command into the router, so at this point it's time to login to the router. It should be obvious you need SSH enabled, and you will want SSH version 2.

Now, the thing about this process that I have found, is that if you have a user who already has a password, even if your using SSH keys it prompts you for the password, there may be a way to resolve this but not that your humble friend (Me!) could find. So if anyone does know a way to stop this behaviour and allow people to login with EITHER SSH key OR password but not both please post it in the comments :). 

So, to account for this we make a new user and we don't assign them a password, we do assign them privilege 15 though so that the enable password does not have to be entered. Once you have entered the final command key-string come back to this page before continuing.

Issue the following commands:

HomeRouter2921(config)#username test privilege 15
HomeRouter2921(config)#ip ssh pubkey-chain 
HomeRouter2921(conf-ssh-pubkey)#username test

At this point your ready to enter the key, now unfortunately IOS has a limit per line of 250 characters, so you will need to copy 250 characters at a time and go from one line to the next, being careful not to miss any characters whatsoever. (Why they can't make this like the certificate enrolment process where you paste everything in in one go i have no idea!)

It will probably look a little something like this:


The start of the key will show: ssh-rsa, you have to copy this in and copy the plaintext bit at the end as this is the description.

Once this is done, you are ready to test it out! That easy hey?

Go to a terminal in Mac OS X and issue the ssh command, we will put the -v flag this time so you can see the process but afterwards you can do away with the -v and just use ssh test@ 

If you assigned a pass-phase to your private key (which you should have done), you will now be prompted by Mac-OS-X itself to enter the pass phase for the private key, after that you should not have to enter this pass phase again until turn off your mac, even subsequent SSH sessions with OTHER routers will be fine.

Peters-MacBook-Pro:.ssh peterrevill$ ssh -v test@
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: Connecting to [] port 22.
debug1: Connection established.
debug1: identity file /Users/peterrevill/.ssh/id_rsa type 1
debug1: identity file /Users/peterrevill/.ssh/id_rsa-cert type -1
debug1: identity file /Users/peterrevill/.ssh/id_dsa type -1
debug1: identity file /Users/peterrevill/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version Cisco-1.25
debug1: no match: Cisco-1.25
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024 p="" sent="">
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 32:a3:4b:36:88:94:fc:c0:b4:17:06:b1:21:c4:c1:2f
debug1: Host '' is known and matches the RSA host key.
debug1: Found key in /Users/peterrevill/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_ACCEPT received

The above output shows you that we sent a key to the router and it accepted it, and then we get on with the rest of the process...

debug1: Authentications that can continue: publickey,keyboard-interactive,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/peterrevill/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: Authentication succeeded (public key).

Authenticated to ([]:22).

We have successfully authenticated!


We are now logged into the router and ready to start configuring!

That about wraps it up for me until the end of the year I believe, and I also reckon i won't be doing any blog posts until some time in February as I am about to go on my Holiday/Snowboarding Trip to Japan! If your going to be in Myoko Kogen between 11th of Jan to 15th of Feb or you will be at Hakuba for some of Feb Send me an email! :)

I want to thank everyone for there continued support, my friends and family and everyone who has been really positive about this blog, I have found it very rewarding to be able to help people and quite a few people whom i have not met have told me hey I know you i read your blog. Really nice Feeling!

Enjoy your Christmas Holidays!

Wednesday, December 11, 2013

Anyconnect SSLVPN

Finally! I found a definitive guide on how to install a 3rd party cert easily:

Saturday, December 7, 2013

UCS emulator troubleshooting tips

Hi Guys!

Found a great site with some UCS emulator troubleshoooting tips that you might find helpful!