CCIE COLLABORATION QUICK REFERENCE cisco press.pdf

(1)

(2)

ptg13358382

Cisco Press

800 East 96th Street Indianapolis, IN 46240

CCIE Collaboration Quick

Reference

(3)

ptg13358382

CCIE Collaboration Quick Reference

Cisco Press 800 East 96th Street Indianapolis, IN 46240 USA

All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information stor-age and retrieval system, without written permission from the publisher, except for the inclusion of brief quotations in a review.

ISBN-13: 978-0-13-384596-9 ISBN-10: 0-13-384596-6

First Edition: May 2014 with corrections June 2014

Warning and Disclaimer

This book is designed to provide information about the Cisco CCIE Collaboration exam. Every effort has been made to make this book as complete and as accurate as possible, but no warranty or fitness is implied.

The information is provided on an “as is” basis. The authors, Cisco Press, and Cisco Systems, Inc. shall have neither liability nor responsibility to any person or entity with respect to any loss or dam-ages arising from the information contained in this book or from the use of the discs or programs that may accompany it.

The opinions expressed in this book belong to the author and are not necessarily those of Cisco Systems, Inc.

(4)

ptg13358382

Trademark Acknowledgments

All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capitalized. Cisco Press or Cisco Systems, Inc. cannot attest to the accuracy of this information. Use of a term in this book should not be regarded as affecting the validity of any trademark or service mark.

Special Sales

For information about buying this title in bulk quantities, or for special sales opportunities (which may include electronic versions; custom cover designs; and content particular to your business, training goals, marketing focus, or branding interests), please contact our corporate sales depart-ment at [email protected] or (800) 382-3419.

For government sales inquiries, please contact [email protected] . For questions about sales outside the U.S., please contact [email protected] .

Feedback Information

At Cisco Press, our goal is to create in-depth technical books of the highest quality and value. Each book is crafted with care and precision, undergoing rigorous development that involves the unique expertise of members from the professional technical community.

Readers’ feedback is a natural continuation of this process. If you have any comments regarding how we could improve the quality of this book, or otherwise alter it to better suit your needs, you can contact us through email at [email protected] . Please make sure to include the book title and ISBN in your message.

We greatly appreciate your assistance.

Publisher: Paul Boger Senior Project Editor: Tonya Simpson Editor-in-Chief: David Dusthimer Copy Editor: Bill McManus

Business Operation Manager, Cisco Press: Jan Cornelssen Technical Editor: Paulo Lopes

Executive Editor: Brett Bartow Editorial Assistant: Vanessa Evans

Managing Editor: Sandra Schroeder Designer: Mark Shirar

Development Editor: Marianne Bartow Composition: Jake McFarland

(5)

ptg13358382

About the Author

Akhil Behl , CCIE No. 19564, is a solutions architect with Cisco Advanced Services, focusing on Cisco Collaboration and Security architectures. He leads Collaboration and Security projects and service delivery worldwide for Cisco Services and the

Collaborative Professional Services (CPS) portfolio. He has played a major role in service conception and creation for various services within Cisco Advanced Services. Akhil has a wide range of experience, from presales to sales to professional services to delivery to post sales, with expertise in consulting, advisory, and guidance services. Prior to his cur-rent role, Akhil spent 10+ years working in various roles at Linksys as a technical support lead, as an escalation engineer at the Cisco Technical Assistance Center (TAC), and as a network consulting engineer in Cisco Advanced Services.

Akhil has a bachelor of technology degree in electronics and telecommunications from IP University and a master’s degree in business administration from Symbiosis Institute. He is a dual Cisco Certified Internetwork Expert in Voice and Security. He also holds many other industry certifications, such as PMP, ITIL, VCP, CCNA, CCSP, CCVP, ISO/IEC 27002, TOGAF, and CEH.

Over the course of his career, Akhil has presented and contributed at various industry forums such as Enterprise Connect, Cloud Connect, Cloud Summit, Interop, Cisco Networkers, and SecCon. He has several research papers published in various national and international journals, including IEEE journals, and is the author of the Cisco Press title Securing Cisco IP Telephony Networks .

(6)

ptg13358382

v

About the Technical Reviewer

Paulo Lopes is a network consulting engineer at the Advanced Services Center of Excellence of Cisco Unified Communications for Cisco. He has been working at Cisco supporting and deploying Cisco Unified Communications solutions for more than 10 years. Paulo is currently the tech lead of the Unified Communications virtual team for the Americas.

(7)

ptg13358382

Dedication

This book is dedicated first to my family, my dear wife Kanika and my lovely sons Shivansh and Shaurya, for without their support, encouragement, and patience, it would not exist. Secondly, to my parents, Vijay Behl and Ravi Behl, and my brothers, Nikhil Behl and Ankit Behl, who have always been there to support me and guide me in all my endeavors.

Acknowledgments

I would like to thank the following amazing people and teams for helping me create this book:

My wife, Kanika, and my kids, Shivansh and Shaurya, for sacrificing many days and weekends over the past year so that I could work on this book. Without their patience and support, this book would not have been possible.

The technical reviewer, Paulo Lopes, for his invaluable feedback and for providing exceptional technical coverage.

The Cisco Press editorial team: Brett Bartow, the executive editor, for seeing the value and vision in the proposed title and providing me the opportunity to build this title; and Marianne Bartow, development editor, and Christopher Cleveland, senior development editor, for their support and guidance all throughout. It is my sincere hope to work again with them in the near future.

(8)

ptg13358382

vii

Contents at a Glance

Chapter 1 Cisco Collaboration Infrastructure 1

Chapter 2 Quality of Service (QoS) 31

Chapter 3 Telephony Standards and Protocols 55

Chapter 4 Cisco Unified Communications Manager 95

Chapter 5 Cisco Unified Communications Security 145

Chapter 6 Cisco Unity Connection 167

Chapter 7 Cisco Unified IM and Presence 191

Chapter 8 Cisco Unified Contact Center Express 209

Chapter 9 Cisco IOS Unified Communications Applications 225

(9)

ptg13358382

Cisco Unity Connection Integration with CUCM and CUCME 168 Cisco Unity Connection SCCP Voicemail Integration with CUCM 169 Cisco Unity Connection SIP Voicemail Integration with CUCM 171 Cisco Unity Connection SCCP Voicemail Integration with CUCME 172 Cisco Unity Connection SIP Voicemail Integration with CUCME 174 Cisco Unity Connection Dial Plan 175

Call Handlers 176

Cisco Unity Connection System Call Handlers 176 Cisco Unity Connection Directory Handlers 178 Cisco Unity Connection Interview Handlers 179 Cisco Unity Connection Single Inbox 180

