8^th November 2012

Firewall.cx, the world’s only awarded Official Cisco Press Reviewer and leading website in Cisco technologies, Linux and networking, announces its new collaboration with Cisco Press's CCIE experts and authors.

With this new collaboration, Firewall.cx aims to bring closer to the community the people who write the great Cisco Press books we've all come to love and rely on. Cisco Press authors who hold at least one CCIE certification will be contributing as guest writers on Firewall.cx, sharing their valuable knowledge and technical expertise with our global IT community, covering new exciting topics in Cisco Unified Communications, Cisco Security, Cisco Certifications, Cisco Wireless, Cisco Firewalls, Cisco Routing and much more!

In addition, Firewall.cx will be interviewing these gurus, providing a first-hand insight into how they obtain their certifications, how they deal with challenging problems, revealing their proven troubleshooting techniques, listen to their advice for newcomers and engineers seeking to increase their knowledge and expertise, plus much more!

To kick-start this new collaboration, Firewall.cx has invited CCIE Voice Akhil Behl, Senior Network Consultant with Cisco Advanced Services and author of the recent Cisco Press title: Securing Cisco IP Telephony Networks. 

Akhil Behl will be providing the Firewall.cx community with a new technical article based on VoIP security and we’ll be publishing a number of upcoming events where the community will have the chance to interact with the author and ask questions!

Keep your eyes on Firewall.cx for updates as they become available.

The Firewall.cx Team

Expert: Akhil Behl Double CCIE (Voice & Security) #19564

Akhil Behl is a Senior Network Consultant with Cisco Advanced Services, focusing on Cisco Collaboration and Security architectures. He leads Collaboration and Security projects worldwide for Cisco Services and the Collaborative Professional Services (CPS) portfolio for the commercial segment. Prior to his current role, he spent 10 years working in various roles at Linksys, Cisco TAC, and Cisco AS. He holds CCIE (Voice and Security), PMP, ITIL, VMware VCP, and MCP certifications.

He has several research papers published to his credit in international journals including IEEE Xplore.

He is a prolific speaker and has contributed at prominent industry forums such as Interop, Enterprise Connect, Cloud Connect, Cloud Summit, Cisco SecCon, IT Expo, and Cisco Networkers.

He is the author of ‘Securing Cisco IP Telephony Networks’ by Cisco Press.

Introduction

Unity Express provides any organization with a quick and convenient way to manage voicemail, auto attendant and interactive voice response (IVR) services.  These services are provided within the Unity Express module.

When purchased, Unity Express includes a few licenses for some services, such as voice ports for auto attendant, while other services like mailboxes are not included.  This policy forces companies requiring these services to purchase additional licenses from Cisco in order to activate or expand the system’s capacity.

A good example is the Unity Express voice mailbox service. When purchasing Unity Express, by default it does not include any mailboxes. 

While the Unity Express web interface allows the creation of voice mailboxes despite the fact no licenses are installed, you won’t be able to make use of them unless the appropriate number of licenses is installed.

When a caller is redirected to a user’s voice mailbox where the system does not have the necessary licenses installed, instead of hearing the called party’s voicemail prompting to leave a message, the following prompt is heard:

Voice mail system is unavailable, try again later, to talk to the operator, press zero.

Engineers and Administrators interested can read our popular articles covering the physical installation and initial setup of Unity Express on Cisco CallManager Express or Cisco Voice Gateways:

• Cisco Unity Express Installation & Setup - ISM-SRE-300-K9 & SM-SRE-700-K9 Installation – Part 1
• Cisco Unity Express Installation/Setup - Service Module & Initial Web Interface Configuration - Part 2

Installing & Verifying Unity Express Licenses – 4 Simple Steps

Installing Unity Express licenses is not all that complicated. We’ve broken down the process into four simple steps to make it as clear and simple as possible:

• Registering and Assigning your Product Authorization Key (PAK) number
• Obtaining the Correct UDI Product ID and Serial Number
• Installing the Software License on Unity Express
• Verifying Unity Express License Installation

No matter what type of license you have the installation process is the same. It is important to note that when installing multiple PAKs for a service they must be combined into a single license. For example, if you have purchased four packs of 5-user-mailbox licenses to support a total of 20 users, you must ensure these are combined into a single 20 mailbox license file and not four x 5-mailbox license files. If problems arise, Cisco support is always available to help resolve any licensing problem.

Before we begin the license installation process it is important to verify the existing licenses so we are sure of what we have already.

Verifying Existing Cisco Unity Express Licenses

Before considering purchasing licenses it is necessary to verify what is already installed. This is easily done by using the following command to view the currently installed licenses. Note that the License Type: Permanent from the command output is what we are looking for. This represents a permanent license, which is also the installed licenses:

