Sie sind auf Seite 1von 315

From the Library of Juan Arcaya

CCIE Collaboration Quick Reference

Cisco Press

800 East 96th Street Indianapolis, IN 46240

Akhil Behl, CCIE No. 19564

From the Library of Juan Arcaya

ii

CCIE Collaboration Quick Reference

CCIE Collaboration Quick Reference

Akhil Behl, CCIE No. 19564 (Voice and Security)

Copyright© 2014 Pearson Education, Inc.

Published by:

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.

From the Library of Juan Arcaya

iii

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 corpsales@pearsoned.com or (800) 382-3419.

For government sales inquiries, please contact governmentsales@pearsoned.com.

For questions about sales outside the U.S., please contact international@pearsoned.com.

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 feedback@ciscopress.com. Please make sure to include the book title and ISBN in your message.

We greatly appreciate your assistance.

Publisher: Paul Boger

Editor-in-Chief: David Dusthimer

Business Operation Manager, Cisco Press: Jan Cornelssen

Executive Editor: Brett Bartow

Managing Editor: Sandra Schroeder

Development Editor: Marianne Bartow

Senior Project Editor: Tonya Simpson

Copy Editor: Bill McManus

Technical Editor: Paulo Lopes

Editorial Assistant: Vanessa Evans

Designer: Mark Shirar

Composition: Jake McFarland

Editorial Assistant: Vanessa Evans Designer: Mark Shirar Composition: Jake McFarland From the Library of Juan Arcaya

From the Library of Juan Arcaya

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.

From the Library of Juan Arcaya

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.

From the Library of Juan Arcaya

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.

From the Library of Juan Arcaya

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

From the Library of Juan Arcaya

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

QoS Deployment Architectures

34

Classification and Marking

33

32

From the Library of Juan Arcaya

ix

Chapter 3

Layer 2 Marking

34

Layer 3 Marking

35

Network-Based Application Recognition

Classification Service Classes

37

36

Classification and Marking for Softclients

Classification and Marking for Video Traffic Queuing 38

37

38

Cisco Queuing Toolset

Weighted Random Early Detection

39

WAN QoS Considerations

41

Traffic Policing and Shaping

41

40

Link Efficiency Mechanisms

43

Compressed RTP

Link Fragmentation and Interleaving

Multilink PPP

Frame Relay Forum 12

Voice Activity Detection

43

44

44

45

43

LAN QoS Considerations QoS Trust Boundary

QoS Considerations for WLAN Endpoints

QoS Considerations for Virtual Unified Communications with Cisco UCS

Medianet 49 Medianet QoS Classes of Service

46

46

47

52

Telephony Standards and Protocols

Voice and Video Codecs

VoIP Media Transmission Protocols

VoIP Signaling Protocols

55

58

57

Skinny Client Control Protocol Media Gateway Control Protocol

Session Initiation Protocol

65

58

61

55

SIP Session Description Protocol SIP Binary Floor Control Protocol

H.323 Gateway, Gatekeeper, and RAS

71

72

H.323 Gateway

H.323 Gatekeeper

H.225 and RAS Signaling

75

76

77

73

48

From the Library of Juan Arcaya

x

CCIE Collaboration Quick Reference

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

Analog Telephony

83

Foreign Exchange Office

83

FXO Disconnect

83

Foreign Exchange Station E&M 84

84

Digital Telephony

85

Integrated Services Digital Network

Q Signaling Protocol

Channel Associated Signaling

87

87

T1 CAS

87

E1 R2

88

85

Non-Facility Associated Signaling

88

Analog and Digital Telephony Call Signaling Elements

Direct Inward Dial

89

Caller ID

89

Echo 90 Trans Hybrid Loss

90

Fax and Modem Protocols

91

Fax Services over IP Network

Modem Services over IP Network

91

93

89

82

Chapter 4

Cisco Unified Communications Manager

95

CUCM Redundancy and Device Registration

95

CUCM Device Pool

96

Common Device Configuration

Codec Selection

99

CUCM Features

100

Call Park and Directed Call Park Call Pickup and Group Pickup

Meet-Me Conference

102

98

100

101

Busy Lamp Field Speed Dials

102

CUCM Native Call Queuing

102

Call Hunting

103

CUCM Media Resources Annunciator 104 Conference Bridge

104

104

From the Library of Juan Arcaya

xi

Media Termination Point Transcoder 105

Music on Hold

Media Resource Group and Media Resource Group List

Trusted Relay Point

105

105

107

CUCM Dial Plan

107

Partitions and Calling Search Spaces

Translation Patterns

Route Patterns

Route List

Route Group

Globalized Call Routing

109

109

110

109

110

108

Local Route Group Time-of-Day Routing

Local Route Group Time-of-Day Routing

Application Dial Rules Directory Dial Rules

Application Dial Rules Directory Dial Rules

111

112

112

113

SIP Dial Rules

113

CUCM Digit Manipulation

CUCM H.323 and SIP Trunks

SIP Uniform Resource Identifier Dialing

Intercluster Lookup Service

Blended Addressing

CUCM Call Admission Control