Cisco Unity Connection Visual Voicemail 183 Voice Mail for Cisco Jabber 184

Cisco Unity Connection Voicemail Networking 186 Intrasite Networking 187

Intersite Networking 188

Voice Profile for Internet Email (VPIM) Networking 189

Chapter 7 Cisco Unified IM and Presence 191

Cisco Unified Communications Manager IM and Presence Components 191 Cisco Unified CM IM and Presence Cluster 192

Cisco Unified CM IM and Presence Server Integration with CUCM 193 Cisco Jabber 197

Presence Federation 198 Intradomain Federation 199 Interdomain Federation 201 Presence Cloud Solutions 202 Group Chat and Compliance 204

Group Chat 204

Logging and Compliance 205

Client-Side IM Logging (History) 205 Server-Side IM Logging (Compliance) 206

(15)

ptg13358382

Chapter 8 Cisco Unified Contact Center Express 209

Cisco UCCX Architecture 209

Cisco UCCX Components and Subsystems 210 UCCX ACD/ICD, IVR, and CTI Functions 211

UCCX ACD Functions 211 UCCX CTI Functions 213 UCCX IVR Functions 213 UCCX Deployment Models 214 UCCX Call Flow 215

UCCX Integration with CUCM 216 UCCX Scripting Components 218

Chapter 9 Cisco IOS Unified Communications Applications 225

Cisco Unified Communications Manager Express 225 Basic Cisco Unified CME Setup 226

Cisco Unified CME–Based SCCP Phone Registration 227 Cisco Unified CME–Based SIP Phone Registration 229 Cisco Unified CME Single Number Reach 230 Survivable Remote Site Telephony 232 MGCP Fallback 236

Multicast Music on Hold in SRST 237 Cisco IOS Dial Plan 238

Voice Translation Rules and Profiles 239 Cisco IOS Dial-Peer Matching Logic 242 Cisco IOS Media Resources 244

Cisco IOS DSP Management 244 Cisco IOS Conferencing Resources 245 Cisco IOS Transcoding Resources 246 Cisco Unified CME–Based Media Resources 246

Cisco Unified CME Conferencing and Transcoding 246 Cisco IOS–Based Call Queuing 249

Cisco Unified CME Basic Automatic Call Distribution 249 Voice Hunt Groups 252

Call Blast 253 Cisco Unity Express 254

(16)

ptg13358382

xv

Cisco Unified CME and CUE Integration 254 CUE Message Waiting Indicator 256

Outcalling 256

(SIP) Subscribe Notify 257 Unsolicited Notify 257 CUE Web Inbox 258 CUE VoiceView Express 258 CUE Auto-Attendant 259 CUE Scripting 261

CUE Voice Profile for Internet Email 263 Cisco IOS Call Admission Control 266

Local CAC 267

Reservation-Based CAC 267 Measurement-Based CAC 268 Cisco IOS CDR Accounting 268

File Accounting 269

Syslog-Based CDR Accounting 269 RADIUS-Based CDR Accounting 269

Cisco Service Advertisement Framework and Call Control Discovery 270 Cisco Unified Border Element 272

CUBE Redundancy 273 CUBE SIP Profiles 277

CUBE Early Offer and Delayed Offer 278 CUBE DTMF Interworking 279

CUBE Mid-Call Signaling 281

Chapter 10 Cisco Collaboration Network Management 283

CUCM Serviceability and OS Administration 283 CUCM Database Replication 283

CUCM Service Activation 284

CUCM Call Detail Records and Call Management Records 288 CUCM Disaster Recovery 289

User Management 290 Cisco EnergyWise 292

(17)

ptg13358382

Icons Used in This Book

PC PC with Software Sun Workstation Macintosh Terminal File Server Web Server Ciscoworks Workstation

Printer Laptop IBM

Mainframe Front End Processor Cluster Controller Modem DSU/CSU

Router Bridge Hub DSU/CSU Catalyst

Switch Multilayer Switch ATM Switch ISDN/Frame Relay Switch Communication Server Gateway Access Server Network Cloud Token Ring Token Ring Line: Ethernet FDDI FDDI

Line: Serial Line: Switched Serial

(18)

ptg13358382

xvii

Command Syntax Conventions

The conventions used to present command syntax in this book are the same conventions used in the IOS Command Reference. The Command Reference describes these conven-tions as follows:

■ Boldface indicates commands and keywords that are entered literally as shown. In actual configuration examples and output (not general command syntax), boldface indicates commands that are manually input by the user (such as a show command).

■ Italics indicate arguments for which you supply actual values.

■ Vertical bars (|) separate alternative, mutually exclusive elements. ■ Square brackets ([ ]) indicate optional elements.

■ Braces ({ }) indicate a required choice.

■ Braces within brackets ([{ }]) indicate a required choice within an optional element.

(19)

(20)

ptg13358382

Cisco Collaboration

Infrastructure

Cisco Unifi ed Communications (UC) is a way of creating collective and adaptive workspaces by incorporating communications and collaboration products with associated applications. Cisco UC helps people to work together more effectively and effi ciently by leveraging various unifi ed applications and services such as voice calls, voice messaging, presence, mobility, and video to people within and outside the organization. This begins with building the underlying infrastructure to support Cisco Collaboration applications, servers, devices, endpoints, and services.

Cisco Unified Communications Deployment Models

Cisco Unified Communications Manager (CUCM) is the brain of the Cisco UC solution and provides a single interface to all other UC features and functions. CUCM supports various deployment models. Each of these models is based on certain requirements of the organization that deploys a Cisco UC network. The Cisco UC deployment models are broadly classified as follows:

■ Campus deployment model: The Cisco UC and Collaboration services, which include call control, media resources, endpoints, and other applications, are all located on a single high-speed local-area network (LAN) or metropolitan-area network (MAN).

■ Centralized deployment model: The Cisco UC and Collaboration services are located in a central campus site or data center. However, the endpoints, applica-tions, media resources, gateways, and other components are dispersed across several remote sites. These sites may be interconnected to a central campus site and to each other by a quality of service (QoS)-enabled WAN.

■ Distributed deployment model: The call control is dispersed across multiple remote sites and multiple campus and/or centralized deployments that are interconnected over a QoS-enabled WAN.

(21)

ptg13358382

These three broad deployment models can be further classified into the following cat-egories of UC deployment models, which are described in more detail in the following subsections:

■ Single-site

■ Multisite WAN with centralized call processing

■ Multisite WAN with distributed call processing

■ Clustering over WAN call processing

Apart from the preceding on-premises models, Cisco offers cloud-based (managed) Collaboration solutions such as Cisco Hosted Collaboration Solution (HCS) and Cisco Hosted Unified Communications Services.

