CCIE COLLABORATION QUICK REFERENCE cisco press.pdf

8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf

1/315

From the Library of Juan Arcaya


2/315

Cisco Press800 East 96th Street

Indianapolis, IN 46240

CCIE Collaboration QuickReference

Akhil Behl, CCIE No. 19564



3/315

CCIE Collaboration Quick ReferenceAkhil Behl, CCIE No. 19564 (Voice and Security)

Copyright© 2014 Pearson Education, Inc.Published by:Cisco Press800 East 96th StreetIndianapolis, IN 46240 USA

All rights reserved. No part of this book may be reproduced or transmitted in any form or by anymeans, 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 ofbrief 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. Everyeffort has been made to make this book as complete and as accurate as possible, but no warranty orfitness 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 programsthat may accompany it.

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

ii CCIE Collaboration Quick Reference



4/315

Trademark Acknowledgments

All terms mentioned in this book that are known to be trademarks or service marks have beenappropriately 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 anytrademark or service mark.

Special Sales

For information about buying this title in bulk quantities, or for special sales opportunities (whichmay 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. Eachbook is crafted with care and precision, undergoing rigorous development that involves the uniqueexpertise of members from the professional technical community.

Readers’ feedback is a natural continuation of this process. If you have any comments regardinghow we could improve the quality of this book, or otherwise alter it to better suit your needs, youcan contact us through email at [email protected]. Please make sure to include the booktitle 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

iii



5/315

iv CCIE Collaboration Quick Reference

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/315

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/315

vi CCIE Collaboration Quick Reference

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.

Everyone else in the Cisco Press production team, for their support and commitment.



8/315

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

Chapter 10 Cisco Collaboration Network Management 283



9/315

viii CCIE Collaboration Quick Reference

Contents

Chapter 1 Cisco Collaboration Infrastructure 1

Cisco Unified Communications Deployment Models 1

Single-Site Deployment Model 2

Multisite WAN with Centralized Call Processing Deployment Model 3

Multisite WAN with Distributed Call Processing Deployment Model 4

Clustering over WAN Call Processing Deployment Model 5

Network Services 6

Dynamic Host Configuration Protocol 6

Domain Name System 7

Trivial File Transfer Protocol 8

Network Time Protocol 11

Cisco Discovery Protocol 12

Link Layer Discovery Protocol 14

Power over Ethernet 15

Voice and Data VLANs 16

IP Routing in Cisco Collaboration Campus Environments 17

Campus Infrastructure Design 17

Campus Access Layer 18

Campus Distribution Layer 18

Campus Core Layer 18

Campus Routed Access Layer Design 19

IPv6 in Cisco Collaboration Networks 20

IPv6 Address Types 21

IPv6 Addressing Model 21

Virtualization in Cisco Collaboration Solutions 23

Cisco UCS Servers 24

VMware ESXi for Cisco Collaboration Virtualization 26

UC Application Install Answer File 26

IP Multicast 27

Wireless in Cisco Collaboration Solutions 28

Chapter 2 Quality of Service (QoS) 31

QoS Requirements for Voice and Video 32

QoS Deployment Architectures 33Classification and Marking 34



10/315

ix

Layer 2 Marking 34

Layer 3 Marking 35

Network-Based Application Recognition 36

Classification Service Classes 37

Classification and Marking for Softclients 37

Classification and Marking for Video Traffic 38

Queuing 38

Cisco Queuing Toolset 39

Weighted Random Early Detection 40

WAN QoS Considerations 41

Traffic Policing and Shaping 41

Link Efficiency Mechanisms 43

Compressed RTP 43

Link Fragmentation and Interleaving 43

Multilink PPP 44

Frame Relay Forum 12 44

Voice Activity Detection 45

LAN QoS Considerations 46

QoS Trust Boundary 46

QoS Considerations for WLAN Endpoints 47

QoS Considerations for Virtual Unified Communications with Cisco UCS 48

Medianet 49

Medianet QoS Classes of Service 52

Chapter 3 Telephony Standards and Protocols 55

Voice and Video Codecs 55

VoIP Media Transmission Protocols 57

VoIP Signaling Protocols 58Skinny Client Control Protocol 58

Media Gateway Control Protocol 61

Session Initiation Protocol 65

SIP Session Description Protocol 71

SIP Binary Floor Control Protocol 72

H.323 Gateway, Gatekeeper, and RAS 73

H.323 Gateway 75

H.323 Gatekeeper 76H.225 and RAS Signaling 77



11/315

x CCIE Collaboration Quick Reference

H.239-Based Dual Video Channels and Cisco Video Equipment Support 82

Analog Telephony 83

Foreign Exchange Office 83

FXO Disconnect 83

Foreign Exchange Station 84

E&M 84

Digital Telephony 85

Integrated Services Digital Network 85

Q Signaling Protocol 87

Channel Associated Signaling 87

T1 CAS 87

E1 R2 88

Non-Facility Associated Signaling 88

Analog and Digital Telephony Call Signaling Elements 89

Direct Inward Dial 89

Caller ID 89

Echo 90

Trans Hybrid Loss 90

Fax and Modem Protocols 91

Fax Services over IP Network 91

Modem Services over IP Network 93

Chapter 4 Cisco Unified Communications Manager 95

CUCM Redundancy and Device Registration 95

CUCM Device Pool 96

Common Device Configuration 98

Codec Selection 99

CUCM Features 100Call Park and Directed Call Park 100

Call Pickup and Group Pickup 101

Meet-Me Conference 102

Busy Lamp Field Speed Dials 102

CUCM Native Call Queuing 102

Call Hunting 103

CUCM Media Resources 104

Annunciator 104Conference Bridge 104



12/315

xi

Media Termination Point 105

Transcoder 105

Music on Hold 105

Media Resource Group and Media Resource Group List 106

Trusted Relay Point 107

CUCM Dial Plan 107

Partitions and Calling Search Spaces 108

Translation Patterns 109

Route Patterns 109

Route List 109

Route Group 110

Globalized Call Routing 110

Local Route Group 111

Time-of-Day Routing 112

Application Dial Rules 112

Directory Dial Rules 113

SIP Dial Rules 113

CUCM Digit Manipulation 114

CUCM H.323 and SIP Trunks 116

SIP Uniform Resource Identifier Dialing 117

Intercluster Lookup Service 119

Blended Addressing 122

CUCM Call Admission Control 122

Locations-Based CAC 123

Enhanced LCAC 124

Resource Reservation Protocol 126

RSVP SIP Preconditions 128

CUCM-Based Call Recording and Silent Monitoring 129

CUCM Mobility 133

Extension Mobility and Extension Mobility Cross Cluster 133

Device Mobility 135

Mobile Connect 136

Mobile Voice Access 138

Service Advertisement Framework and Call Control Discovery 140

SAF Architecture 140

Call Control Discovery Service 142



13/315

xii CCIE Collaboration Quick Reference

Chapter 5 Cisco Unified Communications Security 145

Security Policy 145

Threats to Cisco Collaboration Networks 146

Layer 1 Security 146


Port Security 147

DHCP Snooping 148

Root Guard and BPDU Guard 149

Dynamic ARP Inspection 149

802.1x 149


RFC 2827 Filtering 151

IP Source Guard 151

Unicast Reverse Path Forwarding 152

Routing Protocols Security 152

Router Hardening 152

(Firewall) Security for Layers 4 Through 7 152

Firewall Traversal Mechanisms 153

NAT Traversal 153

IPsec Tunnels 154

IP-Based ACLs 154

Port-Based ACLs 154

Cisco ASA Proxy Features 155

Cisco VPN Phone 156

Application Layer Security 157

CUCM Security By Default 158

CUCM Security Modes 158

CTL Client and CTL File 159

Cisco Unified IP Phone Certificates 161

SRTP and TLS 161

Preventing Toll Fraud 162

CUCM Class of Service 162

Cisco Voice Gateway Toll-Fraud Prevention Application 163

Voice Gateway Class of Restriction 164

Cisco Unity Connection Restriction Rules 165



14/315

xiii

Chapter 6 Cisco Unity Connection 167

Cisco Unity Connection High Availability 167

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 201Presence 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/315

xiv CCIE Collaboration Quick Reference

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 236Multicast 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 246Cisco 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/315

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 283CUCM 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/315

xvi CCIE Collaboration Quick Reference

Icons Used in This Book

PC PC withSoftware

SunWorkstation

Macintosh

Terminal FileServer

WebServer

CiscoworksWorkstation

Printer Laptop IBMMainframe

Front EndProcessor

ClusterController

Modem

DSU/CSU

Router Bridge Hub DSU/CSU CatalystSwitch

MultilayerSwitch

ATMSwitch

ISDN/Frame RelaySwitch

CommunicationServer

Gateway

AccessServer

Network Cloud

TokenRing

Token Ring

Line: Ethernet

FDDI

FDDI

Line: Serial Line: Switched SerialCisco ASA



18/315

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/315

This page intentionally left blank



20/315

Cisco CollaborationInfrastructure

Cisco Unified 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 efficiently by leveraging various unified 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 solutionand provides a single interface to all other UC features and functions. CUCM supportsvarious deployment models. Each of these models is based on certain requirements ofthe organization that deploys a Cisco UC network. The Cisco UC deployment models arebroadly classified as follows:

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

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

■

Distributed deployment model:

The call control is dispersed across multiple remotesites and multiple campus and/or centralized deployments that are interconnectedover a QoS-enabled WAN.

Chapter 1



21/315

2 Chapter 1: Cisco Collaboration Infrastructure

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 followingsubsections:

■ 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 CiscoHosted Unified Communications Services.

Single-Site Deployment Model

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

CC

V

V

Applications Media Resources Infrastructure

Internet

PSTN

CUCMCluster

Endpoints

V

Figure 1-1 Single-Site Deployment Model



22/315


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 tooffer resiliency, fast convergence, and inline power.

■ Deploy QoS from IP Phone (user access layer) to CUCM (data center access layer) togateways 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 InitiationProtocol (SIP) trunks to the IT service provider (ITSP) for off-net calls to the PSTNor 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 CUCMservers in a cluster reside at the same location. Optionally, applications and other mediaresources may be deployed at the same location as well. If the applications and mediaresources are at remote locations, it is beneficial to have a consolidated administrationof 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 sitesare deployed with Cisco Unified Survivable Remote Site Telephony (SRST) on Cisco IOSvoice gateways that allow endpoints and applications to function when the connectionto the campus site is unavailable or disrupted. As shown in Figure 1-2, this deploymentmodel is ideal for small to medium enterprises.

CC

V

V


CUCMCluster

Internet

Media and Conference Resources

IP WAN

PSTN

Endpoints

Endpoints

V V

Figure 1-2 Multisite WAN with Centralized Call Processing Deployment Model



23/315


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 havetheir 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

V


CUCM

Cluster

Internet


IP WAN

PSTN

Endpoints

Endpoints

CUCM

Cluster

V

VV

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



24/315


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 signaling normalization.

■ In addition to other specific best practices for this model, follow general guidelinesfor 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 provideredundancy, both within the region and overall. This model is particularly useful wheremultiple 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 theactive and backup servers are at the same physical site, or a remote failover deploymentmodel, where the active and backup servers are at different sites/data centers. Figure 1-4depicts the clustering over WAN call processing deployment model.

Media Resources

Internet Internet

IP WAN

CUCM

Cluster Over WAN

Infrastructure

EndpointsEndpoints


V

V

V

V

PSTN

PSTN

VV

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 morethan 80 ms.

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

■ Minimize jitter, congestion, and packet loss for ICCS.



25/315


Network Services

This section covers the various network services essential for a functional CiscoCollaboration 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 CiscoUnified IP Phones, Jabber clients, and so on. Although endpoints can be configuredwith a static IP address, DHCP is particularly helpful in assigning IP address and otherimportant parameters in bulk to IP Phones. Individual DHCP scopes must be createdfor each of the voice virtual LANs (VLAN), with sufficient addresses to support themaximum number of phones likely to be deployed in that VLAN. The DHCP service canbe 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 IPCommunications 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 includethe specification of DHCP option 150. This option should contain the IP address ofTFTP 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 canbe achieved by providing multiple differently ordered lists of TFTP server addresses tohosts.

The DHCP lease time controls the duration for which an IP Phone retains an IP addressfrom a DHCP scope. Cisco Unified IP Phones request a new IP address after half thelease time has expired since the last successful DHCP server acknowledgment. After therequest 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 therequesting 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 DHCPrequest 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/315

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 andload-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, Ciscorecommends 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/315


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 DNSclient is enabled on the cluster servers).

