ccie collaboration quick reference cisco press.pdf
TRANSCRIPT
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
1/315
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
2/315
Cisco Press800 East 96th Street
Indianapolis, IN 46240
CCIE Collaboration QuickReference
Akhil Behl, CCIE No. 19564
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
3/315
CCIE Collaboration Quick ReferenceAkhil Behl, CCIE No. 19564 (Voice and Security)
Copyright© 2014 Pearson Education, Inc.Published by:Cisco Press800 East 96th StreetIndianapolis, IN 46240 USA
All rights reserved. No part of this book may be reproduced or transmitted in any form or by anymeans, electronic or mechanical, including photocopying, recording, or by any information stor-age and retrieval system, without written permission from the publisher, except for the inclusion ofbrief quotations in a review.
ISBN-13: 978-0-13-384596-9
ISBN-10: 0-13-384596-6
First Edition: May 2014 with corrections June 2014
Warning and Disclaimer
This book is designed to provide information about the Cisco CCIE Collaboration exam. Everyeffort has been made to make this book as complete and as accurate as possible, but no warranty orfitness is implied.
The information is provided on an “as is” basis. The authors, Cisco Press, and Cisco Systems, Inc.shall have neither liability nor responsibility to any person or entity with respect to any loss or dam-
ages arising from the information contained in this book or from the use of the discs or programsthat may accompany it.
The opinions expressed in this book belong to the author and are not necessarily those of CiscoSystems, Inc.
ii CCIE Collaboration Quick Reference
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
4/315
Trademark Acknowledgments
All terms mentioned in this book that are known to be trademarks or service marks have beenappropriately capitalized. Cisco Press or Cisco Systems, Inc. cannot attest to the accuracy of this
information. Use of a term in this book should not be regarded as affecting the validity of anytrademark or service mark.
Special Sales
For information about buying this title in bulk quantities, or for special sales opportunities (whichmay include electronic versions; custom cover designs; and content particular to your business,training goals, marketing focus, or branding interests), please contact our corporate sales depart-ment at [email protected] or (800) 382-3419.
For government sales inquiries, please contact [email protected].
For questions about sales outside the U.S., please contact [email protected].
Feedback Information
At Cisco Press, our goal is to create in-depth technical books of the highest quality and value. Eachbook is crafted with care and precision, undergoing rigorous development that involves the uniqueexpertise of members from the professional technical community.
Readers’ feedback is a natural continuation of this process. If you have any comments regardinghow we could improve the quality of this book, or otherwise alter it to better suit your needs, youcan contact us through email at [email protected]. Please make sure to include the booktitle and ISBN in your message.
We greatly appreciate your assistance.
Publisher: Paul Boger Senior Project Editor: Tonya Simpson
Editor-in-Chief: David Dusthimer Copy Editor: Bill McManus
Business Operation Manager, Cisco Press: Jan Cornelssen Technical Editor: Paulo Lopes
Executive Editor: Brett Bartow Editorial Assistant: Vanessa Evans
Managing Editor: Sandra Schroeder Designer: Mark Shirar
Development Editor: Marianne Bartow Composition: Jake McFarland
iii
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
5/315
iv CCIE Collaboration Quick Reference
About the Author
Akhil Behl , CCIE No. 19564, is a solutions architect with Cisco Advanced Services,
focusing on Cisco Collaboration and Security architectures. He leads Collaboration
and Security projects and service delivery worldwide for Cisco Services and the
Collaborative Professional Services (CPS) portfolio. He has played a major role in service
conception and creation for various services within Cisco Advanced Services. Akhil has
a wide range of experience, from presales to sales to professional services to delivery to
post sales, with expertise in consulting, advisory, and guidance services. Prior to his cur-
rent role, Akhil spent 10+ years working in various roles at Linksys as a technical support
lead, as an escalation engineer at the Cisco Technical Assistance Center (TAC), and as a
network consulting engineer in Cisco Advanced Services.
Akhil has a bachelor of technology degree in electronics and telecommunications from
IP University and a master’s degree in business administration from Symbiosis Institute.He is a dual Cisco Certified Internetwork Expert in Voice and Security. He also holds
many other industry certifications, such as PMP, ITIL, VCP, CCNA, CCSP, CCVP,
ISO/IEC 27002, TOGAF, and CEH.
Over the course of his career, Akhil has presented and contributed at various industry
forums such as Enterprise Connect, Cloud Connect, Cloud Summit, Interop, Cisco
Networkers, and SecCon. He has several research papers published in various national
and international journals, including IEEE journals, and is the author of the Cisco Press
title Securing Cisco IP Telephony Networks .
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
6/315
v
About the Technical Reviewer
Paulo Lopes is a network consulting engineer at the Advanced Services Center of
Excellence of Cisco Unified Communications for Cisco. He has been working at Cisco
supporting and deploying Cisco Unified Communications solutions for more than 10
years. Paulo is currently the tech lead of the Unified Communications virtual team for
the Americas.
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
7/315
vi CCIE Collaboration Quick Reference
Dedication
This book is dedicated first to my family, my dear wife Kanika and my lovely sons
Shivansh and Shaurya, for without their support, encouragement, and patience, it would
not exist. Secondly, to my parents, Vijay Behl and Ravi Behl, and my brothers, Nikhil
Behl and Ankit Behl, who have always been there to support me and guide me in all my
endeavors.
Acknowledgments
I would like to thank the following amazing people and teams for helping me create this
book:
My wife, Kanika, and my kids, Shivansh and Shaurya, for sacrificing many days and
weekends over the past year so that I could work on this book. Without their patience
and support, this book would not have been possible.
The technical reviewer, Paulo Lopes, for his invaluable feedback and for providing
exceptional technical coverage.
The Cisco Press editorial team: Brett Bartow, the executive editor, for seeing the value
and vision in the proposed title and providing me the opportunity to build this title; and
Marianne Bartow, development editor, and Christopher Cleveland, senior development
editor, for their support and guidance all throughout. It is my sincere hope to work again
with them in the near future.
Everyone else in the Cisco Press production team, for their support and commitment.
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
8/315
vii
Contents at a Glance
Chapter 1 Cisco Collaboration Infrastructure 1
Chapter 2 Quality of Service (QoS) 31
Chapter 3 Telephony Standards and Protocols 55
Chapter 4 Cisco Unified Communications Manager 95
Chapter 5 Cisco Unified Communications Security 145
Chapter 6 Cisco Unity Connection 167
Chapter 7 Cisco Unified IM and Presence 191
Chapter 8 Cisco Unified Contact Center Express 209
Chapter 9 Cisco IOS Unified Communications Applications 225
Chapter 10 Cisco Collaboration Network Management 283
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
9/315
viii CCIE Collaboration Quick Reference
Contents
Chapter 1 Cisco Collaboration Infrastructure 1
Cisco Unified Communications Deployment Models 1
Single-Site Deployment Model 2
Multisite WAN with Centralized Call Processing Deployment Model 3
Multisite WAN with Distributed Call Processing Deployment Model 4
Clustering over WAN Call Processing Deployment Model 5
Network Services 6
Dynamic Host Configuration Protocol 6
Domain Name System 7
Trivial File Transfer Protocol 8
Network Time Protocol 11
Cisco Discovery Protocol 12
Link Layer Discovery Protocol 14
Power over Ethernet 15
Voice and Data VLANs 16
IP Routing in Cisco Collaboration Campus Environments 17
Campus Infrastructure Design 17
Campus Access Layer 18
Campus Distribution Layer 18
Campus Core Layer 18
Campus Routed Access Layer Design 19
IPv6 in Cisco Collaboration Networks 20
IPv6 Address Types 21
IPv6 Addressing Model 21
Virtualization in Cisco Collaboration Solutions 23
Cisco UCS Servers 24
VMware ESXi for Cisco Collaboration Virtualization 26
UC Application Install Answer File 26
IP Multicast 27
Wireless in Cisco Collaboration Solutions 28
Chapter 2 Quality of Service (QoS) 31
QoS Requirements for Voice and Video 32
QoS Deployment Architectures 33Classification and Marking 34
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
10/315
ix
Layer 2 Marking 34
Layer 3 Marking 35
Network-Based Application Recognition 36
Classification Service Classes 37
Classification and Marking for Softclients 37
Classification and Marking for Video Traffic 38
Queuing 38
Cisco Queuing Toolset 39
Weighted Random Early Detection 40
WAN QoS Considerations 41
Traffic Policing and Shaping 41
Link Efficiency Mechanisms 43
Compressed RTP 43
Link Fragmentation and Interleaving 43
Multilink PPP 44
Frame Relay Forum 12 44
Voice Activity Detection 45
LAN QoS Considerations 46
QoS Trust Boundary 46
QoS Considerations for WLAN Endpoints 47
QoS Considerations for Virtual Unified Communications with Cisco UCS 48
Medianet 49
Medianet QoS Classes of Service 52
Chapter 3 Telephony Standards and Protocols 55
Voice and Video Codecs 55
VoIP Media Transmission Protocols 57
VoIP Signaling Protocols 58Skinny Client Control Protocol 58
Media Gateway Control Protocol 61
Session Initiation Protocol 65
SIP Session Description Protocol 71
SIP Binary Floor Control Protocol 72
H.323 Gateway, Gatekeeper, and RAS 73
H.323 Gateway 75
H.323 Gatekeeper 76H.225 and RAS Signaling 77
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
11/315
x CCIE Collaboration Quick Reference
H.239-Based Dual Video Channels and Cisco Video Equipment Support 82
Analog Telephony 83
Foreign Exchange Office 83
FXO Disconnect 83
Foreign Exchange Station 84
E&M 84
Digital Telephony 85
Integrated Services Digital Network 85
Q Signaling Protocol 87
Channel Associated Signaling 87
T1 CAS 87
E1 R2 88
Non-Facility Associated Signaling 88
Analog and Digital Telephony Call Signaling Elements 89
Direct Inward Dial 89
Caller ID 89
Echo 90
Trans Hybrid Loss 90
Fax and Modem Protocols 91
Fax Services over IP Network 91
Modem Services over IP Network 93
Chapter 4 Cisco Unified Communications Manager 95
CUCM Redundancy and Device Registration 95
CUCM Device Pool 96
Common Device Configuration 98
Codec Selection 99
CUCM Features 100Call Park and Directed Call Park 100
Call Pickup and Group Pickup 101
Meet-Me Conference 102
Busy Lamp Field Speed Dials 102
CUCM Native Call Queuing 102
Call Hunting 103
CUCM Media Resources 104
Annunciator 104Conference Bridge 104
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
12/315
xi
Media Termination Point 105
Transcoder 105
Music on Hold 105
Media Resource Group and Media Resource Group List 106
Trusted Relay Point 107
CUCM Dial Plan 107
Partitions and Calling Search Spaces 108
Translation Patterns 109
Route Patterns 109
Route List 109
Route Group 110
Globalized Call Routing 110
Local Route Group 111
Time-of-Day Routing 112
Application Dial Rules 112
Directory Dial Rules 113
SIP Dial Rules 113
CUCM Digit Manipulation 114
CUCM H.323 and SIP Trunks 116
SIP Uniform Resource Identifier Dialing 117
Intercluster Lookup Service 119
Blended Addressing 122
CUCM Call Admission Control 122
Locations-Based CAC 123
Enhanced LCAC 124
Resource Reservation Protocol 126
RSVP SIP Preconditions 128
CUCM-Based Call Recording and Silent Monitoring 129
CUCM Mobility 133
Extension Mobility and Extension Mobility Cross Cluster 133
Device Mobility 135
Mobile Connect 136
Mobile Voice Access 138
Service Advertisement Framework and Call Control Discovery 140
SAF Architecture 140
Call Control Discovery Service 142
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
13/315
xii CCIE Collaboration Quick Reference
Chapter 5 Cisco Unified Communications Security 145
Security Policy 145
Threats to Cisco Collaboration Networks 146
Layer 1 Security 146
Layer 2 Security 147
Port Security 147
DHCP Snooping 148
Root Guard and BPDU Guard 149
Dynamic ARP Inspection 149
802.1x 149
Layer 3 Security 151
RFC 2827 Filtering 151
IP Source Guard 151
Unicast Reverse Path Forwarding 152
Routing Protocols Security 152
Router Hardening 152
(Firewall) Security for Layers 4 Through 7 152
Firewall Traversal Mechanisms 153
NAT Traversal 153
IPsec Tunnels 154
IP-Based ACLs 154
Port-Based ACLs 154
Cisco ASA Proxy Features 155
Cisco VPN Phone 156
Application Layer Security 157
CUCM Security By Default 158
CUCM Security Modes 158
CTL Client and CTL File 159
Cisco Unified IP Phone Certificates 161
SRTP and TLS 161
Preventing Toll Fraud 162
CUCM Class of Service 162
Cisco Voice Gateway Toll-Fraud Prevention Application 163
Voice Gateway Class of Restriction 164
Cisco Unity Connection Restriction Rules 165
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
14/315
xiii
Chapter 6 Cisco Unity Connection 167
Cisco Unity Connection High Availability 167
Cisco Unity Connection Integration with CUCM and CUCME 168
Cisco Unity Connection SCCP Voicemail Integration with CUCM 169
Cisco Unity Connection SIP Voicemail Integration with CUCM 171
Cisco Unity Connection SCCP Voicemail Integration with CUCME 172
Cisco Unity Connection SIP Voicemail Integration with CUCME 174
Cisco Unity Connection Dial Plan 175
Call Handlers 176
Cisco Unity Connection System Call Handlers 176
Cisco Unity Connection Directory Handlers 178
Cisco Unity Connection Interview Handlers 179
Cisco Unity Connection Single Inbox 180
Cisco Unity Connection Visual Voicemail 183
Voice Mail for Cisco Jabber 184
Cisco Unity Connection Voicemail Networking 186
Intrasite Networking 187
Intersite Networking 188
Voice Profile for Internet Email (VPIM) Networking 189
Chapter 7 Cisco Unified IM and Presence 191
Cisco Unified Communications Manager IM and Presence Components 191
Cisco Unified CM IM and Presence Cluster 192
Cisco Unified CM IM and Presence Server Integration with CUCM 193
Cisco Jabber 197
Presence Federation 198
Intradomain Federation 199
Interdomain Federation 201Presence Cloud Solutions 202
Group Chat and Compliance 204
Group Chat 204
Logging and Compliance 205
Client-Side IM Logging (History) 205
Server-Side IM Logging (Compliance) 206
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
15/315
xiv CCIE Collaboration Quick Reference
Chapter 8 Cisco Unified Contact Center Express 209
Cisco UCCX Architecture 209
Cisco UCCX Components and Subsystems 210
UCCX ACD/ICD, IVR, and CTI Functions 211
UCCX ACD Functions 211
UCCX CTI Functions 213
UCCX IVR Functions 213
UCCX Deployment Models 214
UCCX Call Flow 215
UCCX Integration with CUCM 216
UCCX Scripting Components 218
Chapter 9 Cisco IOS Unified Communications Applications 225
Cisco Unified Communications Manager Express 225
Basic Cisco Unified CME Setup 226
Cisco Unified CME–Based SCCP Phone Registration 227
Cisco Unified CME–Based SIP Phone Registration 229
Cisco Unified CME Single Number Reach 230
Survivable Remote Site Telephony 232
MGCP Fallback 236Multicast Music on Hold in SRST 237
Cisco IOS Dial Plan 238
Voice Translation Rules and Profiles 239
Cisco IOS Dial-Peer Matching Logic 242
Cisco IOS Media Resources 244
Cisco IOS DSP Management 244
Cisco IOS Conferencing Resources 245
Cisco IOS Transcoding Resources 246Cisco Unified CME–Based Media Resources 246
Cisco Unified CME Conferencing and Transcoding 246
Cisco IOS–Based Call Queuing 249
Cisco Unified CME Basic Automatic Call Distribution 249
Voice Hunt Groups 252
Call Blast 253
Cisco Unity Express 254
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
16/315
xv
Cisco Unified CME and CUE Integration 254
CUE Message Waiting Indicator 256
Outcalling 256
(SIP) Subscribe Notify 257
Unsolicited Notify 257
CUE Web Inbox 258
CUE VoiceView Express 258
CUE Auto-Attendant 259
CUE Scripting 261
CUE Voice Profile for Internet Email 263
Cisco IOS Call Admission Control 266
Local CAC 267
Reservation-Based CAC 267
Measurement-Based CAC 268
Cisco IOS CDR Accounting 268
File Accounting 269
Syslog-Based CDR Accounting 269
RADIUS-Based CDR Accounting 269
Cisco Service Advertisement Framework and Call Control Discovery 270
Cisco Unified Border Element 272
CUBE Redundancy 273
CUBE SIP Profiles 277
CUBE Early Offer and Delayed Offer 278
CUBE DTMF Interworking 279
CUBE Mid-Call Signaling 281
Chapter 10 Cisco Collaboration Network Management 283
CUCM Serviceability and OS Administration 283CUCM Database Replication 283
CUCM Service Activation 284
CUCM Call Detail Records and Call Management Records 288
CUCM Disaster Recovery 289
User Management 290
Cisco EnergyWise 292
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
17/315
xvi CCIE Collaboration Quick Reference
Icons Used in This Book
PC PC withSoftware
SunWorkstation
Macintosh
Terminal FileServer
WebServer
CiscoworksWorkstation
Printer Laptop IBMMainframe
Front EndProcessor
ClusterController
Modem
DSU/CSU
Router Bridge Hub DSU/CSU CatalystSwitch
MultilayerSwitch
ATMSwitch
ISDN/Frame RelaySwitch
CommunicationServer
Gateway
AccessServer
Network Cloud
TokenRing
Token Ring
Line: Ethernet
FDDI
FDDI
Line: Serial Line: Switched SerialCisco ASA
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
18/315
xvii
Command Syntax Conventions
The conventions used to present command syntax in this book are the same conventions
used in the IOS Command Reference. The Command Reference describes these conven-
tions as follows:
■ Boldface indicates commands and keywords that are entered literally as shown.
In actual configuration examples and output (not general command syntax),
boldface indicates commands that are manually input by the user (such as a
show command).
■ Italics indicate arguments for which you supply actual values.
■ Vertical bars (|) separate alternative, mutually exclusive elements.
■
Square brackets ([ ]) indicate optional elements. ■ Braces ({ }) indicate a required choice.
■ Braces within brackets ([{ }]) indicate a required choice within an optional
element.
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
19/315
This page intentionally left blank
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
20/315
Cisco CollaborationInfrastructure
Cisco Unified Communications (UC) is a way of creating collective and adaptive
workspaces by incorporating communications and collaboration products with
associated applications. Cisco UC helps people to work together more effectively
and efficiently by leveraging various unified applications and services such as voice
calls, voice messaging, presence, mobility, and video to people within and outside the
organization. This begins with building the underlying infrastructure to support Cisco
Collaboration applications, servers, devices, endpoints, and services.
Cisco Unified Communications Deployment Models
Cisco Unified Communications Manager (CUCM) is the brain of the Cisco UC solutionand provides a single interface to all other UC features and functions. CUCM supportsvarious deployment models. Each of these models is based on certain requirements ofthe organization that deploys a Cisco UC network. The Cisco UC deployment models arebroadly classified as follows:
■ Campus deployment model: The Cisco UC and Collaboration services, whichinclude call control, media resources, endpoints, and other applications, are alllocated on a single high-speed local-area network (LAN) or metropolitan-areanetwork (MAN).
■ Centralized deployment model: The Cisco UC and Collaboration services arelocated in a central campus site or data center. However, the endpoints, applica-tions, media resources, gateways, and other components are dispersed across severalremote sites. These sites may be interconnected to a central campus site and to eachother by a quality of service (QoS)-enabled WAN.
■
Distributed deployment model:
The call control is dispersed across multiple remotesites and multiple campus and/or centralized deployments that are interconnectedover a QoS-enabled WAN.
Chapter 1
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
21/315
2 Chapter 1: Cisco Collaboration Infrastructure
These three broad deployment models can be further classified into the following cat-egories of UC deployment models, which are described in more detail in the followingsubsections:
■ Single-site
■ Multisite WAN with centralized call processing
■ Multisite WAN with distributed call processing
■ Clustering over WAN call processing
Apart from the preceding on-premises models, Cisco offers cloud-based (managed)Collaboration solutions such as Cisco Hosted Collaboration Solution (HCS) and CiscoHosted Unified Communications Services.
Single-Site Deployment Model
In a single-site deployment model, all CUCM servers in a cluster, all UC applications, andother media resources reside at the same location. All call processing is accomplishedat the designated site with gateway trunks that connect directly to the public switchedtelephone network (PSTN) and handle external calls. As shown in Figure 1-1, this modelis ideal for small enterprises where call control should remain within a site (for example,headquarters).
CC
V
V
Applications Media Resources Infrastructure
Internet
PSTN
CUCMCluster
Endpoints
V
Figure 1-1 Single-Site Deployment Model
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
22/315
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 tooffer resiliency, fast convergence, and inline power.
■ Deploy QoS from IP Phone (user access layer) to CUCM (data center access layer) togateways for optimum voice quality.
■ Use a high-quality, low-compression codec such as G.711 for highest audio quality.This also allows digital signal processor (DSP) resources to be allocated for confer-encing or media termination point (MTP).
■ Deploy voice gateways or Session Border Controller (SBC) for Session InitiationProtocol (SIP) trunks to the IT service provider (ITSP) for off-net calls to the PSTNor a legacy PBX. All on-net calls should be limited to a central site based on calling
patterns for your enterprise.
Multisite WAN with Centralized Call Processing Deployment Model
In a multisite WAN with a centralized call processing deployment model, all CUCMservers in a cluster reside at the same location. Optionally, applications and other mediaresources may be deployed at the same location as well. If the applications and mediaresources are at remote locations, it is beneficial to have a consolidated administrationof all resources. The remote sites rely on the centralized CUCM cluster for call process-ing and other telephony functions. The centralized CUCM cluster connects with end-points and applications at remote sites through a QoS-enabled IP WAN. Remote sitesare deployed with Cisco Unified Survivable Remote Site Telephony (SRST) on Cisco IOSvoice gateways that allow endpoints and applications to function when the connectionto the campus site is unavailable or disrupted. As shown in Figure 1-2, this deploymentmodel is ideal for small to medium enterprises.
CC
V
V
Applications Media Resources Infrastructure
CUCMCluster
Internet
Media and Conference Resources
IP WAN
PSTN
Endpoints
Endpoints
V V
Figure 1-2 Multisite WAN with Centralized Call Processing Deployment Model
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
23/315
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 havetheir own media resources and applications or employ them from the campus site. The
dial plan can be aggregated using individual intercluster trunks (ICT) or Cisco Unified
Communications Manager Session Management Edition (SME) cluster(s). As shown in
Figure 1-3, this deployment model is ideal for medium to large enterprises.
CC
V
V
Applications Media Resources Infrastructure
CUCM
Cluster
Internet
Media and Conference Resources
IP WAN
PSTN
Endpoints
Endpoints
CUCM
Cluster
V
VV
Figure 1-3 Multisite WAN with Distributed Call Processing Deployment Model
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
24/315
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 guidelinesfor the single-site and multisite WAN with centralized call processing models.
Clustering over WAN Call Processing Deployment Model
In this deployment model, the call control (CUCM and Cisco Business Edition 6000)CUCM is deployed across two or more data centers/sites over the IP WAN to provideredundancy, both within the region and overall. This model is particularly useful wheremultiple large sites have to be encompassed and dial-plan consistency must be main-tained. Clustering over WAN can be either a local failover deployment model, where theactive and backup servers are at the same physical site, or a remote failover deploymentmodel, where the active and backup servers are at different sites/data centers. Figure 1-4depicts the clustering over WAN call processing deployment model.
Media Resources
Internet Internet
IP WAN
CUCM
Cluster Over WAN
Infrastructure
EndpointsEndpoints
Media and Conference Resources
V
V
V
V
PSTN
PSTN
VV
Figure 1-4 Clustering over WAN Call Processing Deployment Model
The following are some best practices associated with the clustering over WAN call pro-cessing deployment model:
■ The round-trip time (RTT) for cluster over WAN call processing should not be morethan 80 ms.
■ End-to-end QoS along with appropriate bandwidth provisioning specifically forIntra-Cluster Communication Signaling (ICCS) is required. Overprovisioning andundersubscription of bandwidth is recommended.
■ Minimize jitter, congestion, and packet loss for ICCS.
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
25/315
6 Chapter 1: Cisco Collaboration Infrastructure
Network Services
This section covers the various network services essential for a functional CiscoCollaboration solution:
■ Dynamic Host Configuration Protocol (DHCP)
■ Domain Name System (DNS)
■ Trivial File Transfer Protocol (TFTP)
■ Network Time Protocol (NTP)
■ Cisco Discovery Protocol (CDP)
■ Link Layer Discovery Protocol (LLDP)
Dynamic Host Configuration Protocol
DHCP is recommended for the successful deployment of UC endpoints such as CiscoUnified IP Phones, Jabber clients, and so on. Although endpoints can be configuredwith a static IP address, DHCP is particularly helpful in assigning IP address and otherimportant parameters in bulk to IP Phones. Individual DHCP scopes must be createdfor each of the voice virtual LANs (VLAN), with sufficient addresses to support themaximum number of phones likely to be deployed in that VLAN. The DHCP service canbe provided by CUCM, a Cisco IOS router or switch, or a third-party server (any RFC
2131–compliant DHCP server may be used to provide configuration information to IPCommunications network devices).
In addition to specifying the common DHCP options such as subnet mask, default router,DNS servers, and so forth, each scope supporting Cisco Unified IP Phones should includethe specification of DHCP option 150. This option should contain the IP address ofTFTP servers. Because TFTP is crucial to the correct operation of a telephony network,it is recommended that DHCP option 150 be used so that TFTP server redundancy canbe achieved by providing multiple differently ordered lists of TFTP server addresses tohosts.
The DHCP lease time controls the duration for which an IP Phone retains an IP addressfrom a DHCP scope. Cisco Unified IP Phones request a new IP address after half thelease time has expired since the last successful DHCP server acknowledgment. After therequest is acknowledged by the DHCP server, the IP Phone retains its IP scope.
For remote sites, DHCP service can be provided by local or remote DHCP servers.Remote DHCP requests can be relayed by Cisco IOS routers/switches on behalf of therequesting endpoint. DHCP relay is configured with the ip helper-address command.The following example outlines the configuration of a Cisco IOS router to relay a DHCPrequest to a DHCP server at a central site.
UCRouter(config)# interface GigabitEthernet 1/1
UCRouter (config-if)# ip helper-address 10.10.10.100
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
26/315
Network Services 7
Example 1-1 shows configuration of a DHCP server on a Cisco IOS router.
Example 1-1 Cisco IOS Router–based DHCP Server Configuration
UCRouter (config)# service dhcp
!
UCRouter (config)# ip dhcp excluded-address 10.10.0.1 10.10.0.10
!
UCRouter (config)# ip dhcp pool VOICE
UCRouter (config-dhcp)# network 10.10.0.0 255.255.255.0
UCRouter (config-dhcp)# default-router 10.10.0.1
UCRouter (config-dhcp)# domain-name mydomain.local
UCRouter (config-dhcp)# option 150 ip 10.76.108.146
UCRouter (config-dhcp)# lease 7
UCRouter (config-dhcp)# dns-server 10.10.0.2
In Example 1-1, the ip dhcp excluded-address command helps segregate addresses from
the assignment pool so they are not assigned to any endpoint. The DHCP pool defines a
network from which the endpoints can get their IP address, option 150, and other param-
eters, as explained earlier.
Domain Name System
DNS is used for name resolution and is particularly useful for management purposes andload-balancing requirements. A Cisco Collaboration network and applications such as
CUCM, Cisco Unity Connection, Cisco Unified IP Phones, Cisco IOS routers, and other
devices can leverage DNS to resolve names to IP addresses.
However, Cisco strongly recommends that DNS not be used for critical communications
in the Collaboration network, such as IP Phone to CUCM, voice gateway to CUCM, and
intra-cluster communication. Cisco suggests using IP addresses, when possible, between
call control and endpoints to avoid any risk of registration failure, because endpoints
won’t be able to resolve the name of the CUCM server(s) when DNS service is unavail-
able. Because a DNS server can be a single point of failure in a Cisco UC network, Ciscorecommends deploying redundant DNS servers or using IP addresses.
During the initial installation of a CUCM cluster, the servers are referenced in the local
server table by their hostnames. Before you install and configure any endpoints on the
system, you should change this table to include the IP addresses of the servers instead of
their hostnames. To change the name of a CUCM server (which defaults to the hostname
during installation), go to the Cisco Unified CM Administration page, choose System >
Server , and replace the server name with its respective IP address, as shown in Figure 1-5.
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
27/315
8 Chapter 1: Cisco Collaboration Infrastructure
Figure 1-5 CUCM Server Hostname to IP Address Substitution
This should be performed even if the system is configured to use DNS (that is, the DNSclient is enabled on the cluster servers).
Trivial File Transfer Protocol TFTP is a crucial component of a Cisco Collaboration network as Cisco Unified IPPhones require a TFTP server to retrieve their firmware, configuration files, phone but-ton template, and other information. This only confirms that having TFTP redundancy isparamount in a critical UC setup. As discussed earlier, DHCP option 150 can be used toenable TFTP redundancy in a Cisco Collaboration network.
A TFTP server has various files that can be used by different types of endpoints (phones,gateways, and so forth), such as the following:
■ Phone firmware files (Cisco-signed files, which are not modifiable)■ Phone configuration files (XMLDefault.cnf.xml or SEP.cnf.xml)
■ Certificate Trust List (CTL) files (only if the cluster is in mixed mode)
■ Identity Trust List (ITL) files (for all endpoints that register with CUCM)
■ Tone localization files
■ User interface (UI) localization and dictionary files
■ Ring List files
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
28/315
Network Services 9
■ Softkey and Phone Button Template files
■ Background images
The Cisco Unified IP Phone to TFTP interaction process can be best illustrated by goingthrough the IP Phone bootup cycle, as shown in the following steps:
Step 1. Assuming that the IP Phone is connected to a Cisco Catalyst switch that iscapable of providing Power over Ethernet (PoE), using Fast Link Pulse (FLP),the switch detects an unpowered IP Phone and powers it up using Cisco pro-prietary standard (provides .48 V DC at up to 6.3 to 7.7 W per port over datapins 1, 2, 3, and 6).
Step 2. Every IP Phone has nonvolatile flash memory in which it stores firmwareimage(s). At startup, the IP Phone runs a bootstrap loader that loads an avail-
able phone image stored in flash memory. Using this image, the IP Phone ini-tializes its software and hardware.
Step 3. As the IP Phone receives power and boots, the switch sends a CiscoDiscovery Protocol (CDP) packet to the IP Phone. This CDP packet providesthe IP Phone with voice VLAN (also known as auxiliary VLAN) informationso that the IP Phone can reach the appropriate VLAN and initiate a DHCPrequest.
Step 4. The IP Phone sends a broadcast request such as a DHCP discover messageto the DHCP server in the voice VLAN. The DHCP server replies with an IP
address, a subnet mask, a default gateway, and the IP address of the CiscoTFTP server. There could be additional optional parameters as well. However,at a minimum, these steps are required for IP Phone connection.
Step 5. The IP Phone contacts the Cisco TFTP server or external TFTP server torequest firmware and files. The TFTP server sends the configuration informa-tion for that IP Phone, which contains an ordered list of up to three CUCMservers or two CUCM servers and an SRST reference. If the IP Phone wasmanually preconfigured in CUCM, the SEP.cnf.xml file isdownloaded for that phone. Otherwise, the XMLDefault.cnf.xml configura-
tion file is used for IP Phones that request auto-registration.Step 6. The .cnf.xml file indicates the firmware load that the IP Phone should be run-
ning. If this image load differs from the one that is currently on the IP Phone,the phone contacts the TFTP server to request the new firmware load file,which has a .bin file extension. The IP Phone installs the firmware in its non-volatile RAM and reboots.
Step 7. After rebooting, the IP Phone downloads other information such as the soft-key template and phone button template. The IP Phone attempts to make aTCP connection to a CUCM server that is considered the highest priority in
its list. The phone registers to the CUCM server and obtains a directory num-ber (DN).
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
29/315
10 Chapter 1: Cisco Collaboration Infrastructure
Cisco TFTP service can be supported in multiple ways to serve local and remote-siteCisco Unified IP Phones:
■ Cisco TFTP Server: The default method of using one or more CUCM servers inthe cluster as TFTP servers that allows IP Phones to download the firmware, con-figuration, and other files. This is an ideal model for an enterprise environment withhigh-speed WAN links because the Cisco Unified IP Phones at a remote site willdownload firmware during initial setup or firmware upgrade via centralized TFTPservers. In case of the multisite WAN with distributed call processing deploymentmodel or the clustering over WAN call processing deployment model, CUCM TFTPservers can be deployed at larger remote sites to serve local phones. Cisco CUCMalso supports proxy TFTP that enables phones to sync with a proxy TFTP serverthat forwards the requests to their respective clusters. This is especially useful in thecase of multiple phones tied to multiple clusters at remote sites. It saves the overheadof manually defining multiple option 150 for IP Phone subnets to the correct TFTPservers.
■ Load Server: A CUCM administrator can assign a TFTP server to each individualphone record using the Load Server parameter. Assigning the Load Server parameteris particularly useful for remote sites where downloading firmware to the phoneis difficult due to lower WAN speeds. In such cases, a CUCM administrator candeploy local TFTP servers (Windows- or IOS-based TFTP) to allow the phones tooperate at remote sites without having to traverse the WAN for firmware download.To enable the Load Server parameters on a per-phone basis, go to the Cisco Unified
CM Administration page, choose Device > Phone , and select the phone for whicha particular load server is to be defined. Browse to Product Specific ConfigurationLayout , define the Load Server IP address/hostname, and enable the same.
■ Peer Firmware Sharing (PFS): PFS is a feature that allows phones participating inthis firmware distribution model to form a peering relationship in a tree-based hier-archy. One phone peers with two other phones. The administrator, however, doesnot need to designate parents (phones initiating PFS) and hosts (phones acceptingPFS). All the peer-enabled Cisco Unified IP Phones on a given IP subnet form a treestructure to distribute the firmware. After the peering relationship is established, the
root phone retrieves the firmware files from the Cisco TFTP server and distributesthem to the associated peers. This helps to reduce the load on the WAN during firm-ware upgrades and minimize the overall time needed to upgrade remote-site phones.PFS is supported with Cisco Unified IP Phone firmware 8.3(1) and later. To ensurethat the phones are participating in a PFS distribution, go to the Cisco Unified CMAdministration page, choose Device > Phone , and select the phone that should beenabled for PFS. Browse to Product Specific Configuration Layout and ensure thatthe Peer Firmware Sharing option is enabled.
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
30/315
Network Services 11
Network Time Protocol
NTP enables network devices to synchronize their clocks to a network time serveror a network-capable clock. NTP is critical for ensuring that all devices in a Cisco
Collaboration network have the same time. Time synchronization is especially criticalon CUCM servers. In addition to ensuring that call detail records (CDR) are accurate andthat log/trace files are synchronized, an accurate time source is necessary for any future(IPsec) features to be enabled within the cluster and for communication with any externalentity.
NTP should be configured across the network to allow for the synchronization of logfiles between multiple devices. Keeping the time accurate on all systems in the infrastruc-ture helps administrators to troubleshoot and correlate events in a Cisco Collaborationnetwork. Devices in a Cisco Collaboration network can receive the time from an authori-
tative time source, such as a Cisco router or an atomic clock.
Example 1-2 outlines the configuration of a router to receive the time from an authorita-tive time source.
Example 1-2 Cisco IOS NTP Client Configuration
UCRouter(config)# ntp authentication-key 1 md5 C1sc0123
UCRouter(config)# ntp trusted-key 1
UCRouter(config)# ntp source FastEthernet0/1
UCRouter(config)# ntp server 10.10.200.200 key 1 prefer source FastEthernet0/1
version 3 UCRouter(config)# ntp authenticate
CUCM automatically synchronizes the NTP time of all subscribers in the cluster to thepublisher. During installation, each subscriber is automatically configured to point to anNTP server running on the publisher. Cisco recommends using an NTP time source withNTP stratum 3 or better (the lower the better). An NTP time source can be added to theCUCM publisher by navigating to the Cisco Unified Operating System Administrationpage and choosing Settings > NTP Servers , as shown in Figure 1-6.
Skinny Call Control Protocol (SCCP) endpoints leverage the CUCM publisher’s NTPsource implicitly. You can add a phone NTP reference for SIP endpoints. To add a phoneNTP reference in CUCM, go to the Cisco Unified CM Administration page and chooseSystem > Phone NTP Reference . You must assign this NTP reference to a date/timegroup, which in turn is assigned to a device pool.
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
31/315
12 Chapter 1: Cisco Collaboration Infrastructure
Cisco Discovery Protocol
CDP is a Cisco-proprietary Layer 2 protocol that was developed for discovering neighbordevices. It is a media- and protocol-independent device-discovery protocol that runs onCisco equipment, including Cisco Unified IP Phones, routers, access servers, and switch-es. A device can advertise its existence to other devices using CDP and can also receiveinformation about other devices on the network. There are two versions of CDP, Version1 and Version 2. All modern Cisco gear runs CDPv2 by default.
CDP operates on all media that supports Sub-Network Access Protocol (SNAP), includ-ing LAN, Frame Relay, and ATM. CDP messages are multicast advertisements sent withthe multicast destination address 01:00:0C:CC:CC:CC on each CDP-enabled interface.
CDP advertisements contain information such as the following:
■ Device ID
■ Port ID
■ Address
■ Capabilities
■ Version
■ Platform
■ Native VLAN
CDP messages are made up of Version, Time to Live (TTL), and Checksum fields, fol-lowed by a number of Type, Length, and Value (TLV) fields. Table 1-1 illustrates variousCDP TLV fields.
Figure 1-6 NTP Server Configuration
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
32/315
Network Services 13
Table 1-1 CDP TLV Fields
CDP TLV Field Description
Device ID Identifies the sending device’s hostname
Address Provides the address of the interface (physical, loopback, VLAN)that is sending the CDP update
Port ID Specifies the port from which the CDP update is sent (outgoingport)
Capabilities Identifies the device’s functional capabilities (e.g., router, switch,host)
Version Specifies the Cisco IOS or firmware version running on the deviceadvertising the updates
Platform Identifies the hardware or virtual platform
Full/Half Duplex Indicates the duplex mode of the advertising device’s connectedinterface
VTP Domain Identifies the VTP domain of the advertising device (if any)
Management Address Identifies the management address of the advertising device (if any)
Example 1-3 illustrates how to access CDP timer, holdtime, and version information as
well as CDP discovery information.
Example 1-3 CDP Information
UCSwitch# show cdp
Global CDP information:
Sending CDP packets every 60 seconds
Sending a holdtime value of 180 seconds
Sending CDPv2 advertisements is enabled
!
UCSwitch# show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater
Device ID Local Intrfce Holdtme Capability Platform Port ID
CM91PUB Fas 0/30 135 H VMware eth0
CUPS91 Fas 0/26 169 H VMware eth0
UCRouter Fas 0/24 163 R S I CISCO3945-Gig 0/0
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
33/315
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 securityreasons, such as hiding device details that you may not want to share with other infra-structure components.
Link Layer Discovery Protocol
LLDP is a vendor-neutral Layer 2 protocol and is analogous to CDP. LLDP is the stan-dards-based IEEE 802.1AB protocol for vendor-neutral interoperability. Similar to CDP,it is used by network devices to advertise their identity, capabilities, and neighbors, butprimarily for non-Cisco equipment or endpoints. If the switches are non-Cisco switches,LLDP for Media Endpoint Devices (LLDP-MED) can be used to detect power and voiceVLAN, provided the switch is capable of delivering Power over Ethernet. Also, if theendpoints are non-Cisco devices, LLDP-MED can be used on Cisco switches to supportthird-party phones.
LLDP information is sent by devices from each of their interfaces at a fixed interval of30 seconds with the holdtime of 120 seconds. This takes place in the form of an Ethernetframe, where each frame contains one LLDP Data Unit (LLDPDU). Each LLDPDU is asequence of TLV structures. By default, LLDP is disabled on Cisco routers and switches.Table 1-2 provides the TLV fields that are advertised by LLDP.
Table 1-2 LLDP TLV Fields
LLDP TLV Field Description
Port Description Identifies the port from which the LLDP update is sent
System Name Identifies the sending device’s hostname
System Description Provides details about the advertising device’s OS/firmware
System Capabilities Identifies the device’s functional capabilities (e.g., router, switch,host)
Management Address Provides the management IP address (if any)
Port VLAN ID Identifies the native VLAN ID of the advertising port
MAC/PHY
Configuration/Status
Provides the MAC address and other physical characteristics
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
34/315
Power over Ethernet 15
Example 1-5 illustrates LLDP configuration on a Cisco switch at a global level and anindividual interface level.
Example 1-5 LLDP Information
UCSwitch# show lldp
% LLDP is not enabled
!
UCSwitch(config)# lldp run
!
UCSwitch(config)# interface FastEthernet 0/1
UCSwitch(config-if)# lldp transmit
UCSwitch(config-if)# lldp receive
Power over Ethernet
There are three ways to power up a Cisco Unified IP Phone:
■ Inline power: Power over Ethernet, derived from switch port
■ Power supply: Using power supply from a wall jack
■ Midspan power injector: Sits between a switch port and the IP Phone and supplies
power to the IP Phone
Cisco supports two types of inline power delivery as PoE: the Cisco original implementa-tion (Cisco proprietary) and the IEEE 802.3af standards-based PoE. The original Ciscoimplementation has the following features:
■ Uses a Cisco proprietary method to determine whether an attached device requirespower. Power is delivered only to devices that require power.
■ Provides .48 V DC at up to 6.3 to 7.7 W per port over data pins 1, 2, 3, and 6.
■ Supports most Cisco devices such as Cisco Unified IP Phones.
After first developing (pre-standard) PoE, Cisco worked with IEEE to create a standards-based PoE delivery mechanism to develop what is currently known as the IEEE 802.3afstandard, which has the following features:
■ Specifies .48 V DC at up to 15.4 W per port over data pins 1, 2, 3, and 6 or over thespare pins 4, 5, 7, and 8 (power sourcing equipment [PSE] can use one or the other,but not both).
■ Enables a new range of Ethernet-powered devices that consume additional power.
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
35/315
16 Chapter 1: Cisco Collaboration Infrastructure
The process via which PoE-enabled switches detect and power a Cisco Unified IP Phonevaries depending on whether you are using the Cisco original standard or the IEEE stan-dards-based implementation. If you employ the Cisco-proprietary method, a switch sends
a Fast Link Pulse (FLP) to the connected device. When the connected device loops theFLP back to the switch, the switch starts supplying power over the Ethernet connectionto the device. If you use IEEE 802.3af, the switch applies a voltage in the order of –2.8 to–10 V, and if a resistance of 25K ohm is detected, the switch supplies power to the con-nected device.
It is recommended to deploy PoE-capable switches at the campus access layer within wir-ing closets to provide inline-powered Ethernet ports for IP phones, thus eliminating theneed for wall power. If the switches are non-Cisco switches, LLDP-MED can be used todetect power and voice VLAN.
Voice and Data VLANs
Virtual LANs (VLAN) enable a network administrator to break up a switching domaininto multiple broadcast domains. Think of a VLAN as virtually fragmenting a Ciscoswitch into multiple sub-switches, with each VLAN/subswitch being a broadcast domainand having a unique IP subnet.
A Cisco Catalyst/Nexus switch has multiple physical ports, all of which belong to VLAN1 by default (out of the box). A set of ports can be assigned to, say, VLAN 100 andanother set of ports can be assigned to VLAN 200. This helps break up (logically) a large
physical switch with a single broadcast domain and a single IP subnet into multiple smallvirtual switches, with each virtual switch having its own broadcast domain and IP subnet.Some of the benefits of this process include increased security, increased performance,and a physical topology–independent network.
When a switch is configured for data and voice VLANs, Cisco Unified IP Phones con-nect to the user-facing access layer ports on the switch, followed by a PC or a data deviceconnecting to the IP Phone’s PC port. IP Phones come with a built-in switch that inter-faces between the PC port and switch port. IP Phones support 802.1Q tagging, and theincoming switch port receives and sends 802.1Q-tagged packets. Voice packets are 802.1Q
tagged, and the switch understands the tagging on the access port, thereby assigningthese packets to voice VLAN. The data packets, on the other hand, pass through the IPPhone to the switch as untagged packets, and the switch assigns these untagged packetsto the data VLAN.
Cisco strongly recommends separating voice and data traffic by using VLANs for the fol-lowing reasons:
■ To provide clear segregation of voice and data traffic
■ To provide QoS marking and classification for real-time voice traffic vis-à-vis data
traffic■ To prevent data applications from directly interacting with voice traffic
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
36/315
IP Routing in Cisco Collaboration Campus Environments 17
Example 1-6 illustrates configuration of voice and data VLANs on a Cisco Catalystswitch.
Example 1-6Voice and Data VLAN Configuration
UCSWITCH(config)# vlan 100
UCSWITCH(config-vlan)# name Data-VLAN
!
UCSWITCH(config)# vlan 200
UCSWITCH(config-vlan)# name Voice-VLAN
!
UCSWITCH(config)# interface range FastEthernet 0/1 - 10
UCSWITCH(config-if-range)# switchport mode access
UCSWITCH(config-if-range)# switchport access vlan 100
UCSWITCH(config-if-range)# switchport voice vlan 200
UCSWITCH(config-if-range)# spanning-tree portfast
IP Routing in Cisco Collaboration Campus Environments
IP routing is used for many functions in Cisco Collaboration networks and forms thebackbone of any successful deployment. IP routing is employed for the following:
■ Inter-VLAN routing
■ Static or dynamic routing
■ Cisco Service Advertisement Framework (SAF)
■ Cisco Unified IP Phone to UC/application server communication
■ UC/application server or IP Phone to gateway communication
For optimum performance of the Cisco Collaboration solution, the network should be
modeled after Cisco’s recommended core, distribution, and access (CDA) layer approach.Layer 3 routing protocols such as Routing Information Protocol (RIP), Enhanced InteriorGateway Routing Protocol (EIGRP), and Open Shortest Path First (OSPF) are commonlyemployed in unified IP environments. Routing protocol parameters such as timers,path/link costs, and route summaries can be used to optimize and control convergencetimes and distribute traffic across multiple paths. Cisco recommends using the passive-interface command to prevent routing neighbor adjacencies via the access layer.
Campus Infrastructure Design
Before examining the specifics of IP routing in a campus environment, it’s important tounderstand the design basics. One of the most important principles of campus network
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
37/315
18 Chapter 1: Cisco Collaboration Infrastructure
design is to introduce and enable a hierarchy in the network infrastructure. This allowseach network layer to play a specific role, thus ensuring scalability, reliability, and bettermanagement.
Campus-wide VLANs are based on the flat design model, meaning they avoid the logical,hierarchical structure and the route summarization provided by routers. Layer 3 switchingprovides the same advantages as routing in campus network design with the added per-formance boost from packet forwarding handled by specialized hardware. Layer 3 switch-ing in the distribution layer and core of the campus segments the campus into smaller,more manageable pieces. A multilayer approach combines Layer 2 switching with Layer 3switching to achieve robust, highly available campus networks.
Campus Access Layer
The campus access layer is where the user-facing devices connect to the LAN (wiringcloset switches) and leverage network services. Typically, at the user access layer, Layer 2is maintained because it can limit broadcast domains within VLANs. More importantly,it has voice and data endpoints that connect to the same switch ports. The access layer isalso known as the network edge. A number of feature sets can be used at this layerto implement network policies around areas such as security, high availability, QoS, andso on.
Campus Distribution Layer
The campus LAN distribution layer consists of the section of the network from the wir-ing closet switches to the next-hop switch. It’s the focal point at which network policiesare created and enforced. This layer is responsible for aggregating incoming user trafficfrom wiring closet access switches and then aggregating it to the core. At the distributionlayer, it is important to provide redundancy to ensure high availability, including redun-dant links between the distribution layer switches and redundant links to access layerswitches. Various first-hop redundancy mechanisms are available, including Hot StandbyRouter Protocol (HSRP), Gateway Load Balancing Protocol (GLBP), and Virtual RouterRedundancy Protocol (VRRP).
Campus Core Layer
The campus core layer serves as the backbone of the entire network infrastructure of acampus, where all the traffic from the distribution layer aggregates. It is at this layer thatingress and egress of traffic in a network occurs. The core layer provides high-speedtransport and interconnectivity of various building blocks within the campus. The corelayer is usually made up of high-speed links that can aggregate all the traffic from pointsin the distribution layer. It is again vital to provide redundancy to ensure high availability.This can be achieved by redundant link or cable paths, redundant devices, and redun-dant subsystems (such as Catalyst Supervisor Engine modules). Cisco Catalyst switches
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
38/315
IP Routing in Cisco Collaboration Campus Environments 19
with Virtual Switching System (VSS) can be used to aggregate two Catalyst SupervisorEngines to act as one.
Campus Routed Access Layer Design
As previously mentioned, Cisco-recommended CDA architecture should be followedwhile designing a campus network. There are two options for access layer design perti-nent to campus network design, as shown in Figure 1-7:
■ Traditional Cisco campus design: Traditional design with Layer 2 at the access layerand Layer 3 at the distribution and core layers
■ Routed access campus design: Modification of the traditional design to extendLayer 3 to the access layer
Layer 3
Core
Distribution
Access
Layer 2
Layer 3
R o u t e d A c c e s s C am
p u sD e si gn
T r a d i t i o n a l C i s c o C a m p u s D e s i g n
Layer 2
Figure 1-7 Traditional Cisco Campus Design Versus Routed Access Campus Design
Compared to the traditional Cisco campus design, the routed access campus design(combining Layer 3 switching at the access and distribution layers) provides the fast-est convergence of voice and data traffic flows. Other advantages over the traditionalapproach include a single control plane, dynamic traffic load balancing, and use of asingle set of tools for troubleshooting.
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
39/315
20 Chapter 1: Cisco Collaboration Infrastructure
The following best practice recommendations apply to the L2/L3 campus networkdesign:
■ The infrastructure topology should adhere to the Cisco-recommended campus CDAdesign approach.
■ Use Layer 3 links beginning with the access layer connecting to the distribution andcore layers for maximum redundancy and fastest convergence time in case of link ordevice failure.
■ The access layer switches should have dual connectivity to distribution switches andsupport the required QoS features.
■ VLANs should not span multiple switches.
■ All Cisco Collaboration device switch ports (e.g., IP phones) should be put inspanning-tree PortFast so that they can move to a fully operational state as fast aspossible.
■ Spanning tree should be limited to access switches, and Layer 3 links should be usedbetween access, distribution, and core switches.
IPv6 in Cisco Collaboration Networks
An IPv6 address contains 128 bits, compared to 32 bits for an IPv4 address. This gives
IPv6 a much larger address space, to the order of 2^128 = 3.4 × 10^38 addresses, com-pared to the IPv4 address space of 2^32 = 4.3 billion addresses.
IPv6 addresses are represented as a series of eight 16-bit fields of (hexadecimal) char-acters and numbers separated by colons. The format used is X:X:X:X:X:X:X:X. Anexample of an IPv6 address is fe80:0:0:0:0:0:a0a:64c8, which is equivalent to IPv4 address10.10.100.200. The IPv6 address fe80:0:0:0:0:0:a0a:64c8 can be shortened by followingsome simple rules:
■ Two colons (::) can be used to compress successive hexadecimal fields of 0s at thebeginning, middle, or end of an IPv6 address. However, this can be done only once
in an address; that is, one instance of :: is allowed per address.
■ The leading 0s in a field are optional.
Following these rules, IPv6 address fe80:0:0:0:0:0:a0a:64c8 can be shortened tofe80::a0a:64c8.
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
40/315
IPv6 in Cisco Collaboration Networks 21
IPv6 Address Types
IPv6 supports the following address types:
■ Unicast: Synonymous to IPv4, an IPv6 unicast address entails sending of messagesto a single network destination identified by a unique address.
■ Anycast: An IPv6 anycast address is an address that is assigned to a set of interfacesthat typically belong to different nodes. A packet sent to an anycast address is deliv-ered to the closest interface, as defined by the routing protocols.
■ Multicast: Similar to IPv4, IPv6 multicast allows a host to send a single data streamto a subset of all hosts simultaneously.
IPv6 Addressing ModelFigure 1-8 depicts the IPv6 addressing model.
Link-local Unique-local Global
Figure 1-8 IPv6 Addressing Model
An IPv6 addressing model pertinent to a Cisco Collaboration network can be defined asfollows:
■ Link-local address: An IPv6 unicast address that can be automatically or manuallyconfigured on an IPv6 interface. Link-local addresses are used exclusively for com-munication between two IPv6 devices on the same link (as well as for Neighbor
Discovery Protocol and stateless auto-configuration process); that is, with localroutability scope. On automatic configuration, the address uses the link-local prefixFE80::/10 (1111 111010) and interface ID.
■ Unique-local address: IPv6 unicast address that uses the prefix FEC0::/10 (1111111011) and concatenates the subnet identifier (the 16-bit field) with the interfaceidentifier. Unique-local addresses are analogous to RFC 1918 private addresses inIPv4 and are not advertised beyond the local site. They are used for local communi-cations, inter-site VPNs, and so forth. Subnet IDs are typically defined using a hierar-chical addressing plan to allow for route summarization.
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
41/315
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 toallow address aggregation. Global addresses are identified by their three high-level
bits set to 001 (2000::/3). These are the unique addresses assigned by service provid-ers or regional registries for participation in the public network.
In context of IPv6, CUCM supports one link-local address, one unique-local address or aglobal address, and an IPv4 address.
Cisco Unified IP Phones can support one link-local address, multiple unique-localaddresses, multiple global addresses, and an IPv4 address. If the phone has both unique-local and global addresses, the global addresses take precedence over unique-localaddresses. If multiple unique-local addresses or multiple global addresses exist, the firstaddress configured is used as the signaling and media address sent to CUCM. Cisco
Unified IP Phones use one IPv6 address (global or unique-local) for CUCM signaling andmedia.
When configured for receiving an IPv6 address, Cisco Unified IP Phone IPv6 addressselection priority is as follows:
1. If configured, use the address that has been manually configured via the IPPhone’s UI.
2. If an address has not been manually configured, use DHCPv6 to assign an address.
3. If neither a DHCPv6 address nor a manually configured address is available, and
Stateless Address Autoconfiguration (SLAAC, RFC 2462) is enabled for the IP Phone(CUCM default is on), the IP Phone uses SLAAC to create an IPv6 address. Therouter RA “O” bit should be set.
Cisco IOS devices support one link-local address, multiple unique-local addresses, mul-tiple global addresses, and multiple IPv4 addresses. Cisco IOS routers use link-localaddresses for routing protocols and use the address selection algorithm (RFC 3484) forapplications running on routers—for example, Telnet, Secure Shell (SSH), and so on. Forresponses to devices, routers attempt to use the same network prefix as the device that isinitiating communication.
To allow IPv6-based call processing, IPv6 must first be enabled throughout a CUCMcluster. This involves the following steps:
Step 1. Configure IPv6 via the Cisco Unified CM Administration page by choosingSystem > Server Configuration . IPv6 must be configured via the OS CLI orCisco Unified Operating System page on each server in the cluster.
Step 2. Enable IPv6 cluster-wide via the Cisco Unified CM Administration page bychoosing System > Enterprise Parameters ; and setting Enable IPv6 to True,set IP Addressing Mode Preference for Media to IPv6, IP Addressing ModePreference for Signaling to IPv6, and Allow Auto-Configuration for Phones(SLAAC) to On.
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
42/315
Virtualization in Cisco Collaboration Solutions 23
Step 3. Configure Common Device Configuration for IP Phone Profile and SIPTrunks to enable IPv4 and IPv6 addressing mode, Signaling Preference, andPhone Auto Configuration settings. Device setting takes precedence over
global settings.
The following are IPv6 deployment guidelines for Cisco Collaboration infrastructure:
■ LAN and WAN environments must be considered when deploying IPv6, as mostapplications and infrastructure components may be configured for or support IPv4.
■ Dual-stack deployments offer the best approach when introducing IPv6 into anynetwork environment, as both IPv4 devices and dual-stack IPv4/v6 devices can inter-operate. Disruption to the existing network is minimal.
Virtualization in Cisco Collaboration Solutions
Cisco Unified Computing System (Cisco UCS) combined with VMware vSphere providesvirtualization for Cisco UC applications. Virtualizing UC applications has many benefits,such as
■ Infrastructure can be simplified and consolidated using virtualized computing plat-forms to reduce server count, network ports, cabling, and power consumption.
■ Cisco UC applications can be deployed and scaled rapidly on a virtualized platform
compared to Media Convergence Server (MCS)-based installations.■ A virtual environment supports simplified upgrade and migration, thereby providing
elasticity in deployment and service enablement.
Cisco offers many virtualization solutions for Cisco Collaboration environments, rangingfrom desktop to data center. Some of the virtual solutions for Cisco Collaboration arelisted in Table 1-3.
Table 1-3 Cisco Collaboration Virtual Solutions
Virtual Solution Description
Cisco UCS Blade server for bare metal or hypervisor-based installation indata centers.
Cisco VirtualizationExperience Infrastructure(VXI)
Delivers integrated Unified Communications platform, is deviceagnostic, and delivers enterprise voice, video, mobility, presence,and session management with security.
Cisco VirtualizationExperience Media Engine(VXME)
Enables Jabber to run in virtualized environments. This is a sub-component of Cisco VXI.
Cisco VirtualizationExperience Client (VXC)
A thin client designed to easily integrate into a virtualized infra-structure. This is a subcomponent of the Cisco VXI solution.
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
43/315
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 DesktopInfrastructure (VDI)
Solution to deliver virtualized desktops and applications bymeans of simplicity, scalability, and superior user experience.Cisco VDI solutions are built on Cisco Unified Data Centerarchitectures. The Cisco VDI solution is available as a Citrix orVMware workload.
Cisco UCS Servers
Cisco UCS servers are an x86-based architecture data center server platform encompass-
ing computing, virtualization, switching fabric, and management software.
The computing component of Cisco UCS is available in two versions:
■ B-Series: Modular packages consisting of a chassis and half-width or full-widthblades. B-Series servers require a storage area network (SAN) for application datastorage.
■ C-Series: Rack-mount servers with built-in direct-attached storage (DAS).Compute hardware is managed by the UCS Manager software running on FabricInterconnects (FI).
UCS Manager can be used to manage both B-Series and C-Series servers. Integrationbetween VMware vCenter and Cisco UCS Manager provides unparalleled control overphysical and virtual assets.
For virtualization, Cisco UCS supports hypervisors, including VMware ESXi and CitrixXenServer. Cisco UCS interacts with Fabric Extenders or Fabric Interconnects to commu-nicate with other data center infrastructure, including SAN switches, storage, and CiscoNexus. Cisco UCS supports Fibre Channel over Ethernet (FCoE). Figure 1-9 depicts aCisco UCS–based virtualized UC application and network architecture.
Cisco UCS leverages the concept of service profiles for statelessness. This allows for anydamaged hardware (blade) to be changed without affecting the virtual machines (VM)running on it. The VMs can be moved to another blade by disassociating the service pro-file from a nonfunctional blade to a functional one.
Cisco UC application configuration templates are available in Open VirtualizationArchive (OVA) format, which allows administrators to build and configure UC applica-tions. For most supported UC applications, preconfigured OVA templates are availableon Cisco.com. If an OVA template is not available for an application, the administratormust manually build OVA files that meet the indicated requirements. Cisco has stringent
requirements for co-residency of UC applications with non-Cisco or non-UC applications.The Cisco-recommended guidelines for co-residency can be found at http://docwiki.cisco.com/wiki/Unified_Communications_Virtualization_Sizing_Guidelines.
From the Library of Juan Arcaya
http://docwiki.cisco.com/wiki/Unified_Communications_Virtualization_Sizing_Guidelineshttp://docwiki.cisco.com/wiki/Unified_Communications_Virtualization_Sizing_Guidelineshttp://docwiki.cisco.com/wiki/Unified_Communications_Virtualization_Sizing_Guidelineshttp://docwiki.cisco.com/wiki/Unified_Communications_Virtualization_Sizing_Guidelines
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
44/315
Virtualization in Cisco Collaboration Solutions 25
Moreover, Cisco supports UC on UCS deployments in three support models:
■ UC on UCS Tested Reference Configuration (TRC): Tested and approved by Cisco
UC and UCS BUs/teams■ UC on UCS Specs-based: Generic server hardware validation by UCS BU/team
■ Third-party Server Specs-based: No hardware validation by UCS BU/team
While virtual machine (OVA) definitions, VMware product, version, and feature support,VMware configuration requirements for UC, and application/VM co-residency policyremain consistent across all three support models, there are a few things to consider whengoing with one model or another. For example, a TRC model is configuration based,whereas UCS Specs-based and Third-party Server Specs-based models are rules based.
For details and updated information, refer to http://docwiki.cisco.com/wiki/UC_Virtualization_Supported_Hardware.
UC Applications(Guest Virtual Machines)
VMwareHypervisor
B-Series Blade
6200 Series FabricInterconnect
Fibre Channel overEthernet (FCoE)
Ethernet
LAN Switch Nexus 5000Series Switch
SAN Switch(MDS 9000 Series)
Fibre Channel
Storage Array
V
Cisco UCS 5100 SeriesChassis
Figure 1-9 Cisco UCS–based UC Application and Network Virtualization Architecture
From the Library of Juan Arcaya
http://docwiki.cisco.com/wiki/UC_Virtualization_Supported_Hardwarehttp://docwiki.cisco.com/wiki/UC_Virtualization_Supported_Hardwarehttp://docwiki.cisco.com/wiki/UC_Virtualization_Supported_Hardwarehttp://docwiki.cisco.com/wiki/UC_Virtualization_Supported_Hardware
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
45/315
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. VMwarevSphere (ESXi) is the hypervisor that sits between the hardware abstraction layer and the
guest OS. VMware ESXi runs directly on the UCS B-Series or C-Series server hardwarewithout the need for any additional software in bare-metal mode. It provides the neces-sary hypervisor functions to host several guest OSs, such as Windows and Linux, on thephysical server.
UC Application Install Answer File
While installing UC applications on a physical or virtual platform, answer files can bevery helpful because they save time and prevent typological or omission errors. UCapplications can be installed on UCS using the platformConfig.xml file where the virtualmachine requires the use of a virtual floppy drive.
To install a Cisco Unified Communications application such as CUCM, Cisco UnityConnection, Cisco Presence, and so on, using the answer files generated by Cisco UnifiedCommunications Answer File Generator ( http://www.cisco.com/web/cuc_afg/index.html)is recommended. This web application also generates the virtual License MAC addressthat is used for obtaining the license.
The answer file generator has the following areas to complete in the ClusterwideConfiguration section:
■ Hardware: Physical Server or Virtual Machine
■ Product: CUCM, Cisco Unity Connection, Cisco Unified Presence, and so on
■ Administrator Credentials: OS Administrator username and password
■ Security Password: Cluster security password
■ Application User Credentials: Administrator GUI username and password
■ Certificate Information: Organization, Unit, Location, State, and Country
■ SMTP: SMTP Location
The answer file generator also has the following areas to complete in the Primary NodeConfiguration and Secondary Node Configuration sections:
■ NIC Interface Settings: Use Auto Negotiation, NIC Speed, NIC Duplex, MTU Size
■ Network Information: Use DHCP for IP Address Resolution, Host Name, IPAddress, IP Mask, Gateway Address
■ DNS: Configure Client DNS, Primary DNS, Secondary DNS, Domain
■ Time Zone: Region, Time Zone
■ Network Time Protocol: NTP Server(s) information (only for primary node)
From the Library of Juan Arcaya
http://www.cisco.com/web/cuc_afg/index.htmlhttp://www.cisco.com/web/cuc_afg/index.htmlhttp://www.cisco.com/web/cuc_afg/index.html
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
46/315
IP Multicast 27
After the platformConfig.xml file is generated, you can use it to install primary and sec-ondary nodes in a UC application cluster by following these steps:
Step 1. Create a virtual floppy image using a virtual floppy program (for example,
WinImage or RawWrite).
Step 2. Insert the platformConfig.xml file into the virtual floppy image and save theresulting image with a .vmd or .flp extension.
Step 3. Upload the virtual floppy image to a datastore accessible from VSphere. ForSAN storage, go to View > Inventory > Datastores . For local storage (such asan internal hard drive), select the host and click the Summary tab. Browse thedatastore and upload the virtual floppy image to it.
Step 4. From the VSphere client, go to Inventory > Virtual Machine > Edit Settings .
In the dialog box that opens, select Floppy Drive on the Hardware tab. Clickthe Use Existing Floppy Image in Datastore radio button, click Browse ,browse to and choose the virtual floppy image, and click OK .
Step 5. In the Device Status area of the Hardware tab, check the Connected andConnect at Power On check boxes. Click OK in the lower-right corner.
Step 6. Proceed with installation of the UC application using the ISO file from thedatastore.
Step 7. In the Platform Installation Wizard window, choose Skip to configure theplatform later using the auto-answer file from the mounted virtual floppyimage.
Step 8. After the system restarts, the Preexisting Installation Configuration windowdisplays and the install process automatically reads the configuration informa-tion file copied onto the virtual floppy image mounted on the UCS.
IP Multicast
IP multicast can be used for various functions in a Cisco Collaboration network. Themost common services that leverage IPv4 or IPv6 multicast are
■ Multicast Music on Hold (MoH) for branch sites. (Cisco Unified IP Phones supportonly IPv4 multicast MoH. IPv6 multicast MoH is not supported.)
■ AutoDiscovery of Gatekeeper (GRQ) messages.
■ DHCPv6 discovery by IPv6-compatible endpoints.
■ Cisco SAF forwarder automatic discovery and communication with other SAFforwarders.
To allow the use of multicast for all the preceding services, the underlying network infra-structure must support the forwarding of multicast IP traffic from the CUCM servers or
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
47/315
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 Management Protocol (IGMP)
■ Protocol Independent Multicast Sparse Mode (PIM-SM)
■ Protocol Independent Multicast Dense Mode (PIM-DM)
■ Cisco Group Management Protocol (CGMP)
Protocols commonly used to enable multicast in an interdomain environment include thefollowing:
■ Multicast Source Discovery Protocol (MSDP)
■ PIM Source-Specific Multicast (PIM-SSM)
IPv6 multicast is based on the same basic principles as IPv4 multicast. The major differ-ences being that IPv6 relies on multicast for more functions, such as neighbor discoveryand node autoconfiguration. Moreover, Mobile IPv6 relies heavily on IPv6 multicast fortheir operations. IGMP is replaced by Multicast Listener Discovery (MLD) in IPv6.
Wireless in Cisco Collaboration Solutions Today’s dynamic environments and organizations demand more than just regular wiredIP Phones—they demand mobility. Wi-Fi is an important aspect because being mobileyet connected within an enterprise is paramount in today’s connected world. Cisco offerson-campus mobility using Voice over Wireless LAN (VoWLAN) with Cisco UnifiedWireless IP Phone 7925G. From an infrastructure perspective, Cisco offers two wirelessnetwork infrastructure solutions: Cisco Unified Wireless LAN Controller (WLC) andCisco Autonomous Access Points (AP). A VoWLAN architecture encompasses multiplecomponents, as shown in Figure 1-10.
Cisco VoWLAN solution has many components, including the following:
■ Cisco WLC
■ Lightweight access points
■ Directory server (LDAP) for endpoint authentication
■ Wi-Fi endpoints, including PCs or laptops with Jabber
■ Wi-Fi–capable Cisco Unified IP Phones
The interaction between endpoints and wireless APs is where Wi-Fi primarily comes intoplay; the rest is an augmentation to existing wired infrastructure.
From the Library of Juan Arcaya
-
8/21/2019 CCIE COLLABORATION QUICK REFERENCE cisco press.pdf
48/315
Wireless in Cisco Collaboration Solutions 29
For a successful VoWLAN solution deployment, certain conditions must be met. Theyare as follows:
■ Noise levels should not exceed —92 dBm with a signal-to-noise ratio (SNR) of25 dB.
■ Signal strength should be −67 dBm.
■ Minimum 20 to 30 percent overlap of adjacent access points with nonoverlappingchannels must be considered during site survey.
■ Packet error rate (PER) should not exceed 1 percent and Jitter should be less than100 ms.
■ To avoid one-way audio issues resulting from different power settings between Wi-FiIP phones and access points, World mode (IEEE 802.11d) should be configured.
■ Traffic Specification (TSPEC) must be enabled for CAC on APs.
■ QoS for voice VLAN must be enabled on Cisco WLC and APs such that the mark-ings match those on wired infrastructure. IEEE 802.11e UP markings should bematched to Voice, Video, and Signaling DSCP markings (Voice EF = 6, Video AF41= 5, and Signaling AF31 = 4).
■ Channel utilization levels should be kept below 50 percent.
■ Cisco Compatible Extensions (CCX) should be enabled on wireless infrastructure
where possible