Single-Site Deployment Model

In a single-site deployment model, all CUCM servers in a cluster, all UC applications, and other media resources reside at the same location. All call processing is accomplished at the designated site with gateway trunks that connect directly to the public switched telephone network (PSTN) and handle external calls. As shown in Figure 1-1 , this model is ideal for small enterprises where call control should remain within a site (for example, headquarters).

CC

V

V Applications Media Resources Infrastructure

Internet PSTN CUCM Cluster Endpoints

V

(22)

ptg13358382

Cisco Unified Communications Deployment Models 3

The following are some best practices associated with the single-site deployment model:

■ Ensure that the infrastructure is highly available, enabled for QoS, and configured to offer resiliency, fast convergence, and inline power.

■ Deploy QoS from IP Phone (user access layer) to CUCM (data center access layer) to gateways for optimum voice quality.

■ Use a high-quality, low-compression codec such as G.711 for highest audio quality. This also allows digital signal processor (DSP) resources to be allocated for confer-encing or media termination point (MTP).

■ Deploy voice gateways or Session Border Controller (SBC) for Session Initiation Protocol (SIP) trunks to the IT service provider (ITSP) for off-net calls to the PSTN or a legacy PBX. All on-net calls should be limited to a central site based on calling patterns for your enterprise.

Multisite WAN with Centralized Call Processing Deployment Model

In a multisite WAN with a centralized call processing deployment model, all CUCM servers in a cluster reside at the same location. Optionally, applications and other media resources may be deployed at the same location as well. If the applications and media resources are at remote locations, it is beneficial to have a consolidated administration of all resources. The remote sites rely on the centralized CUCM cluster for call process-ing and other telephony functions. The centralized CUCM cluster connects with end-points and applications at remote sites through a QoS-enabled IP WAN. Remote sites are deployed with Cisco Unified Survivable Remote Site Telephony (SRST) on Cisco IOS voice gateways that allow endpoints and applications to function when the connection to the campus site is unavailable or disrupted. As shown in Figure 1-2 , this deployment model is ideal for small to medium enterprises.

CC

V

Applications Media Resources Infrastructure

CUCM Cluster

Internet

Media and Conference Resources

IP WAN

PSTN

Endpoints

V V

(23)

ptg13358382

The following are some best practices associated with the multisite WAN with central-ized call processing deployment model:

■ Use CUCM locations-based Call Admission Control (CAC) or Cisco IOS Resource Reservation Protocol (RSVP)-based CAC. This prevents oversubscription of the IP WAN as a result of voice calls.

■ Deploy Automated Alternate Routing (AAR) if the WAN bandwidth is full and CAC doesn’t allow for new calls via the IP WAN.

■ Deploy SRST for remote sites to ensure that the branch router has the capacity for handling IP Phone registration in case of a WAN failure. The voice gateway also provides local PSTN connectivity for remote site endpoints so that emergency calls, toll-free calls, and calls local to a region use the local gateway instead of the IP WAN to the campus PSTN SBC or router.

■ Deploy a low-bandwidth audio codec (for example, G.729) between remote sites and the central site and deploy G.711 within a site for optimum voice quality.

■ Deploy DSP resources at remote sites for conferencing, transcoding, or MTP resources.

Multisite WAN with Distributed Call Processing Deployment Model

In a multisite WAN with a distributed call processing deployment model, each site has its own call control, such as a CUCM cluster, Cisco Business Edition 6000, or Cisco Unified Communications Manager Express (CUCME). The remote sites can either have their own media resources and applications or employ them from the campus site. The dial plan can be aggregated using individual intercluster trunks (ICT) or Cisco Unified Communications Manager Session Management Edition (SME) cluster(s). As shown in Figure 1-3 , this deployment model is ideal for medium to large enterprises.

CC

V

Applications Media Resources Infrastructure

CUCM Cluster

Internet

Media and Conference Resources

IP WAN PSTN Endpoints Endpoints CUCM Cluster V V V

Figure 1-3 Multisite WAN with Distributed Call Processing Deployment Model

(24)

ptg13358382

Cisco Unified Communications Deployment Models 5

The following are some best practices associated with the multisite WAN with distrib-uted call processing deployment model:

■ Deploy SIP proxies such as the Cisco Unified SIP Proxy (CUSP) to provide call rout-ing and SIP signalrout-ing normalization.

■ In addition to other specific best practices for this model, follow general guidelines for the single-site and multisite WAN with centralized call processing models.

Clustering over WAN Call Processing Deployment Model

In this deployment model, the call control (CUCM and Cisco Business Edition 6000) CUCM is deployed across two or more data centers/sites over the IP WAN to provide redundancy, both within the region and overall. This model is particularly useful where multiple large sites have to be encompassed and dial-plan consistency must be main-tained. Clustering over WAN can be either a local failover deployment model, where the active and backup servers are at the same physical site, or a remote failover deployment model, where the active and backup servers are at different sites/data centers. Figure 1-4 depicts the clustering over WAN call processing deployment model.

Media Resources

Internet Internet

IP WAN

CUCM Cluster Over WAN

Infrastructure

Endpoints

Endpoints Media and Conference Resources

V V V V PSTN PSTN V V

Figure 1-4 Clustering over WAN Call Processing Deployment Model

The following are some best practices associated with the clustering over WAN call pro-cessing deployment model:

■ The round-trip time (RTT) for cluster over WAN call processing should not be more than 80 ms.

■ End-to-end QoS along with appropriate bandwidth provisioning specifically for Intra-Cluster Communication Signaling (ICCS) is required. Overprovisioning and undersubscription of bandwidth is recommended.

(25)

ptg13358382

Network Services

This section covers the various network services essential for a functional Cisco Collaboration solution:

■ Dynamic Host Configuration Protocol (DHCP)

■ Domain Name System (DNS)

■ Trivial File Transfer Protocol (TFTP)

■ Network Time Protocol (NTP)

■ Cisco Discovery Protocol (CDP)

■ Link Layer Discovery Protocol (LLDP)

Dynamic Host Configuration Protocol

DHCP is recommended for the successful deployment of UC endpoints such as Cisco Unified IP Phones, Jabber clients, and so on. Although endpoints can be configured with a static IP address, DHCP is particularly helpful in assigning IP address and other important parameters in bulk to IP Phones. Individual DHCP scopes must be created for each of the voice virtual LANs (VLAN), with sufficient addresses to support the maximum number of phones likely to be deployed in that VLAN. The DHCP service can be provided by CUCM, a Cisco IOS router or switch, or a third-party server (any RFC 2131–compliant DHCP server may be used to provide configuration information to IP Communications network devices).