114

116

119

122

122

117

Locations-Based CAC

Enhanced LCAC

Resource Reservation Protocol

RSVP SIP Preconditions

123

124

128

126

CUCM-Based Call Recording and Silent Monitoring

CUCM Mobility

133

129

Extension Mobility and Extension Mobility Cross Cluster

Device Mobility

135

Mobile Connect

136

106

133

Mobile Voice Access

138

Service Advertisement Framework and Call Control Discovery

SAF Architecture

Call Control Discovery Service

140

142

140

From the Library of Juan Arcaya

xii

CCIE Collaboration Quick Reference

Chapter 5

Cisco Unified Communications Security

Security Policy

Threats to Cisco Collaboration Networks

145

145

146

Layer 1 Security

146

Layer 2 Security

147

Port Security

DHCP Snooping

Root Guard and BPDU Guard

Dynamic ARP Inspection 802.1x 149

Layer 3 Security

RFC 2827 Filtering

IP Source Guard

Unicast Reverse Path Forwarding

Routing Protocols Security

Router Hardening

(Firewall) Security for Layers 4 Through 7

147

148

149

149

151

151

151

152

152

152

Firewall Traversal Mechanisms

153

NAT Traversal

153

IPsec Tunnels

154

IP-Based ACLs

154

Port-Based ACLs

154

152

Cisco ASA Proxy Features

Cisco VPN Phone

Application Layer Security CUCM Security By Default

CUCM Security Modes

CTL Client and CTL File

155

157

158

159

156

158

Cisco Unified IP Phone Certificates

161

SRTP and TLS

Preventing Toll Fraud

161

162

CUCM Class of Service

Cisco Voice Gateway Toll-Fraud Prevention Application

Voice Gateway Class of Restriction

Cisco Unity Connection Restriction Rules

162

164

165

163

From the Library of Juan Arcaya

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

Cisco Unified CM IM and Presence Cluster

Cisco Unified CM IM and Presence Server Integration with CUCM

Cisco Jabber

192

193

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)

Server-Side IM Logging (Compliance)

205

206

191

From the Library of Juan Arcaya

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

 

211

 

UCCX ACD Functions UCCX CTI Functions

213

213

 

UCCX IVR Functions

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

Basic Cisco Unified CME Setup

Cisco Unified CME–Based SCCP Phone Registration

Cisco Unified CME–Based SIP Phone Registration

Cisco Unified CME Single Number Reach

225

226

227

229

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

Cisco IOS Conferencing Resources Cisco IOS Transcoding Resources

244

245

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

Voice Hunt Groups

Call Blast

252

253

249

Cisco Unity Express

254

From the Library of Juan Arcaya

xv

Chapter 10

Cisco Unified CME and CUE Integration

CUE Message Waiting Indicator Outcalling 256

256

(SIP) Subscribe Notify

Unsolicited Notify

257

257

CUE Web Inbox

CUE VoiceView Express

CUE Auto-Attendant

CUE Scripting

CUE Voice Profile for Internet Email

258

258

259

261

263

254

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

272

Cisco Unified Border Element

CUBE Redundancy

273

CUBE SIP Profiles

277

CUBE Early Offer and Delayed Offer

CUBE DTMF Interworking CUBE Mid-Call Signaling

279

281

278

Cisco Collaboration Network Management

CUCM Serviceability and OS Administration

CUCM Database Replication

CUCM Service Activation

283

284

283

283

CUCM Call Detail Records and Call Management Records

CUCM Disaster Recovery

289

User Management

290

Cisco EnergyWise

292

288

270

From the Library of Juan Arcaya

xvi

CCIE Collaboration Quick Reference

Icons Used in This Book

CCIE Collaboration Quick Reference Icons Used in This Book Communication PC PC with Sun Macintosh Access

Communication

PC

PC with

Sun

Macintosh

Access

ISDN/Frame Relay

Server

Software

Workstation

Server

Switch

Token Ring
Token
Ring

Token Ring

Terminal

File

Web

Ciscoworks

ATM

Server

Server

Workstation

Switch

Modem

ATM Server Server Workstation Switch Modem Printer Laptop IBM Front End Cluster

Printer

Laptop

IBM

Front End

Cluster

Multilayer

 

Mainframe

Processor

Controller

Switch

Gateway Router Bridge Network Cloud Line: Ethernet
Gateway
Router
Bridge
Network Cloud
Line: Ethernet
FDDI DSU/CSU Hub DSU/CSU FDDI Line: Serial Line: Switched Serial
FDDI
DSU/CSU
Hub
DSU/CSU
FDDI
Line: Serial
Line: Switched Serial
DSU/CSU Hub DSU/CSU FDDI Line: Serial Line: Switched Serial Catalyst Switch Cisco ASA From the Library

Catalyst

Switch

DSU/CSU Hub DSU/CSU FDDI Line: Serial Line: Switched Serial Catalyst Switch Cisco ASA From the Library

Cisco ASA

From the Library of Juan Arcaya

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.

From the Library of Juan Arcaya

This page intentionally left blank

From the Library of Juan Arcaya