Trivial File Transfer Protocol TFTP is a crucial component of a Cisco Collaboration network as Cisco Unified IPPhones require a TFTP server to retrieve their firmware, configuration files, phone but-ton template, and other information. This only confirms that having TFTP redundancy isparamount in a critical UC setup. As discussed earlier, DHCP option 150 can be used toenable 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.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

■ Ring List files



28/315

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 goingthrough 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 iscapable 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 datapins 1, 2, 3, and 6).

Step 2. Every IP Phone has nonvolatile flash memory in which it stores firmwareimage(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 CiscoDiscovery Protocol (CDP) packet to the IP Phone. This CDP packet providesthe IP Phone with voice VLAN (also known as auxiliary VLAN) informationso that the IP Phone can reach the appropriate VLAN and initiate a DHCPrequest.

Step 4. The IP Phone sends a broadcast request such as a DHCP discover messageto 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 CiscoTFTP 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 torequest firmware and files. The TFTP server sends the configuration informa-tion for that IP Phone, which contains an ordered list of up to three CUCMservers or two CUCM servers and an SRST reference. If the IP Phone wasmanually preconfigured in CUCM, the SEP.cnf.xml file isdownloaded for that phone. Otherwise, the XMLDefault.cnf.xml configura-

tion file is used for IP Phones that request auto-registration.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 aTCP 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/315


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

■ Cisco TFTP Server: The default method of using one or more CUCM servers inthe 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 withhigh-speed WAN links because the Cisco Unified IP Phones at a remote site willdownload firmware during initial setup or firmware upgrade via centralized TFTPservers. In case of the multisite WAN with distributed call processing deploymentmodel or the clustering over WAN call processing deployment model, CUCM TFTPservers can be deployed at larger remote sites to serve local phones. Cisco CUCMalso supports proxy TFTP that enables phones to sync with a proxy TFTP serverthat forwards the requests to their respective clusters. This is especially useful in thecase of multiple phones tied to multiple clusters at remote sites. It saves the overheadof manually defining multiple option 150 for IP Phone subnets to the correct TFTPservers.

■ Load Server: A CUCM administrator can assign a TFTP server to each individualphone record using the Load Server parameter. Assigning the Load Server parameteris particularly useful for remote sites where downloading firmware to the phoneis difficult due to lower WAN speeds. In such cases, a CUCM administrator candeploy local TFTP servers (Windows- or IOS-based TFTP) to allow the phones tooperate 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 whicha particular load server is to be defined. Browse to Product Specific ConfigurationLayout , define the Load Server IP address/hostname, and enable the same.

■ Peer Firmware Sharing (PFS): PFS is a feature that allows phones participating inthis firmware distribution model to form a peering relationship in a tree-based hier-archy. One phone peers with two other phones. The administrator, however, doesnot need to designate parents (phones initiating PFS) and hosts (phones acceptingPFS). All the peer-enabled Cisco Unified IP Phones on a given IP subnet form a treestructure to distribute the firmware. After the peering relationship is established, the

root phone retrieves the firmware files from the Cisco TFTP server and distributesthem 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 ensurethat the phones are participating in a PFS distribution, go to the Cisco Unified CMAdministration page, choose Device > Phone , and select the phone that should beenabled for PFS. Browse to Product Specific Configuration Layout and ensure thatthe Peer Firmware Sharing option is enabled.



30/315

Network Services 11

Network Time Protocol

NTP enables network devices to synchronize their clocks to a network time serveror 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 criticalon CUCM servers. In addition to ensuring that call detail records (CDR) are accurate andthat 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 externalentity.

NTP should be configured across the network to allow for the synchronization of logfiles between multiple devices. Keeping the time accurate on all systems in the infrastruc-ture helps administrators to troubleshoot and correlate events in a Cisco Collaborationnetwork. 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 thepublisher. During installation, each subscriber is automatically configured to point to anNTP server running on the publisher. Cisco recommends using an NTP time source withNTP stratum 3 or better (the lower the better). An NTP time source can be added to theCUCM publisher by navigating to the Cisco Unified Operating System Administrationpage and choosing Settings > NTP Servers , as shown in Figure 1-6.

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



31/315


Cisco Discovery Protocol

CDP is a Cisco-proprietary Layer 2 protocol that was developed for discovering neighbordevices. It is a media- and protocol-independent device-discovery protocol that runs onCisco 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 receiveinformation about other devices on the network. There are two versions of CDP, Version1 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 withthe 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 variousCDP TLV fields.

Figure 1-6 NTP Server Configuration



32/315

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 (outgoingport)

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

Version Specifies the Cisco IOS or firmware version running on the deviceadvertising the updates

Platform Identifies the hardware or virtual platform

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

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/315


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 securityreasons, 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, butprimarily 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 voiceVLAN, provided the switch is capable of delivering Power over Ethernet. Also, if theendpoints are non-Cisco devices, LLDP-MED can be used on Cisco switches to supportthird-party phones.

LLDP information is sent by devices from each of their interfaces at a fixed interval of30 seconds with the holdtime of 120 seconds. This takes place in the form of an Ethernetframe, where each frame contains one LLDP Data Unit (LLDPDU). Each LLDPDU is asequence 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

Provides the MAC address and other physical characteristics



34/315

Power over Ethernet 15

Example 1-5 illustrates LLDP configuration on a Cisco switch at a global level and anindividual 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 Ciscoimplementation has the following features:

■ Uses a Cisco proprietary method to determine whether an attached device requirespower. 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.3afstandard, 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 thespare pins 4, 5, 7, and 8 (power sourcing equipment [PSE] can use one or the other,but not both).

■ Enables a new range of Ethernet-powered devices that consume additional power.



35/315


The process via which PoE-enabled switches detect and power a Cisco Unified IP Phonevaries 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 theFLP back to the switch, the switch starts supplying power over the Ethernet connectionto 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 eliminating theneed for wall power. If the switches are non-Cisco switches, LLDP-MED can be used todetect power and voice VLAN.

Voice and Data VLANs

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

A Cisco Catalyst/Nexus switch has multiple physical ports, all of which belong to VLAN1 by default (out of the box). A set of ports can be assigned to, say, VLAN 100 andanother 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 smallvirtual 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 deviceconnecting 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 theincoming 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 assigningthese packets to voice VLAN. The data packets, on the other hand, pass through the IPPhone to the switch as untagged packets, and the switch assigns these untagged packetsto 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■ To prevent data applications from directly interacting with voice traffic



36/315


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

Example 1-6Voice 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 thebackbone 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 InteriorGateway Routing Protocol (EIGRP), and Open Shortest Path First (OSPF) are commonlyemployed in unified IP environments. Routing protocol parameters such as timers,path/link costs, and route summaries can be used to optimize and control convergencetimes 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 tounderstand the design basics. One of the most important principles of campus network



37/315


design is to introduce and enable a hierarchy in the network infrastructure. This allowseach network layer to play a specific role, thus ensuring scalability, reliability, and bettermanagement.

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 switchingprovides 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 3switching to achieve robust, highly available campus networks.

Campus Access Layer

The campus access layer is where the user-facing devices connect to the LAN (wiringcloset switches) and leverage network services. Typically, at the user access layer, Layer 2is 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 isalso known as the network edge. A number of feature sets can be used at this layerto implement network policies around areas such as security, high availability, QoS, andso 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 policiesare created and enforced. This layer is responsible for aggregating incoming user trafficfrom wiring closet access switches and then aggregating it to the core. At the distributionlayer, it is important to provide redundancy to ensure high availability, including redun-dant links between the distribution layer switches and redundant links to access layerswitches. Various first-hop redundancy mechanisms are available, including Hot StandbyRouter Protocol (HSRP), Gateway Load Balancing Protocol (GLBP), and Virtual RouterRedundancy Protocol (VRRP).

Campus Core Layer

The campus core layer serves as the backbone of the entire network infrastructure of acampus, where all the traffic from the distribution layer aggregates. It is at this layer thatingress and egress of traffic in a network occurs. The core layer provides high-speedtransport and interconnectivity of various building blocks within the campus. The corelayer is usually made up of high-speed links that can aggregate all the traffic from pointsin 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/315


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

Campus Routed Access Layer Design

As previously mentioned, Cisco-recommended CDA architecture should be followedwhile 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 layerand Layer 3 at the distribution and core layers

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

Layer 3

Core

Distribution

Access

Layer 2

Layer 3

R o u t e d A c c e s s C am

p u sD e si gn

T r a d i t i o n a l C i s c o C a m p u s D e s i g n

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 traditionalapproach include a single control plane, dynamic traffic load balancing, and use of asingle set of tools for troubleshooting.



39/315


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

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

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

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

■ VLANs should not span multiple switches.

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

■ Spanning tree should be limited to access switches, and Layer 3 links should be usedbetween 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. Anexample of an IPv6 address is fe80:0:0:0:0:0:a0a:64c8, which is equivalent to IPv4 address10.10.100.200. The IPv6 address fe80:0:0:0:0:0:a0a:64c8 can be shortened by followingsome simple rules:

■ Two colons (::) can be used to compress successive hexadecimal fields of 0s at thebeginning, 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 tofe80::a0a:64c8.



40/315

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 messagesto a single network destination identified by a unique address.

■ Anycast: An IPv6 anycast address is an address that is assigned to a set of interfacesthat 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 streamto a subset of all hosts simultaneously.

IPv6 Addressing ModelFigure 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 asfollows:

■ Link-local address: An IPv6 unicast address that can be automatically or manuallyconfigured 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 localroutability scope. On automatic configuration, the address uses the link-local prefixFE80::/10 (1111 111010) and interface ID.

■ Unique-local address: IPv6 unicast address that uses the prefix FEC0::/10 (1111111011) and concatenates the subnet identifier (the 16-bit field) with the interfaceidentifier. Unique-local addresses are analogous to RFC 1918 private addresses inIPv4 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/315


■ 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 toallow 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 aglobal address, and an IPv4 address.

Cisco Unified IP Phones can support one link-local address, multiple unique-localaddresses, multiple global addresses, and an IPv4 address. If the phone has both unique-local and global addresses, the global addresses take precedence over unique-localaddresses. If multiple unique-local addresses or multiple global addresses exist, the firstaddress 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 andmedia.

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

1. If configured, use the address that has been manually configured via the IPPhone’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. Therouter RA “O” bit should be set.

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

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

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

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



42/315


Step 3. Configure Common Device Configuration for IP Phone Profile and SIPTrunks to enable IPv4 and IPv6 addressing mode, Signaling Preference, andPhone 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 mostapplications and infrastructure components may be configured for or support IPv4.

■ Dual-stack deployments offer the best approach when introducing IPv6 into anynetwork 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 providesvirtualization 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, rangingfrom desktop to data center. Some of the virtual solutions for Cisco Collaboration arelisted 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 indata centers.

Cisco VirtualizationExperience Infrastructure(VXI)

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

Cisco VirtualizationExperience Media Engine(VXME)

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

Cisco VirtualizationExperience Client (VXC)

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



43/315


Virtual Solution Description

Cisco VXC Manager Used for managing and deploying VXC thin client. This is a sub-component of the Cisco VXI solution.

Cisco Virtual DesktopInfrastructure (VDI)

Solution to deliver virtualized desktops and applications bymeans of simplicity, scalability, and superior user experience.Cisco VDI solutions are built on Cisco Unified Data Centerarchitectures. The Cisco VDI solution is available as a Citrix orVMware workload.

Cisco UCS Servers

Cisco UCS servers are an x86-based architecture data center server platform encompass-

ing computing, virtualization, switching fabric, and management software.

The computing component of Cisco UCS is available in two versions:

■ B-Series: Modular packages consisting of a chassis and half-width or full-widthblades. B-Series servers require a storage area network (SAN) for application datastorage.

■ C-Series: Rack-mount servers with built-in direct-attached storage (DAS).Compute hardware is managed by the UCS Manager software running on FabricInterconnects (FI).

UCS Manager can be used to manage both B-Series and C-Series servers. Integrationbetween VMware vCenter and Cisco UCS Manager provides unparalleled control overphysical and virtual assets.

For virtualization, Cisco UCS supports hypervisors, including VMware ESXi and CitrixXenServer. Cisco UCS interacts with Fabric Extenders or Fabric Interconnects to commu-nicate with other data center infrastructure, including SAN switches, storage, and CiscoNexus. Cisco UCS supports Fibre Channel over Ethernet (FCoE). Figure 1-9 depicts aCisco UCS–based virtualized UC application and network architecture.

Cisco UCS leverages the concept of service profiles for statelessness. This allows for anydamaged hardware (blade) to be changed without affecting the virtual machines (VM)running on it. The VMs can be moved to another blade by disassociating the service pro-file from a nonfunctional blade to a functional one.

Cisco UC application configuration templates are available in Open VirtualizationArchive (OVA) format, which allows administrators to build and configure UC applica-tions. For most supported UC applications, preconfigured OVA templates are availableon Cisco.com. If an OVA template is not available for an application, the administratormust manually build OVA files that meet the indicated requirements. Cisco has stringent

requirements for co-residency of UC applications with non-Cisco or non-UC applications.The Cisco-recommended guidelines for co-residency can be found at http://docwiki.cisco.com/wiki/Unified_Communications_Virtualization_Sizing_Guidelines.


http://docwiki.cisco.com/wiki/Unified_Communications_Virtualization_Sizing_Guidelineshttp://docwiki.cisco.com/wiki/Unified_Communications_Virtualization_Sizing_Guidelineshttp://docwiki.cisco.com/wiki/Unified_Communications_Virtualization_Sizing_Guidelineshttp://docwiki.cisco.com/wiki/Unified_Communications_Virtualization_Sizing_Guidelines


44/315


Moreover, Cisco supports UC on UCS deployments in three support models:

■ UC on UCS Tested Reference Configuration (TRC): Tested and approved by Cisco

UC and UCS BUs/teams■ UC on UCS Specs-based: Generic server hardware validation by UCS BU/team

■ Third-party Server Specs-based: No hardware validation by UCS BU/team

While virtual machine (OVA) definitions, VMware product, version, and feature support,VMware configuration requirements for UC, and application/VM co-residency policyremain consistent across all three support models, there are a few things to consider whengoing with one model or another. For example, a TRC model is configuration based,whereas UCS Specs-based and Third-party Server Specs-based models are rules based.

For details and updated information, refer to http://docwiki.cisco.com/wiki/UC_Virtualization_Supported_Hardware.

UC Applications(Guest Virtual Machines)

VMwareHypervisor

B-Series Blade

6200 Series FabricInterconnect

Fibre Channel overEthernet (FCoE)

Ethernet

LAN Switch Nexus 5000Series Switch

SAN Switch(MDS 9000 Series)

Fibre Channel

Storage Array

V

Cisco UCS 5100 SeriesChassis

Figure 1-9 Cisco UCS–based UC Application and Network Virtualization Architecture


http://docwiki.cisco.com/wiki/UC_Virtualization_Supported_Hardwarehttp://docwiki.cisco.com/wiki/UC_Virtualization_Supported_Hardwarehttp://docwiki.cisco.com/wiki/UC_Virtualization_Supported_Hardwarehttp://docwiki.cisco.com/wiki/UC_Virtualization_Supported_Hardware


45/315


VMware ESXi for Cisco Collaboration Virtualization

Cisco UCS requires a hypervisor to support a guest OS and virtual machines. VMwarevSphere (ESXi) is the hypervisor that sits between the hardware abstraction layer and the

guest OS. VMware ESXi runs directly on the UCS B-Series or C-Series server hardwarewithout the need for any additional software in bare-metal mode. It provides the neces-sary hypervisor functions to host several guest OSs, such as Windows and Linux, on thephysical server.

UC Application Install Answer File

While installing UC applications on a physical or virtual platform, answer files can bevery helpful because they save time and prevent typological or omission errors. UCapplications can be installed on UCS using the platformConfig.xml file where the virtualmachine requires the use of a virtual floppy drive.

To install a Cisco Unified Communications application such as CUCM, Cisco UnityConnection, Cisco Presence, and so on, using the answer files generated by Cisco UnifiedCommunications Answer File Generator ( http://www.cisco.com/web/cuc_afg/index.html)is recommended. This web application also generates the virtual License MAC addressthat is used for obtaining the license.

The answer file generator has the following areas to complete in the ClusterwideConfiguration section:

■ Hardware: Physical Server or Virtual Machine

■ Product: CUCM, Cisco Unity Connection, Cisco Unified Presence, and so on

■ Administrator Credentials: OS Administrator username and password

■ Security Password: Cluster security password

■ Application User Credentials: Administrator GUI username and password

■ Certificate Information: Organization, Unit, Location, State, and Country

■ SMTP: SMTP Location

The answer file generator also has the following areas to complete in the Primary NodeConfiguration and Secondary Node Configuration sections:

■ NIC Interface Settings: Use Auto Negotiation, NIC Speed, NIC Duplex, MTU Size

■ Network Information: Use DHCP for IP Address Resolution, Host Name, IPAddress, IP Mask, Gateway Address

■ DNS: Configure Client DNS, Primary DNS, Secondary DNS, Domain

■ Time Zone: Region, Time Zone

■ Network Time Protocol: NTP Server(s) information (only for primary node)


http://www.cisco.com/web/cuc_afg/index.htmlhttp://www.cisco.com/web/cuc_afg/index.htmlhttp://www.cisco.com/web/cuc_afg/index.html


46/315

IP Multicast 27

After the platformConfig.xml file is generated, you can use it to install primary and sec-ondary nodes in a UC application cluster by following these steps:

Step 1. Create a virtual floppy image using a virtual floppy program (for example,

WinImage or RawWrite).

Step 2. Insert the platformConfig.xml file into the virtual floppy image and save theresulting image with a .vmd or .flp extension.

Step 3. Upload the virtual floppy image to a datastore accessible from VSphere. ForSAN storage, go to View > Inventory > Datastores . For local storage (such asan internal hard drive), select the host and click the Summary tab. Browse thedatastore and upload the virtual floppy image to it.

Step 4. From the VSphere client, go to Inventory > Virtual Machine > Edit Settings .

In the dialog box that opens, select Floppy Drive on the Hardware tab. Clickthe Use Existing Floppy Image in Datastore radio button, click Browse ,browse to and choose the virtual floppy image, and click OK .

Step 5. In the Device Status area of the Hardware tab, check the Connected andConnect at Power On check boxes. Click OK in the lower-right corner.

Step 6. Proceed with installation of the UC application using the ISO file from thedatastore.

Step 7. In the Platform Installation Wizard window, choose Skip to configure theplatform later using the auto-answer file from the mounted virtual floppyimage.

Step 8. After the system restarts, the Preexisting Installation Configuration windowdisplays and the install process automatically reads the configuration informa-tion file copied onto the virtual floppy image mounted on the UCS.

IP Multicast

IP multicast can be used for various functions in a Cisco Collaboration network. Themost common services that leverage IPv4 or IPv6 multicast are

■ Multicast Music on Hold (MoH) for branch sites. (Cisco Unified IP Phones supportonly IPv4 multicast MoH. IPv6 multicast MoH is not supported.)

■ AutoDiscovery of Gatekeeper (GRQ) messages.

■ DHCPv6 discovery by IPv6-compatible endpoints.

■ Cisco SAF forwarder automatic discovery and communication with other SAFforwarders.

To allow the use of multicast for all the preceding services, the underlying network infra-structure must support the forwarding of multicast IP traffic from the CUCM servers or



47/315


endpoints or gateways to respective VLANs across the campus and extended network(inter-domain).

Protocols commonly used to enable multicast in a campus environment include the

following:

■ Internet Group Management Protocol (IGMP)

■ Protocol Independent Multicast Sparse Mode (PIM-SM)

■ Protocol Independent Multicast Dense Mode (PIM-DM)

■ Cisco Group Management Protocol (CGMP)

Protocols commonly used to enable multicast in an interdomain environment include thefollowing:

■ Multicast Source Discovery Protocol (MSDP)

■ PIM Source-Specific Multicast (PIM-SSM)

IPv6 multicast is based on the same basic principles as IPv4 multicast. The major differ-ences being that IPv6 relies on multicast for more functions, such as neighbor discoveryand node autoconfiguration. Moreover, Mobile IPv6 relies heavily on IPv6 multicast fortheir operations. IGMP is replaced by Multicast Listener Discovery (MLD) in IPv6.

Wireless in Cisco Collaboration Solutions Today’s dynamic environments and organizations demand more than just regular wiredIP Phones—they demand mobility. Wi-Fi is an important aspect because being mobileyet connected within an enterprise is paramount in today’s connected world. Cisco offerson-campus mobility using Voice over Wireless LAN (VoWLAN) with Cisco UnifiedWireless IP Phone 7925G. From an infrastructure perspective, Cisco offers two wirelessnetwork infrastructure solutions: Cisco Unified Wireless LAN Controller (WLC) andCisco Autonomous Access Points (AP). A VoWLAN architecture encompasses multiplecomponents, as shown in Figure 1-10.

Cisco VoWLAN solution has many components, including the following:

■ Cisco WLC

■ Lightweight access points

■ Directory server (LDAP) for endpoint authentication

■ Wi-Fi endpoints, including PCs or laptops with Jabber

■ Wi-Fi–capable Cisco Unified IP Phones

The interaction between endpoints and wireless APs is where Wi-Fi primarily comes intoplay; the rest is an augmentation to existing wired infrastructure.



48/315

Wireless in Cisco Collaboration Solutions 29

For a successful VoWLAN solution deployment, certain conditions must be met. Theyare as follows:

■ Noise levels should not exceed —92 dBm with a signal-to-noise ratio (SNR) of25 dB.

■ Signal strength should be −67 dBm.

■ Minimum 20 to 30 percent overlap of adjacent access points with nonoverlappingchannels must be considered during site survey.

■ Packet error rate (PER) should not exceed 1 percent and Jitter should be less than100 ms.

■ To avoid one-way audio issues resulting from different power settings between Wi-FiIP phones and access points, World mode (IEEE 802.11d) should be configured.

■ Traffic Specification (TSPEC) must be enabled for CAC on APs.

■ QoS for voice VLAN must be enabled on Cisco WLC and APs such that the mark-ings match those on wired infrastructure. IEEE 802.11e UP markings should bematched to Voice, Video, and Signaling DSCP markings (Voice EF = 6, Video AF41= 5, and Signaling AF31 = 4).

■ Channel utilization levels should be kept below 50 percent.

■ Cisco Compatible Extensions (CCX) should be enabled on wireless infrastructure

where possible

CCIE COLLABORATION QUICK REFERENCE cisco press.pdf

Documents

Transcript of CCIE COLLABORATION QUICK REFERENCE cisco press.pdf