In addition to specifying the common DHCP options such as subnet mask, default router, DNS servers, and so forth, each scope supporting Cisco Unified IP Phones should include the specification of DHCP option 150. This option should contain the IP address of TFTP servers. Because TFTP is crucial to the correct operation of a telephony network, it is recommended that DHCP option 150 be used so that TFTP server redundancy can be achieved by providing multiple differently ordered lists of TFTP server addresses to hosts.

The DHCP lease time controls the duration for which an IP Phone retains an IP address from a DHCP scope. Cisco Unified IP Phones request a new IP address after half the lease time has expired since the last successful DHCP server acknowledgment. After the request is acknowledged by the DHCP server, the IP Phone retains its IP scope.

For remote sites, DHCP service can be provided by local or remote DHCP servers. Remote DHCP requests can be relayed by Cisco IOS routers/switches on behalf of the requesting endpoint. DHCP relay is configured with the ip helper-address command. The following example outlines the configuration of a Cisco IOS router to relay a DHCP request to a DHCP server at a central site.

UCRouter(config)# interface GigabitEthernet 1/1 UCRouter (config-if)# ip helper-address 10.10.10.100

(26)

ptg13358382

Network Services 7

Example 1-1 shows configuration of a DHCP server on a Cisco IOS router.

Example 1-1 Cisco IOS Router–based DHCP Server Configuration

UCRouter (config)# service dhcp

!

UCRouter (config)# ip dhcp excluded-address 10.10.0.1 10.10.0.10

!

UCRouter (config)# ip dhcp pool VOICE

UCRouter (config-dhcp)# network 10.10.0.0 255.255.255.0

UCRouter (config-dhcp)# default-router 10.10.0.1

UCRouter (config-dhcp)# domain-name mydomain.local

UCRouter (config-dhcp)# option 150 ip 10.76.108.146

UCRouter (config-dhcp)# lease 7

UCRouter (config-dhcp)# dns-server 10.10.0.2

In Example 1-1 , the ip dhcp excluded-address command helps segregate addresses from the assignment pool so they are not assigned to any endpoint. The DHCP pool defines a network from which the endpoints can get their IP address, option 150, and other param-eters, as explained earlier.

Domain Name System

DNS is used for name resolution and is particularly useful for management purposes and load-balancing requirements. A Cisco Collaboration network and applications such as CUCM, Cisco Unity Connection, Cisco Unified IP Phones, Cisco IOS routers, and other devices can leverage DNS to resolve names to IP addresses.

However, Cisco strongly recommends that DNS not be used for critical communications in the Collaboration network, such as IP Phone to CUCM, voice gateway to CUCM, and intra-cluster communication. Cisco suggests using IP addresses, when possible, between call control and endpoints to avoid any risk of registration failure, because endpoints won’t be able to resolve the name of the CUCM server(s) when DNS service is unavail-able. Because a DNS server can be a single point of failure in a Cisco UC network, Cisco recommends deploying redundant DNS servers or using IP addresses.

During the initial installation of a CUCM cluster, the servers are referenced in the local server table by their hostnames. Before you install and configure any endpoints on the system, you should change this table to include the IP addresses of the servers instead of their hostnames. To change the name of a CUCM server (which defaults to the hostname during installation), go to the Cisco Unified CM Administration page, choose System > Server , and replace the server name with its respective IP address, as shown in Figure 1-5 .

(27)

ptg13358382

Figure 1-5 CUCM Server Hostname to IP Address Substitution

This should be performed even if the system is configured to use DNS (that is, the DNS client is enabled on the cluster servers).

Trivial File Transfer Protocol

TFTP is a crucial component of a Cisco Collaboration network as Cisco Unified IP Phones require a TFTP server to retrieve their firmware, configuration files, phone but-ton template, and other information. This only confirms that having TFTP redundancy is paramount in a critical UC setup. As discussed earlier, DHCP option 150 can be used to enable TFTP redundancy in a Cisco Collaboration network.

A TFTP server has various files that can be used by different types of endpoints (phones, gateways, and so forth), such as the following:

■ Phone firmware files (Cisco-signed files, which are not modifiable)

■ Phone configuration files (XMLDefault.cnf.xml or SEP< MAC address >.cnf.xml)

■ Certificate Trust List (CTL) files (only if the cluster is in mixed mode)

■ Identity Trust List (ITL) files (for all endpoints that register with CUCM)

■ Tone localization files

■ User interface (UI) localization and dictionary files

(28)

ptg13358382

Network Services 9

■ Softkey and Phone Button Template files

■ Background images

The Cisco Unified IP Phone to TFTP interaction process can be best illustrated by going through the IP Phone bootup cycle, as shown in the following steps:

Step 1. Assuming that the IP Phone is connected to a Cisco Catalyst switch that is capable of providing Power over Ethernet (PoE), using Fast Link Pulse (FLP), the switch detects an unpowered IP Phone and powers it up using Cisco pro-prietary standard (provides .48 V DC at up to 6.3 to 7.7 W per port over data pins 1, 2, 3, and 6).

Step 2. Every IP Phone has nonvolatile flash memory in which it stores firmware image(s). At startup, the IP Phone runs a bootstrap loader that loads an avail-able phone image stored in flash memory. Using this image, the IP Phone ini-tializes its software and hardware.

Step 3. As the IP Phone receives power and boots, the switch sends a Cisco

Discovery Protocol (CDP) packet to the IP Phone. This CDP packet provides the IP Phone with voice VLAN (also known as auxiliary VLAN) information so that the IP Phone can reach the appropriate VLAN and initiate a DHCP request.

Step 4. The IP Phone sends a broadcast request such as a DHCP discover message to the DHCP server in the voice VLAN. The DHCP server replies with an IP address, a subnet mask, a default gateway, and the IP address of the Cisco TFTP server. There could be additional optional parameters as well. However, at a minimum, these steps are required for IP Phone connection.

Step 5. The IP Phone contacts the Cisco TFTP server or external TFTP server to request firmware and files. The TFTP server sends the configuration informa-tion for that IP Phone, which contains an ordered list of up to three CUCM servers or two CUCM servers and an SRST reference. If the IP Phone was manually preconfigured in CUCM, the SEP< MAC address >.cnf.xml file is

downloaded for that phone. Otherwise, the XMLDefault.cnf.xml configura-tion file is used for IP Phones that request auto-registraconfigura-tion.

Step 6. The .cnf.xml file indicates the firmware load that the IP Phone should be run-ning. If this image load differs from the one that is currently on the IP Phone, the phone contacts the TFTP server to request the new firmware load file, which has a .bin file extension. The IP Phone installs the firmware in its non-volatile RAM and reboots.