Chapter 1

Cisco Collaboration Infrastructure

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

From the Library of Juan Arcaya

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 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).

Applications Media Resources Infrastructure V Internet CUCM Cluster CC PSTN V V Endpoints
Applications
Media Resources
Infrastructure
V
Internet
CUCM
Cluster
CC
PSTN
V
V
Endpoints

Figure 1-1

Single-Site Deployment Model

From the Library of Juan Arcaya

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.

Media and Conference Resources Applications Media Resources Infrastructure Internet CUCM Cluster IP WAN V V
Media and Conference Resources
Applications
Media Resources
Infrastructure
Internet
CUCM
Cluster
IP WAN
V
V
CC
PSTN
V
Endpoints
V
Endpoints

Figure 1-2

Multisite WAN with Centralized Call Processing Deployment Model

From the Library of Juan Arcaya

4

Chapter 1: Cisco Collaboration Infrastructure

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.

Media and Conference Resources Applications Media Resources Infrastructure Internet CUCM CUCM Cluster Cluster IP
Media and Conference Resources
Applications
Media Resources
Infrastructure
Internet
CUCM
CUCM
Cluster
Cluster
IP WAN
V
V
CC
PSTN
V
V
Endpoints
V
Endpoints

Figure 1-3

Multisite WAN with Distributed Call Processing Deployment Model

From the Library of Juan Arcaya

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 signaling 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 and Conference Resources Media Resources Infrastructure Internet Internet IP WAN V V CUCM Cluster
Media and Conference Resources
Media Resources
Infrastructure
Internet
Internet
IP WAN
V
V
CUCM
Cluster Over WAN
PSTN
V
PSTN
V
V
V
Endpoints
Endpoints

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.

Minimize jitter, congestion, and packet loss for ICCS.

From the Library of Juan Arcaya

6

Chapter 1: Cisco Collaboration Infrastructure

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

From the Library of Juan Arcaya

Network Services

7

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

Example 1-1

Cisco IOS Router–b ased 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.

From the Library of Juan Arcaya

8

Chapter 1: Cisco Collaboration Infrastructure

8 Chapter 1: Cisco Collaboration Infrastructure Figure 1-5 CUCM Server Hostname to IP Address Substitution This

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 config uration 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

Ring List files

From the Library of Juan Arcaya

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-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 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).

From the Library of Juan Arcaya

10

Chapter 1: Cisco Collaboration Infrastructure

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 bas is, 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 P hone 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.

From the Library of Juan Arcaya

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.

From the Library of Juan Arcaya

12

Chapter 1: Cisco Collaboration Infrastructure

12 Chapter 1: Cisco Collaboration Infrastructure Figure 1-6 NTP Server Configuration Cisco Discovery Protocol CDP is

Figure 1-6

NTP Server Configuration

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 (TL V) fiel ds. Table 1-1 illustrates various CDP TL V fiel ds.

From the Library of Juan Arcaya

Network Services

13

Table 1-1

CDP TL V 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)

Mana gement Address

Identifies the mana gement address of the advertis ing 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

From the Library of Juan Arcaya

14

Chapter 1: Cisco Collaboration Infrastructure

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 TL V fields that are advertised by LLDP .

Table 1-2

LLDP TL V 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)

Mana gement Address

Provides the mana gement IP address (if any)

Port VLAN ID

Identifies the native VLAN ID of the advertising port

MAC/PHY

Provides the MAC address and other physical characteristics

Configuration/Status

From the Library of Juan Arcaya

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).

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

From the Library of Juan Arcaya

16

Chapter 1: Cisco Collaboration Infrastructure

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 eliminating 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 tra ffic

To provide QoS marking and classification for real-time voice tra ffic v is-à-vis data traffic

To prevent data applications from directly interacting with voice tra ffic

From the Library of Juan Arcaya

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

V oice and Data VLAN Conf iguration

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

From the Library of Juan Arcaya

18

Chapter 1: Cisco Collaboration Infrastructure

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 mana geme nt.

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

From the Library of Juan Arcaya

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 A ccess Lay er 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

Core Routed Access Campus Design Layer 3 Layer 3 Distribution Layer 2 Access Layer 2
Core
Routed Access Campus Design
Layer 3
Layer 3
Distribution
Layer 2
Access
Layer 2
Traditional Cisco Campus Design

Figure 1-7

Traditional Cisco Campus Design V ersus 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.

From the Library of Juan Arcaya

20

Chapter 1: Cisco Collaboration Infrastructure

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.

From the Library of Juan Arcaya

IPv6 in Cisco Collaboration Networks

21

IPv6 Address Types

IPv6 supports the following address types:

Unicast: Synonymous to IP v4, 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 address ing model. Link-local Unique-local Global
Figure 1-8 depicts the IPv6 address ing 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.

From the Library of Juan Arcaya

22

Chapter 1: Cisco Collaboration Infrastructure

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-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 multiple 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.

From the Library of Juan Arcaya

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.

From the Library of Juan Arcaya

24

Chapter 1: Cisco Collaboration Infrastructure

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 Desktop Infrastructure (VDI)