License Type: Evaluation is, as the output indicates, evaluation licenses. These are not installed/purchased licenses and normally are limited to a 60 day trial period after which they expire and are disabled.

Another way to verify the installed licenses is to log into the Unity Express GUI interface and visit the Administration>Licenses section:

As both CLI output and GUI interface confirm, we currently have two VMIVR-PORT licenses installed. This license feature will allow up to two simultaneous calls to the autoattendant system or user voice mailbox service.

Register & Assign your Cisco Product Authorization Key (PAK) Number

When purchasing a Unity Express license, you’ll receive it either as a hardcopy or electronically delivered license. The license contains an 11-digit Product Authorization Key number, also known as PAK. The PAK is basically your license, which needs to be associated with your Unity Express hardware. This process is done through the Cisco.com website. Once associated, the necessary license file will be delivered to you electronically and you’ll then need to install it on Unity Express.

To begin registration, visit  http://www.cisco.com/go/license.  A valid CCO account is required, so users without a CCO account will be required to register first. After the logon process is complete, we need to enter our 11-digit PAK number as shown in the screenshot below:

Introduction

This article extends our DMVPN article series by answering common questions regarding the differences between Single Tier Headend and Dual Tier Headend architectures.

When hearing the DMVPN terms single tier or dual tier it can be difficult to understand exactly their meanings.  While the difference between the two might seem clear when looking at a DMVPN with single or dual tier headend setup, what really goes on is usually not revealed or analysed in great depth, until now…

While there are plenty of diagrams online illustrating Single Tier and Dual Tier Headend architectures, we found none that would analyse the differences on a packet/protocol level. This is usually the level of analysis many engineers require to truly understand how each model works.

We always assume the DMVPN network (mGRE tunnel) is protected using the IPSecurity protocol.

Single Tier Headend

Single Tier Headend involves a DMVPN setup with one single Hub router responsible for all DMVPN services. Practically, this means both Crypto IPSec and mGRE tunnel terminate on the same router, the Hub.

This is illustrated in our detailed diagram below:

In Single Tier Headend IPSec runs in Tunnel Model, encrypting the whole GRE tunnel and Data carried within. This ensures true confidentiality of our GRE tunnel and provides great flexibility in terms of VPN network design.

Engineers and Administrators who would like to learn more about protecting GRE using IPSec (both Tunnel and Transport Mode) can read our popular  GRE over IPSec - Selecting and Configuring GRE IPSec Tunnel or Transport Mode article.

As expected, a Single Tier Headend setup means that all processing is performed by one single CPU. The burden of encrypting, decrypting, encapsulating, decapsulating and maintaining the NHRP database falls on a single Hub. As a rule of thumb, the faster the Internet connection speed on the Hub router the bigger the burden will be on its CPU as it needs to process VPN data at a much faster rate. DMVPN scalability issues is a topic that will be covered on Firewall.cx.

DMVPN deployments based on Single Tier Headend architecture also support spoke-to-spoke VPN tunnels, allowing remote offices to dynamically build VPN tunnels between each other. Remote offices (spokes) are also configured with mGRE tunnels (like the Hub), allowing them to create the dynamic spoke-to-spoke tunnels.

Dual Tier Headend

Dual Tier Headend is a more popular approach to DMVPN, especially when it comes to VPN redundancy. Cisco usually uses this method when analysing DMVPN networks, however, this does not mean the Single Tier is not an acceptable solution.

With Dual Tier Headend Crypto IPSec terminates on a router positioned in front of the Hub, while the mGRE tunnel terminates on the Hub. This is illustrated in our detailed diagram below:

VMware has been the trend setter in everything to do with virtualisation. Some of the key aspects it delivers are cost reduction, improved SLA, flexibility, operation efficiency, automation and standardisation. This publication from VMware Press uses VMware vSphere 5 to demonstrate how, as an IT Manager, one can use this in a datacentre environment. Full credit goes to both authors who have taken care to carry out a full analysis of all the product in their entirety, ensuring readers would be able to derive the full benefits.