Step 7. After rebooting, the IP Phone downloads other information such as the soft-key template and phone button template. The IP Phone attempts to make a TCP connection to a CUCM server that is considered the highest priority in its list. The phone registers to the CUCM server and obtains a directory num-ber (DN).

(29)

ptg13358382

Cisco TFTP service can be supported in multiple ways to serve local and remote-site Cisco Unified IP Phones:

■ Cisco TFTP Server: The default method of using one or more CUCM servers in the cluster as TFTP servers that allows IP Phones to download the firmware, con-figuration, and other files. This is an ideal model for an enterprise environment with high-speed WAN links because the Cisco Unified IP Phones at a remote site will download firmware during initial setup or firmware upgrade via centralized TFTP servers. In case of the multisite WAN with distributed call processing deployment model or the clustering over WAN call processing deployment model, CUCM TFTP servers can be deployed at larger remote sites to serve local phones. Cisco CUCM also supports proxy TFTP that enables phones to sync with a proxy TFTP server that forwards the requests to their respective clusters. This is especially useful in the case of multiple phones tied to multiple clusters at remote sites. It saves the overhead of manually defining multiple option 150 for IP Phone subnets to the correct TFTP servers.

■ Load Server: A CUCM administrator can assign a TFTP server to each individual phone record using the Load Server parameter. Assigning the Load Server parameter is particularly useful for remote sites where downloading firmware to the phone is difficult due to lower WAN speeds. In such cases, a CUCM administrator can deploy local TFTP servers (Windows- or IOS-based TFTP) to allow the phones to operate at remote sites without having to traverse the WAN for firmware download. To enable the Load Server parameters on a per-phone basis, go to the Cisco Unified CM Administration page, choose Device > Phone , and select the phone for which a particular load server is to be defined. Browse to Product Specific Configuration

Layout , define the Load Server IP address/hostname, and enable the same.

■ Peer Firmware Sharing (PFS): PFS is a feature that allows phones participating in this firmware distribution model to form a peering relationship in a tree-based hier-archy. One phone peers with two other phones. The administrator, however, does not need to designate parents (phones initiating PFS) and hosts (phones accepting PFS). All the peer-enabled Cisco Unified IP Phones on a given IP subnet form a tree structure to distribute the firmware. After the peering relationship is established, the root phone retrieves the firmware files from the Cisco TFTP server and distributes them to the associated peers. This helps to reduce the load on the WAN during firm-ware upgrades and minimize the overall time needed to upgrade remote-site phones. PFS is supported with Cisco Unified IP Phone firmware 8.3(1) and later. To ensure that the phones are participating in a PFS distribution, go to the Cisco Unified CM Administration page, choose Device > Phone , and select the phone that should be enabled for PFS. Browse to Product Specific Configuration Layout and ensure that the Peer Firmware Sharing option is enabled.

(30)

ptg13358382

Network Services 11

Network Time Protocol

NTP enables network devices to synchronize their clocks to a network time server or a network-capable clock. NTP is critical for ensuring that all devices in a Cisco Collaboration network have the same time. Time synchronization is especially critical on CUCM servers. In addition to ensuring that call detail records (CDR) are accurate and that log/trace files are synchronized, an accurate time source is necessary for any future (IPsec) features to be enabled within the cluster and for communication with any external entity.

NTP should be configured across the network to allow for the synchronization of log files between multiple devices. Keeping the time accurate on all systems in the infrastruc-ture helps administrators to troubleshoot and correlate events in a Cisco Collaboration network. Devices in a Cisco Collaboration network can receive the time from an authori-tative time source, such as a Cisco router or an atomic clock.

Example 1-2 outlines the configuration of a router to receive the time from an authorita-tive time source.

Example 1-2 Cisco IOS NTP Client Configuration UCRouter(config)# ntp authentication-key 1 md5 C1sc0123 UCRouter(config)# ntp trusted-key 1

UCRouter(config)# ntp source FastEthernet0/1

UCRouter(config)# ntp server 10.10.200.200 key 1 prefer source FastEthernet0/1 version 3

UCRouter(config)# ntp authenticate

CUCM automatically synchronizes the NTP time of all subscribers in the cluster to the publisher. During installation, each subscriber is automatically configured to point to an NTP server running on the publisher. Cisco recommends using an NTP time source with NTP stratum 3 or better (the lower the better). An NTP time source can be added to the CUCM publisher by navigating to the Cisco Unified Operating System Administration page and choosing Settings > NTP Servers , as shown in Figure 1-6 .

Skinny Call Control Protocol (SCCP) endpoints leverage the CUCM publisher’s NTP source implicitly. You can add a phone NTP reference for SIP endpoints. To add a phone NTP reference in CUCM, go to the Cisco Unified CM Administration page and choose System > Phone NTP Reference . You must assign this NTP reference to a date/time group, which in turn is assigned to a device pool.

(31)

ptg13358382

Cisco Discovery Protocol

CDP is a Cisco-proprietary Layer 2 protocol that was developed for discovering neighbor devices. It is a media- and protocol-independent device-discovery protocol that runs on Cisco equipment, including Cisco Unified IP Phones, routers, access servers, and switch-es. A device can advertise its existence to other devices using CDP and can also receive information about other devices on the network. There are two versions of CDP, Version 1 and Version 2. All modern Cisco gear runs CDPv2 by default.

CDP operates on all media that supports Sub-Network Access Protocol (SNAP), includ-ing LAN, Frame Relay, and ATM. CDP messages are multicast advertisements sent with the multicast destination address 01:00:0C:CC:CC:CC on each CDP-enabled interface. CDP advertisements contain information such as the following:

■ Device ID ■ Port ID ■ Address ■ Capabilities ■ Version ■ Platform ■ Native VLAN

CDP messages are made up of Version, Time to Live (TTL), and Checksum fields, fol-lowed by a number of Type, Length, and Value (TLV) fields. Table 1-1 illustrates various CDP TLV fields.

(32)

ptg13358382

Network Services 13

Table 1-1 CDP TLV Fields

CDP TLV Field Description

Device ID Identifies the sending device’s hostname

Address Provides the address of the interface (physical, loopback, VLAN) that is sending the CDP update

Port ID Specifies the port from which the CDP update is sent (outgoing port)

Capabilities Identifies the device’s functional capabilities (e.g., router, switch, host)

Version Specifies the Cisco IOS or firmware version running on the device advertising the updates

Platform Identifies the hardware or virtual platform

Full/Half Duplex Indicates the duplex mode of the advertising device’s connected interface