Solution to deliver virtualized desktops and applications by means of simplicity, scalability, and superior user experience. Cisco VDI solutions are built on Cisco Unified Data Center architectures. The Cisco VDI solution is available as a Citrix or VMware 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-width blades. B-Series servers require a storage area network (SAN) for application data storage.

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

UCS Manager can be used to manage both B-Series and C-Series servers. Integration between VMware vCenter and Cisco UCS Manager provides unparalleled control over physical and virtual assets.

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

Cisco UCS leverages the concept of service profiles for statelessness. This allows for any damaged 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 Virtualization Archive (OVA) format, which allows administrators to build and configure UC applica- tions. For most supported UC applications, preconfigured OVA templates are available on Cisco.com. If an OVA template is not available for an application, the administrator must 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 .

From the Library of Juan Arcaya

Virtualization in Cisco Collaboration Solutions

25

UC Applications (Guest Virtual Machines) VMware Hypervisor B-Series Blade Cisco UCS 5100 Series Chassis 6200
UC Applications
(Guest Virtual Machines)
VMware
Hypervisor
B-Series Blade
Cisco UCS 5100 Series
Chassis
6200 Series Fabric
Interconnect
V
Fibre Channel over
Ethernet (FCoE)
Ethernet
Fibre Channel
LAN Switch
Nexus 5000
SAN Switch
(MDS 9000 Series)
Storage Array
Series Switch

Figure 1-9

Cisco UCS–based UC Appl ication and N etwork Virtualization Architecture

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 har dware 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 policy remain consistent across all three support models, there are a few things to consider when going 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.

From the Library of Juan Arcaya

26

Chapter 1: Cisco Collaboration Infrastructure

VMware ESXi for Cisco Collaboration Virtualization

Cisco UCS requires a hypervisor to support a guest OS and virtual machines. VMware vSphere (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 hardware without 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 the physical server.

UC Application Install Answer File

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

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

The answer file generator has the following areas to complete in the Clusterwide Configuration 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 Node Configuration 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, IP Address, 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)

From the Library of Juan Arcaya

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 the resulting image with a .vmd or .flp extension.

Step 3.

Upload the virtual floppy image to a datastore accessible from VSphere. For SAN storage, go to View > Inventory > Datastores. For local storage (such as an internal hard drive), select the host and click the Summary tab. Browse the datastore 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. Click the 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 and Connect 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 the datastore.

Step 7.

In the Platform Installation Wizard window, choose Skip to configure the platform later using the auto-answer file from the mounted virtual floppy image.

Step 8.

After the system restarts, the Preexisting Installation Configuration window displays 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. The most common services that leverage IPv4 or IPv6 multicast are