• VMware vSphere 5® Building a Virtual Datacenter (VMware Press Technology

Introduction

Following our successful article Understanding Cisco Dynamic Multipoint VPN - DMVPN, mGRE, NHRP, which serves as a brief introduction to the DMVPN concept and technologies used to achieve the flexibility DMVPNs provide, we thought it would be a great idea to expand a bit on the topic and show the most common DMVPN deployment models available today. This will provide an insight to engineers and IT Managers considering implementing a DMVPN network.

Those seeking help to configure a DMVPN network can also refer to our Configuring Cisco Dynamic Multipoint VPN (DMVPN) - Hub, Spokes , mGRE Protection and Routing - DMVPN Configuration article which fully covers the deployment and configuration of a Single DMVPN Network/Cloud  - Single Tier Headend Architecture.

DMVPN Deployment Models

There is a number of different ways an engineer can implement a DMVPN network. The fact that there is a variety of DMVPN models, each one with its caveats and requirements, means that almost any VPN requirement can be met as long as we have the correct hardware, software license and knowledge to implement it.

Speaking of implementation, no matter how complex the DMVPN network might get, it’s pretty straightforward once it's broken down into sections.

Engineers already working with complex DMVPNs can appreciate this and see the simplicity in configuration they offer.  At the end, it’s all a matter of experience.

Providing configuration for each deployment model is out of this article’s scope, however, we will identify key services used in each deployment model along with their strong and weak points.

Future articles will cover configuration of all DMVPN deployment models presented here.

Following are the most popular DMVPN deployment models found in over 85% of DMVPN networks across the globe:

• Single DMVPN Network/Cloud  - Single Tier Headend Architecture
• Single DMVPN Network/Cloud  - Dual Tier Headend Architecture
• Dual DMVPN Network/Cloud – Single Tier Headend Architecture
• Dual DMVPN Network/Cloud – Dual Tier Headend Architecture

In every case a complete DMVPN deployment consists of the following services, also known as control planes:

1. Dynamic Routing (Next Hop Resolution Protocol)
2. mGRE Tunnels
3. Tunnel Protection – IPSec Encryption that protects the GRE tunnel and data

It’s time now to take a look at each deployment model.

Single DMVPN Network/Cloud - Single Tier Headend Architecture

This deployment model is DMVPN in its simplest form.  It consists of the main Hub located at the headquarters and remote spokes spread amongst the remote offices.

The term ‘Single DMVPN’ refers to the fact there is only one DMVPN network in this deployment.  This DMVPN network consists of the yellow GRE/IPSec Hub-and-Spoke tunnels terminating at the central Hub from one end and the remote spokes on the other end.

The term ‘Single Tier Headend’ means that all control planes are incorporated into a single router – the Hub. This means it takes care of the dynamic routing (NHRP), mGRE tunnels and IPSec Tunnel Protection.

The central hub maintains the Next Hop Resolution Protocol (NHRP) database and is aware of each spoke’s public IP address.

When setting up a DMVPN network, every spoke is configured, using static NHRP mappings, to register with the Hub. Through this process, every spoke is aware of every other’s public IP address via the NHRP server (Hub), no matter if the spokes IP addresses are dynamic or static.

Through DMVPN, each spoke is able to dynamically build a VPN tunnel to each other spoke, allowing the direct communication between them without needing to tunnel all traffic through the main Hub. This saves valuable bandwidth, time and money.

We should at this point note that in Phase 1 DMVPN, all traffic passes through the Hub.  Phase 2 and Phase 3 DMVPN, directly forms spoke-to-spoke tunnels and sends traffic directly, bypassing the Hub.

The Single DMVPN - Single Tier Headend Architecture has the advantage of requiring only one Hub router, however, the Hub’s CPU is also the limiting factor for this deployment’s scalability as it undertakes all three control planes (NHRP, mGRE & IPSec protection). 

In addition the Hub router, and its link to the Internet, is the single point of failure in this design. If any of the two (Hub or Internet link) fail, it can cripple the whole VPN network.

This DMVPN model is a usual approach for a limited budget DMVPN network with a few remote branches.  Routing protocols are also not required when implementing a single DMVPN network/cloud. Instead, static routes can be used with the same end result.

Single DMVPN Network/Cloud - Dual Tier Headend Architecture

This DMVPN deployment consists of two routers at the headquarters. The first router, R1, is responsible for terminating the IPSec connections to all spokes, offloading the encryption and decryption process from the main Hub behind it. The Hub router undertakes the termination of mGRE tunnel, NHRP server and processing of all routing protocol updates.

The only real advantage offered by the Dual Tier Headend Architecture (Single DMVPN cloud) is that it can support a significantly greater number of spokes.

A limitation of Dual Tier Headend Architecture is the absence of the spoke-to-spoke connections, in Dual Tier DMVPN spoke-to-spoke connections are not supported. 

Dual DMVPN Network/Cloud – Single Tier Headend Architecture

The Dual DMVPN topology with spoke-to-spoke deployment consists of two headend routers, Hub 1 and Hub 2.  Each DMVPN network (DMVPN 1 & DMVPN 2) represents a unique IP subnet, one is considered the primary DMVPN while the other is the secondary/backup DMVPN.