VTP Domain Identifies the VTP domain of the advertising device (if any) Management Address Identifies the management address of the advertising device (if any)

Example 1-3 illustrates how to access CDP timer, holdtime, and version information as well as CDP discovery information.

Example 1-3 CDP Information UCSwitch# show cdp

Global CDP information:

Sending CDP packets every 60 seconds Sending a holdtime value of 180 seconds Sending CDPv2 advertisements is enabled !

UCSwitch# show cdp neighbors

Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge S - Switch, H - Host, I - IGMP, r - Repeater

Device ID Local Intrfce Holdtme Capability Platform Port ID CM91PUB Fas 0/30 135 H VMware eth0 CUPS91 Fas 0/26 169 H VMware eth0 UCRouter Fas 0/24 163 R S I CISCO3945-Gig 0/0

(33)

ptg13358382

CDP can be disabled globally or on a per-interface basis, as shown in Example 1-4 .

Example 1-4 Disabling CDP at Global and Interface Level UCRouter(config)# no cdp run

!

UCRouter(config)# int FastEthernet 0/1 UCRouter(config-if)# no cdp enable

Disabling CDP is useful when phones are not connected to switch ports, and for security reasons, such as hiding device details that you may not want to share with other infra-structure components.

Link Layer Discovery Protocol

LLDP is a vendor-neutral Layer 2 protocol and is analogous to CDP. LLDP is the stan-dards-based IEEE 802.1AB protocol for vendor-neutral interoperability. Similar to CDP, it is used by network devices to advertise their identity, capabilities, and neighbors, but primarily for non-Cisco equipment or endpoints. If the switches are non-Cisco switches, LLDP for Media Endpoint Devices (LLDP-MED) can be used to detect power and voice VLAN, provided the switch is capable of delivering Power over Ethernet. Also, if the endpoints are non-Cisco devices, LLDP-MED can be used on Cisco switches to support third-party phones.

LLDP information is sent by devices from each of their interfaces at a fixed interval of 30 seconds with the holdtime of 120 seconds. This takes place in the form of an Ethernet frame, where each frame contains one LLDP Data Unit (LLDPDU). Each LLDPDU is a sequence of TLV structures. By default, LLDP is disabled on Cisco routers and switches. Table 1-2 provides the TLV fields that are advertised by LLDP.

Table 1-2 LLDP TLV Fields

LLDP TLV Field Description

Port Description Identifies the port from which the LLDP update is sent System Name Identifies the sending device’s hostname

System Description Provides details about the advertising device’s OS/firmware System Capabilities Identifies the device’s functional capabilities (e.g., router, switch,

host)

Management Address Provides the management IP address (if any)

Port VLAN ID Identifies the native VLAN ID of the advertising port MAC/PHY

Configuration/Status

(34)

ptg13358382

Power over Ethernet 15

Example 1-5 illustrates LLDP configuration on a Cisco switch at a global level and an individual interface level.

Example 1-5 LLDP Information UCSwitch# show lldp % LLDP is not enabled ! UCSwitch(config)# lldp run !

UCSwitch(config)# interface FastEthernet 0/1 UCSwitch(config-if)# lldp transmit

UCSwitch(config-if)# lldp receive

Power over Ethernet

There are three ways to power up a Cisco Unified IP Phone:

■ Inline power: Power over Ethernet, derived from switch port

■ Power supply: Using power supply from a wall jack

■ Midspan power injector: Sits between a switch port and the IP Phone and supplies power to the IP Phone

Cisco supports two types of inline power delivery as PoE: the Cisco original implementa-tion (Cisco proprietary) and the IEEE 802.3af standards-based PoE. The original Cisco implementation has the following features:

■ Uses a Cisco proprietary method to determine whether an attached device requires power. Power is delivered only to devices that require power.

■ Provides .48 V DC at up to 6.3 to 7.7 W per port over data pins 1, 2, 3, and 6.

■ Supports most Cisco devices such as Cisco Unified IP Phones.

After first developing (pre-standard) PoE, Cisco worked with IEEE to create a standards-based PoE delivery mechanism to develop what is currently known as the IEEE 802.3af standard, which has the following features:

■ Specifies .48 V DC at up to 15.4 W per port over data pins 1, 2, 3, and 6 or over the spare pins 4, 5, 7, and 8 (power sourcing equipment [PSE] can use one or the other, but not both).

(35)

ptg13358382

The process via which PoE-enabled switches detect and power a Cisco Unified IP Phone varies depending on whether you are using the Cisco original standard or the IEEE stan-dards-based implementation. If you employ the Cisco-proprietary method, a switch sends a Fast Link Pulse (FLP) to the connected device. When the connected device loops the FLP back to the switch, the switch starts supplying power over the Ethernet connection to the device. If you use IEEE 802.3af, the switch applies a voltage in the order of –2.8 to –10 V, and if a resistance of 25K ohm is detected, the switch supplies power to the con-nected device.

It is recommended to deploy PoE-capable switches at the campus access layer within wir-ing closets to provide inline-powered Ethernet ports for IP phones, thus eliminatwir-ing the need for wall power. If the switches are non-Cisco switches, LLDP-MED can be used to detect power and voice VLAN.

Voice and Data VLANs

Virtual LANs (VLAN) enable a network administrator to break up a switching domain into multiple broadcast domains. Think of a VLAN as virtually fragmenting a Cisco switch into multiple sub-switches, with each VLAN/subswitch being a broadcast domain and having a unique IP subnet.

A Cisco Catalyst/Nexus switch has multiple physical ports, all of which belong to VLAN 1 by default (out of the box). A set of ports can be assigned to, say, VLAN 100 and another set of ports can be assigned to VLAN 200. This helps break up (logically) a large physical switch with a single broadcast domain and a single IP subnet into multiple small virtual switches, with each virtual switch having its own broadcast domain and IP subnet. Some of the benefits of this process include increased security, increased performance, and a physical topology–independent network.

When a switch is configured for data and voice VLANs, Cisco Unified IP Phones con-nect to the user-facing access layer ports on the switch, followed by a PC or a data device connecting to the IP Phone’s PC port. IP Phones come with a built-in switch that inter-faces between the PC port and switch port. IP Phones support 802.1Q tagging, and the incoming switch port receives and sends 802.1Q-tagged packets. Voice packets are 802.1Q tagged, and the switch understands the tagging on the access port, thereby assigning these packets to voice VLAN. The data packets, on the other hand, pass through the IP Phone to the switch as untagged packets, and the switch assigns these untagged packets to the data VLAN.

Cisco strongly recommends separating voice and data traffic by using VLANs for the fol-lowing reasons:

■ To provide clear segregation of voice and data traffic