Multicast Music on Hold (MoH) for branch sites. (Cisco Unified IP Phones support only 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 SAF forwarders.

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

From the Library of Juan Arcaya

28

Chapter 1: Cisco Collaboration Infrastructure

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 Mana gement Protocol (I GMP)

Protocol Independent Multicast Sparse Mode (PIM-SM)

Protocol Independent Multicast Dense Mode (PIM-DM)

Cisco Group Mana gement Protocol ( CGMP)

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

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 discovery and node autoconfiguration. Moreover, Mobile IPv6 relies heavily on IPv6 multicast for their 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 wired IP Phones—they demand mobility. Wi-Fi is an important aspect because being mobile yet connected within an enterprise is paramount in today’s connected world. Cisco offers on-campus mobility using Voice over Wireless LAN (VoWLAN) with Cisco Unified Wireless IP Phone 7925G. From an infrastructure perspective, Cisco offers two wireless network infrastructure solutions: Cisco Unified Wireless LAN Controller (WLC) and Cisco Autonomous Access Points (AP). A VoWLAN architecture encompasses multiple components, 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 into play; the rest is an augmentation to existing wired infrastructure.

From the Library of Juan Arcaya

Wireless in Cisco Collaboration Solutions

29

Cisco WLC CUCM Lightweight AP Switch Switch LDAP Cisco Unified IP Phone (Wireless) Laptop with
Cisco WLC
CUCM
Lightweight AP
Switch
Switch
LDAP
Cisco Unified IP
Phone (Wireless)
Laptop with
Softphone (Jabber)
Cisco Unified IP
Phone (Wired)

Figure 1-10

Cisco V oWLAN Architecture

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

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

Signal strength should be −67 dBm.

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

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

To avoid one-way audio issues resulting from different power settings between Wi-Fi IP 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 be matched 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 to save battery life on the IP phone to increase the Delivery Traffic Indication Message (DTIM) period.

From the Library of Juan Arcaya

This page intentionally left blank

From the Library of Juan Arcaya

Chapter 2

Quality of Service (QoS)

Voice and video over IP traffic consists of two parts: media/bearer traffic and signaling traffic. Media traffic is based on the Real-time Transport Protocol (RTP), which runs on top of the User Datagram Protocol (UDP). Signaling traffic is based on a number of protocols, such as Session Initiation Protocol (SIP), Skinny Call Control Protocol (SCCP), H.323 protocol, and Media Gateway Control Protocol (MGCP), all of which are TCP/UDP based. When an RTP packet is lost, re-creating or retransmitting it is neither possible nor worthwhile. As its name indicates, RTP works in real time, so any attempt to restore missing packets would not make sense because the packets would arrive out of order/sequence during a live conversation.

In today’s converged networks where voice, video, and data coexist, it is important to treat voice and video traffic differently from data traffic, which is mostly TCP based and is easily retransmitted without loss of quality. Quality of service (QoS) enables network administrators to leverage tools for providing special treatment for delay and time- sensitive traffic such as voice. The network infrastructure must provide classification, policing, and scheduling services for multiple traffic classes.

Voice quality is directly affected by the following three QoS factors:

Latency (delay): The unwarranted time required for a packet to traverse the network from source to destination

Jitter (delay variation): Irregular time interval in the arrival of packets

Packet loss: Packets lost in transit from source to destination due to network con- gestion, link flapping, or other reasons

Many sources of delay are introduced both during a packet formation and during transit from source to destination, as outlined in Table 2-1. Moreover, the delay can be either a fixed delay or a variable delay depending on where it is introduced. Fixed delay adds to overall delay introduced from source to destination. Variable delay is a function of queues and buffers.

From the Library of Juan Arcaya

32

Chapter 2: Quality of Service (QoS)

Table 2-1

Sources of Delay During Voice Packet Formation and Traversal from Source

to Destination

Delay

Description

Coder delay

The time taken by a digital signal processor (DSP) to compress a block of pulse-code modulated (PCM) samples. This is a fixed delay function for a certain endpoint with a certain codec.

Packetization delay

The time it takes to put a payload (encoded voice) into a voice packet and encapsulate it within IP, UDP, and RTP headers. It’s a fixed delay function.

Queuing delay

The delay exper ienced as a frame is queued waiting to be transmit- ted on a link. It’s a variable delay function because it depends on link speed.

Serialization delay

The time taken to put a frame on the wire from a network interface. It’s a fixed delay function.

Propagation delay

The time taken for a bit to traverse a network link (from one end to the other).

De-jitter delay

The delay exper ienced as a res ult of a de-jitter buffer on a receiving device (such as a Cisco IOS router) that eliminates any jitter between packets before they are sent out to their destination. It’s a fixed delay function.

QoS Requirements for Voice and Video

The key QoS requirements and recommendations for RTP traffic are

Voice bearer tra ffic should be marked to DSCP EF per the QoS baseline and RFC 3246.

Packet loss should be no more than 1 percent.

One-way latency (mouth to ear) should be no more than 150 ms.

Average one-way jitter should be targeted under 30 ms.

Additionally, for voice calls, the following are recommended leading practices:

17 to 106 kbps of guaranteed priority bandwidth should be provided per call for media (depending on the sampling rate, codec, and Layer 2 overhead).

150 bps + Layer 2 overhead guaranteed bandwidth should be provided for voice- control traffic per call.

Additional requirements for video traffic are as follows:

From the Library of Juan Arcaya

QoS Deployment Architectures

33

The minimum priority bandwidth guarantee required is size of Video-stream + 10 to 20 percent.

Call Admission Control (CAC) must be enabled.

QoS Deployment Architectures

QoS can be implemented via Integrated Services (IntServ) or Differentiated Services (DiffServ) architecture. IntServ architecture provides QoS by assuring treatment for a specific traffic flow. Resource Reservation Protocol (RSVP) is an example of an IntServ mechanism where each router on the path for packet transmission is informed of the upcoming packet stream. DiffServ architecture, on the other hand, differentiates/classifies various types of traffic and provides several levels of service based on that classification. In other words, unlike IntServ, DiffServ labels packets with a particular priority marking that can be referenced by other network devices/applications and hence classified in vari- ous traffic classes to be treated accordingly.

To help deploy QoS for Collaboration (and converged) networks, Cisco provides a QoS toolkit composed of the following tools:

Classification and marking

Queuing (congestion mana geme nt)

Congestion avoidance

Traffic polic ing

Traffic shaping

Link efficiency me chanisms

Medianet

Figure 2-1 illustrates the QoS tools’ order of operation at a high level.

Classification/

Marking

IP Precedence

DSCP

RSVP

ACLs

Policing

Traffic Policing

Rate Limiting

Queuing

LLQ

CBWFQ

WRED

Shaping/

Fragmentation

FRTS

LFI

FRF.12

MLP

Fragmentation FRTS LFI FRF.12 MLP Figure 2-1 QoS T ools’ Order of Operation QoS operation
Fragmentation FRTS LFI FRF.12 MLP Figure 2-1 QoS T ools’ Order of Operation QoS operation
Fragmentation FRTS LFI FRF.12 MLP Figure 2-1 QoS T ools’ Order of Operation QoS operation

Figure 2-1

QoS T ools’ Order of Operation

QoS operation largely depends on QoS policies provisioned in a network. It starts with classification and marking, followed by policing, queuing, and, finally, shaping and frag- mentation. It is essential to plan and deploy end-to-end QoS in LAN, WAN, and virtual- ized environments to ensure that voice and video quality is acceptable. The sections that

From the Library of Juan Arcaya

34

Chapter 2: Quality of Service (QoS)

follow discuss QoS tools and their application. The following QoS tools and applications, as well as considerations for LAN, WAN, wireless, and virtualized environments, are cov- ered in this chapter.

Classification and Marking

Classification is the process by which Cisco Collaboration infrastructure devices and applications can identify packets or frames and sort traffic into different classes. Classification can be done based on various criteria, such as IP address or protocol and port. Once packet types are identified based on classification criteria, they can be marked according to a policy such that other network devices and applications will rec- ognize these packets and treat them as per the QoS policy being applied. Packets can be marked using fields within packets and frames at Layer 3 and Layer 2 respectively. At Layer 3, the Type of Service (ToS) or Differentiated Services (DS) fields in an IP header can be used for marking. At Layer 2, the 802.1p field in the IEEE 802.1Q tag can be used for marking tra ffic.

Layer 2 Marking

Class of service (CoS) markings are applied to frames that transit an 802.1Q trunk. An IEEE 802.1Q tag consists of Tag Protocol ID (TPID) and Tag Control Information (TCI) fiel ds. Figure 2-2 d epicts the Layer 2 frame w ith IEEE 802.1Q tag.

802.1Q Frame

IEEE 802.1Q

VLAN Tag

w ith IEEE 802.1Q tag. 802.1Q Frame IEEE 802.1Q VLAN Tag Preamble (8) Destination Address Source

Preamble

(8)

Destination

Address

Source

Address

TPID

(2)

TCI

(2)

Type/

Length

 

Data

(Payload)

FCS

(2)

(6)

(6)

(2)

 
 

User Priority

 

CFI

VLAN ID

 
 

(3)

(1)

 

(12)

 

Figure 2-2

Used for CoS Markings

IEEE 802.1Q T ag–b ased QoS (C oS) Marking

The TPID field is a 2-byte field and contains a fixed value of 0x8100 that indicates a tagged (802.1Q) frame. The TCI field is a 2-byte field that contains three su bfiel ds:

From the Library of Juan Arcaya

Classification and Marking

35

User Priority: A 3-bit field used to reflect the QoS priority of the frame

Canonical Format Indicator (CFI): A 1-bit field that indicates whether the type of information that a frame carrier is in a canonical (Ethernet) or noncanonical (Token Ring) format

VLAN ID: A 12-bit field that indicates the VLAN from which the frame originated

CoS markings leverage the 3 bits from the User Priority field from within the TCI field in a 802.1Q tagged frame. Because CoS markings use 3 bits, CoS values range from 0 through 7, with values 6 and 7 being reserved.

Layer 3 Marking

At Layer 3 (network layer), packet marking can be accomplished using the ToS byte in an IPv4 header. Two predominant types of marking mechanisms leverage the ToS byte: IP Precedence and Differentiated Services Code Point (DSCP).

IP Precedence is an old approach and has been successively replaced by DSCP for mark- ing IP packets. IP Precedence uses the 3 leftmost bits in the ToS byte. With 3 bits to use, IP Precedence values can range from 0 to 7, with 6 and 7 reserved. The fields in the ToS byte are as follows:

(IP) Precedence: A 3-bit field used to specify the relative priority or importance of a packet

Type of Service (ToS): A 4-bit field that defines how the network should make trade-offs between throughput, delay, reliability, and cost

MBZ: Must be zero

DSCP, on the other hand, uses the 6 leftmost bits from the ToS byte in an IPv4 header as the DiffServ (DS) field. With 6 bits, DiffServ has up to 64 DSCP values (0 to 63) that are assigned to various classes of traffic. The Internet Engineering Task Force (IETF) recom- mends selective DSCP values for use to maintain relative levels of priority. These selective values are called Per-Hop Behaviors (PHB) and determine how packets are treated at each hop along the path from the source to the destination. The subfields in the DS byte are as follows:

DiffServ: A 6-bit field used to specify the DSCP value (and therefore PHB) of a packet

CU: Currently unused

Figure 2-3 illustrates the relationship between the ToS byte, IP Precedence, and DSCP fiel ds.

From the Library of Juan Arcaya

36

Chapter 2: Quality of Service (QoS)

IPv4 Packet

ToS

ToS

ToS
 

12

3

4

5

6

78

Precedence

   

ToS

MBZ

IP Precedence

78 Precedence     ToS MBZ IP Precedence DSCP CU Figure 2-3 IPv4 ToS Byte: IP

DSCP

Precedence     ToS MBZ IP Precedence DSCP CU Figure 2-3 IPv4 ToS Byte: IP Precedence

CU

Figure 2-3

IPv4 ToS Byte: IP Precedence and DSCP Overview

When configuring a router to mark or recognize a DSCP value, decimal numbers or the name of a specific DSCP value can be used. The four different DiffServ PHBs are as follows:

Assured Forwarding (AF): Specifies four AF PHBs grouped into four classes. When using AF, the first 3 bits of the DS field define the queuing class (1 to 4), and the last 3 bits define the drop precedence (1 to 3). AF therefore has 12 classes to it and pro- vides assurance that a packet is forwarded as long as it doesn’t exceed the subscribed rate.

Best Effort (BE): Specified when all 6 bits of the DS field are 0; that is, the packet doesn’t need any specific QoS treatment or doesn’t meet the requirements of any of the other defined classes. BE is also known as default PHB.

Class Selector (CS): Used for backward compatibility with network devices and applications that use IP Precedence. When using this PHB, the last 3 bits of the DSCP field are 0.

Expedited Forwarding (EF): States a low-delay, low-loss, and low-jitter QoS treat- ment with guaranteed bandwidth.

Network-Based Application R ecognition

Network-Based Application Recognition (NBAR) is one of the most powerful QoS marking tools available with Cisco IOS. NBAR enables a router to look into the actual content of the packet, including the application layer. This allows traffic to be marked and classified based on payload rather than lower-layer information such as IP address, frame information, or port numbers. NBAR depends on Cisco Express Forwarding (CEF)

From the Library of Juan Arcaya

Classification and Marking

37

and is deployed using the Cisco Modular Quality of Service Command-Line Interface

(MQC) framework. The following configuration example illustrates NBAR configuration

to match all RTP traffic (audio, video, payload type) based on protocol rather than UDP

port values:

UCRouter(config)# class-map match-any rtp UCRouter(config-cmap)# match protocol rtp

NBAR can be deployed if you are using IPv4 addressing, whereas NBAR2 can be deployed if you are using an IPv6 addressing scheme. NBAR is based on the Service Control Engine (SCE) and is backward compatible.

Classification Service Cla sses

Cisco recommends applying classification/marking to all types of traffic, including voice and video media, call signaling traffic, and different data traffic flows. This set of recom- mendations is called the Cisco QoS baseline. Table 2-2 gives an insight to these service classes.

Table 2-2

Service Classes Based on Cisco QoS Bas eline

Network Service/Application

Classification/Service Class

Network control traffic for switches and routers

CS6 (DSCP 48)

IP voice media traffic (with LLQ)

EF (DSCP 46)

IP interactive video traffic (videoconferenc ing)

AF41 (DSCP 34)

IP streaming video traffic (live, prerecorded)

CS4 (DSCP 32)

Priority data tra ffic (SQL, ecommer ce)

AF31 (DSCP 26)

Voice and video signaling traffic (SIP, H.323, MGCP, SCCP)

CS3 (DSCP 24)

Transactional data (databases)

AF21 (DSCP 18)

Network mana gement (Telnet, SSH)

CS2 (DSCP 16)

Bulk data (HTTP, FTP)

AF11 (DSCP 10)

Scavenger traffic (P2P)

CS1 (DSCP 8)

Best effort (HTTP)

BE (DSCP 0)

Classification and Marking for Softclients

A common issue pertinent to softclients (softphones) such as Jabber and Cisco IP

Communicator is ambiguity in marking and classifying the media and signaling traffic

to and from PCs or laptops. A PC or a laptop connected via a data VLAN sends many

data packets along with voice packets, and unless the OS allows correct marking of these

From the Library of Juan Arcaya

38

Chapter 2: Quality of Service (QoS)

packets by softclient applications, the packets are overridden by default OS-provided CoS markings. The issue becomes even more obscure when a PC is connected to a switch via the PC port on a Cisco Unified IP Phone. In such cases, the IP Phone by default re-marks all CoS values received from the PC to 0, thereby disregarding any markings by Cisco softclients.

For Cisco softclients, QoS classification and marking can be provided by a Trusted Relay Point (TRP). A TRP is a software function that uses a Media Termination Point (MTP) provider and is dynamically inserted in a call flow by CUCM. Media streams from softclients can be bridged together, thereby facilitating the QoS markings and classifica- tion to be applied for PC-to-PC softphone calls. For more information on TRP, refer to Chapter 4 , “Cisco Unified Communications Manager.”

Classification and Marking for Video Traffic

In addition to the previously discussed QoS requirements for video traffic, the following are best practices associated with interactive video:

Interactive video traffic should be marked to DSCP AF41.

Excess videoconferencing tra ffic can be marked down (policing) to AF42 or AF43.

The following are best practices pertinent to streaming video:

Streaming video should be marked to DSCP CS4 (for both unicast and multicast streams).

Guaranteed bandwidth requir ements depend on the encoding format and rate of the video stream.

Non-business-oriented streaming video applications, such as entertainment video content, may be marked as Scavenger class DSCP CS1.

Latency should be no more than 4 to 5 seconds (depending on the video application’s buffering capabilities).

Packet loss should be no more than 5 percent.

Queuing

Beginning with classification and marking, a packet needs to be treated as per the QoS policy. QoS tools such as policing or queuing can make forwarding or dropping deci- sions based on these markings. Queuing is a congestion management tool. It ensures that, during temporary periods of congestion, traffic (packets) is buffered, prioritized, and, if required, reordered before being transmitted to the destination.

From the Library of Juan Arcaya

Queuing

39

Cisco Queuing Toolset

A number of queuing tools are available in Cisco IOS Software and are listed in Table 2-3.

Table 2-3

Queuing T oolset

Queuing Tool

Description

First-In, First-Out (FIFO)

A default queuing mechanism for interfaces with speeds greater than 2.048 Mbps. As the name suggests, the packets are treated

as they arrive and no reordering is done.

Priority Queuing (PQ)

A legacy queuing method with four queues, where higher- priority queues must be emptied before forwarding traffic from lower-priority queues.

Custom Queuing (CQ)

A legacy queuing method that entertains up to 16 queues in a round-robin (RR) cycle, emptying a pre-specified number of bytes from each queue during each iteration.

Weighted Fair Queuing (WFQ)

A flow-based algorithm, derived from Fair Queuing (FQ), and a

default queuing method for low-speed interfaces. WFQ makes forwarding decisions based on a packet’s size and Layer 3 pri- ority marking.

IP RTP Priority

A legacy queuing method that creates a strict PQ for voice traffic for a range of UDP destination ports, with other packets treated with the WFQ method.

Low-Latency Queuing (LLQ)

The queuing method created specifically for voice and video traffic. LLQ allows traffic to be categorized in up to 64 differ- ent classes, with different amounts of bandwidth or priority treatment for these classes.

Class-Based Weighted Fair Queuing (CBWFQ)

Similar to LLQ, but without the PQ mechanism.

Cisco recommends CBWFQ or LLQ methodologies for queuing with current versions of

Cisco IOS in Cisco Collaboration networks. Example 2-1 illustrates the MQC approach

to LLQ.

Example 2-1

MQC Approach to LLQ

UCRouter(config)# class-map RTP-Audio

UCRouter(config-cmap)# match protocol rtp audio

!

UCRouter(config)# class-map RTP-Video

UCRouter(config-cmap)# match protocol rtp video

!

UCRouter(config)# class-map match-any Signaling

From the Library of Juan Arcaya

40

Chapter 2: Quality of Service (QoS)

UCRouter(config-cmap)# match ip dscp cs3

UCRouter(config-cmap)# match ip dscp af31

!

UCRouter(config)# policy-map Voice-Priority UCRouter(config-pmap)# class RTP-Audio UCRouter(config-pmap-c)# priority percent 20 UCRouter(config-pmap-c)# class RTP-Video

UCRouter(config-pmap-c)# priority percent 10 UCRouter(config-pmap-c)# class Signaling UCRouter(config-pmap-c)# bandwidth 128 UCRouter(config-pmap-c)# class class-default UCRouter(config-pmap-c)# fair-queue

!

UCRouter(config)# interface serial 0/0 UCRouter(config-if)# ip address 10.10.1.250 255.255.255.0

UCRouter(config-if)# service-policy output Voice-Priority

In Example 2-1, NBAR is used to recognize RTP audio and video traffic and DSCP mark- ings (default markings by Cisco UC applications and the majority of endpoints) for sig- naling that is matched. Voice audio is given priority treatment of guaranteed 20 percent of the link’s bandwidth, whereas video traffic is given 10 percent of priority guaranteed bandwidth. Signaling traffic is given up to 128 kbps of bandwidth, and the remaining traf- fic is treated by class default via the fair queuing method (that is, this traffic is entertained only when the priority queues have first been serviced up to their assigned bandwidth).

Weighted Random Early Detection

Queues can overfill. To prevent an interface’s output q ueue from filling to its capac- ity, newly arriving packets can be discarded. Before queues are completely full, packets can be tail dropped from the back of queues or selectively dropped. The problem with randomly dropping packets is that some of them might be high priority (such as RTP packets) and some might be low priority. Moreover, randomly dropping packets causes issues such as multiple TCP retransmission requests, which further fill up the queues with retransmitted packets. Weighted Random Early Detection (WRED) allows selective packet dropping on Cisco routers.

WRED is a congestion-avoidance QoS tool. It supports drop thresholds defined for vari- ous markings such as DSCP markings. These thresholds are the minimum threshold, maximum threshold, and mark probability denominator. WRED can be configured on a per-interface basis or as an MQC class. The interface configuration of WRED for DSCP AF21 with a minimum threshold of 32 packets and a maximum threshold of 40 packets is as follows:

UCRouter(config)# interface FastEthernet 0/0 UCRouter(config-if)# random-detect dscp-based UCRouter(config-if)# random-detect dscp af21 32 40

From the Library of Juan Arcaya

WAN QoS Considerations

41

MQC-based WRED configuration is as follows:

UCRouter(config)# policy-map HTTPS UCRouter(config-pmap)# class HTTP-Secure UCRouter(config-pmap-c)# random-detect dscp-based

The command random-detect [ dscp-based | prec-based ] can be used to define either DSCP-based marking or IP precedence–based marking for calculating drop probability. The default is prec-based.

WAN QoS Considerations

WAN links typically require additional mechanisms such as traffic policing, traffic shap- ing, and link efficiency tools to ensure that voice and video media and signaling packets are sent without undue delay, jitter, and packet loss.