■ To provide QoS marking and classification for real-time voice traffic vis-à-vis data traffic

(36)

ptg13358382

IP Routing in Cisco Collaboration Campus Environments 17

Example 1-6 illustrates configuration of voice and data VLANs on a Cisco Catalyst switch.

Example 1-6 Voice and Data VLAN Configuration UCSWITCH(config)# vlan 100

UCSWITCH(config-vlan)# name Data-VLAN !

UCSWITCH(config)# vlan 200

UCSWITCH(config-vlan)# name Voice-VLAN !

UCSWITCH(config)# interface range FastEthernet 0/1 - 10 UCSWITCH(config-if-range)# switchport mode access UCSWITCH(config-if-range)# switchport access vlan 100 UCSWITCH(config-if-range)# switchport voice vlan 200 UCSWITCH(config-if-range)# spanning-tree portfast

IP Routing in Cisco Collaboration Campus

Environments

IP routing is used for many functions in Cisco Collaboration networks and forms the backbone of any successful deployment. IP routing is employed for the following:

■ Inter-VLAN routing

■ Static or dynamic routing

■ Cisco Service Advertisement Framework (SAF)

■ Cisco Unified IP Phone to UC/application server communication

■ UC/application server or IP Phone to gateway communication

For optimum performance of the Cisco Collaboration solution, the network should be modeled after Cisco’s recommended core, distribution, and access (CDA) layer approach. Layer 3 routing protocols such as Routing Information Protocol (RIP), Enhanced Interior Gateway Routing Protocol (EIGRP), and Open Shortest Path First (OSPF) are commonly employed in unified IP environments. Routing protocol parameters such as timers, path/link costs, and route summaries can be used to optimize and control convergence times and distribute traffic across multiple paths. Cisco recommends using the

passive-interface command to prevent routing neighbor adjacencies via the access layer.

Campus Infrastructure Design

Before examining the specifics of IP routing in a campus environment, it’s important to understand the design basics. One of the most important principles of campus network

(37)

ptg13358382

design is to introduce and enable a hierarchy in the network infrastructure. This allows each network layer to play a specific role, thus ensuring scalability, reliability, and better management.

Campus-wide VLANs are based on the flat design model, meaning they avoid the logical,

hierarchical structure and the route summarization provided by routers. Layer 3 switching provides the same advantages as routing in campus network design with the added per-formance boost from packet forwarding handled by specialized hardware. Layer 3 switch-ing in the distribution layer and core of the campus segments the campus into smaller, more manageable pieces. A multilayer approach combines Layer 2 switching with Layer 3 switching to achieve robust, highly available campus networks.

Campus Access Layer

The campus access layer is where the user-facing devices connect to the LAN (wiring closet switches) and leverage network services. Typically, at the user access layer, Layer 2 is maintained because it can limit broadcast domains within VLANs. More importantly, it has voice and data endpoints that connect to the same switch ports. The access layer is also known as the network edge. A number of feature sets can be used at this layer to implement network policies around areas such as security, high availability, QoS, and so on.

Campus Distribution Layer

The campus LAN distribution layer consists of the section of the network from the wir-ing closet switches to the next-hop switch. It’s the focal point at which network policies are created and enforced. This layer is responsible for aggregating incoming user traffic from wiring closet access switches and then aggregating it to the core. At the distribution layer, it is important to provide redundancy to ensure high availability, including redun-dant links between the distribution layer switches and redunredun-dant links to access layer switches. Various first-hop redundancy mechanisms are available, including Hot Standby Router Protocol (HSRP), Gateway Load Balancing Protocol (GLBP), and Virtual Router Redundancy Protocol (VRRP).

Campus Core Layer

The campus core layer serves as the backbone of the entire network infrastructure of a campus, where all the traffic from the distribution layer aggregates. It is at this layer that ingress and egress of traffic in a network occurs. The core layer provides high-speed transport and interconnectivity of various building blocks within the campus. The core layer is usually made up of high-speed links that can aggregate all the traffic from points in the distribution layer. It is again vital to provide redundancy to ensure high availability. This can be achieved by redundant link or cable paths, redundant devices, and redun-dant subsystems (such as Catalyst Supervisor Engine modules). Cisco Catalyst switches

(38)

ptg13358382

IP Routing in Cisco Collaboration Campus Environments 19

with Virtual Switching System (VSS) can be used to aggregate two Catalyst Supervisor Engines to act as one.

Campus Routed Access Layer Design

As previously mentioned, Cisco-recommended CDA architecture should be followed while designing a campus network. There are two options for access layer design perti-nent to campus network design, as shown in Figure 1-7 :

■ Traditional Cisco campus design: Traditional design with Layer 2 at the access layer and Layer 3 at the distribution and core layers

■ Routed access campus design: Modification of the traditional design to extend Layer 3 to the access layer

Layer 3 Core Distribution Access Layer 2 Layer 3

Routed Access Campus Design

Traditional Cisco Campus Design Layer 2

Figure 1-7 Traditional Cisco Campus Design Versus Routed Access Campus Design

Compared to the traditional Cisco campus design, the routed access campus design (combining Layer 3 switching at the access and distribution layers) provides the fast-est convergence of voice and data traffic flows. Other advantages over the traditional approach include a single control plane, dynamic traffic load balancing, and use of a single set of tools for troubleshooting.

(39)

ptg13358382

The following best practice recommendations apply to the L2/L3 campus network design:

■ The infrastructure topology should adhere to the Cisco-recommended campus CDA design approach.

■ Use Layer 3 links beginning with the access layer connecting to the distribution and core layers for maximum redundancy and fastest convergence time in case of link or device failure.

■ The access layer switches should have dual connectivity to distribution switches and support the required QoS features.

■ VLANs should not span multiple switches.

■ All Cisco Collaboration device switch ports (e.g., IP phones) should be put in spanning-tree PortFast so that they can move to a fully operational state as fast as possible.

■ Spanning tree should be limited to access switches, and Layer 3 links should be used between access, distribution, and core switches.

IPv6 in Cisco Collaboration Networks

An IPv6 address contains 128 bits, compared to 32 bits for an IPv4 address. This gives IPv6 a much larger address space, to the order of 2^128 = 3.4 × 10^38 addresses, com-pared to the IPv4 address space of 2^32 = 4.3 billion addresses.

IPv6 addresses are represented as a series of eight 16-bit fields of (hexadecimal) char-acters and numbers separated by colons. The format used is X:X:X:X:X:X:X:X. An example of an IPv6 address is fe80:0:0:0:0:0:a0a:64c8, which is equivalent to IPv4 address 10.10.100.200. The IPv6 address fe80:0:0:0:0:0:a0a:64c8 can be shortened by following some simple rules:

■ Two colons (::) can be used to compress successive hexadecimal fields of 0s at the beginning, middle, or end of an IPv6 address. However, this can be done only once in an address; that is, one instance of :: is allowed per address.

■ The leading 0s in a field are optional.

Following these rules, IPv6 address fe80:0:0:0:0:0:a0a:64c8 can be shortened to fe80::a0a:64c8.

(40)

ptg13358382

IPv6 in Cisco Collaboration Networks 21

IPv6 Address Types

IPv6 supports the following address types:

■ Unicast: Synonymous to IPv4, an IPv6 unicast address entails sending of messages to a single network destination identified by a unique address.

■ Anycast: An IPv6 anycast address is an address that is assigned to a set of interfaces that typically belong to different nodes. A packet sent to an anycast address is deliv-ered to the closest interface, as defined by the routing protocols.

■ Multicast: Similar to IPv4, IPv6 multicast allows a host to send a single data stream to a subset of all hosts simultaneously.

IPv6 Addressing Model

Figure 1-8 depicts the IPv6 addressing model.

Link-local Unique-local Global

Figure 1-8 IPv6 Addressing Model

An IPv6 addressing model pertinent to a Cisco Collaboration network can be defined as follows:

■ Link-local address: An IPv6 unicast address that can be automatically or manually configured on an IPv6 interface. Link-local addresses are used exclusively for com-munication between two IPv6 devices on the same link (as well as for Neighbor Discovery Protocol and stateless auto-configuration process); that is, with local routability scope. On automatic configuration, the address uses the link-local prefix FE80::/10 (1111 111010) and interface ID.

■ Unique-local address: IPv6 unicast address that uses the prefix FEC0::/10 (1111 111011) and concatenates the subnet identifier (the 16-bit field) with the interface identifier. Unique-local addresses are analogous to RFC 1918 private addresses in IPv4 and are not advertised beyond the local site. They are used for local communi-cations, inter-site VPNs, and so forth. Subnet IDs are typically defined using a hierar-chical addressing plan to allow for route summarization.

(41)

ptg13358382

■ Global address: Address that is routable across the Internet. Global addresses consti-tute IPv6 addresses for widespread generic use and are structured as a hierarchy to allow address aggregation. Global addresses are identified by their three high-level bits set to 001 (2000::/3). These are the unique addresses assigned by service provid-ers or regional registries for participation in the public network.

In context of IPv6, CUCM supports one link-local address, one unique-local address or a global address, and an IPv4 address.

Cisco Unified IP Phones can support one link-local address, multiple unique-local addresses, multiple global addresses, and an IPv4 address. If the phone has both unique-local and global addresses, the global addresses take precedence over unique-unique-local addresses. If multiple unique-local addresses or multiple global addresses exist, the first address configured is used as the signaling and media address sent to CUCM. Cisco Unified IP Phones use one IPv6 address (global or unique-local) for CUCM signaling and media.

When configured for receiving an IPv6 address, Cisco Unified IP Phone IPv6 address selection priority is as follows:

1. If configured, use the address that has been manually configured via the IP Phone’s UI.

2. If an address has not been manually configured, use DHCPv6 to assign an address. 3. If neither a DHCPv6 address nor a manually configured address is available, and

Stateless Address Autoconfiguration (SLAAC, RFC 2462) is enabled for the IP Phone (CUCM default is on), the IP Phone uses SLAAC to create an IPv6 address. The router RA “O” bit should be set.

Cisco IOS devices support one link-local address, multiple unique-local addresses, mul-tiple global addresses, and mulmul-tiple IPv4 addresses. Cisco IOS routers use link-local addresses for routing protocols and use the address selection algorithm (RFC 3484) for applications running on routers—for example, Telnet, Secure Shell (SSH), and so on. For responses to devices, routers attempt to use the same network prefix as the device that is initiating communication.

To allow IPv6-based call processing, IPv6 must first be enabled throughout a CUCM cluster. This involves the following steps:

Step 1. Configure IPv6 via the Cisco Unified CM Administration page by choosing System > Server Configuration . IPv6 must be configured via the OS CLI or Cisco Unified Operating System page on each server in the cluster.

Step 2. Enable IPv6 cluster-wide via the Cisco Unified CM Administration page by choosing System > Enterprise Parameters ; and setting Enable IPv6 to True, set IP Addressing Mode Preference for Media to IPv6, IP Addressing Mode Preference for Signaling to IPv6, and Allow Auto-Configuration for Phones (SLAAC) to On.

(42)

ptg13358382

Virtualization in Cisco Collaboration Solutions 23

Step 3. Configure Common Device Configuration for IP Phone Profile and SIP Trunks to enable IPv4 and IPv6 addressing mode, Signaling Preference, and Phone Auto Configuration settings. Device setting takes precedence over global settings.

The following are IPv6 deployment guidelines for Cisco Collaboration infrastructure:

■ LAN and WAN environments must be considered when deploying IPv6, as most applications and infrastructure components may be configured for or support IPv4.

■ Dual-stack deployments offer the best approach when introducing IPv6 into any network environment, as both IPv4 devices and dual-stack IPv4/v6 devices can inter-operate. Disruption to the existing network is minimal.

Virtualization in Cisco Collaboration Solutions

Cisco Unified Computing System (Cisco UCS) combined with VMware vSphere provides virtualization for Cisco UC applications. Virtualizing UC applications has many benefits, such as

■ Infrastructure can be simplified and consolidated using virtualized computing plat-forms to reduce server count, network ports, cabling, and power consumption.

■ Cisco UC applications can be deployed and scaled rapidly on a virtualized platform compared to Media Convergence Server (MCS)-based installations.

■ A virtual environment supports simplified upgrade and migration, thereby providing elasticity in deployment and service enablement.

Cisco offers many virtualization solutions for Cisco Collaboration environments, ranging from desktop to data center. Some of the virtual solutions for Cisco Collaboration are listed in Table 1-3 .

Table 1-3 Cisco Collaboration Virtual Solutions Virtual Solution Description

Cisco UCS Blade server for bare metal or hypervisor-based installation in data centers.

Cisco Virtualization Experience Infrastructure (VXI)

Delivers integrated Unified Communications platform, is device agnostic, and delivers enterprise voice, video, mobility, presence, and session management with security.

Cisco Virtualization Experience Media Engine (VXME)

Enables Jabber to run in virtualized environments. This is a sub-component of Cisco VXI.

Cisco Virtualization Experience Client (VXC)

A thin client designed to easily integrate into a virtualized infra-structure. This is a subcomponent of the Cisco VXI solution.