Designing Cisco Network Service Architectures

ARCH
Designing Cisco Network
Service Architectures
Volume 2
Version 2.0
Student Guide
05.08.07
DISCLAIMER WARRANTY: THIS CONTENT IS BEING PROVIDED “AS IS.” CISCO MAKES AND YOU RECEIVE NO WARRANTIES IN
CONNECTION WITH THE CONTENT PROVIDED HEREUNDER, EXPRESS, IMPLIED, STATUTORY OR IN ANY OTHER PROVISION OF
THIS CONTENT OR COMMUNICATION BETWEEN CISCO AND YOU. CISCO SPECIFICALLY DISCLAIMS ALL IMPLIED
WARRANTIES, INCLUDING WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT AND FITNESS FOR A PARTICULAR
PURPOSE, OR ARISING FROM A COURSE OF DEALING, USAGE OR TRADE PRACTICE. This learning product may contain early release
content, and while Cisco believes it to be accurate, it falls subject to the disclaimer above.
Table of Contents
Volume 2
E-Commerce Module Design......................................................................................... 7-1
Overview ............................................................................................................................................ 7-1
Module Objectives....................................................................................................................... 7-1
High Availability for E-Commerce
7-3
Overview ............................................................................................................................................ 7-3
Objectives.................................................................................................................................... 7-3
E-Commerce Module Overview......................................................................................................... 7-4
Components of High Availability........................................................................................................ 7-5
Redundancy ................................................................................................................................ 7-7
Technology.................................................................................................................................. 7-8
People ......................................................................................................................................... 7-9
Processes.................................................................................................................................. 7-11
Tools.......................................................................................................................................... 7-13
Summary.......................................................................................................................................... 7-14
Common Component Designs for the E-Commerce Module
7-15
Overview .......................................................................................................................................... 7-15
Objectives.................................................................................................................................. 7-15
Common Firewall Designs for E-Commerce ................................................................................... 7-16
Typical E-Commerce Topology................................................................................................. 7-16
Server as Application Gateway ................................................................................................. 7-17
Virtualization with Firewall Contexts ......................................................................................... 7-18
Virtual Firewall Layers............................................................................................................... 7-19
Firewall Modes .......................................................................................................................... 7-20
Common Server Load Balancer Designs for E-Commerce ........................................................... 7-22
Functions of a Server Load Balancer........................................................................................ 7-22
Cisco Server Load Balancing Products .................................................................................... 7-23
SLB Design Models................................................................................................................... 7-25
SLB Router Mode...................................................................................................................... 7-26
SLB Inline Bridge Mode ............................................................................................................ 7-27
SLB One-Arm Mode Overview.................................................................................................. 7-28
Common Topology Designs for E-Commerce................................................................................. 7-31
Design Option: One Firewall Per ISP........................................................................................ 7-31
Design Option: Stateful Failover with Common External Prefix................................................ 7-32
Design Option: Distributed Data Centers.................................................................................. 7-33
Summary.......................................................................................................................................... 7-35
Integrated E-Commerce Designs
7-37
Overview .......................................................................................................................................... 7-37
Objectives.................................................................................................................................. 7-37
Base E-Commerce Module Design ................................................................................................. 7-38
Base Design Routing Logic....................................................................................................... 7-39
Base Design Server Traffic Flows............................................................................................. 7-40
Two Firewall Layers Design ............................................................................................................ 7-41
Two Firewall Layers Design Traffic Flows ................................................................................ 7-42
“One-Armed” Design with Two Firewall Layers............................................................................... 7-43
“One-Armed” Design with Two Firewall Layers Traffic Flows................................................... 7-44
“One-Armed” Design with Direct Server Traffic Flows.............................................................. 7-45
“One-Armed” SLB Design with Firewall Contexts ........................................................................... 7-46
“One-Armed” SLB Design with Firewall Contexts Traffic Flows ............................................... 7-47
“One-Armed” SLB Design with CSS ......................................................................................... 7-48
Testing E-Commerce Designs......................................................................................................... 7-49
Summary.......................................................................................................................................... 7-51
Tuning for E-Commerce
7-53
Overview.......................................................................................................................................... 7-53
Objectives ................................................................................................................................. 7-53
E-Commerce Tuning Overview ....................................................................................................... 7-54
BGP Tuning ..................................................................................................................................... 7-55
Enhanced Object Tracking .............................................................................................................. 7-56
Example: HSRP and IP SLA Tracking ...................................................................................... 7-57
Example: Injecting Routes and IP SLA ..................................................................................... 7-58
Optimized Edge Routing Overview ................................................................................................. 7-59
OER Operations........................................................................................................................ 7-60
OER Solution Topologies.......................................................................................................... 7-62
Cisco Global Server Load Balancing............................................................................................... 7-63
Summary ......................................................................................................................................... 7-64
Module Summary ............................................................................................................................ 7-65
References................................................................................................................................ 7-65
Module Self-Check .......................................................................................................................... 7-67
Module Self-Check Answer Key ............................................................................................... 7-71
Security Services Design...............................................................................................8-1
Overview............................................................................................................................................ 8-1
Module Objectives....................................................................................................................... 8-1
Firewall Design Considerations
8-3
Overview............................................................................................................................................ 8-3
Lesson Objectives....................................................................................................................... 8-3
Firewall Modes .................................................................................................................................. 8-4
Virtual Firewall Overview ................................................................................................................... 8-6
Firewall Context Design Considerations..................................................................................... 8-7
MSFC Placement ........................................................................................................................ 8-8
Active/Active Firewall Topology......................................................................................................... 8-9
Active/Active Topology Features .............................................................................................. 8-10
Asymmetric Routing with Firewalls.................................................................................................. 8-11
Asymmetric Routing with ASR Group on a Single FWSM........................................................ 8-12
Asymmetric Routing with Active/Active Topology..................................................................... 8-13
Performance Scaling with Multiple FWSMs .................................................................................... 8-14
Example: Load Balancing FWSMs Using Policy-Based Routing ............................................. 8-14
Example: Load Balancing FWSMs Using ECMP Routing ........................................................ 8-15
Private VLAN Security ..................................................................................................................... 8-16
PVLAN Review.......................................................................................................................... 8-16
FWSM in PVLAN Environment - Isolated Ports........................................................................ 8-18
FWSM in PVLAN Environment - Community VLANs ............................................................... 8-19
Zone-Based Policy Firewall ............................................................................................................. 8-20
Summary ......................................................................................................................................... 8-22
Network Admission Control Design
8-23
Overview.......................................................................................................................................... 8-23
Lesson Objectives..................................................................................................................... 8-23
Network Security with Access Control............................................................................................. 8-24
Network Admission Control Comparison .................................................................................. 8-25
NAC Appliance Fundamentals ........................................................................................................ 8-26
NAC Appliance Components .................................................................................................... 8-26
NAS Scaling .............................................................................................................................. 8-29
NAS Deployment Options................................................................................................................ 8-31
NAS Gateway Modes................................................................................................................ 8-32
NAS Operating Modes .............................................................................................................. 8-33
NAS Client Access Modes ........................................................................................................ 8-34
Physical Deployment Models.................................................................................................... 8-35
NAC Appliance Designs .................................................................................................................. 8-36
Layer 2 In-Band Designs .......................................................................................................... 8-37
Layer 2 Out-of-Band Designs ................................................................................................... 8-40
ii
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Layer 3 In-Band Designs........................................................................................................... 8-42
Layer 3 Out-of-Band Designs.................................................................................................... 8-45
NAC Framework Overview .............................................................................................................. 8-47
Router Platform Support for NAC Framework .......................................................................... 8-49
Switch Platform Support for NAC Framework........................................................................... 8-51
Cisco Client Security Software ........................................................................................................ 8-52
Summary.......................................................................................................................................... 8-54
Intrusion Detection and Prevention Designs
8-55
Overview .......................................................................................................................................... 8-55
Lesson Objectives..................................................................................................................... 8-55
IDS/IPS Overview ............................................................................................................................ 8-56
IPS/IDS Design Considerations ................................................................................................ 8-60
IDS/IPS Deployments ...................................................................................................................... 8-61
IPS Appliance Deployment Options .......................................................................................... 8-62
IPS Deployment Challenges ..................................................................................................... 8-64
IDS/IPS Management Interface Deployment Options .............................................................. 8-65
IDS/IPS Monitoring and Management ............................................................................................. 8-67
Scaling CS-MARS with Global Controller Deployment............................................................. 8-69
Summary.......................................................................................................................................... 8-70
Module Summary............................................................................................................................. 8-71
References ................................................................................................................................ 8-72
Module Self-Check .......................................................................................................................... 8-75
Module Self-Check Answer Key ............................................................................................... 8-79
IPsec and SSL VPN Design ........................................................................................... 9-1
Overview ............................................................................................................................................ 9-1
Module Objectives....................................................................................................................... 9-1
Remote Access VPN Design
9-3
Overview ............................................................................................................................................ 9-3
Objectives.................................................................................................................................... 9-3
Remote Access VPN Overview ......................................................................................................... 9-4
Example: Easy VPN Client IPsec Implementation...................................................................... 9-5
SSL VPNs .......................................................................................................................................... 9-6
Clientless Access ........................................................................................................................ 9-8
Thin Client ................................................................................................................................... 9-9
Thick Client................................................................................................................................ 9-10
Remote Access VPN Design Considerations.................................................................................. 9-11
VPN Termination Device and Firewall Placement .................................................................... 9-11
Routing Design Considerations ................................................................................................ 9-12
Address Assignment Design Considerations............................................................................ 9-13
Other Design Considerations .................................................................................................... 9-14
Example: VPN Architecture....................................................................................................... 9-15
Summary.......................................................................................................................................... 9-16
Site-to-Site VPN Design
9-17
Overview .......................................................................................................................................... 9-17
Objectives.................................................................................................................................. 9-17
Site-to-Site VPN Applications .......................................................................................................... 9-18
WAN Replacement Using Site-to-Site IPsec VPNs .................................................................. 9-18
WAN Backup Using Site-to-Site IPsec VPNs ........................................................................... 9-19
Regulatory Encryption Using Site-to-Site IPsec VPNs ............................................................. 9-20
Site-to-Site VPN Design Considerations ......................................................................................... 9-21
IP Addressing and Routing ....................................................................................................... 9-21
Scaling, Sizing, and Performance ............................................................................................. 9-22
Design Topologies .................................................................................................................... 9-27
VPN Device Placement Designs............................................................................................... 9-28
Summary.......................................................................................................................................... 9-31
© 2007 Cisco Systems, Inc.
Designing Cisco Network Service Architectures (ARCH) v2.0
iii
IPsec VPN Technologies
9-33
Overview.......................................................................................................................................... 9-33
Objectives ................................................................................................................................. 9-33
IPSec VPN Overeview..................................................................................................................... 9-34
Extensions to Standard IPsec VPNs ........................................................................................ 9-35
Cisco Easy VPN .............................................................................................................................. 9-36
Overview of Easy VPN Server Wizard on SDM........................................................................ 9-37
Overview of Easy VPN Remote Wizard on SDM...................................................................... 9-38
GRE over IPsec ............................................................................................................................... 9-39
GRE over IPsec Design Recommendations............................................................................. 9-40
DMVPN............................................................................................................................................ 9-42
DMVPN Overview ..................................................................................................................... 9-43
Example: DMVPN Topology ..................................................................................................... 9-44
DMVPN Design Recommendations.......................................................................................... 9-45
VTI Overview ................................................................................................................................... 9-46
GET VPN ......................................................................................................................................... 9-48
GET VPN Topology................................................................................................................... 9-49
Summary ......................................................................................................................................... 9-50
VPN Management and Scaling
9-51
Overview.......................................................................................................................................... 9-51
Objectives ................................................................................................................................. 9-51
Recommendations for Managing VPNs .......................................................................................... 9-52
Cisco Security Management Suite for VPNs ............................................................................ 9-52
Recommendations for Managing VPNs.................................................................................... 9-54
Considerations for Scaling VPNs .................................................................................................... 9-55
Determining PPS....................................................................................................................... 9-56
Determining the PPS Rate........................................................................................................ 9-61
Routing Protocol Considerations for IPsec VPNs..................................................................... 9-63
Summary ......................................................................................................................................... 9-65
Module Summary ............................................................................................................................ 9-67
References................................................................................................................................ 9-67
Module Self-Check .......................................................................................................................... 9-69
Module Self-Check Answer Key ............................................................................................... 9-74
IP Multicast Design....................................................................................................... 10-1
Overview.......................................................................................................................................... 10-1
Module Objectives..................................................................................................................... 10-1
IP Multicast Review
10-3
Overview.......................................................................................................................................... 10-3
Objectives ................................................................................................................................. 10-3
Overview of IP Multicast .................................................................................................................. 10-4
Unicast vs. Multicast ................................................................................................................. 10-4
TCP Contrasted to UDP............................................................................................................ 10-5
Multicast Adoption Trends ........................................................................................................ 10-7
Cisco Multicast Architecture...................................................................................................... 10-8
IP Multicast Group Membership ...................................................................................................... 10-9
Multicast Group Address Range ............................................................................................. 10-10
IP Multicast MAC Address Mapping ....................................................................................... 10-11
Multicast Address Assignment................................................................................................ 10-13
IGMP ....................................................................................................................................... 10-14
Multicast Routing ........................................................................................................................... 10-15
Multicast Distribution Tree Creation........................................................................................ 10-16
RPF Overview ......................................................................................................................... 10-17
Multicast Distribution Trees..................................................................................................... 10-18
Multicast Forwarding at Layer 2 .................................................................................................... 10-20
IGMP Snooping....................................................................................................................... 10-21
Summary ....................................................................................................................................... 10-22
iv
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
PIM and RP Considerations
10-23
Overview ........................................................................................................................................ 10-23
Objectives................................................................................................................................ 10-23
PIM Deployment Models................................................................................................................ 10-24
Any-Source Multicast .............................................................................................................. 10-25
Bidirectional PIM ..................................................................................................................... 10-28
Source Specific Multicast ........................................................................................................ 10-30
RP Considerations......................................................................................................................... 10-33
Anycast RP.............................................................................................................................. 10-33
Static RP Addressing .............................................................................................................. 10-34
Auto-RP................................................................................................................................... 10-35
BSR ......................................................................................................................................... 10-39
Summary........................................................................................................................................ 10-41
IP Multicast Security
10-43
Overview ........................................................................................................................................ 10-43
Objectives................................................................................................................................ 10-43
Security Considerations for IP Multicast........................................................................................ 10-44
Unicast and Multicast State Requirements ............................................................................. 10-46
Multicast State and Replication............................................................................................... 10-47
Attack Traffic in Multicast Networks ........................................................................................ 10-49
Scoped Addresses .................................................................................................................. 10-52
Multicast Access Control ............................................................................................................... 10-53
Host Receiver Side Access Control ........................................................................................ 10-54
PIM-SM Source Control .......................................................................................................... 10-55
Disabling Multicast Groups ..................................................................................................... 10-56
Summary........................................................................................................................................ 10-57
Module Summary........................................................................................................................... 10-59
References .............................................................................................................................. 10-59
Module Self-Check ........................................................................................................................ 10-61
Module Self-Check Answer Key ............................................................................................. 10-65
Voice Over WLAN Design............................................................................................ 11-1
Overview .......................................................................................................................................... 11-1
Module Objectives..................................................................................................................... 11-1
VoWLAN in the Enterprise
11-3
Overview .......................................................................................................................................... 11-3
Objectives.................................................................................................................................. 11-3
VoWLAN Drivers.............................................................................................................................. 11-4
Cisco Unified Wireless Network Review ................................................................................... 11-4
VoWLAN Drivers in the Enterprise............................................................................................ 11-6
Voice-Ready Architecture ................................................................................................................ 11-8
Cisco Voice-Ready Architecture ............................................................................................... 11-9
Voice Impact on WLANs ......................................................................................................... 11-10
Summary........................................................................................................................................ 11-11
VoWLAN Coverage and RF Survey
11-13
Overview ........................................................................................................................................ 11-13
Objectives................................................................................................................................ 11-13
Enterprise VoWLAN Coverage Considerations............................................................................. 11-14
Signal-to-Noise Ratio .............................................................................................................. 11-16
Non-Overlapping Channels..................................................................................................... 11-19
General Recommendations for VoWLANs ............................................................................. 11-25
VoWLAN Site Survey..................................................................................................................... 11-28
Cisco WCS Deployment Planning Tool .................................................................................. 11-30
Access Point Location............................................................................................................. 11-31
Conducting the RF Survey for VoWLAN................................................................................. 11-34
Summary........................................................................................................................................ 11-38
© 2007 Cisco Systems, Inc.
Designing Cisco Network Service Architectures (ARCH) v2.0
v
VoWLAN Infrastructure Considerations
11-39
Overview........................................................................................................................................ 11-39
Objectives ............................................................................................................................... 11-39
Voice Specific Infrastructure Considerations ................................................................................ 11-40
Roaming ........................................................................................................................................ 11-41
Layer 2 Intercontroller Roaming.............................................................................................. 11-43
Layer 3 Intercontroller Roaming.............................................................................................. 11-44
Enhanced Neighbor Lists........................................................................................................ 11-46
QoS Considerations ...................................................................................................................... 11-47
IEEE 802.11e and Wi-Fi Multimedia ....................................................................................... 11-48
Call Admission Control............................................................................................................ 11-50
Security Considerations................................................................................................................. 11-51
VoWLAN Authentication and Encryption Recommendations ................................................. 11-51
Other Design Recommendations for VoWLAN Security ........................................................ 11-53
VoWLAN Clients............................................................................................................................ 11-55
Summary ....................................................................................................................................... 11-58
Module Summary .......................................................................................................................... 11-59
References.............................................................................................................................. 11-59
Module Self-Check ........................................................................................................................ 11-61
Module Self-Check Answer Key ............................................................................................. 11-65
Network Management Capabilities with Cisco IOS Software ................................... 12-1
Overview.......................................................................................................................................... 12-1
Module Objectives..................................................................................................................... 12-1
Embedded Management Capabilities
12-3
Overview.......................................................................................................................................... 12-3
Objectives ................................................................................................................................. 12-3
Embedded Management Rationale................................................................................................. 12-4
Enterprise Applications Rely on WAN Links ............................................................................. 12-5
Cisco IOS Software Supports Network Management............................................................... 12-6
Application Optimization and Cisco IOS Technologies ............................................................ 12-7
Syslog Considerations..................................................................................................................... 12-9
Cisco IOS Syslog Message Standard..................................................................................... 12-10
Syslog Issues .......................................................................................................................... 12-11
Summary ....................................................................................................................................... 12-12
NetFlow Considerations
12-13
Overview........................................................................................................................................ 12-13
Objectives ............................................................................................................................... 12-13
NetFlow Technology Overview...................................................................................................... 12-14
Principal NetFlow Uses........................................................................................................... 12-15
Definition of a Flow ........................................................................................................................ 12-16
Traditional IP Flows................................................................................................................. 12-17
Flow Record Creation.................................................................................................................... 12-18
Example: NetFlow Data Before QoS Deployment .................................................................. 12-19
Example: NetFlow Data After QoS Deployment ..................................................................... 12-20
NetFlow Cache Management........................................................................................................ 12-21
NetFlow Export Versions ............................................................................................................... 12-22
NetFlow Version 9 Export Packet ........................................................................................... 12-23
NetFlow Deployment ..................................................................................................................... 12-26
Where to Apply NetFlow Monitoring ....................................................................................... 12-27
Summary ....................................................................................................................................... 12-28
NBAR Considerations
12-29
Overview........................................................................................................................................ 12-29
Objectives ............................................................................................................................... 12-29
NBAR Overview............................................................................................................................. 12-30
NBAR Overview ...................................................................................................................... 12-31
NBAR Packet Inspection......................................................................................................... 12-32
NBAR Protocol Discovery ....................................................................................................... 12-34
vi
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
NetFlow and NBAR Differentiation.......................................................................................... 12-35
Reporting NBAR Protocol Discovery Statistics ............................................................................. 12-36
Example: AdventNet NetFlow Analyzer .................................................................................. 12-37
Example: Concord eHealth ..................................................................................................... 12-38
Example: InfoVista VistaView ................................................................................................. 12-39
Example: Micromuse Netcool Proviso .................................................................................... 12-40
Example: MRTG Support for NBAR........................................................................................ 12-41
NBAR and AutoQoS ...................................................................................................................... 12-42
Cisco AutoQoS for Enterprise ................................................................................................. 12-43
Example: AutoQoS Discovery Progress ................................................................................. 12-44
Example: AutoQoS Suggested Policy..................................................................................... 12-45
Summary........................................................................................................................................ 12-46
IP SLA Considerations
12-47
Overview ........................................................................................................................................ 12-47
Objectives................................................................................................................................ 12-47
IP SLA Technology Overview ........................................................................................................ 12-48
Cisco IOS IP SLA Measurements ........................................................................................... 12-50
Cisco IOS IP SLA Measurements Capability .......................................................................... 12-52
IP SLA Source and Responder ............................................................................................... 12-53
IP SLA Operation With Responder ......................................................................................... 12-54
IP SLA SNMP Features .......................................................................................................... 12-57
Deploying IP SLA Measurements.................................................................................................. 12-58
Impact of QoS on IP SLA Statistics......................................................................................... 12-59
Scaling IP SLA Deployments .................................................................................................. 12-61
Hierarchical Monitoring with IP SLA Measurements............................................................... 12-62
Network Management Applications Using IP SLA Measurements ............................................... 12-63
Network Management Application Considerations ................................................................. 12-65
Summary........................................................................................................................................ 12-66
Module Summary........................................................................................................................... 12-67
References .............................................................................................................................. 12-67
Module Self-Check ........................................................................................................................ 12-69
Module Self-Check Answer Key ............................................................................................. 12-73
© 2007 Cisco Systems, Inc.
Designing Cisco Network Service Architectures (ARCH) v2.0
vii
viii
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Module 7
E-Commerce Module Design
Overview
The e-commerce module enables organizations to support e-commerce applications through the
Internet. The e-commerce module uses multiple component design techniques that have been
discussed in this course. The first lesson reviews how high availability is of particular
importance for the e-commerce module. The second lesson examines common uses of
firewalls, server load balancers, and connections to multiple ISPs in e-commerce designs. The
third lesson discusses how to integrate network components into e-commerce design providing
varying levels of security. The last lesson looks at tools and techniques for tuning e-commerce
designs.
Module Objectives
Upon completion of this module, you will be able to:
„
Discuss the importance of high availability for e-commerce designs
„
Discuss how firewalls, server load balancers, and multiple ISP connections are used in
e-commerce designs.
„
Discuss how to integrate firewalls and server load balancers into functioning e-commerce
designs.
„
Describe tuning techniques for improving the performance and availability of an
e-commerce module design
7-2
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Lesson 1
High Availability for
E-Commerce
Overview
This lesson identifies why high availability is so important for the e-commerce module. It also
discusses aspects of providing high availability for an e-commerce design. Since high
availability is not achieved solely by spending money on technical products, this lesson
discusses some non-technical aspects of high availability.
Objectives
Upon completing this lesson, you will be able to discuss high availability requirements and
components for e-commerce modules. This ability includes being able to meet these objectives:
„
Discuss the importance of high availability for e-commerce designs
„
Discuss high availability components needed to support the e-commerce network module
E-Commerce Module Overview
This topic provides an overview of the high availability requirements of the e-commerce
module.
E-Commerce Module Overview
ƒ The e-commerce module is the public face of an organization:
– Web and application responses to users must be fast.
ƒ E-commerce downtime is particularly harmful:
– It reflects negatively on the organization.
– Lost business can cost millions of dollars an hour.
ƒ The e-commerce module must minimize downtime.
– Multiple high availability techniques are used in the
e-commerce designs.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—7-4
E-commerce applications represent the public face of an organization; therefore the
e-commerce module has strict design requirements. Web and application responses to users
must be fast. E-commerce downtime is particularly harmful not only because it reflects
negatively on the organization, but also because lost business can cost millions of dollars per
hour.
Therefore, e-commerce designs have a more stringent requirement to minimize downtime
compared to other parts of an enterprise network. Multiple high availability techniques are used
in e-commerce designs.
7-4
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Components of High Availability
This section identifies components of high availability.
Components of High Availability
ƒ The objective of high availability is to prevent
outages and minimize downtime.
ƒ Achieving high availability integrates multiple
components:
1. Redundancy
2. Technology
3. People
4. Processes
5. Tools
ƒ The first two components are relatively easy
ƒ The last three components are usually where
gaps lead to outages:
– Designer may not be able to fix people,
processes, and tools
– Consultant doing post-outage design
review can talk about them
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—7-6
High availability is an organizational objective with the goal of preventing outages or at least
minimizing downtime. Achieving high availability is hard work. It takes ongoing effort and
iterated improvement. High availability is not something you have or do not have, it is a skill
that an organization achieves and perfects over time.
To actually start making progress on providing high availability requires integrating multiple
components:
1. Redundancy
2. Technology (including hardware and software features)
3. People
4. Processes
5. Tools
The network redundancy and technology components are relatively easy to accomplish because
they are elements that can be purchased and deployed. A traditional network designer will
expect to be involved with these two aspects of high availability.
However, no matter how much and how well redundancy and technology have been designed
and deployed, high availability will not have been achieved unless the people component
(sufficient manpower with the right skills, training, and mind-set), the process component
(company expectations, change control process, etc.), and the tools component (network
management, good documentation) are present. If any one of the last three high availability
© 2007 Cisco Systems, Inc.
E-Commerce Module Design
7-5
components is missing, then incidents will happen and outages will occur. Initially the network
designer may not be able to fix the people, processes, and tools in an organization. Often it
takes a consultant doing a post-outage design review to talk about these components and
suggest changes.
7-6
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Redundancy
Redundancy means using extra equipment or network links to reduce or eliminate the effects of
a failure.
Redundancy
ƒ Redundancy is used to reduce or
eliminate the effects of a failure.
ƒ Design of redundancy attempts to
eliminate single points of failure:
– Avoid single causes of failure.
– Use geographic diversity and path
diversity.
– Use dual devices and links.
– Use dual WAN providers.
– As appropriate, implement dual data
centers.
– As appropriate, use dual co-locations,
dual central office facilities, power
substations, etc.
ƒ Design of redundancy needs to
trade off cost versus benefit:
– Hours of downtime is compared to costs
of redundancy, planning, etc.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—7-7
Redundancy designs attempts to eliminate single points of failure, where one failed device or
design element brings down service.
Single causes of failure are also avoided in a redundant design:
„
Geographic diversity and path diversity are often included
„
Dual devices and links are very common.
„
Dual WAN providers are fairly common
„
Dual data centers are sometimes used, especially for large companies and large
e-commerce sites
„
Dual co-location facilities, dual phone central office facilities, and dual power substations
can be implemented
Redundant design must trade off cost versus benefit. It takes time to plan redundancy and
verify geographic diversity of service providers. Additional links and equipment cost money to
purchase and maintain. These options need to be balanced against risks, costs of downtime, etc.
The time and money invested in redundancy designs should be spent where they will have the
most impact. Consequently, redundancy is most frequently found in network, data center, or
e-commerce module cores, then in critical WAN links or ISP connections. Additional
e-commerce module redundancy can double up elements in the path between users and
applications, and the applications and back end databases and mainframes.
© 2007 Cisco Systems, Inc.
E-Commerce Module Design
7-7
Technology
Use of appropriate Cisco technologies can improve high availability.
Technology
– Stateful Switch-Over
SSO
Standby
– Non-Stop Forwarding
Active
ƒ Cisco routing continuity options
ƒ Techniques for detecting failure
and triggering failover
– Service monitoring on server load
balancers
– Enhanced Object Tracking and IP SLA
Line Cards
– Optimized Edge Routing
ƒ Other technologies
Forwarding
Continues
No Link Flap
– Fast converging routing
– Server load balancing
– Firewall stateful failover
© 2007 Cisco Systems, Inc. All rights reserved.
BGP
Adjacency
Maintained
ARCH v2.0—7-8
There are several Cisco routing continuity options such as Non-Stop Forwarding (NSF), Stateful
Switch-Over (SSO), and graceful restart capabilities that can improve availability. These
technologies allow processor failover without a link flap, continued forwarding of packets, and
maintenance of BGP adjacencies.
Note
NSF with SSO is discussed in more detail in the Design Enterprise Campus Networks
module of this course.
There are also techniques for detecting failure and triggering failover to a redundant device.
These techniques include service monitoring on server load balancers, Enhanced Object
Tracking for IP Service Level Agreements (SLA), and Optimized Edge Routing (OER).
Other technologies also contribute to high availability. For example, fast routing convergence
helps maintain high availability, as does using server load balancers. Firewall stateful failover
allows user or application sessions to be maintained across a firewall device failover.
Note
7-8
Firewall stateful failover is discussed in more detail in the “Security Services Design” module
of this course.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
People
People are one of the most critical components of high availability.
People
ƒ Staff work habits and skills matter!
– Attention to detail
– Reliability and consistency
ƒ Good skills and ongoing technical training are needed:
– Including lab time working with technology, practical skills, troubleshooting
challenge scenarios, etc.
– Communication and documentation are important.
ƒ What other groups expect
ƒ Why the network is designed the way it is, how it is supposed to work.
ƒ If people are not given the time to do the job right, they cut
corners:
– If the design target is just “adequate”, falling short is poor.
ƒ Staff team should align with services.
– Owner and experts for each key service application and other
components.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—7-9
Redundant equipment and links and advanced technology are just the beginnings of high
availability. In the prepare, plan, design, implement, operate, and optimize (PPDIOO)
methodology, the people component is vitally important as well. Staff work habits and skills
can impact high availability. For example, attention to detail enhances high availability while
sloppiness hurts availability. Reliable and consistent wiring and configurations are easier to
manage and troubleshoot.
The level of staff skills and technical training are also important when it comes to taking full
advantage of redundancy. Devices must be correctly configured. Lab testing is important in
order to understand under what circumstances failover will activate, and what failover will and
will not accomplish. For example, non-stateful firewall failover may be adequate in terms of
passing traffic, a practical understanding of the application can show that with non-stateful
failover. Application sessions will lock up for an extended period of time until an application
timeout causes session re-establishment. Designs including failover must be tested for the entire
system, not just for individual components.
Good communication and documentation are also important. The network administrators need
to be able to communicate with other network, security, application, and server teams. The
network documentation should cover why things are designed the way they are, and how the
network is supposed to work. Failover behavior is complex enough that it is unwise to have to
re-capture failover logic and boundary conditions every time some part of the design changes.
Field experience leads to the observation that if people are not given the time to do the job
right, they will have to cut corners. Testing and documentation are often the first items to be
eliminated. Lack of thorough testing and documentation will have long term consequences on
the ability to maintain, expand, and troubleshoot the network.
© 2007 Cisco Systems, Inc.
E-Commerce Module Design
7-9
If the design target is just “adequate” coverage, falling short of that target can lead to a poor
design. Designs should try for something better than adequate, to ensure that no part of the
implementation or operation of the high availability network is inadequate.
One other organizational recommendation is to align staff teams with services. If the corporate
web page depends on staff reporting to other managers, then the manager of the e-commerce
site may be competing for staff time with the Network Engineering or Operations manager. In
most cases, the person who does the staff evaluation and provides the pay bonus generally gets
most of the staff person’s attention. This can make it hard to get routine testing or maintenance
done for the e-commerce site if the staff does not report to the e-commerce manager. The
owner or expert on key service applications and other components should be identified, and
included in design and re-design efforts.
7-10
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Processes
Processes also play an important role in high availability.
Processes
ƒ Build repeatable processes:
– Document change procedures, failover planning and lab testing, and
implementation procedures.
ƒ Use labs appropriately:
– Lab reflects the production network, failover mechanisms are tested and
understood, new code is validated before deployment.
ƒ Use meaningful change controls:
– Test all changes before deployment, use good planning with roll-back plans,
conduct realistic and thorough risk analysis.
ƒ Manage operation changes:
– Perform regular capacity management audits, manage IOS versions, track
design compliance as recommended practices change, develop disaster
recovery plans.
ARCH v2.0—7-10
© 2007 Cisco Systems, Inc. All rights reserved.
Sound repeatable process can lead to high availability. Continual process improvement as part
of the PPDIOO methodology plays a role in achieving high availability. Organizations need to
build repeatable processes and then gradually improve them. Tasks that are always
implemented as one-off items represent a lost opportunity to learn as an organization.
Organizations should build repeatable processes:
„
By documenting change procedures for repeated changes (e.g. IOS upgrades)
„
By documenting failover planning and lab testing procedures
„
By documenting the network implementation procedure, so that the process can be revised
and improved the next time components are deployed
Organizations should use labs appropriately:
„
Lab equipment should accurately reflect the production network
„
Failover mechanisms are tested and understood
„
New code is systematically validated before deployment
Since staff members tend to ignore processes that consume a lot of time or appear to be a waste
of time, organizations also need meaningful change controls:
„
Test failover and all changes before deployment.
„
Plan well, including roll-back planning in detail
„
Conduct a realistic and thorough risk analysis
© 2007 Cisco Systems, Inc.
E-Commerce Module Design
7-11
Management of operational changes are also important:
„
Perform regular capacity management audits
„
Track and manage IOS versions
„
Track design compliance as recommended practices change
„
7-12
Develop plans for disaster recovery and continuity of operations
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Tools
Software and documentation are tools that contribute to high availability.
Tools
ƒ Monitor availability and key statistics for devices
and links
– Use performance thresholds, TopN reporting, and trending to spot potential
problems
– Monitor packet loss, latency, jitter, drops
ƒ Good documentation is a set of power tools:
– Network diagrams
– Network design write-ups
– Key addresses, VLANs, servers
– Services to applications, application to virtual server, and virtual server to real
server tables
ARCH v2.0—7-11
© 2007 Cisco Systems, Inc. All rights reserved.
Organizations are starting to monitor service and component availability. Assuming proper
failover, services should continue operating when single components fail. Without component
monitoring, a failure to detect and replace a failed redundant component may lead to an outage
when the second component subsequently fails.
Performance thresholds and reporting the top N devices with a specific characteristics (TopN
reporting) are useful, both for noticing when capacity is running out, and also for correlating
service slowness with stressed network or server resources. Monitoring packet loss, latency,
and jitter, and drops for WAN links or ISPs is also important. Those metrics can be the first
indication of an outage, or of potential SLA deterioration to the point where it affects delivery
of services.
Good documentation provides an extremely powerful set of tools:
„
Network diagrams help in planning, and also in fixing outages more quickly. Out of date
documentation can lead to design errors, lack of redundancy, and other undesirable
consequences.
„
Documentation of how and why the network is designed the way it is helps capture
knowledge that can be critical when a different person needs to alter the design, re-examine
how failover works, or make other changes.
„
Key addresses, VLANs and servers should be documented.
„
Documentation tying services to applications and virtual and physical servers can be
incredibly useful when troubleshooting.
© 2007 Cisco Systems, Inc.
E-Commerce Module Design
7-13
Summary
This topic summarizes the key points discussed in this lesson.
Summary
ƒ High availability is particularly important for the e-commerce module,
since it is the public face of the organization.
ƒ Multiple components are all needed to provide high availability:
– Redundancy components are extra equipment or network links that
reduce effects of a single failure.
– Technology components are features such as NSF/SSO and graceful
restart that support network continuity.
– People components include the staff and their training.
– Process components include change processes and failover testing.
– Tools include appropriate monitoring tools and good documentation.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—7-12
An e-commerce design including only redundancy and technology components will be
incomplete without the other components of high availability.
7-14
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Lesson 2
Common Component Designs
for the E-Commerce Module
Overview
The e-commerce module ties together routing, switching, firewall, and server content load
balancing components. It may also include other components.
This lesson reviews common e-commerce designs using firewalls and server load balancers as
preparation for integrating these elements into more complex e-commerce module designs in
later lessons. It also discusses common approaches for connecting to multiple ISPs.
Objectives
Upon completing this lesson, you will be able to discuss common design approaches for
e-commerce modules. This ability includes being able to meet these objectives:
„
Discuss common design approaches to redundant firewalls
„
Discuss common design approaches to redundant server load balancers
„
Discuss common design approaches to multiple ISP connections
Common Firewall Designs for E-Commerce
This topic looks at common firewall designs for the e-commerce module.
Typical E-Commerce Topology
Most e-commerce modules look very similar in how they connect to the Internet.
Typical E-Commerce Topology
Service
Provider A
Internet
Service
Provider B
Edge Routers
Core Switches
Aggregation Switches
Internal
Network
WEB Tier
Access Switches
Application Tier
Database Tier
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—7-16
The e-commerce module is typically implemented in the data center facility. It is connected to
the Internet by means of one or multiple Service Providers. Inside the e-commerce module,
there are multiple layers of firewalling. These multiple layers are the reason some people refer
to this design as a “firewall sandwich”. The firewall connections in the diagram are either in an
active or standby state. A large site may use three layers of firewalls, while smaller sites may
use only two layers of firewalls.
Typically the Internet connects to a web tier or the outer DMZ supporting web servers, as
shown in the diagram. The web tier servers are protected from Internet devices by a pair of
firewalls. The web servers communicate with application or middleware servers in the data
center through a second pair of firewalls. The servers providing the application or middleware
services represent the Application Tier. The application servers communicate with mainframes
or databases in the Database Tier through the third pair of firewalls.
Although the specific connection is not shown, the e-commerce servers connect through the
firewalls back to the internal network. This connectivity permits staff to update the applications
and servers, and do other maintenance and monitoring. When the e-commerce module is at a
co-location facility, the edge routers may also provide the connection back to the corporate
internal network. If the e-commerce module resides within a data center, the inner-most
firewalls may provide the connection back to the internal network.
7-16
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Server as Application Gateway
Some minor variations on this firewall sandwich design are occasionally used.
Server as Application Gateway
ƒ Only way between firewall layers is
through a server application.
– Is more secure then two firewalls.
– Hacker would need to penetrate two
operating systems to attack the next
firewall in sequence.
Web Tier
– Can be implemented with outer and
inner VLANs on a switch at each tier.
– Can be implemented on a single
interface per server with port-specific
Application Tier
ACLs on firewalls.
ƒ Workaround option is a direct VLAN
between firewall layers.
– May be required due to application or
Database Tier
site needs.
Internet
Service
Provider A
Note: Diagram omits switches
and some details for clarity.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—7-17
In some architectures, all traffic between the firewall layers goes through the servers. In the
diagram, one interface of the web servers provides web services, and a separate interface
connects to application servers through another firewall. In this design, the web tier servers are
acting as application-specific gateways.
Note
Sites requiring high levels of security sometimes require firewalls using different operating
systems, to ensure that if the outer firewall is breached, the same compromise does not
permit breach of the inner firewall.
When it is possible, this application-specific gateway approach adds security because a hacker
would have to penetrate the firewall and the web server operating system in order to attack the
middle layer of firewalls. This approach may support the high level of security requirement and
avoid operating firewalls from multiple vendors.
The diagram shows a logical representation of the application-specific gateway design. Usually,
the two web tier server interfaces connect to a switch (or four interfaces connect to two
switches). Separate VLANs represent the outer and inner sets of interface connections for the
web tier servers.
Another variation of the application-specific gateway design uses one connection from each
server to each switch, but uses a port-specific access list (ACL) on the firewalls. In this case,
the ACL on the Internet edge firewall pair allows only web and related traffic to the web
servers. The middle firewall only allows application traffic coming from the web servers.
© 2007 Cisco Systems, Inc.
E-Commerce Module Design
7-17
As a workaround option when there is some traffic that must go between firewalls, a single
VLAN can connect to both firewall layers. This might be needed if an application tier server
needs to communicate directly with some devices on the Internet or in the internal network if
the internal network is connected to the Internet edge firewall.
Virtualization with Firewall Contexts
The Cisco firewall family now allows for virtualization using firewall contexts.
Virtualization with Firewall Contexts
ƒ Specific VLANs or
interfaces are attached to
specific security contexts.
ƒ Each context has its own
policies (NAT, access lists,
protocol fixups, etc.).
FWSM
FWSM
FWSM
FWSM
Firewall
Server Farm
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—7-18
A physical firewall or Application Control Engine (ACE) module can be virtualized, or divided
up into separate contexts. These virtual contexts operate very much like separate physical
firewall devices. It is possible to control the actual firewall resources that each context is
allocated. This prevents a problem in one context from affecting another.
The figure shows a server farm connected to a firewall where the firewall contexts are to be
used to provide virtual firewalls to different servers. The firewall contexts retain the secure
separation of rules and other customer features. In enterprise networks, firewall contexts can be
used to separate different Internet-facing e-commerce blocks, different layers of the firewall
sandwich, and for other purposes. Contexts can also separate different types of functionality for
a Firewall Services Module (FWSM) within a Cisco Catalyst 6500 Series switch chassis.
Note
7-18
Additional details of virtual firewalls are discussed in the “Security Services Design” module
of this course.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Virtual Firewall Layers
The actual implementation of the multi-tiered e-commerce module may be done with a single
pair of firewall devices using virtual firewall layers.
Virtual Firewall Layers
Internet
Service
Provider A
6500
switch
Web Tier
Application Tier
VLANs
FWSM
FWSM
© 2007 Cisco Systems, Inc. All rights reserved.
Interfaces
Logical Traffic Flow
ARCH v2.0—7-19
For example, a pair of Cisco Catalyst 6500 series switches with FWSMs might be used instead
of the four firewalls shown in the previous diagram.
The dotted lines in the figure correspond to the layers of links in the logical traffic flow
diagram. Traffic would come from the Internet, pass through the firewall to get to the web tier,
pass through the firewall again to get from the web tier to the application tier, and pass once
more through the firewall to get to the databases, mainframe, or internal network.
Note
If such a design is used, it is a good idea to provide a logical diagram showing the VLANs
internal to the 6500 switch. Routing or default gateway logic can be superimposed, to
document how packets flow, why traffic can or cannot flow from a tier directly to/from the
Internet, how failover works, etc.
Some sites prefer to document this design using the “firewall sandwich” diagram shown earlier,
with notes indicating the different firewall layers in the diagram are actually the same physical
device.
© 2007 Cisco Systems, Inc.
E-Commerce Module Design
7-19
Firewall Modes
A firewall can run in either routed or transparent mode.
Firewall Modes
Transparent Mode
Routed Mode
10.30.10.0/16
10.30.10.0/16
Outside Interface
10.30.10.2/16
VLAN 30
VLAN 30
Management
Interface
10.30.6.1/16
VLAN 40
Inside Interface
10.40.6.1/16
10.40.6.0 /16
10.30.10.0 /16
Transparent Mode
VLAN 40
Routed Mode
ƒ FWSM bridges (switches) two
VLANs.
ƒ FWSM routes between
VLANs.
ƒ Traffic passing through the
FWSM is subject to IP ACLs.
ƒ Traffic routed between VLANs
is subject to IP ACLs, security
state tracking, etc.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—7-20
Cisco firewall technology now allows for firewall designs where the firewall operates in either
the transparent or bridged mode, or in traditional routed mode. The mode can be established on
a per-context basis depending on licensing.
The difference between the modes is that in transparent mode, the firewall bridges two VLANs
together. Normally one VLAN corresponds to one subnet. With transparent mode, the firewall
switches traffic at Layer 2 between two VLANs, which together make up one IP subnet. Any
traffic that goes through the firewall is subject to stateful IP address-based access lists, etc. This
mode is sometimes described as the “bump in the wire” mode.
In the traditional routed mode, the firewall routes traffic between VLANs or interfaces. As
traffic is routed, it passes through the firewall and is subject to stateful IP address-based access
lists, inspection, and other firewall configuration options.
Note
Additional details of firewall modes are discussed in the ‘Security Services Design’ module
of this course.
Most current designs use the firewalls in the routed mode.
7-20
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Example: Transparent Firewall Application
The example discusses an example application using a firewall in transparent mode.
Example: Transparent Firewall
Application
ƒ A transparent mode FWSM can
isolate less secure servers from more
secure servers within the same VLAN
and subnet:
– No server re-addressing is
needed.
MSFC
VLAN 10
FWSM
– Selected switch ports are shifted
from VLAN 10 to 11 and the
FWSM bridges the two VLANs.
– Object-oriented IP ACLs for are
supported.
VLAN 11
ƒ Alternatives include:
– VACLs with no ability to create
objects for logical groupings and
simpler rules
– Private VLANs
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—7-21
Some organizations need to isolate a set of servers from other servers on the same VLAN.
One solution is shown in the figure. The “more secure” server ports are placed on VLAN 11,
The FWSM in a Cisco Catalyst 6500 Series switch is configured in transparent mode to bridge
VLANs 10 and 11 together . The Multilayer Switch Feature Card (MSFC) routes traffic for the
subnet onto the combined VLAN 10 and 11. The FWSM uses an IP ACL to control what traffic
passes from VLAN 10 into VLAN 11. No re-cabling and no re-addressing are needed to
support this implementation.
An alternate solution is to use switch VLAN ACLs (VACLs). Switch VACLs control traffic
within a VLAN at the IP address level. Using ACLs would require server re-addressing to
relocate some of the servers onto a different VLAN and subnet. This is difficult to do quickly,
and can require a lot of work from server and application staff.
Note
Maintaining VACLs can be difficult. Many organization prefer to use FWSMs for their object
oriented configuration, since the FWSMs allow for logical grouping of IP addresses and
ports making for simpler rules.
Private VLANs might also be considered as another alternative for securing the server ports.
Note
© 2007 Cisco Systems, Inc.
Additional details of private VLANs are discussed in the ‘Security Services Design’ module
of this course.
E-Commerce Module Design
7-21
Common Server Load Balancer Designs for
E-Commerce
There are some common design approaches used with Content Load Balancing devices.
Functions of a Server Load Balancer
This section discusses the functions of a server load balancer (SLB).
Functions of a Server Load Balancer
Clients
Web
Servers
Load
Balancer
Database
ƒ Represents multiple server farms
with public IP addresses.
ƒ Intelligently distributes incoming requests according
to configurable rules.
Application
ƒ Can rewrite source and/or destination IP or MAC
addresses, depending on mode.
ƒ Monitors the health of servers.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—7-23
A SLB or content load balancer supports both scaling and high availability by distributing
client requests for service across active servers. A SLB provides a public IP address or virtual
IP address for each service. Clients resolve this address through DNS requests. The SLB
intelligently passes traffic through to a pool of real servers based on load and configured rules.
The SLB can rewrite source as well as destination IP or MAC addresses, depending on mode.
SLBs allow a heavy workload to be spread across many actual servers. The SLB monitors the
health and performance of the servers. When a server needs to be taken down for maintenance,
it can be removed from the server pool, and the SLB will continue providing the services using
the remaining servers. Similarly, additional server capacity can be added to the pool if the need
should arise. These features contribute to enhanced availability for e-commerce module
designs.
Paired SLB devices can function in various failover configurations. Sophisticated service
monitoring can be used to ensure that service fails over to the redundant device should the
primary SLB device lose vital connectivity.
7-22
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Cisco Server Load Balancing Products
Cisco has three product lines providing content and server load balancing services, as well as
numerous other features.
Cisco Server Load Balancing Products
CSS
CSM
ACE
These products provide much functionality in addition to
server load balancing.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—7-24
The Cisco CSS 11500 Series Content Services Switch (CSS) is a high-performance, highavailability modular architecture for web infrastructures. As the premiere switch for the Cisco
Web Network Services Software, the Cisco CSS 11500 Series helps businesses to build global
Web networks optimized for content delivery and e-commerce. By activating HTTP headers,
the CSS 11500 Series helps to ensure availability, optimize utilization, reduce latency, increase
scalability, and enhance security for websites, server farms, cache clusters, and firewall
systems. The CSS has a mechanism to monitor backend servers and their applications for load
balancing decisions.
The Cisco Content Switching Module (CSM) adds advanced Layer 4 to Layer 7 server load
balancing capabilities to Cisco Catalyst 6500 Series switches or the Cisco 7600 Series routers.
The Cisco CSM offers a complete set of advanced features and benefits including:
„
Investment protection in a high-density, scalable platform with proven reliability
„
Reduced application response times, optimized service delivery, increased application
uptime and service scalability for servers, firewalls, VPN devices, Secure Socket Layer
protocol (SSL) termination devices and caches
„
Fault-tolerant configurations to provide improved application uptime utilizing connection
and sticky state redundancy for seamless failover
„
Accommodation for a wide range of common IP protocols, including TCP, User Datagram
Protocol (UDP), and higher-level protocols, including Hypertext Transfer Protocol (HTTP),
File Transfer Protocol (FTP), Telnet, Domain Name System (DNS), Real-Time Streaming
Protocol (RTSP) and Simple Mail Transfer Protocol (SMTP)
© 2007 Cisco Systems, Inc.
E-Commerce Module Design
7-23
„
Integration into an existing infrastructure, minimizing the time and resources required to
deploy server load balancing services
The Cisco Application Control Engine (ACE) provides:
7-24
„
Centralized control for IT over the deployment and management of application service
while allowing individual groups to administer their own application instances: The
capability to manage 250 virtual partitions, which incorporate Layer 2-7 services, within a
single physical device plus role-based access control, workflow management, and rollback
capability, help simplify management and reduce costs.
„
Industry-leading application and device performance: 16-Gbps throughput and 345,000
sustained connection setups per second to handle large-scale operations plus unique WAN
latency and bandwidth reduction capabilities help drive optimal end-user response times
across the network
„
Rich levels of application and network security: includes bidirectional support for content
inspection, SSL encryption/decryption, and transaction logging for application security
forensics
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
SLB Design Models
This section discusses design approaches that can be used with SLB devices.
SLB Design Models
ƒ Three basic SLB design models:
– Router mode
– Bridge mode inline
– One arm mode (or two arm mode) with alternative
implementations:
ƒ Server default gateway is the SLB.
ƒ PBR is used.
ƒ Client source NAT is used.
ƒ Redundancy decisions
– Active/passive
– Active/active
– Failover triggers
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—7-25
There are three basic design approaches used with SLB devices:
„
Router mode. In this design approach, the SLB routes between outside and inside subnets.
„
Bridge mode (inline). In this design approach, the SLB operates in a transparent bridging
mode.
„
One-arm (or two-arm) mode. The one-arm or two-arm mode can be implemented in
several ways. The server default gateway can be set to the SLB device. Policy Based
Routing (PBR) or client source Network Address Translation (NAT) can be used. The point
of these techniques is to force replies from servers to pass back through the SLB on their
way to the customer or end-user.
With any of the three basic design approaches, there are options for redundancy. One
redundancy option is an active/passive implementation where the SLBs are configured with one
active SLB that is backed up by a passive SLB. With active/active redundancy, one SLB is
active for certain virtual IP addresses or services, and another SLB is active for others. The
SLBs in the active/active implementation back each other up. There are also various
configuration options for failover triggers.
Note
© 2007 Cisco Systems, Inc.
A discussion of failover triggers is beyond the scope of the this course.
E-Commerce Module Design
7-25
SLB Router Mode
One very popular SLB design approach is the SLB Router Mode.
SLB Router Mode
Subnet A
Outside
Inside
Subnet B
Inside
ƒ SLB routes in router mode:
– VIPs are usually in routable
public subnet.
– Servers are in private IP subnet
– Design is easy to deploy with
many server IP subnets.
ƒ By default ,if a packet is sent to the
MAC address of the SLB, the SLB
will route the packet from an
outside address to an inside
address.
ƒ Design is the preferred
configuration for appliance-based
server load balancers.
Subnet C
Servers Default Gateway:
SLB Inside Address
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—7-26
In this design approach, the SLB routes between outside and inside subnets. The Virtual IP
addresses (VIPs) of services are usually in a globally routable public IP subnet. In the figure,
public network is subnet A. The real servers are typically in a private IP subnet. In the figure,
the private networks are subnets B and C. The SLB knows to route a packet between the public
and the private subnets when it sees its MAC address as destination.
This design is easy to deploy and works well with many server IP subnets. It is the
recommended approach for the CSS or any appliance-based content load balancer. The real
servers typically use the SLB inside address as their default gateway. As the return reply traffic
passes through the SLB, the source real IP is changed to the VIP address, so the end-user has
no direct way of telling that there is a SLB in the path. The end user does not see the IP address
of the real server.
Note
You may need to readdress some network devices to support SLB deployments.
Using private IP addresses for the real servers protects them from direct attack across the
Internet. Would-be hackers cannot route traffic directly to the real servers.
7-26
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
SLB Inline Bridge Mode
The SLB may be used in an inline bridge mode.
SLB Inline Bridge Mode
ƒ SLB bridges in bridge mode:
– Servers are in routable IP subnet.
VLAN 20
Subnet A
VLAN 10
– VIPs can be in the same or different
subnet.
– Design requires one IP subnet for
each server farm.
ƒ The SLB acts as a transparent device
between the servers and upstream
firewall or Layer 3 device.
ƒ Although this is a suggested
configuration for integrated load
balancers, there can be spanning tree
and redundancy issues for appliancebased load balancers.
Servers Default Gateway:
Upstream Router
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—7-27
This mode operates much like the firewall transparent bridging mode. The content load
balancer or SLB device bridges, acting as a “bump in the wire” or transparent device between
servers and upstream firewall or Layer 3 device.
With this design, the real servers are in a globally routable IP subnet. The VIP addresses of
services can be in the same or a different subnet. Each server farm must be in one IP subnet
which means the servers cannot be spread across multiple subnets. This restriction is because
the MAC address of the common VIP is changed to the specific MAC address of a real server
in order to direct traffic to the appropriate real server.
This design is one suggested configuration for integrated load balancers. If SLBs are deployed
in a redundant configuration, you need to be concerned about spanning tree implications in the
design.
Note
© 2007 Cisco Systems, Inc.
Configuring and designing for SLBs for routed operation is typically simpler than for bridged
operation because troubleshooting SLB-induced spanning tree issues can get complicated.
E-Commerce Module Design
7-27
SLB One-Arm Mode Overview
The One-Armed (or Two-Armed) mode is another popular approach for deploying SLB
devices.
SLB One-Arm Mode Overview
Subnet B
Subnet B
ƒ SLB is not inline.
ƒ Return traffic requires PBR,
server default gateway pointing
to SLB, or client source NAT.
– Mode is not as common as
bridge or routed mode.
ƒ This out-of-band approach
supports scaling.
Servers Default Gateway:
SLB
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—7-28
In this approach, the SLB is connected to a switch, typically with one or two connections. It is
not directly inline with the traffic path as with the previous designs. In the one-armed approach,
the SLB VIP and the real servers are in the same VLAN or subnet. In the two-armed approach,
the SLB routes traffic to the real server subnet, which can be a private subnet.
Routing causes inbound end-user traffic to reach the VIP on the SLB. The SLB then translates
the IP destination to a real server IP address and forwards to the real server, as in routed mode.
The main difference is that return traffic needs to be forced to go to the SLB, so that the source
IP address of traffic from the real server can be translated back to the VIP that the end user
device thinks it is communicating with.
There are multiple ways to cause return traffic to go through the SLB:
„
The simplest way is to set the server default gateway to the SLB rather than the router.
„
Another approach is to use policy based routing to “push” or “deflect” the appropriate
outbound server traffic over to the SLB as next hop.
„
A third approach is to use client source NAT (CSNAT), where the client source address is
replaced with the SLB address. The server then sends its reply back to the SLB, which
changes the destination address back to the real end user address and forwards the packet.
This is based on a connection table in the SLB. The main reason this approach is not as
popular is that many sites want the original end user IP address, either for simple web logs
and marketing purposes, or for security audit trail purposes. CSNAT interferes with the
direct ability to do either of these things.
One advantage of the one-armed or two-armed (out of band) approach is that inbound and
outbound traffic need not go through the SLB. For example, PBR can allow the real server to
7-28
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
do a file transfer or backup directly out of the e-commerce module, without having to burden
the SLB with processing all those packets. This may be helpful in scaling the e-commerce
module to support greater traffic volumes.
Another advantage is that scaling by adding SLBs is simple. Different VIPs steer traffic to the
different SLBs. PBR or CSNAT steer replies back through the correct SLB. Server default
gateways could be used to provide services using completely different server pools.
Misconfigured SLB One-Arm Mode Flows
This figure shows how the traffic flows in misconfigured one-armed SLB mode.
Misconfigured SLB One-Arm Mode Flows
1
Source
|
Destination
Router MAC
SLB MAC
Client IP
VIP
Random Port
VIP Port
1
2
SLB MAC
Client IP
Selected
Server MAC
Selected
Server IP
Random Port
3
SLB MAC
Selected
Client IP
Server IP RESET
© 2007 Cisco Systems, Inc. All rights reserved.
3
VIP Port
Server MAC
VIP Port
2
Random Port
Without PBR, Client NAT,
or Servers Gateway Being
Set for Load Balancer
ARCH v2.0—7-29
Step 1: The client sends traffic to the VIP. It is routed by the edge router, which uses its MAC
address as source MAC. It looks up the VIP in its routing table and applies the SLB MAC as
destination MAC address.
Step 2: The SLB substitutes its MAC as source MAC, and the selected server MAC and IP as
destination information.
Step 3: Unless server default gateway, PBR, or CSNAT is in place, the real server reply goes
directly to the client. This will cause a RESET, since the client is receiving traffic from a
different IP address than the VIP its connection was established to. The RESET means the SLB
will appear to be operating incorrectly. Really, the problem is the lack of having deployed a
mechanism to force replies back through the SLB.
© 2007 Cisco Systems, Inc.
E-Commerce Module Design
7-29
SLB Full Rewrite
The figure shows a SLB device doing full rewrite based on Client Source NAT (CSNAT).
SLB Full Rewrite Based on
Client Source NAT
Source
|
Destination
Router MAC
SLB MAC
Client IP
VIP
Random Port
VIP Port
Selected
Server MAC
Selected
SLB Natpool IP
Server IP
SLB Random
Specific
Port
Server Port
SLB MAC
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—7-30
With CSNAT, the IP address of the client is rewritten by NAT before the packet goes to the
server. Note that everything about the source (MAC, IP, and port) is rewritten. When the server
replies, it has no choice but to reply to the SLB device.
One potential issue with CSNAT is accountability. Traffic logs on the servers will only show
the IP address of the SLB.
7-30
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Common Topology Designs for E-Commerce
This topic discusses common topology designs for e-commerce.
Design Option: One Firewall Per ISP
One of the key components for e-commerce is ISP connectivity.
Design Option: One Firewall Per ISP
ƒ Devices use NAT to two
ISP-assigned blocks.
ƒ DNS resolves of VIP
addresses from both ISP
blocks.
ƒ Failover is disruptive.
ƒ External DNS needs to be
aware of site connectivity.
Internet
Service
Provider A
172.16.1.0 /24
Service
Provider B
172.20.1.0 /24
X
10.0.0.0 /8
www.corp.com
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—7-32
The figure shows a common approach to dual-homing or connecting a site to two ISPs. This
approach is common among small sites since it is relatively easy to set up and administer. The
basic approach is to use a router and/or firewall to connect to each ISP.
Note
With the Cisco IOS firewall features, one device might be used for both functions. Another
variation on this design uses one router to support both ISP connections.
Each edge path uses NAT to translate the inside address of the e-commerce servers to the
address block provided by the ISP. External DNS resolves the site name, www.corp.com, to an
address from either external address block. If the DNS software resolves using a round robin
approach, users are roughly load balanced across the two paths to the company web server.
Routing takes the traffic to the outside of the relevant NAT device or firewall.
There are some drawbacks to this design. The main issue is that any failure on the ISP edge
path means loss of session because the failover between edge paths is not stateful. Dual routers
and connections per ISP can be used for more robust connectivity to each ISP. In this case, the
non-stateful failover will only be used when connectivity through one ISP is lost.
In addition, the external DNS needs to be aware of site connectivity so that it can cease
resolving the domain name to addresses at the site that is down.
© 2007 Cisco Systems, Inc.
E-Commerce Module Design
7-31
Design Option: Stateful Failover with Common External Prefix
A more sophisticated way to dual-home an e-commerce site to two ISPs uses stateful failover
with a common external prefix.
Design Option: Stateful Failover with
Common External Prefix
ƒ Devices use NAT to a
common external prefix.
ƒ Both ISPs advertise the
common prefix.
Service
Provider A
Internet
Service
Provider B
172.16.1.0 /24
ƒ Firewalls support stateful
failover.
10.0.0.0 /8
www.corp.com
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—7-33
The figure shows this approach. The main difference is that the firewall pair and the NAT
devices support some form of stateful failover. The NAT devices translates addresses to a block
that both ISPs are willing to advertise for the site, 172.16.1.0 /24 in the figure. This might be a
block obtained from one of the providers, or for large organizations it can be a block obtained
independently from the IP address authorities.
The edge routers advertise this block via BGP to both ISPs, who must be willing to advertise it
to their peers.
Note
The site should use an assigned BGP AS number to prevent the site becoming a transit link
between the ISPs, and also to prevent looping of routing information.
When one provider loses routing or its link, BGP provides users with automatic failover to the
other path into the site. Should there be a failure internal to the site (switches or links), the
firewalls can support stateful failover with an active/active design. HSRP is used for failover
should one switch to router link fail.
7-32
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Design Option: Distributed Data Centers
Very large e-commerce sites often use distributed data centers.
Design Option: Distributed Data Centers
Service
Provider A
APP A
Internet
Service
Provider B
APP B
APP A
APP B
ƒ Active/active designs
ƒ “Off the air” detection
– DNS-based
– Cisco GSS
FC
Production
Data Center
© 2007 Cisco Systems, Inc. All rights reserved.
ƒ DNS approach
– Diversity
– Advertisement of
both sites
FC
Backup
Data Center
ARCH v2.0—7-34
A two chassis deployment can provide more failover flexibility than having one chassis with
dual components such as power and supervisor modules. Similarly, having two sites increases
overall high availability while lessening the uptime requirements for each individual site. When
the e-commerce modules are implemented in well designed distributed data centers, this
approach also means that one site can occasionally be taken offline for maintenance while not
disrupting customer service. Using two e-commerce sites also protects against regional
problems. This feature is becoming a requirement for banks and other critical services.
To support the distributed data center design, applications need to be migrated to technology
allowing active/active hot databases as opposed to active database and mirrored hot spare
database. Another key element when using distributed sites is technology to detect when a site
is “off the air” and should be failed over. The devices that detect the need for failover and
respond must be external to the two sites. This technology can be an external service, or can be
provided by equipment at one or more Service Provider co-location facilities. The “off the air”
detection might be provided by an external service such Akamai or Ultra DNS. It might also be
provided using the Cisco Global Site Selector (GSS) technology, typically within a provider colocation facility. The function provided is called Global Server Load Balancing (GSLB).
Note
GLSB is discussed in more detail in this module.
Some organizations dislike any DNS-based failover techniques because DNS or browser caches
retain old DNS values for quite some time, and that many implementations do not exhibit
proper behavior in regard to DNS TTL values. Implementations also may incorrectly use
source IP to guess user location, or do reordering when a DNS server or GSS provides an
© 2007 Cisco Systems, Inc.
E-Commerce Module Design
7-33
ordered list of addresses. Nonetheless, various large sites do use GSLB and feel strongly that it
improves their service offering.
Another consideration at some sites is diversity of DNS which impacts the degree of protection
against Distributed Denial of Service (DDoS) on DNS servers. Large external DNS services
using Anycast IP are one way to protect DNS from attacks. Other approaches you might
consider are site-controlled external DNS servers or GSS devices in co-location facilities.
One design approach for distributed e-commerce modules is to tie the redundant sites together
via an internal WAN link to avoid the need for external failover response. With this approach,
DNS provides the addresses of servers at either site, addressed from a block of addresses
advertised through the ISPs of both sites. Should the connectivity from one site to the Internet
fail, Internet and internal routing redirect traffic to go through the other connection. Delay in
failover and the impact of any routing instability are potential drawbacks to this approach. On
the other hand, failover at Internet scale cannot be too rapid or instability would results.
Note
7-34
This discussion briefly overviews some of the major factors a multi-site designer should
consider.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Summary
This topic summarizes the key points discussed in this lesson.
Summary
ƒ The “firewall sandwich” approach is common in e-commerce module
designs:
– It separates web, application, and database or inside zones with
redundant firewall layers.
– These layers may be virtualized in a FWSM.
– Firewalls are used in routing or bridging modes.
ƒ SLBs map a virtual IP to real servers for enhanced availability and
scaling of server capacity
– SLBs can be used in router, bridge, or one-armed modes
ƒ Dual ISP connections is a common e-commerce topology:
– One firewall per ISP with separate NAT pools is one design.
– Common external prefix advertised through BGP with a single NAT
pool is another design.
– Distributed data centers with different ISPs supports very large
e-commerce sites.
© 2007 Cisco Systems, Inc. All rights reserved.
© 2007 Cisco Systems, Inc.
ARCH v2.0—7-35
E-Commerce Module Design
7-35
7-36
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Lesson 3
Integrated E-Commerce
Designs
Overview
This lesson focuses on complete e-commerce designs, rather than how to design for the
addition of one more component to a network infrastructure. Complete design are important
because the e-commerce design differs in crucial ways from the rest of a data center or campus
design.
In this lesson, various common ways to assemble functioning e-commerce modules are
discussed. Four designs are examined in some detail to illustrate options and allow analysis of
how each topology works. The lesson concludes with some general observations that apply to
any of the four common designs.
Objectives
Upon completing this lesson, you will be able to discuss integrated e-commerce designs. This
ability includes being able to meet these objectives:
„
Discuss a basic e-commerce module design including traffic flows
„
Discuss a two firewall layer SLB design including traffic flows
„
Discuss the “one-armed” SLB design with two firewall layers including traffic flows
„
Discuss the “one-armed” SLB design with multiple security contexts including traffic flows
„
Discuss testing incidents and failovers in prospective e-commerce module designs
Base E-Commerce Module Design
The figure shows the essentials of a basic e-commerce module design.
Base E-Commerce Module Design
Security Details
Internet
Cat6509-Core-1
Cat6509-Core-2
VLAN 2
VLAN 2
ƒ Layer 3 firewall used
ƒ Firewall perimeter at the core
VLAN 3
Cat6513-Agg-1
Cat6513-Agg-2
VLAN 3
CSM2
Control
PortChannel
VLAN 18
VLAN 18
VLAN 17
Web VLAN
App VLAN
ƒ Server default gateway is the CSM VIP
– RHI is possible
ƒ All server traffic goes through the CSM
DB VLAN
Cat6509-Access-1
App Server Web Server
ƒ CSM is used in routed mode
ƒ CSM default gateway is the HSRP group
on the MSFC
VLAN 19
VLAN 19
ƒ Security perimeter not possible between
web/app/DB tiers
SLB Details
VLAN 200
CSM1
VLAN 17
ƒ Aggregation and access are considered
trusted zones
Cat6509-Access-2
– Additional configurations needed for
direct access to servers and non-load
balanced server initiated sessions
DB Server
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—7-39
The basic e-commerce design is deployed in a redundant manner.
The core layer supports the first stage of firewalls. In the figure, the core layer uses Cisco
Catalyst 6509 Series switches with integrated Firewall Service Modules (FWSMs). This design
places the firewall perimeter at the core, and the firewalls in the core are used in Layer 3 routed
mode. The aggregation and access layers are considered trusted zones. There is no security
between the web, application, and database zones in this basic design. This does mean that if
one of the servers is compromised, the attacker may have full access to the other servers and
the internal network.
The aggregation layer supports connectivity to the server load balancers (SLBs) or firewalls in
routed mode. In the figure, Cisco Catalyst 6513 Series switches with Cisco Content Switching
Module (CSM) are used as SLBs. Other SLBs such as the Application Control Engine (ACE)
could be used. The default gateway for the e-commerce servers is the virtual IP address (VIP)
on the SLB or firewall in the aggregation layer. The default gateway for the CSMs is an HSRP
address on the Multilayer Switched Feature Card (MSFC) on the same switch. Since the MSFC
is directly connected to the SLB, route health injection supporting host routes is possible.
The access switches connect the web servers, application servers, and database servers. In some
more complex designs, the database servers or mainframes are inside the main data center,
isolated by firewalls from the e-commerce module.
In this design, all e-commerce traffic goes via the CSMs. Additional CSM configuration is
needed for direct access to the servers, or for non-load-balanced sessions initiated by the
servers.
7-38
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Base Design Routing Logic
This section discusses the routing logic in the base e-commerce design.
Base Design Routing Logic
Static or BGP route
Internet
CORE1
CORE2
Static route, NH=FW
VLAN 2
VLAN 3
VLAN 2
AGG1
AGG2
VLAN 3
0/0, NH=ISP router
connected interface
Static route, NH=HSRP
0/0, NH=HSRP VIP
VLAN 200
Connected routes,
NH=CSM
CSM1
VLAN 17
Connected subnets
CSM2
Control
PortChannel
VLAN 18
VLAN 19
VLAN 18
VLAN 19
0/0, NH=FW
VLAN 17
0/0, NH=HSRP VIP
Web VLAN
App VLAN
DB VLAN
ACC1
Switches are Cisco
Catalyst 6500 Series
© 2007 Cisco Systems, Inc. All rights reserved.
ACC2
App
Server
Web
Server
0/0, NH=CSM
DB
Server
ARCH v2.0—7-40
De
The routing in the base e-commerce module is mostly static, using virtual IP addresses to
support failover. The figure clarifies how the routing is intended to work. This can be
particularly helpful in determining that failover has been properly designed.
The left side of the figure shows how traffic is routed by way of next hop (NH) addresses to the
Virtual IP of a service on the CSM and then to a server IP. The right side of the figure shows
how traffic is routed out from servers using NH addresses to the Internet.
Inbound, the ISP uses a static or BGP route to direct traffic to the network shown. The border
router probably uses a static route with Next Hop (NH) the outside IP of the firewall. OSPF
routing might be used instead.
The firewall uses a static route, with next hop the HSRP address of the Route Processor
component in the switch. That in turn uses a connected route to reach the CSM or ACE, and
static routes to reach the server actual IP addresses. If route health injection (RHI) is used, it
provides the necessary routes to the virtual IPs (VIPs). Finally, the CSM or ACE views the
server subnets as directly connected subnets.
Outbound, servers use the CSM or ACE as default gateway. From there, a default route causes
traffic to go to the HSRP VIP on the MSFCs, and then to the firewall inside IP address, then to
the HSRP VIP of the border router pair, and finally to the connected interface of the ISP router.
The VLANs between the aggregation layer switches are used for first hop redundancy protocols
(FHRP) or failover heartbeat detection.
© 2007 Cisco Systems, Inc.
E-Commerce Module Design
7-39
Base Design Server Traffic Flows
The graphic shows representative flows going to and from a web server in the base design.
De
Base Design Server Traffic Flows
Internet
Internet
CORE1
VLAN 2
VLAN 3
CORE1
CORE2
VLAN 2
AGG1
Firewall Makes
Security
Decisions
AGG2
CORE2
VLAN 2
VLAN 3
AGG1
VLAN 3
CSM Makes
SLB Decision
CSM2
VLAN 18
VLAN 17
VLAN 17
VLAN 19
VLAN 18
VLAN 17
VLAN 18
VLAN 19
Web VLAN
App VLAN
VLAN 19
Web VLAN
App VLAN
DB VLAN
DB VLAN
ACC1
ACC2
App Server Web Server
CSM2
Control
PortChannel
VLAN 18
VLAN 19
VLAN 3
VLAN 200
CSM1
Control
PortChannel
VLAN 17
AGG2
CSM Makes
SLB Decision
VLAN 200
CSM1
VLAN 2
Firewall Makes
Security
Decisions
ACC1
DB Server
Load Balanced Session Flow
© 2007 Cisco Systems, Inc. All rights reserved.
ACC2
App Server Web Server
DB Server
Server Management Session Flow
ARCH v2.0—7-41
The left side of the figure shows a load-balanced session flow. The right side shows a server
management session flow, perhaps an SSH connection direct to a server.
The flow is fairly straightforward. The firewall handles security logic. The CSM handles the
SLB decision or passes management traffic directly to a specific server.
Note
7-40
Sometimes special server management addresses are used to make it easier to configure
the CSM to pass management traffic directly to the server. In other cases, the actual server
address is used, rather than the Virtual IP (VIP) of the service, to indicate management
traffic to the SLB module.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Two Firewall Layers Design
This section discusses a sample design using two firewall layers to support the e-commerce
module.
Two Firewall Layers Design
Security Details
ƒ Layer 3 firewall used as firewall
perimeter at the core
Internet
CORE1
CORE2
VLAN 2
VLAN 3
ƒ Layer 3 firewall with single context at the
aggregation layer
VLAN 2
AGG1
AGG2
VLAN 3
ƒ Firewall services are deployed in the
aggregation between Web/App/DB tiers
SLB Details
FWSM1
VLAN 7
FWSM2
VLAN 8
VLAN 9
CSM1
VLAN 17
Multiple Control
PortChannels
VLAN 18
VLAN 19
VLAN 8
VLAN 9
VLAN 7
CSM2
VLAN 18
VLAN 19
VLAN 17
Web VLAN
App VLAN
– Server default gateway is the
aggregation firewall primary IP address
– No extra configurations needed for
direct access to servers or non-load
balanced server initiated sessions
ƒ CSM default gateway is the firewall primary
IP address
DB VLAN
ACC1
ACC2
App Server Web Server
ƒ CSM is used in bridged design with
multiple bridged VLAN pairs
DB Server
– MSFC is not directly connected to the
CSM, RHI is not possible
ƒ All server traffic goes through the CSM
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—7-43
For more protection, a firewall can be inserted into the aggregation layer. In the sample design
in the figure, FWSM modules have been added to the aggregation switches. The additional
FWSM provides security between the web, application, and database tiers. Even if the exteriorfacing web servers are compromised, there is a high degree of protection for the application and
database servers, and any connections to the rest of the internal data center network or
mainframe.
Note
ACE modules could be used in place of the FWSMs.
With this design, the CSM can be used in routed mode as was done in the base design or it can
be used in bridged mode to bridge between multiple VLAN pairs. The figure illustrates a
bridged approach where the default gateway for the servers is the primary FWSM interface in
the aggregation switch rather than an address on the CSM.
The aggregation switch FWSM routes traffic directly to the server subnets. This traffic is
bridged through the CSM, so the traffic burden on the CSM is not reduced. However, no extra
configuration is needed for direct access to the servers (e.g. for deterministic testing from
outside) or for non-load-balanced sessions initiated by the servers (e.g. FTP downloads).
Note
© 2007 Cisco Systems, Inc.
Since the MSFC is not on the same subnet as the CSM, route health injection is not
possible.
E-Commerce Module Design
7-41
The VLANs between the aggregation layer switches is used for FHRP or failover heartbeat
detection.
Two Firewall Layers Design Traffic Flows
The graphic shows representative flows going to and from a web server in the two firewall
layers design.
Two Firewall Layers Design Traffic Flows
Internet
Internet
CORE1
VLAN 2
VLAN 3
FWSM1
VLAN 7
CSM1
VLAN 17
CORE1
CORE2
VLAN 2
VLAN 2
AGG1
Core Firewall
Makes
Security
Decisions
AGG2
Internal DMZs
Perimeters
VLAN 8
VLAN 9
Multiple
Control
CSM
Makes
PortChannels
SLB Decision
VLAN 18
VLAN 19
VLAN 18
VLAN 19
VLAN 3
VLAN 3
FWSM2
VLAN 8
VLAN 9
CORE2
VLAN 2
AGG1
FWSM1
VLAN 7
VLAN 7
CSM2
CSM1
VLAN 17
VLAN 17
VLAN 8
VLAN 9
Multiple Control
CSM
Bridges
PortChannels
Traffic
VLAN 3
FWSM2
VLAN 8
VLAN 9
VLAN 7
CSM2
VLAN 18
VLAN 19
VLAN 17
Web VLAN
App VLAN
DB VLAN
ACC2
App Server Web Server
Internal DMZs
Perimeters
VLAN 18
VLAN 19
Web VLAN
App VLAN
DB VLAN
ACC1
AGG2
ACC1
ACC2
App Server Web Server
DB Server
Load Balanced Session Flow
DB Server
Web Server to App Server Session Flow
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—7-44
User web traffic is shown in the left half of the figure:
„
The perimeter firewall at the core still makes security decisions.
„
The aggregation layer firewall provides internal DMZ perimeters protecting the servers.
„
The CSM makes the SLB decisions as before.
The right half of the figure shows the traffic flow from web server to application server. The
flow from the web server is bridged through the CSM to the default gateway for that subnet on
the aggregation switch FWSM. The FWSM then routes the traffic to the application server
subnet. The traffic is bridged through the CSM to the application server.
Return traffic from the application server to the web server is handled similarly. The
application server subnet default gateway is used to direct traffic to the FWSM, which routes it
back onto the web server subnet.
7-42
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
“One-Armed” Design with Two Firewall Layers
This section discusses a design using “one-armed” SLB device with two firewall layers
supporting the e-commerce module.
“One-Armed” Design with Two Firewall
Layers
Security Details
ƒ Layer 3 firewall is used as firewall
perimeter at the core.
Internet
CORE1
CORE2
VLAN 2
VLAN 3
VLAN 2
AGG1
AGG2
VLAN 3
Multiple Control
PortChannels
FWSM1
VLAN 17
ƒ CSM is used in a one-armed fashion:
– Servers default gateway is the
aggregation firewall primary IP
address.
FWSM2
VLAN 18
VLAN 19
VLAN 18
VLAN 19
VLAN 17
Web VLAN
App VLAN
ACC1
ACC2
App Server Web Server
– No extra configurations needed for
direct access to servers or non-load
balanced server initiated sessions.
– All non-load balanced traffic to/from
servers will bypass the CSM.
DB VLAN
© 2007 Cisco Systems, Inc. All rights reserved.
ƒ Firewall services are deployed in the
aggregation between Web/App/DB tiers.
SLB Details
CSM2
CSM1
ƒ Layer 3 firewall with single context is
used at the aggregation layer.
DB Server
ƒ CSM default gateway is the HSRP group
address on the MSFC.
– Since MSFC is directly connected to
the CSM, RHI is possible.
ARCH v2.0—7-46
In a “one-armed” design with two firewall layers, the CSM can be moved to a position where
selected traffic to and from the servers does not go through the CSM. The design can be scaled
by adding additional FWSM and CSM or ACE modules to the switch chassis.
In this design, the default gateway of the servers remains the appropriate primary IP address on
the firewall interface in the aggregation switch in the relevant subnet (VLAN). The default
gateway of the CSM is the HSRP group address on the MSFCs.
Inbound traffic is routed to the CSM as a connected route to the VIP of the service on the CSM.
The CSM then statically routes inbound traffic to the aggregation switch FWSM, which routes
to the connected server subnet. Traffic bound directly for a real server IP bypasses the CSM.
The appropriate outbound traffic from servers needs to be directed by PBR or CSNAT to the
CSM. The MSFC is once again directly connected to the CSM, so route health injection is
possible. No extra configuration is needed for direct traffic to and from servers. Non-load
balanced traffic bypasses the CSM.
© 2007 Cisco Systems, Inc.
E-Commerce Module Design
7-43
“One-Armed” Design with Two Firewall Layers Traffic Flows
The graphic shows representative flows going to and from a web server in the “one-armed”
SLB design with two firewall layers.
“One-Armed” Design with Two Firewall
Layers Traffic Flows
Internet
Internet
CORE1
CORE2
VLAN 2
PBR/
SRCVLAN 3
NAT
CORE1
VLAN 2
VLAN 2
AGG1
Core Firewall
Makes
Security
Multiple
Control
Decisions
PortChannels
AGG2
CORE2
VLAN 3
VLAN 3
VLAN 2
AGG1
AGG2
CSM2
CSM1
CSM2
CSM1
ACE Is
Bypassed
ACE Makes
SLB Decision
FWSM1
VLAN 17
Internal DMZs FWSM2
Perimeters VLAN 18
VLAN 18
VLAN 19
FWSM1
VLAN 17
VLAN 17
VLAN 19
Web VLAN
App VLAN
DB VLAN
ACC1
ACC2
App Server Web Server
VLAN 3
Multiple Control
PortChannels
Internal DMZs FWSM2
Perimeters VLAN 18
VLAN 18
VLAN 19
VLAN 17
VLAN 19
Web VLAN
App VLAN
DB VLAN
ACC1
DB Server
Load Balanced Session Flow
© 2007 Cisco Systems, Inc. All rights reserved.
ACC2
App Server Web Server
DB Server
Web Server to App Server Session Flow
ARCH v2.0—7-47
The left half of the figure remains much the same as before. The difference is that PBR or
CSNAT is required to direct the outbound server traffic from the MSFC to the SLB.
The right half of the figure differs from the previous design. The web server to application
server traffic can bypass the CSM in this design approach. The FWSM can route traffic
between the web server VLAN and the application server VLAN.
If server load balancing is desired for web to application traffic, a more complex approach is
required, for example, virtual application server address in another subnet to allow simple
routing of web to virtual application traffic by way of the CSM.
7-44
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
“One-Armed” Design with Direct Server Traffic Flows
The graphic shows representative flows for server management and direct Internet traffic
differently going to and from a web server in the one-armed design with two firewall layers.
“One-Armed” Design with Direct Server
Traffic Flows
Internet
CORE1
VLAN 2
VLAN 3
CORE2
Firewall Makes
Security
AGG1Decisions
VLAN 2
AGG2
Multiple Control
PortChannels
ACE Is
CSM1 Bypassed
FWSM1
VLAN 17
Internal DMZs
Perimeters
VLAN 18
VLAN 19
CSM2
FWSM2
VLAN 18
VLAN 19
VLAN 17
Web VLAN
App VLAN
DB VLAN
ACC1
ACC2
App Server Web Server
DB Server
Server Management Session Flow
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—7-48
This design moves the CSM out of the traffic path so that the CSM can be bypassed for
non-load-balanced traffic and direct Internet traffic to and from the servers.
© 2007 Cisco Systems, Inc.
E-Commerce Module Design
7-45
“One-Armed” SLB Design with Firewall Contexts
This section arm discusses a design option using the “one-armed” SLB model with the
aggregation firewall supporting multiple firewall contexts.
“One-Armed” Design with Firewall
Contexts
Security Details
ƒ Layer 2 firewall used with multiple
contexts.
Internet
CORE1
CORE2
VLAN 12
VLAN 12
AGG1
AGG2
Secure Internal
Segment
VLAN 2
VLAN 7
VLAN 8
VLAN 9
VLAN 2
FWSM2
VLAN 18
VLAN 19
Web VLAN
App VLAN
DB VLAN
VLAN 18
VLAN 19
VLAN 17
– No extra configurations needed for direct
access to servers or non-load balanced
server initiated sessions.
– All non-load balanced traffic to/from
servers will bypass the CSM.
ACC1
ACC2
App Server Web Server
SLB Details
– Servers default gateway is the HSRP
primary IP address.
Multiple Control
PortChannels
VLAN 17
ƒ Aggregation MSFC is a secure internal
segment with protection from each
connected network.
ƒ CSM is used in a one-armed fashion:
VLAN 7
VLAN 8
VLAN 9
FWSM1
ƒ Firewall perimeter at outside, internal
and each DMZ.
DB Server
© 2007 Cisco Systems, Inc. All rights reserved.
ƒ CSM default gateway is the HSRP group
address on the MSFC.
– Since MSFC is directly connected to the
CSM, RHI is possible.
ARCH v2.0—7-50
The aggregation FWSM can be used in transparent mode, with the MSFC routing between the
server VLANs. A firewall context can also be placed logically in the Layer 2 path before traffic
reaches the MSFC. This option removes the need for a separate firewall in the core layer.
The CSM is deployed in a “one-armed” topology still in routed mode. Since the MSFC is
directly connected to the CSM, route health injection is possible. Since the CSM is in “onearmed” mode, non-load-balanced traffic can easily bypass the CSM.
7-46
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
“One-Armed” SLB Design with Firewall Contexts Traffic Flows
The graphic shows representative flows going to and from a web server in the “one-armed”
design with multiple firewall contexts.
“One-Armed” SLB Design with Firewall
Contexts Traffic Flows
Internet
Internet
CORE1
CORE2
VLAN 12
VLAN 12
AGG1
CORE1
CORE2
VLAN 12
AGG2
VLAN 12
AGG1
ACE Makes
SLB Decision
ACE Is
Bypassed
Secure Internal
Segment
VLAN 2
VLAN 7
VLAN 8
VLAN 9
VLAN 2
Secure Internal
Segment
VLAN 2
VLAN 7
VLAN 8
VLAN 9
FWs
VLAN 18
VLAN 19
Multiple Control
PortChannels
VLAN 18
VLAN 19
Web VLAN
App VLAN
DB VLAN
ACC1
FWSM2
VLAN 17
DB Server
Load Balanced Session Flow
© 2007 Cisco Systems, Inc. All rights reserved.
FWSM1
Virtual
VLAN
17
FWs
ACC2
App Server Web Server
VLAN 2
VLAN 7
VLAN 8
VLAN 9
VLAN 7
VLAN 8
VLAN 9
Multiple Control
PortChannels
FWSM1
Virtual
VLAN
17
AGG2
VLAN 18
VLAN 19
VLAN 18
VLAN 19
Web VLAN
App VLAN
DB VLAN
FWSM2
VLAN 17
ACC1
ACC2
App Server Web Server
DB Server
Web Server to App Server Session Flow
ARCH v2.0—7-51
On the left side of the figure, inbound traffic reaches the core router and is routed to the MSFC
in the aggregation layer switch. In order to reach the MSFC, it passes through a FWSM firewall
context in transparent mode for security checks and ACLs. The MSFC then routes inbound
packets to the VIP on the CSM, which does destination NAT on the packets. The CSM then
routes the packets to the web server subnet. Since the FWSM is logically between the MSFC
and the VLAN for the web servers, the FSWM applies ACLs and security enforcement.
Note
Each subnet (web, app, DB) occurs on two VLANs, which the FWSM bridges together.
Outbound traffic from web server goes through FWSM to MSFC, is routed to the CSM via
PBR, and goes from there out to the core router.
The right half of the diagram shows traffic being routed by the MSFC between the web server
subnet and the application server subnet. This traffic passes through the FWSM twice, giving
ample opportunity to enforce ACLs and security policies. Return traffic also passes through the
FWSM twice.
All routing next hops use HSRP virtual addresses, either on the MSFC or on the core routers.
With a little configuration effort, traffic from web to application server can pass through the
CSM.
Note
© 2007 Cisco Systems, Inc.
This discussion did not cover how the redundant CSM or FWSM gets used. The trunk
between the switches is necessary to support failover.
E-Commerce Module Design
7-47
“One-Armed” SLB Design with CSS
This section looks at a “one-armed” SLB design with CSS modules that firewalls all traffic.
“One-Armed” SLB Design with CSS
Secure Internal
Segment
CSS11506_1
Design Approach
CSS11506_2
VLAN 41 10.32.222.0/30
Data
PortChannel
CORE1
CORE2
MSFC
MSFC
VLAN 5
VLAN 3
LAN FailOver
PortChannel
ƒ Aggregation MSFC is a secure internal
segment with protection from each
connected network.
VLAN 201
StateLink
PortChannel
FWSM1
– NAT is performed on the MSFC.
ƒ Firewall perimeters are at outside,
internal and each DMZ.
VLAN 200
VLAN 6
VLAN 14
ƒ Layer 2 firewall used with multiple
contexts.
FWSM2
VLAN 103 10.73.222.0/27
ƒ Server access switches are set up as
Layer 2 devices.
Web Server 1
Server Load Balancing Details
Web Server 2
VLAN 105 10.73.222.32/28
ƒ CSM is used in a one-armed fashion
App Server 1
– Servers default gateway is the HSRP
primary IP address.
App Server 2
VLAN 114 10.73.220.0/23
– All non-load balanced traffic to/from
servers will bypass the CSM.
Inside
Core
Internal Router
VLAN 106 10.10.137.0/24
Edge Router 1
Edge Router 2
Internet
© 2007 Cisco Systems, Inc. All rights reserved.
ƒ CSM default gateway is the HSRP group
address on the MSFC.
– Since MSFC is directly connected to the
CSM, RHI is possible.
ARCH v2.0—7-52
The figure shows how a FWSM can be used to firewall all traffic. In this design, a Layer 2
firewall is used with multiple security contexts. There are several DMZs, with firewall
perimeters outside, inside, and at each DMZ. The aggregation layer MSFC is a secure internal
segment with protection from each connected network including malicious activity from data
center networks.
In the figure, the external CSS is used in one-armed fashion. The dual CSS devices are
connected with ports in the same VLANs.
NAT is implemented on the MSFC, since a transparent firewall does not support this function.
Another design option is to use an additional routed context on FWSM to support NAT.
The CSS default gateway is the HSRP group address on the MSFC. The CSS pair are directly
connected at Layer 2 to the MSFCs, so RHI is possible. Due to the implementation of CSS in
one-armed mode, non-load-balanced traffic to and from servers can bypass the CSS devices.
7-48
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Testing E-Commerce Designs
This section discusses considerations for testing and troubleshooting e-commerce designs.
Testing E-Commerce Designs
ƒ Lab testing can validate network behavior for failover conditions.
ƒ Good preparations allows simulations of failures to align closely
with real conditions:
– Silent packet discards can be simulated by sending traffic in a
VLAN on a trunk.
– Layer 3 switches may experience partial or total system
failures.
ƒ Documenting tested conditions and results aids future
troubleshooting and design analysis.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—7-54
Redundant hardware components and proper configurations help support high availability. But
when something breaks, a good designer will need to understand the ways in which redundant
devices fail over. It is also very important to test failover conditions as thoroughly as possible.
This requires preliminary analysis on how the network devices detect different types of failures.
Testing not only confirms correct device configuration, but can also help identify modes where
failover does not occur. For example, application operation may act differently when packets
are silently dropped (e.g. due to loss of NAT or stateful firewall state) than when a TCP RESET
or ICMP Unreachable is received.
Since about any device or link can fail, failover testing looks at how to best simulate failures.
Good preparation leads to good testing. For example, simulating a link failure by removing the
Ethernet connection out at one end works does cause a failure. But that is a fairly clean failure
mode, where the switch or other device detects loss of Ethernet link voltage. Simulations of
failures should align closely with real conditions. You may also want to simulate a one-way
cabling condition or quiet packet drops:
„
Silent packet discards can be simulated by sending traffic in a VLAN on a trunk, where the
VLAN is disallowed at the other end of the trunk. Routing some network prefix to NULL0
also discards packets to that destination prefix. However, implementing passive interfaces
or otherwise altering routing to delete the route to a destination is not the same as a silent
discard since the router will normally send “Destination network unreachable” packets
back to the sender when packets are received without a prefix in the routing table.
„
Layer 3 switches might experience a system failure (simulated turning off power), or might
experience a partial failure (simulated by removing one module). In the case of a partial
failure, Layer 3 operations might stop functioning but Layer 2 operations may continue.
Neighboring devices would then experience loss of traffic and connectivity, but not loss of
© 2007 Cisco Systems, Inc.
E-Commerce Module Design
7-49
Ethernet link status. This might be simulated by configuring “no ip routing” on the MSFC
or route processor on a Layer 3 switch.
Good documentation of the preparation and testing will aid in future troubleshooting. When an
incident occurs in the production network, the documentation can be updated, reflecting lessons
learned, possibly presenting alternatives to simulate the observed failure mode. This process
can enable future testing to include the recent lesson learned. A test lab and documentation can
also be used to validate new software releases and configuration changes. It is important to run
through the “regression tests” to make sure aspects of failover has not changed based on new
software or configuration enhancements which may render the existing network design or
configuration less useful.
7-50
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Summary
This topic summarizes the key points discussed in this lesson.
Summary
ƒ Where security requirements are moderate, a basic e-commerce
design may provide firewall services only in the core layer.
ƒ A two firewall layers design provides additional security by
providing firewall services in the core and aggregation layer.
ƒ In the one-armed mode, LSBs can be deployed attached to one
side of the MSFC with the FWSM routing between MSFC and ecommerce servers.
ƒ A higher level of security can be attained by using the one-armed
LSB design with multiple firewall contexts providing a firewall
perimeters outside, inside, and at each network connection or
DMZ.
ƒ Testing consists of analysis of failure points and modes, along lab
simulations of the various failure modes and effects.
© 2007 Cisco Systems, Inc. All rights reserved.
© 2007 Cisco Systems, Inc.
ARCH v2.0—7-55
E-Commerce Module Design
7-51
7-52
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Lesson 4
Tuning for E-Commerce
Overview
This lesson examines several devices and technologies that enhance the performance and
availability of an e-commerce module. The lesson illustrates how some of these technologies
can be used to improve a design.
Objectives
Upon completing this lesson, you will be able to discuss tuning for e-commerce designs. This
ability includes being able to meet these objectives:
„
Discuss how Border Gateway Protocol (BGP) tuning can be used to control packet flow in
e-commerce designs
„
Discuss how Enhanced Object Tracking (EOT) is used to support e-commerce designs
„
Discuss how Optimized Edge Routing (OER) is used to support e-commerce designs
„
Discuss how Global Server Load Balancing (GSLB) is used to support e-commerce designs
E-Commerce Tuning Overview
There are Cisco technologies that can enhance e-commerce designs.
Tuning for E-Commerce
ƒ Multiple Cisco technologies can enhance e-commerce designs.
ƒ Several technologies may be useful in a broad range of situations:
– BGP tuning
– Enhanced Object Tracking
– Optimized Edge Routing
– DNS-based site selection and failover
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—7-59
This lesson will highlight several technologies that may be useful in a broad range of situations:
„
Border Gateway Protocol (BGP) tuning
„
Enhanced Object Tracking (EOT)
„
Optimized Edge Routing (OER)
„
DNS-based site selection and failover including GLSB with Cisco Global Site Selector
Note
7-54
This list is a sampling of technologies and techniques that can be used to tune e-commerce
designs.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
BGP Tuning
BGP routing can be tuned to control packet flow and convergence characteristics.
BGP Tuning
ƒ BGP is the tool of choice for
communicating to the ISP.
ƒ Designs should consider which
traffic enters and exits the
e-commerce module by which
ISP.
Service
Provider A
Internet
Service
Provider B
ƒ Designs should plan the
failover behavior.
Note: Review the Building Scalable
Cisco Internetworks course and the
Configuring BGP on Cisco Routers
course for details.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—7-61
BGP tuning can be used to control packet flow by communicating the available prefixes,
routing policies and preferences of a site to their ISP.
Designs need to consider which traffic enters and exits the e-commerce data center or data
centers by which ISP and which link. Most sites attempt some form of load balancing. While
load balancing ideally should result in traffic flows being split 50-50 across two links, in
practice this is hard to achieve. Designs should attempt approximate balancing with some
capacity for simple tuning. This practice recognizes that traffic monitoring will be necessary,
and that re-tuning of traffic flows will require changes to router BGP configurations.
With a single provider, MED or BGP communities can be used to communicate the site
preferences for traffic flow from the Internet to the organization. RFC 1998 provides the details
of using BGP communities. With multiple providers, MED is unlikely to be advertised between
providers, so BGP communities or AS pre-pending can be used to influence inbound traffic.
The failover behavior of the BGP routing needs to be tested and understood. ISPs constantly
update route filters, so monitoring traffic and periodic testing is a good way to assure that your
prefixes have not been accidentally filtered.
Note
© 2007 Cisco Systems, Inc.
Manipulating routing updates and configuring BGP is covered in the Building Scalable Cisco
Internetworks course and in the Configuring BGP on Cisco Routers course.
E-Commerce Module Design
7-55
Enhanced Object Tracking
Enhanced Object Tracking (EOT) is a Cisco IOS capability that efficiently uses a standalone
process to track the status of objects.
Enhanced Object Tracking
Enhanced
Tracking Clients
Objects Tracked
• Line protocol
HSRP
VRRP
• IP routing state
Object
Tracking
Process
GLBP
ƒ
ƒ
ƒ
ƒ
• IP route reachability
• IP route metric
threshold
• IP SLA operations
EOT is a stand-alone process that tracks objects.
EOT can help verify the end-to-end path status.
HSRP, GLBP, and VRRP can be clients of EOT.
EOT ensures high availability with more options than interface tracking.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—7-63
The EOT process notifies other processes that registered interest when EOT detects a problem.
EOT was first available in 12.2(15) T Cisco IOS software. EOT is useful in verifying
end-to-end path availability and helps identify situations where the network is sending traffic
down a path that is black-holing packets, has congestion or has bad quality problems.
Hot Standby Router Protocol (HSRP), Virtual Router Redundancy Protocol (VRRP), and
Gateway Load Balancing Protocol (GLBP) have the ability to track the up or down state of a
local interface on a router. These protocols are First Hop Redundancy Protocols (FHRPs). If the
link fails on a primary FHRP router, standby tracking can cause the FHRP to switch traffic over
to a standby router to ensure continued communication.
EOT adds the ability to discover non-local problems and react. HSRP, GLBP, and VRRP can
be clients of EOT. EOT can track:
„
Line protocol
„
IP routing state (interface up, IP address known, and routing enabled)
„
Reachability of an IP route (route present and accessible)
„
IP routing metric (above or below a threshold)
„
Results of IP SLA operations (reachability of target, or thresholds for packet loss, latency,
and jitter) [First available in 12.3(4) T and 12.2(25) S code.]
EOT can also track Boolean “and” and “or” combinations of conditions, as well as weighted
combinations of condition thresholds for sophisticated failover logic.
7-56
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Example: HSRP and IP SLA Tracking
The figure shows one way in which EOT might be used.
Example: HSRP and IP SLA Tracking
ServerA
Internet
ISP2
ISP1
IP SLA
Router1
.1
HSRP:
10.10.10.10
. . .
ip sla 18
icmp-echo <server>
ip sla schedule 18 start-time now life forever
track 100 rtr 18 state
interface FastEthernet0/0
ip address 10.10.10.1 255.255.255.224
standby 1 ip 10.10.10.10
standby 1 priority 105
standby 1 preempt
standby 1 track 100 decrement 10
Router2
.2
10.10.7.1
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—7-64
In the figure, an IP Service Level Agreements (SLA) measurement is being run from Router1
to ServerA across ISP1. Local hosts reach ServerA by way of Router1 until EOT forces a
failover to Router2 in response to loss of packets, latency, or jitter along the ISP1 connection.
This is a sample configuration:
ip sla 18
icmp-echo <server>
ip sla schedule 18 start-time now life forever
track 100 rtr 18 state
interface FastEthernet0/0
ip address 10.10.10.1 255.255.255.224
standby 1 ip 10.10.10.10
standby 1 priority 105
standby 1 preempt
standby 1 track 100 decrement 10
This example illustrates that EOT can be used to influence the choice of exit router and
outbound path. Typically this is done in response to conditions outside the local network.
© 2007 Cisco Systems, Inc.
E-Commerce Module Design
7-57
Example: Injecting Routes and IP SLA
This example looks at how route injection into BGP can depend on server reachability.
Example: Injecting Routes and IP SLA
User1
Internet
ISP1
3. Don’t Advertise
the Route Anymore
BGP
Router1
ISP 2
BGP
Router2
IP SLA
1. Original Path
XX
2. Traffic “Black
Holed”
4. Alternate Path
ServerA
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—7-65
In the figure, an IP SLA measurement is set up from Router1 to ServerA, based on a specific
route to the server. A more general prefix is configured as a static route that tracks this IP SLA
measurement. If ServerA should become unreachable (quit responding), then the static route
will be withdrawn.
The BGP configuration can advertise this static routes. When the static routes are withdrawn in
response to an EOT condition, BGP will cease advertising the routes to the ISP1.In this case,
EOT provides a relatively simple way to track reachability through a complex network. When
reachability fails, failover to another ISP link or another site can be triggered.
This example illustrates how to control what is advertised to a BGP peer at an ISP. The
advertisement controls the path and entrance router used by inbound traffic.
This is a simplified portion of the configuration:
ip sla 1
icmp-echo <server>
ip sla schedule 18 start-time now life forever
track 123 rtr 1 reachability
ip route <server_network> 255.255.255.0 Null0 track 123
! (more specific routes will be used to forward packets)
router bgp 65505
redistribute static
7-58
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Optimized Edge Routing Overview
Cisco IOS Optimized Edge Routing (OER) is another alternative to detect undesirable
conditions along a path.
Optimized Edge Routing (OER) Overview
ƒ WAN access links are the largest end-to-end bottleneck.
ƒ By default, BGP chooses best path based on fewest AS-Path hops.
ƒ OER provides alternate path selection based on policies.
– OER components include MC and BRs.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—7-67
WAN access links are the largest end-to-end bottleneck in wide area connectivity. Normally
BGP determines the best outbound path based on shortest Autonomous System (AS) Path,
together with all the other BGP decision criteria. OER allows the path selection to be based on
policies that can include measured reachability, delay, loss, jitter, synthetic Mean Option Score
(for voice), load, and monetary cost.
OER provides automatic outbound route optimization and load distribution for multiple
connections by selecting the optimal exit point. OER is an integrated Cisco IOS software
solution that allows users to monitor IP traffic flows and then define policies and rules based on
prefix performance, link load distribution, link cost, and traffic type. OER selects which exit
path is best. It does not affect routing or path selection for inbound traffic from outside the site.
To implement OER, a site configures one or more border routers (BRs) that communicate with
a router chosen and configured as the master controller (MC). The MC makes decisions about
which outbound path to use, based on the configured policy. The figure shows multiple paths
from an enterprise or content provider to a remote office or content consumer.
© 2007 Cisco Systems, Inc.
E-Commerce Module Design
7-59
OER Operations
The section provides a high level discussion of how OER works.
OER Operations
Prefix and/or
Traffic Class*
Feedback from
Netflow to
confirms that
traffic is going
through selected
Exit.
Passive
measurement/
Active
measurement using
IP SLA
Control prefix
using BGP or
STATIC.
Control traffic
class using PBR.
Policy based on delay, loss,
unreahability, jitter, load, and
range.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—7-68
OER follows a cycle of learn, measure, apply policy, optimize, and verify.
Learn Phase
In the Learn phase, the configuration identifies prefixes and traffic classes of interest.
Measure Phase
In the Measure phase, passive or active measurement provides measurements using each BR.
Passive monitoring amounts to looking up NetFlow data in memory. The router observes what
happens when packets are sent, and record the results as internal NetFlow statistics. If there are
no packets being sent, there is no new data for the system. NetFlow data captures delay and
throughput statistics. The delay measurements are based on TCP round trip time (RTT) for the
initial SYN to following ACK. The OER data also records packet loss (comparing highest TCP
sequence number and received packets with lower sequence number) and Unreachables (SYN
with no received ACK) for passive measurements. OER passive monitoring is based on TCP
traffic flows for IP traffic. Passive monitoring of non-TCP sessions is not supported because
UDP does not readily provide delay estimates, response counts, and other traffic data.
Active probing defaults to ICMP echo and ping.
Note
Repeated ping probing might trigger an IDS or IPS intervention (or to activate) on the remote
site.
OER active probing can be configured to use IP SLA measurements instead of ping. This
allows OER to respond to delay or jitter in the network. Currently, OER can use ICMP, TCP
7-60
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
connections, or UDP echo for active probing. Note that the target for the latter two must be
capable of responding. If the target is a router, it must be configured with "rtr responder".
As of Cisco IOS software release 12.3(14) T, OER can do traceroute probes. These probes
collect delay, loss, and reachability information for each hop from source address to probe
target prefix. You can configure these probes to run in three ways: continuous (run all the
time), policy based (run only when the prefix is out of policy), or on-demand.
Apply Phase
In the Apply Policy phase, the MC periodically gathers data from the BRs, and applies the
configured policy to determine the best route.
Optimize Phase
In the Optimize Phase, controls are applied either by adding a static or BGP route, or if traffic
classes are to be controlled, through Policy Based Routing (PBR).
OER routing control is exerted by injecting routes into the BRs. This is done through OER
command messages from the MC to the BRs, and not by inserting routes on the master
controller. Currently, OER can influence routing in two ways:
„
Setting the BGP local preference for a specific prefix
„
Creating a temporary static route for a specific prefix
This routing change at the BRs influences the other routers in the internal network through one
of the following methods:
„
Internal BGP peering
„
BGP or static route redistribution into the IGP
If you have BRs in close proximity (namely, with a high speed LAN connection between
them), you can use default routes to get packets to the border, and then have OER shift some
traffic for selected prefixes between the two exit routers. OER is mainly concerned about
preferring one BR to the other. The IGP routing only comes into this if you have to rely on your
IGP to route traffic between the BRs, or if you want optimal routing, directly to the "correct"
BR.
The injected BGP or static route is not advertised to external peers, and has no routing impact
outside the local site.
Verify Phase
In the Verify Phase, feedback from NetFlow confirms that traffic is using the selected exit path.
© 2007 Cisco Systems, Inc.
E-Commerce Module Design
7-61
OER Solution Topologies
There are several design topologies where OER can be useful.
OER Solution Topologies
1) SOHO/Broadband
2) Remote Office
ISP1/WAN1
BR
MC/BR
ISP2/WAN2
MC/BR
3) Headquarters/Content/Hosting/Data Centers
ISP1/WAN1
BR
MC
ISP2/WAN2
BR
BR—Border Router, MC—Master Controller
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—7-69
The figure shows some of the topologies where OER can be used.
In the first example, a small office home office (SOHO) or broadband site has two exit paths.
The single edge router is configured to be both MC and BR. It selects between the two exit
paths using OER. This topology reflects a smaller site doing E-Commerce, with one router
connected to two ISPs or to two Points of Presence for a single ISP.
In the second example, a remote office with two exit routers to two ISPs uses OER to select the
best path to headquarters. One of the BRs is also the MC. This topology might be a site doing
e-commerce, with two routers connected to two ISPs or to two Points of Presence (PoPs) for a
single ISP.
In third example, a larger e-commerce site has an MC separate from the two BRs. OER helps
select the better outbound path through ISP1 or ISP2.
OER is generally used to influence outbound traffic path selection. Using EOT with selective
route advertisement is one good way to influence inbound traffic path.
7-62
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Cisco Global Server Load Balancing
This section provides a brief overview of Cisco Global Server Load Balancing.
Cisco Global Server Load Balancing
ƒ In real-time, globally load
balance all web-based
traffic across multiple data
centers.
ƒ Re-route all traffic to a
backup data center in
case of a disaster.
DataCenter A
DataCenter B
SLB,
CSM,
CSS
SLB,
CSM,
CSS
ƒ Simplify the management
of the DNS process by
providing centralized
command and control.
Local DNS
RR Records
Best Destination
GSS-2
www.x.com
GSS-1
Clients Requesting Websites
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—7-71
Another way of tuning e-commerce service delivery is to provide external selection of the best
destination for each client.
Organizations that provide web and application hosting services often require network devices
that can perform complex request routing to two or more redundant, geographically dispersed
data centers. These network devices need to provide fast response times and disaster recovery
and failover protection through global server load balancing (GSLB). The Cisco GSLB product
is the Cisco Global Site Selector (GSS). GSS leverages global content deployment across
multiple distributed and mirrored data locations, optimizing site selection, improving Domain
Name System (DNS) responsiveness, and ensuring data center availability/
„
GSS provides real-time global load balancing across multiple data centers and improves the
global data center selection process by offering user-selectable global load-balancing
algorithms. It scales to support hundreds of data centers or server load balancers (SLBs).
„
GSS provides traffic rerouting in case of disaster. It provides a scalable dedicated hardware
platform to ensure web-based applications are always available, by detecting site outages or
site congestion and rerouting content requests. GSS traffic-management process
continuously monitors the load and health of the SLBs within each data center. This
information is used in conjunction with customer-controlled load-balancing algorithms to
enable the GSS to select a data center that is available and not overloaded within userdefinable load conditions-in real time.
„
GSS offloads DNS servers by taking over the domain resolution process, and transmits
these requests at thousands of requests per second. It complements the existing DNS
infrastructure by providing centralized domain management.
© 2007 Cisco Systems, Inc.
E-Commerce Module Design
7-63
Summary
This topic summarizes the key points discussed in this lesson.
Summary
ƒ BGP is the primary way to communicate reachable prefixes and
routing policies and preferences to multiple ISPs.
ƒ EOT is an efficient way to track the status of remote objects and
react to this status.
ƒ OER uses passive or active measurements including IP SLA
measurements to determine best exit router.
ƒ GSLB provides a way to externally load balance site selection for
user traffic and respond to site outages or congestion.
© 2007 Cisco Systems, Inc. All rights reserved.
7-64
Designing Cisco Network Service Architectures (ARCH) v2.0
ARCH v2.0—7-72
© 2007 Cisco Systems, Inc.
Module Summary
This topic summarizes the key points discussed in this module.
Module Summary
ƒ High availability e-commerce designs require redundancy and
Cisco technology, supplemented by organizational efforts
concerning people, processes, and tools.
ƒ E-commerce module design requires integrating firewall, SLB,
multiple ISP routing, routing, Layer 2 switches, and servers into a
highly available design.
ƒ Common e-commerce designs support load balancing traffic to
servers with levels of security provided by firewall perimeters.
ƒ Tuning using BGP features, EOT, OER, and GSLB enhance the
performance and availability of e–commerce designs.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—7-74
High availability is an important consideration for the e-commerce module. High availability
design requires redundancy and Cisco technology, supplemented by organizational efforts
concerning people, processes, and tools.
E-Commerce module design requires integrating firewall, server load balancing, multiple ISP
connections, routing, Layer 2 switches, and servers into a highly available design.
Typical e-commerce designs support load balancing traffic to servers with levels of security
provided by firewall perimeters. Basic designs provide one level of firewall services, while
more advanced designs include multiple firewall contexts supporting firewall perimeters at
every network connection in the e-commerce module
Many technologies can be useful in enhancing the performance and availability of e-commerce
designs. Features such as BGP tuning, EOT, OER, and GSLB are often deployed in a broad
range of situations.
References
For additional information, refer to these resources:
„
Cisco Systems, Inc. Data Center Networking: Integrating Security, Load Balancing, and
SSL Services Using Service Modules (Systems Reference Network Design) at
http://www.cisco.com/application/pdf/en/us/guest/netsol/ns304/c649/cdccont_0900aecd800
f252b.pdf
„
Cisco Systems, Inc. Data Center Networking: Internet Edge Design Architectures
(Solutions Reference Network Design) at
© 2007 Cisco Systems, Inc.
E-Commerce Module Design
7-65
http://www.cisco.com/application/pdf/en/us/guest/netsol/ns304/c649/ccmigration_09186a0
08014ee4e.pdf
7-66
„
Cisco Systems, Inc. Designing and Managing High Availability Networks at
http://www.cisco.com/application/pdf/en/us/guest/products/ps6550/c1161/cdccont_0900aec
d8031069b.pdf
„
Cisco Systems, Inc. “High availability Introduction” at
http://www.cisco.com/en/US/products/ps6550/products_ios_technology_home.html
„
Cisco Systems, Inc. Configuring Secure (Router) Mode on the Content Switching Module at
http://www.cisco.com/warp/public/117/csm/csm_router.pdf
„
Cisco Systems, Inc. Configuring Single Subnet (Bridge) Mode on the CSM at
http://www.cisco.com/warp/public/117/csm/csm_bridge.pdf
„
Cisco Systems, Inc. “APP-1103: Introduction to Content Switching Technologies”
Networkers 2006 presentation (accessible on a subscription basis) at
http://www.networkersonline.net
„
Cisco Systems, Inc. “DC-2503: Implementing Data Center Services (Interop, Design and
Deploymnet)” Networkers 2006 presentation (accessible on a subscription basis) at
http://www.networkersonline.net .
„
Cisco Systems, Inc. Configuring Enhanced Object Tracking at
http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/hiap_c/haipbtrk.p
df
„
Cisco Systems, Inc. Building Scalable Cisco Internetworks course at
http://tools.cisco.com/E-LearningIT/LPCM/LpcmLLController?action=CourseDesc&COURSE_ID=4952
„
Cisco Systems, Inc. Configuring BGP on Cisco Routers course at
http://tools.cisco.com/E-LearningIT/LPCM/LpcmLLController?action=CourseDesc&COURSE_ID=4807
„
Cisco Systems, Inc. Cisco IOS Optimized Edge Routing Configuration Guide at
http://www.cisco.com/application/pdf/en/us/guest/products/ps6350/c2001/ccmigration_091
86a0080789b51.pdf
„
Chesapeake NetCraftsmen, Inc. Basics of Cisco Optimized Edge Routing (OER) at
http://www.netcraftsmen.net/welcher/papers/oer01.pdf
„
Chesapeake NetCraftsmen, Inc. Configuring Cisco Optimized Edge Routing (OER) at
http://www.netcraftsmen.net/welcher/papers/oer02.pdf
„
Cisco Systems, Inc. Cisco Global Site Selector CLI-Based Global Server Load-Balancing
Configuration Guide at
http://www.cisco.com/application/pdf/en/us/guest/products/ps4162/c2001/ccmigration_091
86a00807e0a23.pdf
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Module Self-Check
Use the questions here to review what you learned in this module. The correct answers and
solutions are found in the Module Self-Check Answer Key.
Q1)
What are two characteristics of an e-commerce designs? (Choose two.) (Source: High
Availability for E-Commerce)
A)
B)
C)
D)
E)
Q2)
What are the two traditional design components for high availability? (Choose two.)
(Source: High Availability for E-Commerce)
A)
B)
C)
D)
E)
Q3)
single points of failure
multiple points of congestion
geographic diversity
dual co-location facilities
doubled-up elements in the path between users and applications
What are two Cisco routing continuity options that support high availability? (Choose
two.) (Source: High Availability for E-Commerce)
A)
B)
C)
D)
E)
Q5)
tools
technology
processes
applications
redundancy
Which one of these items do most redundancy designs attempt to eliminate? (Source:
High Availability for E-Commerce)
A)
B)
C)
D)
E)
Q4)
e-commerce applications are independent of the servers that use them
e-commerce designs have less stringent high availability requirements as
compared to other parts of an enterprise network
e-commerce designs have more stringent high availability requirements as
compared to other parts of an enterprise network
e-commerce downtime is particularly harmful to an organization
e-commerce downtime is typically not particularly harmful to an organization
IP SLA
NSF
OER
service monitoring on service load balancers
SSO
Which one of the following is an organizational recommendation to support high
availability? (Source: High Availability for E-Commerce)
A)
B)
C)
D)
E)
© 2007 Cisco Systems, Inc.
align staff teams with services
communicate with other network, security, application, and server teams
enhance high availability with attention to detail
identify the owner or expert on key service applications
implement reliable and consistent wiring and configurations for easier
management and troubleshooting
E-Commerce Module Design
7-67
Q6)
How do processes play an important role in supporting high availability? (Source: High
Availability for E-Commerce)
A)
B)
C)
D)
E)
Q7)
What two power tools contribute to high availability? (Chose two.) (Source: High
Availability for E-Commerce)
A)
B)
C)
D)
E)
Q8)
C)
D)
E)
E)
providing a private IP address or virtual IP address for each service
providing a public IP address or virtual IP address for each service
resolving DNS requests for destination IP addresses for each service
rewriting source as well as destination IP or MAC addresses depending on
SLB mode
supporting scaling and high availability by distributing client requests for
service across active servers
What are three characteristics of SLB router mode? (Choose three.) (Source: Common
Designs for the E-Commerce Module)
A)
B)
C)
D)
E)
7-68
a method to avoid operating firewalls from multiple vendors
an architectures where all traffic between firewalls goes through
application-specific gateways
an architectures where all traffic between firewalls goes through
application-specific servers
firewall connections in either an active or standby state
multiple layers of firewalling
What are three functions of a SLB? (Choose three.) (Source: Common Designs for the
E-Commerce Module)
A)
B)
C)
D)
Q11)
in the aggregation layer
in the application tier
in the core layer
in the data center
in the web tier
What is a “firewall sandwich?” (Source: Common Designs for the E-Commerce
Module)
A)
B)
Q10)
TopN reporting
network diagrams
packet monitoring
repeatable processes
network design write-ups
Where is an e-commerce design typically implemented? (Source: Common Designs for
the E-Commerce Module)
A)
B)
C)
D)
E)
Q9)
failover and change testing should be performed after deployment
lab equipment should accurately reflect the production network
repeatable processes can be gradually improved
roll-back processes should be outlined in implementation plans
services should continue operating when single components fail
The design supports multiple server subnets.
The end user does not see the IP address of the real server.
The end user sees the IP address of the real server.
The SLB acts as a “bump in the wire” between servers and upstream firewall
or Layer 3 devices.
The SLB routes between outside and inside subnets.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Q12)
What are three characteristics of SLB one-arm mode? (Choose three.) (Source:
Common Designs for the E-Commerce Module)
A)
B)
C)
D)
E)
F)
Q13)
Why is a common external prefix desirable in e-commerce topologies? (Source:
Common Designs for the E-Commerce Module)
A)
B)
C)
D)
E)
Q14)
at the Internet
at the core layer
at the core and aggregation layers
at the aggregation and access layers
between the aggregation layer router and the e-commerce servers
What are three characteristics about the “one armed” SLB design? (Chose three.)
(Source: Integrated E-Commerce Designs)
A)
B)
C)
D)
E)
Q16)
Devices can use NAT to a common external prefix.
HSRP can be used for failover should one switch to router link fail.
DNS software can resolve queries using a round robin approach between sites.
When one ISP loses routing or its link, BGP can provide users with automatic
failover to the other path into the site.
An assigned BGP AS number prevents the site becoming a transit link between
the ISPs and prevents looping of routing information.
Where is the firewall perimeter in a basic e-commerce design? (Source: Integrated ECommerce Designs)
A)
B)
C)
D)
E)
Q15)
Return traffic does not require special handling.
The SLB is directly inline with the default traffic path.
The SLB is not directly inline with the default traffic path.
The SLB VIP and the real servers are in the same VLAN or subnet.
Return traffic can use PBR to deflect appropriate outbound server traffic over
to the SLB as next hop.
The SLB routes traffic to the real server subnet if the real servers are not in the
same VLAN or subnet as the SLB VIPs.
Outbound traffic from servers may need to be directed by PBR or CSNAT to
the CSM.
The CSM statically routes all inbound server traffic to the aggregation switch
FWSM, which routes the traffic to the connected server subnet.
The MSFC is directly connected to the CSM.
The MSFC is not directly connected to the CSM.
The SLB is moved to a position where selected traffic to and from the servers
does not go through the SLB
What are two characteristics about the two firewall layers e-commerce design when the
CSM is not in routed mode? (Chose two.) (Source: Integrated E-Commerce Designs)
A)
B)
C)
D)
E)
© 2007 Cisco Systems, Inc.
Outbound traffic from servers may need to be directed by PBR or CSNAT to
the CSM.
The aggregation switch FWSM routes traffic to the server subnets.
The MSFC is directly connected to the CSM.
The MSFC is not directly connected to the CSM.
The SLB is moved to a position where selected traffic to and from the servers
does not go through the SLB
E-Commerce Module Design
7-69
Q17)
How does BGP tuning control packet flow into the e-commerce module? (Source:
Tuning for E-Commerce)
A)
B)
C)
D)
E)
Q18)
What are three characteristics of EOT? (Chose three.) (Source: Tuning for
E-Commerce)
A)
B)
C)
D)
E)
F)
Q19)
F)
HSRP, GLBP, and VRRP can be clients of OER.
It uses a MC and BRs.
It helps to detect undesirable conditions along a path.
It uses AS pre-pending to influence inbound traffic.
It provides automatic outbound route optimization and load distribution for
multiple connections by selecting the optimal exit point.
It provides external selection of the best destination for each client.
What are three characteristics of GSS? (Chose three.) (Source: Tuning for
E-Commerce)
A)
B)
C)
D)
E)
F)
7-70
It helps verify end-to-end path availability.
HSRP, GLBP, and VRRP can be clients of EOT.
It improves DNS responsiveness by providing centralized domain
management.
It load balances traffic flows 50-50 across two links.
It provides automatic outbound route optimization and load distribution for
multiple connections by selecting the optimal exit point.
It helps identify situations where the network is sending traffic down a path
that is black-holing packets.
What are three characteristics of OER? (Chose three.) (Source: Tuning for
E-Commerce)
A)
B)
C)
D)
E)
Q20)
by communicating the available prefixes, routing policies and preferences of a
site to their ISP
by detecting undesirable conditions along the path to the e-commerce module
by moving the SLB to a position where selected traffic to and from the servers
does not go through the SLB
by tracking the status of objects along the path to the e-commerce module
by using the MED to communicate the site preferences for traffic to multiple
ISPs
It helps verify end-to-end path availability.
HSRP, GLBP, and VRRP can be clients of GSS.
It uses AS pre-pending to influence inbound traffic.
It provides external selection of the best destination for each client.
It provides real-time global load balancing across multiple data centers.
It improves DNS responsiveness by providing centralized domain
management.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Module Self-Check Answer Key
Q1)
C, D
Q2)
B, E
Q3)
A
Q4)
B, E
Q5)
A
Q6)
C
Q7)
B, E
Q8)
D
Q9)
E
Q10)
B, D, E
Q11)
A, B, E
Q12)
C, D, E
Q13)
D
Q14)
B
Q15)
A, C, E
Q16)
B, D
Q17)
A
Q18)
A, B, F
Q19)
B, C, E
Q20)
D, E, F
© 2007 Cisco Systems, Inc.
E-Commerce Module Design
7-71
7-72
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Module 8
Security Services Design
Overview
As enterprises continually expand their mission-critical networks with new intranet, extranet,
and e-commerce applications, network security is increasingly vital to prevent corruption and
intrusion, and eliminate network security vulnerabilities. Without precautions, enterprises could
experience major security breaches, resulting in serious damages or loss.
This module looks at security design. It assumes you already know how to implement firewalls
and security features including access control lists (ACLs), IP security (IPsec) connections,
network address translation (NAT), and port address translation (PAT).
Module Objectives
Upon completing this module, you will be able to design security-intelligent network services
for performance, scalability, and availability, given specified enterprise network needs. This
ability includes being able to meet these objectives:
„
Discuss design considerations for firewall services in the enterprise
„
Describe design considerations for using network admission control services in the
enterprise
„
Discuss design considerations for intrusion detection and prevention services in the
enterprise
8-2
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Lesson 1
Firewall Design Considerations
Overview
Firewalls have long provided the first line of defense in network security infrastructures. They
accomplish this by comparing corporate policies about network access rights for users to the
connection information surrounding each access attempt. User policies and connection
information must match up, or the firewall does not grant access to network resources.
This lesson looks at firewall design considerations. It discusses options for firewall deployment
and topologies including firewall modes, virtual firewalls, asymmetric routing using
active/active topologies, scaling firewall performance, private VLANs, and zone-based
firewalls.
Lesson Objectives
Upon completing this lesson, you will be able to discuss and design firewall services for
enterprise networks. This ability includes being able to meet these objectives:
„
Describe routed and transparent firewall modes
„
Describe considerations for designing virtual firewalls
„
Discuss the active/active firewall topology and its design considerations
„
Describe requirements for asymmetric routing with firewall designs
„
Discuss load balancing options for scaling firewall performance
„
Discuss private VLAN security considerations
„
Discuss zone-based policy firewalls
Firewall Modes
A firewall can run in either routed or transparent mode.
Firewall Mode—Routed or Transparent
Transparent Mode
Routed Mode
10.30.10.0/24
Outside Interface
10.30.10.2/24
10.30.10.0/24
VLAN 30
VLAN 30
Management
Interface
10.30.6.1/24
Inside Interface
10.40.6.1/24
VLAN 40
10.40.6.0 /24
VLAN 40
10.30.10.0 /24
Routed mode:
ƒ Is the traditional firewall mode.
ƒ Is a Layer 3 device with each interface addressed.
Transparent mode:
ƒ Is available starting version 2.2 in FWSM and 7.0 in PIX and ASA.
ƒ Is a Layer 2 device with only management interface per bridge group addressed.
ƒ Supports routing protocols and IP multicast traffic.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—8-4
In the traditional routed mode, the firewall is considered to be a Layer 3 device in the network.
It can perform NAT between connected networks. Routed mode supports many interfaces, and
each interface is on a different subnet and requires an IP address on that subnet.
Transparent mode is a newer mode available since Firewall Service Module (FWSM) 2.2 and
7.0 in the Cisco Adaptive Security Appliance (ASA) devices.
Note
This lesson primarily uses the FWSM as the example firewall. ASA and PIX devices could
be used as well. PIX or ASA operational differences are shown in the lesson.
In transparent mode, the firewall is not a router hop but a Layer 2 device. Per context, the
firewall connects the same network on its inside and outside interface in transparent mode.
Note
A single firewall can be partitioned into multiple virtual devices, known as security
contexts. Each context has its own security policy, interfaces, and administrators.
Firewalls can support multiple pairs of inside and outside interfaces as a bridge group. Each
bridge group connects to a different network. A transparent firewall has one IP address
assigned to the entire bridge group, and uses this management address as the source address for
packets originating on the firewall. Similar to routed mode, transparent mode requires access
lists to allow traffic through the FWSM, except for ARP packets which are allowed
automatically.
8-4
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Note
FWSM and ASA have different access control list (ACL) mechanisms for controlling traffic.
For an ASA, IPv4 traffic is allowed through the transparent firewall automatically from a
higher security interface to a lower security interface, without an access list. ARPs are
allowed through the transparent firewall in both directions without an access list. ARP traffic
can be controlled by ARP inspection. For Layer 3 traffic traveling from a low (originating from
lower security level interface) to a high security interface, an extended access list is
required.
Transparent mode can allow certain types of traffic in an access list that are blocked by routed
mode, including unsupported routing protocols. Routing protocol adjacencies are supported
through a transparent firewall. OSPF, RIP, EIGRP, or BGP traffic is allowed based on an
extended access list. Protocols such as HSRP, VRRP, and IP multicast can be supported
through a transparent firewall. Transparent mode can also optionally use EtherType access lists
to allow non-IP traffic.
© 2007, Cisco Systems, Inc
Security Services Design
8-5
Virtual Firewall Overview
A virtual firewall (VFW) separates multiple firewall security contexts on a single firewall.
Virtual Firewall Overview
Core/Internet
FSWM
VLAN 10
MSFC
VLAN 25
ADMIN
VFW-1
VLAN 11
VFW-2
VLAN 21
A
VFW-3
VLAN 31
B
C
ƒ Specific VLANs are attached to specific security contexts.
– Up to 250 contexts on the FWSM
ƒ Administrative context isused for network connectivity.
ƒ Each context has its own policies (NAT, access lists, protocol fixups, etc.).
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—8-6
Specific VLANs are tied to a specific security context. In routed mode, up to 256 VLANs can
be assigned to a context. The FWSM has an overall limit of 1000 VLAN interfaces divided between
all contexts. Up to 250 contexts are supported on a FWSM depending on the software license..
Each context has its own policies such as NAT, access lists, and protocol fixups.
The Cisco Firewall Service Module (FSWM) uses the administrative context for network
connectivity and to assign VLANs to contexts. With the default FWSM software, up to two
security contexts and the administrative context are provided.
Note
8-6
The FWSM does not include any external physical interfaces. VLAN interfaces are
assigned to the FWSM similar to assigning a VLAN to a switch port. The FWSM
includes an internal interface to the Switch Fabric Module (if present) or the shared bus.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Firewall Context Design Considerations
Resources classes are important to firewall operations because multiple contexts can use a
resource class.
Firewall Context Design Considerations
Context
Soft Drinks
Default Class
Silver Class
Gold Class
(Some Limits
Set)
Bronze Class
(Some Limits Set)
(All Limits Set)
Context
Soda
Context
Tonic
Context
Pop
Context
Water
Note: Limits set in default class are the base for all other classes and
contexts not assigned to a class.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—8-7
An attack or anomaly on one context can impact another context. All contexts belong to the
default class if they are not assigned to another class. If a context belongs to a class other than
the default class, those class settings always override the default class settings. However, if a
class has any settings that are not defined, then the member context uses the default class for
those limits. By default, all security contexts have unlimited access to the resources of the
FWSM or security appliance, except where maximum limits per context are enforced. If one or
more contexts use too many resources, they cause other contexts to be denied connections.
Resource management limits the use of resources per context.
Note
The FWSM does not limit the bandwidth per context; however, the switch containing the
FWSM can limit bandwidth per VLAN.
The FWSM and security appliances manage resources by assigning contexts to resource
classes. Each context uses the resource limits set by the class. If some resources are
oversubscribed, or some resources are unlimited, a few contexts can use up those resources,
potentially affecting service to other contexts. As a recommended practice, set limits for all
resources together as a percentage of the total available for the device and set the limit for
individual resources as a percentage or as an absolute value.
The FWSM and security appliances are subject to oversubscription if more than 100 percent of
the resources are assigned across all contexts. For example, if the Bronze class is set to limit
connections to 20 percent per context, and 10 contexts are assigned to the class, a total of 200
percent is allocated. If contexts concurrently use more than the system limit, then each context
© 2007, Cisco Systems, Inc
Security Services Design
8-7
gets less than the 20 percent you intended and some connections will be denied because the
system limit is reached.
MSFC Placement
The Multilayer Switch Feature Card (MSFC) can be placed on the inside or the outside of the
firewall depending on the VLANs assigned to the FWSM.
MSFC Placement—Inside or Outside
Internet
Internet
ƒ MSFC can be placed on
the inside or the outside
of the firewall.
– Is configured based
on the VLAN
assignment.
ƒ Placing the MSFC inside
the firewall secures the
MSFC.
ƒ Placing the MSFC
outside makes design
and management easier.
VLAN 100
VLAN 101
MSFC
FWSM
VLAN 201
VLAN 200
FWSM
MSFC
VLAN 2
VLAN 9
VLAN 4
VLAN 6
MSFC
Outside
of FWSM
© 2007 Cisco Systems, Inc. All rights reserved.
VLAN 5
VLAN 7
MSFC
Inside of
FWSM
ARCH v2.0—8-8
In the figure, the MSFC is outside of the firewall when VLAN 200 is assigned to the outside
interface of the FWSM. The FWSM processes and protects all traffic to the inside VLANs 2, 4,
and 6. The MSFC routes between the Internet and the switched networks. Placing the MSFC
outside the FWSM makes design and management easier.
The MSFC is inside of the firewall when VLAN 101 is assigned to the outside interface of the
FWSM. The MSFC routes between VLANs 201, 5, 7, and 9. No inside traffic goes through the
FWSM unless it is destined for the Internet. The FWSM secures the MSFC.
For multiple context mode, if the MSFC is placed inside the FWSM, it should only connect to a
single context. If the MSFC connects to multiple firewall contexts, the MSFC will route
between the contexts which might not be your intention.
Note
8-8
The typical scenario for multiple contexts is to use the MSFC outside of the FWSM and to
have the MSFC route between the Internet and the switched networks and between
contexts.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Active/Active Firewall Topology
The active/active firewall topology uses two firewalls that are both actively providing firewall
services.
Active/Active Firewall Topology
.1
VLAN 1200
TOP
102.102.102.0/24
.1
202.202.202.0 VLAN 1201
North
FWSM-1
.2
#1 act
.50
FWSM-2
.3
#2
sby
Ctx
A
.51
.3
#1
sby
Ctx
A
.51
Failover
Trunk
.2
#2 act
.50
South
VLAN 1102
VLAN 1101
101.101.101.0/24
.1
.1
Down
.1
VLAN 100
Server
10.10.10.100
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—8-10
When a FWSM is running in virtual firewall mode, it is possible to use active/active
redundancy. In the active/active topology, the security contexts on the FWSM are divided into
failover groups. A failover group is a logical group of one or more security contexts. The
FWSM supports a maximum of 2 failover groups. The administrative context is always a
member of failover group 1, and any unassigned security contexts are by default also members
of failover group 1.
In the figure, FWSM-1 and FWSM-2 are each configured with two failover groups. FSWM-1 is
active for group 1, and standby for group 2. FSWM-2 is active for group 2, and standby for
group 1. The first VFW is mapped to group 1, while the second VFW is mapped to group 2.
© 2007, Cisco Systems, Inc
Security Services Design
8-9
Active/Active Topology Features
This section identifies several of the important features of the active/active topology.
Active/Active Topology Features
ƒ Two identical FWSMs are connected through a dedicated failover
link.
– Virtual firewalls are mapped to a failover group.
– Failover group status is active or standby.
– Active state of both failover groups with all contexts can be
assumed by either FWSM.
ƒ Failover can be configured as preemptive:
– FWSM with higher priority for a failover group regains active
role.
ƒ For failover link redundancy, EtherChannels are used from
separate linecard modules.
ƒ Design supports load balancing in network.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—8-11
The active/active failover configuration requires two identical FWSMs connected to each other
through a dedicated failover link and optionally a state link using an inter-chassis design.
Note
The active/active failover configuration can also be supported with redundant FWSM in a
single chassis. The failover link is a VLAN.
The health of the active interfaces and units is monitored to determine if specific failover
conditions are met. If those conditions are met, failover occurs. The MAC address of the
primary unit is used by all interfaces in the active contexts. When an active failover group fails,
it changes to the standby state while the associated standby failover group becomes active. The
interfaces in the failover group that becomes active assume the MAC address and IP addresses
of the interfaces in the failover group that failed.
This design supports preemption so that the FWSM with a higher priority will resume an active
role after recovering from a failure condition.
Additional redundancy is supported if links from separate modules are used to form the Gigabit
Ethernet EtherChannels supporting the failover trunk and state traffic VLANs.
Since both devices can pass network traffic with active/active topology, this design supports
load balancing in the network.
8-10
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Asymmetric Routing with Firewalls
The FWSMs support asymmetric routing where return traffic for a session is received through a
different interface than the interface where the traffic originated.
Asymmetric Routing
ƒ ASR groups supports asymmetric routing for a connection.
– Use the asr-group command to configure.
– Supports up to eight interfaces in an ASR group.
– Supports up to 32 groups per FWSM.
ƒ Operates in failover and non-failover configurations.
ƒ Operates in both routed and transparent modes.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—8-13
Asymmetric routing most commonly occurs when two interfaces on a single FWSM, or two
FWSMs in a failover pair, are connected to different service providers and the outbound
connection does not use a NAT address. By default, the FWSM drops the return traffic because
there is no connection information for the traffic received through a different interface than the
interface where the traffic originated.
Asymmetric routing of the return traffic is supported by using the asr-group interface
command. The FSWM supports up to 32 ASR groups. Each ASR groups supports a maximum
of 8 interfaces. Asymmetric routing is supported in the active/active failover redundancy mode,
and in designs without failover redundancy in either single mode or within a virtual firewall by
using asymmetric routing (ASR) groups. Asymmetric routing is supported in both the routed
and transparent modes of firewall operation.
© 2007, Cisco Systems, Inc
Security Services Design
8-11
Asymmetric Routing with ASR Group on a Single FWSM
Interfaces inside a common ASR group support packets belonging to a given session to enter
and leave from any interface within the ASR group.
Asymmetric Routing with ASR Groups
on a Single FWSM
ƒ Any interface inside a
common ASR group supports
packets for a given session.
ƒ After valid SYN packet,
FWSM accepts returning
SYN-ACK segment on
another interface in ASR
group.
Top
Inbound
Session Traffic
A
B
Out-one
Out-two
FWSM
Outbound
Session Traffic
Client
10.20.10.100
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—8-14
When an interface configured with the asr-group command receives a packet for which it has
no session information, it checks the session information for the other interfaces that are in the
same group. If it does not find a match, the packet is dropped. If it finds a match, and the
incoming traffic originated on a different interface on the same unit, some or all of the Layer 2
header is rewritten and the packet is re-injected into the stream and forwarded to the intended
host.
After valid SYN is sent out an ASR group interface, the FWSM will accept a returning
SYN-ACK on another interface in ASR group.
8-12
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Asymmetric Routing with Active/Active Topology
Interfaces inside a common ASR group in an active/active topology also support asymmetric
routing.
Asymmetric Routing with Active/Active
Topology
Server
10.10.10.100
Top
VLAN W
Inbound
Session
Traffic
VLAN X
FWSM-1
Ctx AA
Ctx
Ctx B
Forwarded
Inbound
Session
Traffic
FWSM-2
Ctx A
B
Ctx B
Failover
Trunk
VLAN Y
VLAN Z
Outbound
Session Traffic
© 2007 Cisco Systems, Inc. All rights reserved.
Down
Client
10.20.10.100
ARCH v2.0—8-15
In the active/active topology, when an interface configured with the asr-group command
receives a packet for which it has no session information, it checks the session information for
the other interfaces that are in the same group. If it does not find a match, the packet is dropped.
If it finds a match, and the incoming traffic originated on a peer unit that was active for the
context, some or all of the Layer 2 header is rewritten and the packet is redirected to the active
peer.
The figure shows that the traffic is forwarded though the outside interface of context A on the
unit where context A is in the standby state and returns through the outside interface of context
A on the unit where context A is in the active state. This redirection continues as long as the
session is active.
© 2007, Cisco Systems, Inc
Security Services Design
8-13
Performance Scaling with Multiple FWSMs
For high throughput, up to four FWSMs can be installed in a single chassis using an
active/active design. This section discusses two methods to load balance multiple FWSMs:
1. Traffic engineering mechanisms, such as Policy-based Routing (PBR), to selectively steer
traffic through multiple FWSMs
2. Routing, such as static or Equal Cost Multipath Routing (ECMP), to direct flows per
FWSM
Example: Load Balancing FWSMs
Using Policy-Based Routing
GATE
Routing is not by
destination address:
ƒ Can use source IP
address or application
type.
6500
MSFC
FWSM
ƒ Can support redundant
paths.
ƒ Can support
asymmetric routing.
© 2007 Cisco Systems, Inc. All rights reserved.
FWSM
FWSM
FWSM
6500
Server Farm
ARCH v2.0—8-17
Example: Load Balancing FWSMs Using Policy-Based Routing
PBR is a mechanism for implementing packet forwarding and routing according to policies
defined by the network administrator instead of paths selected by traditional routing methods.
Instead of routing by the destination address as determined by a routing protocol, PBR uses
more flexible methods such as source IP addresses or application types to match on the identity
of the user and then selects the forwarding path. A redundant path could be configured in the
event of a link failure or the device going down.
The figure shows load balancing multiple FWSMs in an active/active design using PBR
supported by the gateway router. A source-based selection method is used to determine
destination firewall path. This is a static load sharing method based on class maps and route
maps to divide traffic among multiple FWSMs. The route maps are configured with
redundancy so that if the first FWSM goes down, a backup FWSM is used.
8-14
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Example: Load Balancing FWSMs
Using Equal Cost Multipath Routing
ƒ Routing is by source
address.
6500
ƒ Selectively routes traffic
through each FWSM.
ƒ Can support asymmetric
routing.
6500
FWSM
FWSM
FWSM
FWSM
MSFC
Server Farm
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—8-18
Example: Load Balancing FWSMs Using ECMP Routing
Static routing or ECMP routing can also be used to selectively route traffic through each of the
FWSMs. Care must be taken to ensure that the return path goes through the same firewall, or
that the FWSM support asymmetric routing in an active/active design.
The figure shows load balancing multiple FWSMs in an active/active design using ECMP
routing. The standard destination-based selection method is used by the routing protocol to
determine which FWSM to use. If a FWSM goes down, the routing protocol will automatically
load balance the traffic across the remaining FWSMs.
© 2007, Cisco Systems, Inc
Security Services Design
8-15
Private VLAN Security
This topic discusses how private VLANs (PVLANs) can be used to provide security in the
enterprise campus.
PVLAN Review
PVLANs allow Layer2 isolation between ports within a VLAN.
Private VLAN Review
Promiscuous Port
Primary VLAN
Community VLAN
Community VLAN
Isolated VLAN
x x x
x
Community
‘A’
© 2007 Cisco Systems, Inc. All rights reserved.
Community
‘B’
Isolated
Ports
ARCH v2.0—8-20
In a regular VLAN, all ports can communicate. PVLANs provide Layer 2 isolation between the
ports within the same private VLAN without having to rely on separate VLANs for each port
and on subnetting. PVLANS provide a logical separation of the network that keeps traffic
isolated.
The ports that belong to a private VLAN are associated with a set of primary, community, and
isolated VLANs that are used to create the private VLAN structure. A private VLAN domain
has one primary VLAN. Every port in a private VLAN domain is a member of the primary
VLAN. Secondary VLANs provide Layer 2 isolation between ports within the same private
VLAN domain. There are two types of secondary VLANs:
„
Isolated VLANs—Ports within an isolated VLAN cannot communicate with each other at
the Layer 2 level.
„
Community VLANs—Ports within a community VLAN can communicate with each other
but can not communicate with ports in other communities at the Layer 2.
There are three types of private VLAN ports:
„
8-16
Promiscuous—This port communicates with all other private VLAN ports and is the port
used to communicate with network devices including routers, backup servers, and
administrative workstations. This port listens to the secondary VLANs, and send traffic
using the primary VLAN.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
„
Isolated—This port has complete Layer 2 separation from the other ports within the same
private VLAN with the exception of the promiscuous port. Isolated ports use a secondary
VLAN to send traffic out and block any traffic coming from the secondary VLAN. All the
isolated ports in the system can share the same secondary VLAN.
„
Community—These ports communicate among themselves and with their promiscuous
ports. These ports are isolated at Layer 2 from all other ports in other communities and
from isolated ports. A separate secondary VLAN is allocated for each community.
Note
© 2007, Cisco Systems, Inc
If a broadcast or multicast packet comes from the promiscuous port, it is sent to all the ports
in the private VLAN domain including all community and isolated ports.
Security Services Design
8-17
FWSM in PVLAN Environment - Isolated Ports
The FWSM 3.1 supports private VLANs with Cisco IOS Software 12.2(18)SXF.
FWSM in PVLAN Environment
Isolated Ports on FWSM in Routed Mode
ƒ PVLANs are popular in DMZ
and server farms.
Layer 3
ƒ Primary VLAN are assigned to
the FWSM.
– Primary and secondary
VLAN mapping are provided
by the MSFC.
ƒ Hosts in the isolated PVLAN
are segregated.
Routed Mode
MSFC
VLAN 822
FWSM
VLAN 1000
Primary VLAN
Secondary VLAN
VLAN 500
6500
– FWSM will not route packets VLAN 500
back out the interface they
came in from.
Layer 2
VLAN 500
Layer 2
10.10.10.100
10.10.10.101
Isolated Ports
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—8-21
PVLANs provide an easy way to implement Layer 2 traffic segregation within a VLAN. This
feature is popular in DMZ and server farm designs.
On a Cisco Catalyst 6500 Series switch, the primary and secondary VLANs are configured on
the supervisor. From the perspective of the Multilayer Switch Feature Card (MSFC) router
integrated in the switch, the FWSM is sitting on a promiscuous port and sees all traffic to and
from the PVLAN. Only the primary VLAN is assigned to the FWSM, but is it made aware of
the primary and secondary VLAN mappings through the MSFC. The FWSM automatically
supports isolation of the secondary VLAN traffic to the community and isolated VLANs. The
FWSM acts as a gateway between hosts on the PVLANs and the outside world.
The figure illustrates the use of PVLANs supporting isolated ports with the FWSM in
routed mode. Isolated ports are separated at Layer 2 by the switch processor. Outbound
traffic from an isolated port is sent by the FSWM to the MSFC which routes the traffic
appropriately. The FWSM will not forward traffic between isolated ports, since the FWSM will
not route packets back out the interface they came in from. Inbound traffic for the isolated port
is sent by the MSFC to the FWSM, which sends it to the switch processor. The switch
processor forwards the packets to the isolated port based on MAC address.
8-18
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
FWSM in PVLAN Environment - Community VLANs
Community VLANs are supported by Layer 2 functions in the switch processor.
FWSM in PVLAN Environment
Community Ports on FWSM in Routed Mode
ƒ Hosts in the community PVLAN
can communicate with each
other:
Layer 3
MSFC
Routed Mode
VLAN 822
– Outbound traffic is seen by
all devices in the VLAN.
FWSM
– Inbound traffic is forwarded
by the FWSM to the
community VLAN.
VLAN 501, 1000
Primary VLAN
6500
Secondary VLAN
VLAN 501
Layer 2
10.10.11.110
10.10.11.111
Community VLAN
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—8-22
The figure illustrates the use of community VLANs with the FWSM in routed mode.
Community ports are interconnected at Layer 2 by the switch processor. Outbound
traffic from a community port is seen by all devices on the community VLAN including the
FWSM. The FSWM will forward outbound traffic to the MSFC which routes the traffic
appropriately. Inbound traffic for the community port is sent by the MSFC to the FWSM,
which sends it community VLAN. The Layer 2 switch processor forwards to the appropriate
community port or ports based on MAC address.
© 2007, Cisco Systems, Inc
Security Services Design
8-19
Zone-Based Policy Firewall
The zone-based policy firewall configuration model is new design supported by the Cisco IOS
Firewall feature set.
Zone-Based Policy Firewall
DMZ
Untrusted
Trusted
ƒ ZPF is a new Cisco IOS Firewall configuration model:
– Interfaces are assigned to zones.
– Policies are applied to traffic moving between zones, not interfaces.
ƒ ZPF is more flexible and more easily understood:
– Firewall configuration and troubleshooting is based on the explicit policy
on inter-zone traffic.
– Default policy is to deny all between zones.
– Multiple traffic classes and actions can be applied per zone pair.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—8-24
Zone-based policy firewall (ZPF) changes the design model from the older interface-based
model to a zone-based configuration model. The ZPF configuration model assigns interfaces to
zones, and applies an inspection policy to traffic moving between the zones. Zones establish the
security borders of the network. A zone defines a boundary where traffic is subjected to policy
restrictions as it crosses to another region of the network.
A security zone is configured for each region of relative security within the network, so that all
interfaces that are assigned to the same zone are protected with a similar level of security. For
example, the figure shows an access router with three interfaces each assigned to its own zone:
„
One interface connected to the public Internet
„
One interface connected to a private trusted LAN that must not be accessible from the
public untrusted Internet
„
One interface connected to an Internet service demilitarized zone (DMZ), where a Web
server, Domain Name System (DNS) server, and e-mail server must be accessible to the
public Internet.
In this figure, each zone holds only one interface. If an additional interface is added to the
private zone, the hosts connected to the new interface in the zone would be able to pass traffic
to all hosts on the existing interface in the same zone. Traffic to hosts in other zones would be
similarly affected by existing policies.
ZPF allows a more flexible, more easily configuration model. Firewall policy troubleshooting
is based on the explicit policy on inter-zone traffic. The ZPF default policy between zones is to
deny all. If no policy is explicitly configured, all traffic moving between zones is blocked. This
8-20
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
is a significant departure from stateful inspection model, in which traffic was implicitly allowed
unless it was explicitly blocked with an access control list (ACL). Traffic is implicitly allowed
to flow by default among interfaces that are members of the same zone.
Inter-zone policies offer considerable flexibility and granularity, so different inspection policies
can be applied to multiple host groups connected to the same router interface. Multiple traffic
classes and actions can be applied per zone-pair.
© 2007, Cisco Systems, Inc
Security Services Design
8-21
Summary
This topic summarizes the key points discussed in this lesson.
Summary
ƒ In the traditional routed mode, the firewall is considered to be a
Layer 3 device. In transparent mode, the firewall is a Layer 2
device.
ƒ A VFW separates multiple firewall security contexts on a single
firewall.
ƒ The active/active firewall topology uses two firewalls that are both
actively providing firewall services.
ƒ FWSMs 3.1 support asymmetric routing.
ƒ Firewall performance can be scaled using up to four FWSMs in a
chassis using load balancing.
ƒ PVLANs allow Layer 2 isolation between ports within a VLAN.
ƒ The zone-based policy firewall model applies an inspection policy
to traffic moving between the zones.
© 2007 Cisco Systems, Inc. All rights reserved.
8-22
Designing Cisco Network Service Architectures (ARCH) v2.0
ARCH v2.0—8-25
© 2007 Cisco Systems, Inc.
Lesson 2
Network Admission Control
Design
Overview
Network admission control (NAC) is a set of technologies and solutions built on an industry
initiative led by Cisco Systems. NAC uses the network infrastructure to enforce security policy
compliance on all devices seeking to access network computing resources, thereby limiting
damage from emerging security threats such as viruses, worms, and spyware. Customers using
NAC can allow network access only to compliant and trusted endpoint devices (PCs, servers,
and PDAs, for example) and can restrict the access of noncompliant devices.
Lesson Objectives
Upon completing this module, you will be able to discuss and design network admission
control services. This ability includes being able to meet these objectives:
„
Discuss methods to provide network security with access control
„
Discuss NAC Appliance fundamentals
„
Describe NAC Appliance deployment optionsDescribe NAC Appliance designs
„
Discuss the NAC Framework
„
Describe Cisco client security software
Network Security with Access Control
Network security services can be enhanced with access control.
Network Access Control
ƒ Identity-Based Networking Services (IBNS)
– Identifies and authenticates the user or
device on the network and ensures
access to correct network resources.
– 802.1X provides port-based access
control and operates at Layer 2.
ƒ Network Admission Control (NAC)
– Performs posture validation to ensure
that only compliant machines can
connect to the network.
– NAC provides posture assessment and
device containment at Layer 3 or
Layer 2.
ƒ IBNS and NAC are complementary
functions.
© 2007 Cisco Systems, Inc. All rights reserved.
Si
Si
Edge Access Control
ARCH v2.0—8-29
Cisco Identity Based Networking Services (IBNS) is an integrated solution combining several
Cisco products that offer authentication, access control, and user policies to secure network
connectivity and resources. Cisco IBNS solution enables greater security while simultaneously
offering cost-effective management of changes throughout the organization. The IBNS
framework allows enterprises to manage user mobility and reduce the overhead costs associated
with granting and managing access to network resources. 802.1x authenticates clients
requesting Layer 2 (link layer) access to the network. However, with IBNS users and devices
are authenticated and allowed admission to the network based on who or what they are, but not
their condition.
Network Admission Control (NAC) helps ensure that only healthy client devices, such as
workstations and end-user PCs, are granted full network access. Cisco NAC agent loaded on
the client device queries anti-virus, patch management, and personal firewall client software to
assess the condition or posture of a client device before allowing that device network access.
NAC helps ensure that a network client has an up-to-date virus signature set, the most current
operating system patches, and is not infected. If the client requires an anti-virus signature
update or an operating system update, NAC directs the client to complete the necessary updates
before allowing access to the protected network resources. If the client has been compromised
or if a virus outbreak is occurring on the network, NAC places the client into a quarantined
network segment. After the client has completed its update process or disinfection, the client is
checked again. Clients with a healthy status are permitted normal network access.
IBNS/802.1x and NAC provide complementary functions: user authentication and posture
validation.
8-24
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Network Admission Control Comparison
This section compares NAC Appliance and NAC Framework.
Network Admission Control Comparison
Network
Access
Devices
Hosts Attempting
Network Access
Policy Server
Decision Points
and Remediation
Enforcement
Cisco NAC
Framework
Cisco
Posture
Agent
Credentials
Credentials
EAP/UDP,
Access Rights
Notification
Credentials
Vendor
Servers
HTTPS
RADIUS
EAP/802.1x
Cisco NAC
Appliance
AAA
Server
Comply?
Cisco NAM
Cisco
NAA
Credentials
Credentials
UDP (discovery)
SSL
SNMP
Notification
Cisco
NAS
© 2007 Cisco Systems, Inc. All rights reserved.
Comply or Fix
Cisco.com
Update Server
(Windows. Symantec,
McAfee, Trend, Sophos,
Zone, CA, etc.)
ARCH v2.0—8-30
Cisco supports two flavors of NAC:
„
The Cisco NAC Framework is technology standard that integrates an intelligent network
infrastructure with solutions from more than 60 manufacturers of leading antivirus and
other security and management software solutions to enforce security policy compliance on
all devices seeking to access network computing resources. The Cisco NAC Framework is
embedded software modules within NAC-enabled products that provide ubiquitous across
all network access methods. Posture information can be gathered and access policy
enforced for hosts attempting network access through routers, switches, wireless access
points, and VPN concentrators. The NAC Framework leverages multiple Cisco and NACaware vendor products.
„
Cisco NAC Appliance (formerly called Cisco Clean Access) is a turnkey solution for
controlling and securing networks. The Cisco NAC Appliance condenses NAC capabilities
into an appliance form. The Cisco NAC Appliance client, server, and manager products
allow network administrators to authenticate, authorize, evaluate, and remediate wired,
wireless, and remote users and their machines prior to allowing users onto the network. It
identifies whether networked devices such as laptops, IP phones, personal digital assistants,
or printers are compliant with an organization's security policies, and repairs any
vulnerabilities before permitting access to the network.
© 2007, Cisco Systems, Inc
Security Services Design
8-25
NAC Appliance Fundamentals
This topic discusses fundamentals of the Cisco NAC Appliance including components and
terminology.
NAC Appliance Components
The Cisco NAC Appliance is an admission control and compliance enforcement solution.
NAC Appliance Components
Cisco NAC Appliance Manager (Cisco
NAM)
ƒ Centralizes management for administrators, support
personnel, and operators.
Cisco NAC Appliance Server (Cisco NAS)
ƒ Serves as an in-band or out-of-band device for network
access control.
Cisco NAC Appliance Agent (Cisco NAA)
ƒ Provides an optional Windows-based read-only client
that validates what must or must not be running before
a host is allowed network access.
Rule-set Updates
ƒ Supports scheduled automatic updates for anti-virus,
critical hot-fixes and other applications.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—8-32
There are four components comprising the Cisco NAC Appliance:
8-26
„
Cisco NAC Appliance Manager (Cisco NAM)—Administration server for Cisco NAC
Appliance deployment where the policies are defined. The secure web console of the Cisco
NAM is the single point of management for up to 20 Cisco NAC Appliance Servers in a
deployment (or 40 NASes in a Super-NAM installation). The NAM acts as the
authentication proxy to the authentication servers that reside on the back end. For Out-ofBand (OOB) deployment, the NAM console allows control of switches and VLAN
assignment of user ports through the use of SNMP.
„
Cisco NAC Appliance Server (Cisco NAS)—Enforcement server between the untrusted
(managed) network and the trusted network. The Cisco NAS enforces the policies defined
in the NAM web console, including network access privileges, authentication requirements,
bandwidth restrictions, and Cisco NAC Appliance system requirements. It can be deployed
in-band (always inline with user traffic) or out-of-band (inline with user traffic only during
authentication and posture assessment). It can also be deployed in Layer-2 mode (users are
Layer 2-adjacent to NAS) or Layer-3 mode (users are multiple Layer 3 hops away from the
NAS).
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
„
Cisco NAC Appliance Agent (Cisco NAA)—Optional read-only agent that resides on
Windows clients. The Cisco NAA checks applications, files, services or registry keys to
ensure that clients meets specified network and software requirements prior to gaining
access to the network.
„
NAC Appliance Policy Updates—Regular updates of pre-packaged policies and rules that
can be used to check the up-to-date status of operating systems, antivirus, antispyware, and
other client software. The Cisco NAC Appliance Policy Updates currently provide built-in
support for 24 antivirus vendors and 17 antispyware vendors.
Example: Clean Access Policy Updates
Critical Windows Updates
Windows XP, Windows
2000, Windows 98, Windows ME
Anti-Virus Updates
Anti-Spyware Updates
Other 3rd Party Checks
Cisco
Security
Agent
Note: Customers can easily add customized checks.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—8-33
Example: Cisco NAC Appliance Policy Updates
Automatic security policy updates provided by Cisco as part of the standard software
maintenance package deliver predefined policies for the most common network access criteria,
including policies that check for critical operating system updates, common antivirus software
virus definition updates, and common antispyware definition updates.
The figure show some of the software applications supported. The Cisco NAC Appliance is
preconfigured to offer policy checks for more than 200 applications from 50 vendors.
Note
For the latest supported applications, please review the release notes under "Clean Access
Supported AV/AS Product List” at
http://www.cisco.com/en/US/products/ps6128/prod_release_notes_list.html.
In addition to the preconfigured checks, the customer has full access to the Cisco NAC
Appliance rules engine and can create any custom check or rule for any other third-party
application.
© 2007, Cisco Systems, Inc
Security Services Design
8-27
Example: Process Flow with NAC
Appliance
1
End user attempts to
access network
NAM
Authentication
Server
NAS
2 User is redirected
Intranet/
Network
to a login page
3b Device is “clean”
3a Device is noncompliant
or login is incorrect
Quarantine
Role
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—8-34
Example: Process Flow with NAC Appliance
The figure illustrates the process flow with NAC Appliance:
1. The end user attempts to access a Web page or use the Intranet.
2. The user is redirected to a login page. The NAC Appliance validates username and
password, and also performs device and network scans to assess vulnerabilities on the
device.
3a. If the device is noncompliant to corporate policies or the login is incorrect, the user is
denied access to the network and assigned to a quarantine role with access only to online
remediation resources.
Note
After remediation, the user returns to step 2 for validation and scanning.
3b. If the login is correct and the device is compliant to the policies, the device is placed on the
certified devices list and is granted access to network.
8-28
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
NAS Scaling
This topic looks at scaling servers and managers in the NAC Appliance solution.
NAC Appliance Solution Sizing
Super Manager
manages up to 40
Users = online, concurrent
Enterprise and
Branch Servers
Standard
Manager
manages up to 20
Enterprise and
Branch Servers
Manager Lite
manages up to 3
1500 or 2500
users each
Branch Office
or SMB Servers
1500 or 2500
users each
100 users 250 users 500 users
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—8-35
There are three levels of NAM for supporting NAC Appliance solutions:
„
Cisco NAC Appliance Lite Manager manages up to 3 NAS supporting 100, 250, or 500
users per server.
„
Cisco NAC Appliance Standard Manager manages up to 20 NAS supporting 1500 or 2500
users per server.
„
Cisco NAC Appliance Super Manager manages up to 40 NAS supporting 1500 or 2500
users per server.
© 2007, Cisco Systems, Inc
Security Services Design
8-29
Server Scaling Numbers
Values apply to
concurrent postureassessed users only,
NOT concurrent devices.
Bandwidth is the least
important calculation for
determining how many
users a NAS can support.
Factors included are
numerous:
ƒ Number of new user
authentications per second
ƒ Number of posture
assessments per second
ƒ How many checks are in
each posture assessment
ƒ Number of agent-less
network scans per second
ƒ Number of plug-ins per scan
ƒ Rescan timer intervals
ƒ Per role and total online timer
intervals
ƒ Bandwidth controls
ƒ Filters and access controls
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—8-36
Users supported on a server is a measure of concurrent users that have been scanned for posture
compliance, not network devices such as printers or IP phones.
The number of users supported per server is influenced by many factors that consume CPU and
server resources:
„
Number of new user authentications per second
„
Number of posture assessments per second
„
How many checks are in each posture assessment
„
Number of agent-less network scans per second
„
Number of plug-ins per scan
„
Rescan timer intervals
„
Per role and total online timer intervals
„
Bandwidth controls
„
Filters and access controls
Note
8-30
Interface bandwidth is the least important calculation for determining how many users a NAS
can support.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
NAS Deployment Options
This topic describes the deployment options for the NAS.
NAS Deployment Options
ƒ Virtual or real gateway mode
ƒ In-band or out-of-band operating mode
ƒ Layer 2 or Layer 3 client access deployment
ƒ Central or edge deployment
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—8-38
There are four deployment variables with NAS deployments:
„
Virtual gateway or real gateway which determines if the NAS acts as a Layer 2 or Layer 3
device in the network.
„
In-band or out-of-band operating mode which defines when traffic flows through the NAS.
„
Layer 2 or Layer 3 client access mode which defines whether user devices are Layer 2 or
Layer 3 adjacent to the NAS.
„
Central or edge physical deployment which determines whether the NAS devices is
physically inline with the traffic path.
Note
© 2007, Cisco Systems, Inc
These variables are discussed in this section.
Security Services Design
8-31
NAS Gateway Modes
There are three NAS gateway modes.
NAS Gateway Modes
Virtual Gateway
NAS
10.1.1.1
Intranet/
Network
10.1.1.5
10.1.1.3
Real-IP Gateway
NAT Gateway
NAS
Intranet/
Network
10.1.1.5
10.1.1.3
© 2007 Cisco Systems, Inc. All rights reserved.
172.16.2.1
ARCH v2.0—8-39
The NAS can operate as a logical Layer 2 or Layer 3 network device depending on the gateway
mode configured:
„
In a Virtual Gateway mode, the NAS operates as a standard Layer 2 Ethernet bridge, but
with added functionality provided by the IP filter and IP Security (IPsec) module. This
configuration is typically used when the untrusted network already has a Layer 3 gateway,
and is the most common deployment option.
„
In the Real-IP Gateway mode, the NAS operates as the Layer 3 default gateway for
untrusted network (managed) clients. All traffic between the untrusted and trusted network
passes through the NAS, which applies the IP filtering rules, access policies, and any other
traffic handling mechanisms that are configured. NAS is designated as a static route for the
managed subnet, and can perform DHCP services or act as a DHCP relay.
„
In the NAT Gateway mode, the NAS functions similarly to the Real-IP Gateway
configuration as a Layer 3 gateway, but adds Network Address Translation (NAT) services.
With NAT, clients are assigned IP addresses dynamically from a private address pool. The
NAS performs the translation between the private and public addresses as traffic is routed
between the untrusted (managed) and external network. The NAS supports standard,
dynamic NAT and 1:1 NAT. In 1:1 NAT, there is a one-to-one correlation between public
and private addresses. With 1:1 NAT, port numbers as well as IP addresses can be mapped
for translation.
Note
8-32
The NAT Gateway mode is primarily intended to facilitate testing, as it requires the least
amount of network configuration and is easy to initially set up. However, because it is limited
in the number of connections it can handle, NAT Gateway mode (in-band or out-of-band) is
not supported for production deployment.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
The installation type and operating mode determines the services the NAS will provide. For
example, the NAS can operate as a bridge between the untrusted and trusted network, or it can
operate as a gateway for the untrusted network.
NAS Operating Modes
NAS has two traffic flow deployment models, in-band (IB)or out-of-band (OOB).
NAS
NAS Operating Modes
In-Band:
ƒ Easiest deployment
VLAN 110
VLAN 10
ƒ NAS remains in traffic path
ƒ Ongoing ACL filtering and role
based access control
VLAN 10
Out-of-Band:
VLAN 110
NAS
ƒ NAS in traffic path only during
posture assessment
ƒ VLAN port based and role
based access control
ƒ ACL filtering during posture
assessment
VLAN 10
VLAN 10
VLAN 110
VLAN 110, 10
Note: IB is supported on any switch, hub, or access point. OOB
is supported on common Cisco switches.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—8-40
Any NAS can be configured for either method, but a NAS can only be one at a time. Selection
of mode is based on whether the customer wants to remove the NAS from the data path after
posture assessment.
IB traffic flow is the easiest deployment option. The NAS remains in the traffic path before and
after posture assessment. In-band operation provides ongoing ACL filtering and bandwidth
throttling as well as role based access control.
OOB traffic flow has the NAS in the traffic path only during the posture assessment. OOB
mode provides port VLAN based and role based access control. ACL filtering and bandwidth
throttling are provided only during posture assessment.
Note
© 2007, Cisco Systems, Inc
IB is supported with the NAS connected to any switch, hub, or access point. OOB is
supported with the NAS connected to most common Cisco switches with recent software
releases.
Security Services Design
8-33
NAS Client Access Modes
This section discusses the NAS client access deployment modes.
NAS Client Access Modes
Layer 2 NAS
ƒ Layer 2 Mode
– MAC address of client is used
to identify device.
VLAN 10
– Is most common deployment
mode for LANs.
VLAN 110
ƒ Layer 3 Mode
– IP and MAC address of client
is needed to identify device.
VLAN 10
VLAN 110
Layer 3 NAS
ƒ Client access mode is
independent from NAS operating
mode.
VLAN 10
ƒ NAS can be configured for either
mode, but only one at a time.
VLAN 110
VLAN 10
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—8-41
The client access deployment mode selection is based on whether the client is Layer 2 adjacent
to the NAS:
„
Layer 2 Mode. The MAC address of the client device is used to uniquely identify the
device. This mode supports both Virtual Gateway and the Real-IP Gateway operations in
both IB and OOB deployments. This is the most common deployment model for LANs.
„
Layer 3 Mode. The client device is not Layer 2 adjacent to the NAS. The IP (and MAC
starting with NAA v. 4 in L3 OOB applications) address of the client is used to identify the
device. This mode supports both Virtual Gateway and the Real-IP Gateway operations with
IB and OOB deployments.
Any NAS can be configured for either client access method, but a NAS can only be one at a
time. Client access mode is configured independently from NAS operating mode.
8-34
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Physical Deployment Models
This section discusses the NAS physical deployment modes that affect the physical traffic path.
NAS Physical Deployment Models
Edge:
NAS
ƒ NAS is physically and logically
in traffic path.
ƒ VAN IDs are passed through
NAS.
VLAN 10
VLAN 10
NAS
Central:
ƒ Is most common option
ƒ NAS is logically inline, but not
physically inline.
ƒ VAN IDs are mapped across
NAS.
ƒ Is most scalable option.
VLAN 10, 20
VLAN 110, 120
VLAN 110, 10
VLAN 10, 20
VLAN 120, 20
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—8-42
The edge deployment model is the easiest physical deployment option to understand. The NAS
is physically and logically in line to the traffic path. VLAN IDs are passed straight through the
device when in virtual gateway mode. This deployment option can become complex when there
are multiple access closets.
The central deployment model is the most common option and the easiest deployment option.
In this option, the NAS is logically inline, but not physically inline. The VLAN IDs need to be
mapped across the NAS when in virtual gateway mode. This deployment option is the most
scalable option for large environments as each NAS can support devices from multiple access
switches.
© 2007, Cisco Systems, Inc
Security Services Design
8-35
NAC Appliance Designs
This topic reviews some common NAC Appliance designs.
NAC Appliance Redundancy Design
Active
Standby
Access
VLAN 900
Standby
Active
VLAN 40, 50, 60
VLAN 40, 50, 60
Layer 2
Trunk
VLAN 140, 150, 160
Active
VLAN 10, 20, 30
Si
VLAN 140, 150, 160
Standby
Si
VLAN 110, 120, 130
VLAN 10, 20, 30
Collapsed
Core /
Distribution
VLAN 110, 120, 130
Access
VLAN 110
VLAN 120
VLAN 130
VLAN 140
VLAN 150
VLAN 160
Note: Redundancy is not shown in the following examples for diagram
simplicity only!
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—8-44
As a recommended practice, the NAC Appliance solutions are implemented with full
redundancy. A failover bundle is either a pair of NAMs or NASes. The NAM failover bundle
provides management redundancy. The NAS failover bundle provides redundant NAS
operations for the protected devices.
In the figure, the network has two sets of NAS failover bundles. One NAS failover bundle
support devices on VLANs 110, 120, and 130. The other NAS failover bundle support devices
on VLANs 140, 150, and 160. All components in the design are in an active / standby state.
Each failover bundle shares a virtual MAC and virtual IP address. Because of the shared MAC
address, Layer 2 connectivity is required between components. The redundant distribution
switches are interconnected with a Layer 2 trunk.
Note
The VLANs do not span the access layer switches in this design. The Layer 2 trunk between
the distribution switches is only needed to provide Layer 2 connectivity between the NAS
failover bundles.
The NAMs connect to the redundant distribution switches and support all the NASes in the
network.
Note
8-36
Redundancy is not shown in the rest of the figures in this lesson for simplicity only. Every
design that follows can, should, and would have redundancy.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Layer 2 In-Band Designs
This section reviews some Layer 2 In-Band designs.
Layer 2 In-Band
ƒ Client traffic is always
inline.
ƒ NAS securely manages
traffic.
ƒ Design supports hubs,
access points, and
switches.
VLAN 10
NAM
VLAN 91
VLAN 10, 90
NAS
VLAN 110
VLAN 110
(VLAN 110
mapped to
VLAN 10)
VLAN 110
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—8-45
The Layer 2 In-Band topology is the most common deployment option. The NAS is logically
inline with the client traffic, but is not physically inline. When the Virtual Gateway mode is
implemented, the VLAN IDs are mapped by the NAS.
In the figure, VLAN 110 is mapped to VLAN 10 by the NAS. All client traffic passes through
the NAS. The NAS securely manages all traffic after posture assessment. The MAC address of
the client is used to identify the device.
This is the most scalable design in large environments, as this design can be transparently
implemented in the existing network supporting multiple access layer switches. It will support
all network infrastructure equipment.
© 2007, Cisco Systems, Inc
Security Services Design
8-37
Example: Layer 2 In-Band Virtual Gateway
Intranet/
Network
VLAN 10
NAM
VLAN 91
VLAN 10, 90
NAS
10.90.1.2
Management
VLAN 110
10.91.1.2
VLAN 110
VLAN 110
SVI VLAN 10 10.1.1.1
SVI VLAN 90 10.90.1.1
SVI VLAN 91 10.91.1.1
DHCP Server VLAN 10
Scope 10.1.1.5 – 10.1.1.100
Client IP 10.1.1.5
Default Gateway 10.1.1.1
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—8-46
Example: Layer 2 In-Band Virtual Gateway
The figure illustrates a Layer 2 In-Band Virtual Gateway design. The NAS maps traffic from
VLAN 110 to VLAN 10. The Layer 3 distribution switch has switched virtual interfaces (SVIs)
for the VLANs connecting to the NAM, NAS, and access switches. The distribution switch is
the DHCP server and the default gateway for the access layer devices. The existing IP
addressing in the network is not changed when the Virtual Gateway is implemented.
8-38
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Example: Layer 2 In-Band Real-IP Gateway
Intranet/
Network
VLAN 10
NAM
VLAN 91
VLAN 10, 90
NAS
10.90.1.2
Management
VLAN 110
10.91.1.2
VLAN 110
SVI VLAN 10 10.1.1.1
SVI VLAN 90 10.90.1.1
SVI VLAN 91 10.91.1.1
VLAN 110
SVI VLAN 10 10.1.1.2
SVI VLAN 90 10.90.1.2
SVI VLAN 110 10.110.1.1
DHCP Server VLAN 110
Scope 10.110.1.5 – 10.110.1.100
Client IP 10.110.1.5
Default Gateway 10.110.1.1
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—8-47
Example: Layer 2 In-Band Real-IP Gateway
The figure illustrates a Layer 2 In-Band Real-IP Gateway design. The NAS is now the DHCP
server and the default gateway for the access layer devices. The NAS has static routes to the
other subnets in the organization. The Layer 3 distribution switch has switched virtual
interfaces (SVIs) for the VLANs connecting to the NAM, NAS, and access switches. The
existing IP addressing in the network changes when the Real-IP Gateway is implemented.
© 2007, Cisco Systems, Inc
Security Services Design
8-39
Layer 2 Out-of-Band Designs
This section reviews some Layer 2 Out-of-Band designs.
Layer 2 Out-of-Band
ƒ Client is inline before and
during posture
assessment.
ƒ User VLAN is changed
and NAS is bypassed
only after a successful
login.
VLAN 10
NAM
VLAN 91
ƒ NAS uses SNMP for traps
and switch configuration.
NAS
VLAN 110
ƒ NAS securely manages
traffic only during
assessment.
ƒ Design requires
supported OOB switches.
VLAN 10, 90
VLAN 10, 110
VLAN 110
Posture
Assessment
© 2007 Cisco Systems, Inc. All rights reserved.
VLAN 10
Network
Access
ARCH v2.0—8-48
The connections of the Layer 2 Out-of-Band is similar to the Layer 2 In-Band design, except
that the link from the access switch to the distribution switch is now a trunk supporting both the
posture assessment VLAN and the network access VLAN.
The client is inline with the NAS before and during posture assessment. The user VLAN is
changed and NAS is bypassed only after a successful login and assessment. The NAS securely
manages traffic only during assessment.
Note
The NAM can support either dynamic VLAN assignment based on roles, or geographic
VLAN assignment based on the VLANs on the switch. Only one MAC address is supported
per switch port except for IP telephony devices.
This design requires use of supported OOB switches such as the Cisco Catalyst Series 2950,
2960, 3500XL, 3550, 3560, 3750, 4500, and 6500 switches with the appropriate software
image.
Note
Refer to the following link for a list of Cisco NAC Appliance supported switches and
versions:
http://www.cisco.com/univercd/cc/td/doc/product/vpn/ciscosec/cca/cca40/switch.ht
m#wp65186
The NAM uses SNMP for traps and switch configuration.
8-40
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Example: Layer 2 Out-of-Band Virtual
Gateway
Intranet/
Network
VLAN 10
NAM
VLAN 91
VLAN 10, 90
NAS
10.90.1.2
VLAN 110
10.91.1.2
VLAN 10, 110
VLAN 10 or
VLAN 110
SVI VLAN 10 10.1.1.1
SVI VLAN 90 10.90.1.1
SVI VLAN 91 10.91.1.1
DHCP Server VLAN 10
Scope 10.1.1.5 – 10.1.1.100
Client IP 10.1.1.5
Default Gateway 10.1.1.1
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—8-49
Example: Layer 2 Out-of-Band Virtual Gateway
The figure example addressing with a Layer 3 Out-of-Band Virtual Gateway design. The NAS
maps traffic from VLAN 110 to VLAN 10 during the posture assessment. The Layer 3
distribution switch has switched virtual interfaces (SVIs) for the VLANs connecting to the
NAM, NAS, and access switches. The distribution switch is the DHCP server and the default
gateway for the access layer devices. The existing IP addressing in the network is not changed
when the Virtual Gateway is implemented.
© 2007, Cisco Systems, Inc
Security Services Design
8-41
Layer 3 In-Band Designs
This section reviews some Layer 3 In-Band designs.
Layer 3 In-Band
Intranet/
Network
ƒ Client traffic is always
inline.
ƒ NAS securely manages
traffic.
VLAN 10
NAM
ƒ Design used when MAC
address is no longer
unique.
VLAN 91
VLAN 10, 90
NAS
VLAN 110
VLAN 110
VLAN 700
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—8-50
With the Layer 3 In-Band topology, the client device is not Layer 2 adjacent to the NAS. The
IP address of the client is used to identify the device, since the MAC address provided to the
NAS is not from the client. This design is used to securely manage traffic from remote sites or
for VPN concentrators.
8-42
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Example: Layer 3 In-Band with Virtual
Gateway
Intranet/
Network
VLAN 10
NAM
VLAN 91
VLAN 10, 90
NAS
VLAN 110
LAN IP 10.1.1.2
WAN IP 192.168.1.1
Default Gateway 10.1.1.1
LAN IP 172.16.32.1
WAN IP 192.168.1.2
Default Gateway 192.168.1.1
VLAN 110
SVI VLAN 10 10.1.1.1
SVI VLAN 90 10.90.1.1
SVI VLAN 91 10.91.1.1
VLAN 700
VLAN 700
Client IP 172.16.32.5
Default Gateway 172.16.32.1
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—8-51
Example: Layer 3 In-Band Virtual Gateway
The figure illustrates a Layer 3 In-Band Virtual Gateway design. The NAS maps traffic from
VLAN 110 to VLAN 10. The Layer 3 distribution switch has switched virtual interfaces (SVIs)
for the VLANs connecting to the NAM, NAS, and access switches. The distribution switch is
the default gateway for the access layer devices. The DHCP server is typically a remote router.
Traffic from remote site all goes through NAS.
This design also supports VPN concentrators. Instead of the remote router pair, the VPN
concentrator connects to the distribution switch. Traffic from the VPN concentrator is
forwarded through the NAS for posture assessment and management.
© 2007, Cisco Systems, Inc
Security Services Design
8-43
Example: Layer 3 In-Band with Multiple
Remotes
Intranet/
Network
VLAN 10
NAM
VLAN 10, 90
VLAN 91
NAS
VLAN 110
LAN IP 10.1.1.2
WAN IP 192.168.1.1
WAN IP 192.168.2.1
Default Gateway 10.1.1.1
VLAN 110
SVI VLAN 10 10.1.1.1
SVI VLAN 90 10.90.1.1
SVI VLAN 91 10.91.1.1
LAN IP 172.16.32.1
WAN IP 192.168.1.2
Default Gateway 192.168.1.1
Client IP 172.16.32.5
Default Gateway 172.16.32.1
LAN IP 172.16.33.1
WAN IP 192.168.2.2
Default Gateway 192.168.2.1
Client IP 172.16.33.5
Default Gateway 172.16.33.1
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—8-52
Example: Layer 3 In-Band Virtual Gateway with Multiple Remote Sites
The figure illustrates a Layer 3 In-Band Virtual Gateway design with multiple remote sites. The
NAS maps traffic from VLAN 110 to VLAN 10. Traffic to centralized hosts and Internet goes
through NAS.
Note
8-44
Unless additional configuration steps are taken, traffic between clients at remote sites does
not go through NAS since the campus router allows routing between the edge routers. In
order to securely manage traffic between the remote sites, you can implement networking
technologies such as policy based routing or virtual routing and forwarding instances to
isolate the remote sites. Implementing NAS at the remote sites will also secure the traffic.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Layer 3 Out-of-Band Designs
This section reviews some Layer 3 Out-of-Band designs.
Layer 3 Out-of-Band
ƒ Client is in-line before and
during posture assessment
ƒ User VLAN is changed and
NAS is bypassed only after
a successful login and
assessment.
ƒ NAM uses SNMP for traps
and switch configuration
ƒ Design requires supported
OOB switches.
VLAN 10
NAM
VLAN 91
NAS
VLAN 110
VLAN 110
VLAN 70,
80
© 2007 Cisco Systems, Inc. All rights reserved.
VLAN 10, 90
VLAN 70 or
VLAN 80
ARCH v2.0—8-53
Layer 3 support for out-of-band deployments enables administrators to deploy the NAS out-ofband centrally in core or distribution layer to support users behind Layer 3 access switches and
remote users behind WAN routers in some instances. With Layer 3 OOB, users more than one
Layer 3 hop away from the NAS are supported for authentication and posture assessment. After
authentication and posture assessment, the client traffic no longer passes through the NAS.
With the Layer 3 Out-of-Band topology, the IP address (and MAC address starting with NAA
v. 4 Layer 3 OOB applications) of the client is used to identify the device, since the MAC
address (prior to NAA v.4 client) provided to the NAS is not from the client. This design
requires use of supported OOB switches such as the Cisco Catalyst Series 2950, 2960, 3500XL,
3550, 3560, 3750, 4500, and 6500 switches with the appropriate software image. The NAM
uses SNMP for traps and switch configuration.
Note
Refer to the list of Cisco NAC Appliance supported switches and versions at
http://www.cisco.com/univercd/cc/td/doc/product/vpn/ciscosec/cca/cca40/switch.ht
m#wp65186
© 2007, Cisco Systems, Inc
Security Services Design
8-45
Example: Layer 3 Out-of-Band with
Addressing
Intranet/
Network
VLAN 10
NAM
VLAN 90
VLAN 10, 90
NAS
VLAN 110
LAN IP 10.1.1.2
WAN IP 192.168.1.1
Default Gateway 10.1.1.1
VLAN 110
VLAN 70 IP 172.16.32.1
VLAN 80 IP 10.1.80.1
WAN IP 192.168.1.2
INET IP 208.222.102.2
Default Gateway 208.222.102.1
VLAN 70,
80
Internet
© 2007 Cisco Systems, Inc. All rights reserved.
SVI VLAN 10 10.1.1.1
SVI VLAN 90 10.90.1.1
SVI VLAN 91 10.91.1.1
VLAN 70 or
VLAN 80
VLAN 70 Client IP 172.16.32.5
Default Gateway 172.16.32.1
VLAN 80 Client IP 10.1.80.5
Default Gateway 10.1.80.1
ARCH v2.0—8-54
Example: Layer 3 Out-of-Band Virtual Gateway
The figure shows example addressing with a Layer 3 Out-of-Band Virtual Gateway design
supporting remote users. The NAS maps traffic from VLAN 110 to VLAN 10 during the
posture assessment. The Layer 3 distribution switch has switched virtual interfaces (SVIs) for
the VLANs connecting to the NAM, NAS, and access switches. The remote site edge router is
the DHCP server and the default gateway for the client devices. The remote site edge router
uses a trunk to the remote access switch to support either the production VLAN or the posture
assessment VLAN.
8-46
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
NAC Framework Overview
NAC Framework is as an architecture-based framework solution designed to take advantage of
an existing base of both Cisco network technologies and existing deployments of security and
management solutions from other manufacturers.
NAC Framework Architecture
Subject
(Managed or
Unmanaged Host)
Enforcement
Decision and
Remediation
ACS
Directory
Server
LAN
Posture
Validation
Server(s)
Audit
Server
WAN
Patch
Server
Reporting
Server
Remote
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—8-56
Cisco NAC Framework assesses the state, or posture, of a host to prevent unauthorized or
vulnerable endpoints from accessing the network. The Cisco NAC posture validation process
has three major architectural components:
„
Subjects. Managed or unmanaged hosts that are accessing the network on which NAC is
enforced. Typical hosts are desktop computers, laptops, and servers, but may also include
IP phones, network printers, and other network-attached devices. The subjects use posture
agent software to communicate with NAC devices. The Cisco Trust Agent is Cisco’s
implementation of the posture agent.
„
Enforcement devices. Network devices acting as a NAC enforcement point. These may
include Cisco access routers, VPN gateways, Cisco Catalyst Layer 2 and Layer 3 switches,
and wireless access points.
„
Decision and remediation devices. Many network devices that support the NAC
architecture:
—
AAA Server (Authentication, Authorization and Accounting Server)—The central
policy server that aggregates one or more authentications and/or authorizations into
a single system authorization decision and maps this decision to a network access
profile for enforcement by the NAD. Cisco Secure Access Control Server (ACS) is
Cisco’s AAA server product that supports NAC.
—
Directory Server—A centralized directory server for performing user and/or
machine authentication. Possible directory services include Lightweight Directory
Access Protocol (LDAP), Microsoft Active Directory (AD), Novell Directory
Services (NDS), and one-time token password servers (OTP).
© 2007, Cisco Systems, Inc
Security Services Design
8-47
8-48
—
Posture Validation Server (PVS)—A posture validation server from one or more
third parties acts as an application-specific policy decision point in NAC for
authorizing a set of posture credentials from one or more posture plug-in against a
set of policy rules. Examples include anti-virus servers or security application
servers.
—
Remediation Server—A management solution used to bring non-compliant hosts
into compliance. This could be a specialized patch management application or as
simple as a web site for distributing software. The better and more efficient your
host patching and remediation is, the less risk
—
Audit Server—A server or software that performs vulnerability assessment (VA)
against a host to determine the level of compliance or risk of the host prior to
network admission.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Router Platform Support for NAC Framework
This section discusses NAC Framework support on Cisco router platforms.
Router Platform Support
ƒ NAC Layer 3 IP shipped
June 2004 in IOS 12.3(8)T
– T-train images with security
– The same image that includes
firewall, NIPS, and crypto
ƒ NAC Agentless Host (audit)
supported in Cisco IOS 12.4(6)T
Cisco 18xx, 28xx, 38xx
Yes
Cisco 72xx, 75xx
Yes
Cisco 37xx
Yes
Cisco 3640, 3660-ENT Series
Yes
Cisco 2600XM, 2691
Yes
Cisco 1701, 1711, 1712, 1721,
1751, 1751-V, 1760
Yes
Cisco 83x
Yes
Cisco 74xx, 73xx, 71xx (S-train)
TBD
ƒ Network module switches
Cisco 5xxx
TBD
– 16, 24, 48 port NM
Cisco 4500
No
– 2800, 3700, 3800 router
platforms
Cisco 3660-CO Series
No
Cisco 3620
No
Cisco 2600 Non-XM Models
No
Cisco 1750, 1720, 1710
No
– NAC Layer 2 802.1x and NAC
Layer 2 IP
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—8-57
Routers that support NAC-L3-IP method (EAP over UDP) are considered NAC Release 1.0
devices. NAC-L3-IP was first introduced as part of the initial release of NAC in the summer of
2004. NAC-L3-IP is a posture-only credential checks that supports authorization capabilities,
URL redirect, and downloadable ACLs. NAC-L3-IP is triggered by a Layer 3 packet entering a
router interface with an IP admission ACL configured. NAC-L3-IP is mainly positioned for
aggregation deployments (WAN, VPN, WLAN, etc.). The current deployment options
currently preclude the use of NAC-L3-IP in the distribution layer of a campus infrastructure
since the Catalyst Layer 3 switches do not currently support NAC-L3-IP.
NAC agentless hosts are a mechanism in NAC to allow network access to hosts that do not or
cannot perform NAC or other compliance authorizations. Network attached devices that fall
into this category often include printers, scanners, photocopiers, cameras, sensors, badge
readers, and specialized equipment. NAH devices may also include computers with
unsupported OSes, hardened OSes, embedded OSes, or personal firewalls. Static exceptions
can be configured to allow hosts to bypass the posture validation process based on specified
MAC or IP address. Static exceptions can be configured in ACS to allow any specified hosts to
bypass the posture validation process based on MAC address. Both individual and wildcard
addresses can be specified. NAC Agentless Host is supported in Cisco IOS 12.4(6)T.
Devices that support either the NAC-L2-IP method which uses Extensible Authentication
Protocol over User Data Protocol (EAP over UDP), or the NAC L2 802.1X (EAP over IEEE
802.1X) method are NAC Release 2.0 devices. NAC-L2- IP is triggered by ARP or optionally
DHCP traffic on a switch interface. NAC-L2-IP is also a posture-only credential checks that
supports authorization capabilities, URL redirect, and downloadable ACLs. NAC-L2-IP
sessions are active for as long as the host responds to periodic status query messages
implemented using ARP probes or until they are terminated. The access-control lists that set the
default policy for the switch port on the NAC-L2-IP switches are implemented in hardware.
© 2007, Cisco Systems, Inc
Security Services Design
8-49
One of the main benefits of NAC-L2-IP is that it was designed to support multiple hosts per
port. The network administrator needs to be aware that unlike NAC-L3-IP, there are a limited
number of hosts per port that can be supported in NAC-L2-IP. Some network module switches
for the Cisco Integrated Services Router platforms support
NAC-L2-IP or the NAC-L2-802.1X.
Note
Refer to the following URL for a list of supported routers:
http://www.cisco.com/univercd/cc/td/doc/product/vpn/ciscosec/ntadctrl/nac20rn1.h
tm#wp1010792
8-50
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Switch Platform Support for NAC Framework
This section discusses NAC Framework support on Cisco router platforms.
Switch Platform Support
Platform,
Supervisor
OS
NAC Layer 2
802.1x
NAC Layer 2 IP
NAC Layer 3
IP
NAC Agentless
Host
6500―Sup32, 720
Native
Cisco IOS
Future
Yes
Future
NAC Layer 2 IP
6500—Sup2
Native
Cisco IOS
No
No
No
No
6500―Sup2, 32, 720
Hybrid
Yes
Yes
No
NAC Layer 2 IP
6500―Sup2, 32, 720
CATOS
Yes
Yes
No
NAC Layer 2 IP
4500 Series―SupII+,
II+TS, II+10GE, IV, V,
V-10GE
Cisco IOS
Yes
Yes
Future
NAC Layer 2 IP
4900
Cisco IOS
Yes
Yes
Future
NAC Layer 2 IP
3550,3560, 3750
Cisco IOS
Yes
Yes
No
NAC Layer 2 IP
2950,2940, 2955,
2960, 2970
Cisco IOS
Yes
No
No
No
6500―Sup1A
All
No
No
No
No
5000
All
No
No
No
No
4000 Sup I, II, III
(Cisco IOS)
CATOS
No
No
No
No
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—8-58
The table shows NAC Framework support in Cisco Catalyst switches. NAC performs posture
validation at the Layer 2 network edge for hosts with or without 802.1x enabled. Vulnerable
and noncompliant hosts can be isolated, given reduced network access, or directed to
remediation servers based on organizational policy. By ensuring that every host complies with
security policy, organizations can significantly reduce the damage caused by infected hosts.
Note
Refer to the following URL for a list of supported switches at
http://www.cisco.com/univercd/cc/td/doc/product/vpn/ciscosec/ntadctrl/nac20rn1.h
tm#wp1010792
© 2007, Cisco Systems, Inc
Security Services Design
8-51
Cisco Client Security Software
This section reviews three client security software applications from Cisco.
Cisco Client Software
Cisco NAC Appliance Agent:
ƒ Optional client-side component of the Cisco Clean Access system
ƒ Provides device-based registry scans
Cisco Security Agent:
ƒ Provides threat protection for server and desktop computing systems
ƒ Integrates with NAC Framework and Cisco Security MARS
Cisco Secure Services Client:
ƒ Client software that provides a single authentication framework for
multiple device types on the basis of the IEEE 802.1X standard
ƒ Provides an end-to-end authentication service when combined with the
Cisco Secure Access Control Server (ACS)
Cisco Trust Agent:
ƒ Is a core component of the NAC Framework
ƒ Allows NAC to determine if security or management software is installed
and current.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—8-60
Cisco has four client security software applications that support network security:
8-52
„
Cisco NAC Appliance Agent (NAA). Is an optional client-side component of the Cisco
NAC Appliance system. It is a read-only client that delivers device-based registry scans on
unmanaged environments. The agent enhances posture assessment functions and
streamlines remediation. It is a free download provisioned over the Internet. Many
customers that use the Cisco NAC Appliance Agent often it a required download before
network access is granted. It only works with NAS.
„
Cisco Security Agent. Is security software provides threat protection for server and
desktop computing systems. The Cisco Security Agent goes identifies and prevents
malicious behavior before it can occur, thereby removing potential known and unknown
security risks that threaten enterprise networks and applications. It also provides the
capability at the endpoint to apply QoS markings to application network traffic as specified
by Cisco Security Agent policy rules. These markings can be used by Cisco IOS devices
upstream in the enterprise network to classify the packets and apply QoS service policies
such as policing and queuing. Cisco Security Agent integrates with NAC Framework and
Cisco Security Monitoring, Analysis, and Response System (MARS) to support threat
identification and investigation across the network.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
„
„
Cisco Secure Services Client (SSC). Is client software that supports the deployment of a
single authentication framework on multiple device types, for access to both wired and
wireless networks. As a component of the Cisco Unified Wireless Network, the Secure
Services Client:
—
Provides a single authentication framework for multiple device types on the basis of
the IEEE 802.1X standard
—
Supports leading security standards such as Wi-Fi Protected Access (WPA), WPA2,
and Extensible Authentication Protocol (EAP)
—
Supports Windows 2000 and Windows XP
—
Provides an end-to-end authentication service when combined with the Cisco Secure
Access Control Server
—
Fully integrates with the Cisco Unified Wireless Network access points and wireless
LAN controllers
—
Supports third-party credential databases
—
Protects network endpoint devices
—
Enforces security policies
Cisco Trust Agent. Is client software that must be installed on hosts whose host policy
state requires validation prior to permitting network access under the NAC Framework.
A core component of the NAC Framework, Cisco Trust Agent allows NAC to determine if
Cisco Security Agent, antivirus software, or other required third-party security or
management software is installed and current. It also provides information about the OS
version and patch level. As a component of the NAC Framework, the Cisco Trust Agent:
—
Acts as a middleware component that takes host policy information and securely
communicates the information to the authentication, authorization, and accounting
(AAA) policy server.
—
Interacts directly with "NAC-enabled" applications running on the host without user
intervention.
—
Can communicate at Layer 3 or Layer 2 using built-in communication components.
—
Includes an 802.1x supplicant for Layer 2 communications in wired environments.
—
Authenticates the requestor through encrypted communications with the AAA
server.
—
Allows customers to build scripts for custom information gathering.
—
Integrates with Cisco Security Agent and can be distributed by NAC participants
with their applications for simplified management and distribution.
© 2007, Cisco Systems, Inc
Security Services Design
8-53
Summary
This topic summarizes the key points discussed in this lesson.
Summary
ƒ IBNS and NAC are two complementary methods to provide
network security with access control.
ƒ The NAC Appliance is an admission control and compliance
enforcement solution comprised of NAM, NAS, NAA, and clean
access policy updates.
ƒ A NAS can be configured based on gateway type, operating
mode, client access mode, and physical deployment mode.
ƒ NAC Appliance designs can redundantly implement the NAS
Layer 2 or Layer 3 network device supporting in-band or out-ofband traffic flow.
ƒ The NAC framework architecture leverages both Cisco network
technologies and other security and management solutions.
ƒ Cisco client security software includes NAS Appliance Agent,
Cisco Security Agent, Cisco Trust Agent, and Cisco Secure
Services Client .
© 2007 Cisco Systems, Inc. All rights reserved.
8-54
Designing Cisco Network Service Architectures (ARCH) v2.0
ARCH v2.0—8-61
© 2007 Cisco Systems, Inc.
Lesson 3
Intrusion Detection and
Prevention Designs
Overview
Cisco intrusion detection and prevention solutions are part of the Cisco Self-Defending
Network. Designed to identify and stop worms, network viruses, and other malicious traffic,
these solutions can help protect networks. Cisco provides a broad array of solutions for
intrusion detection and prevention at both the network and at the endpoint.
This module gives an overview of Intrusion Detection Systems (IDS) and Intrusion Prevention
Systems (IPS) used in enterprise networks.
Lesson Objectives
Upon completing this module, you will be able to discuss and design IDS/IPS services for
enterprise networks. This ability includes being able to meet these objectives:
„
Provide an overview of IDS/IPS solutions
„
Discuss IDS/IPS deployments
„
Discuss IDS/IPS monitoring and management
IDS/IPS Overview
This section provides an overview of intrusion detection and intrusion prevention systems.
IDS/IPS Comparison
Intrusion Detection System
IP Address
Promiscuous Interface:
No IP Address
Network Link to the
Management Console
Data Capture
Data Flow
Intrusion Prevention System
IP Address
Network Link to the
Management Console
Data Flow
Transparent Interface:
No MAC or IP Addresses
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—8-64
IPS and IDS systems can be a hardware appliance or part of the Cisco IOS software. Cisco IPS
software is usually capable of both inline (IPS feature) and promiscuous (IDS feature)
monitoring, while Cisco IDS software is only capable of promiscuous (IDS feature)
monitoring.
Intrusion Detection Systems
Intrusion Detection Systems (IDS) passively listen to network traffic. The IDS is not in the
traffic path, but listens promiscuously to copies of all traffic on the network. Typically only one
promiscuous interface is required for network monitoring on an IDS. Further promiscuous
interfaces could be used to monitor multiple networks. When IDS detects malicious traffic, it
sends an alert to the management station. An IDS may also have the capability of sending a
TCP reset to the end host to terminate any malicious TCP connections.
In promiscuous mode, packets do not flow through the sensor. The sensor analyzes a copy of
the monitored traffic rather than the actual forwarded packet. The advantage of operating in
promiscuous mode is that the sensor does not affect the packet flow with the forwarded traffic.
The disadvantage of operating in promiscuous mode, however, is the sensor cannot stop
malicious traffic from reaching its intended target for certain types of attacks, such as atomic
attacks (single-packet attacks). The response actions implemented by promiscuous sensor
devices are post-event responses and often require assistance from other networking devices,
for example, routers and firewalls, to respond to an attack.
8-56
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Intrusion Prevention Systems
Intrusion Prevention Systems (IPS) are active devices in the traffic path, listening inline to
network traffic and permitting or denying flows and packets into the network. The inline
interfaces have no MAC or IP address and cannot be detected directly. All traffic passes
through the IPS for inspection. Traffic arrives on one IPS interface and exits on another. When
an IPS detects malicious traffic, it sends an alert to the management station and can block the
malicious traffic immediately. The original and subsequent malicious traffic are blocked as the
IPS proactively prevents attacks protecting against network viruses, worms, malicious
applications and vulnerability exploits. An IPS resembles a Layer 2 bridge or repeater. An IPS
by default passes all packets unless specifically denied by a policy.
Operating in inline interface pair mode puts the IPS directly into the traffic flow and affects
packet-forwarding rates making them slower by adding latency. This allows the sensor to stop
attacks by dropping malicious traffic before it reaches the intended target, thus providing a
protective service. Not only is the inline device processing information on Layers 3 and 4, but it
is also analyzing the contents and payload of the packets for more sophisticated embedded
attacks (Layers 3 to 7). This deeper analysis lets the system identify and stop and/or block
attacks that would normally pass through a traditional firewall device.
© 2007, Cisco Systems, Inc
Designing Security Services
8-57
IDS/IPS Components
There are two main components in an IDS/IPS solution.
IDS/IPS Components
Sensors:
ƒ Can be host-based or network-based
ƒ Include three common types:
– Signature-based
– Anomaly-based
– Policy-based
Security management and monitoring infrastructure:
ƒ Performs configuration and deployment services
ƒ Performs alert collection, aggregation, and correlation
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—8-65
There are two major components in an IDS/IPS solution:
„
„
8-58
Sensors. Can be either host-based such as the Cisco Secure Agent or network-based such
as an IPS appliance. The network-based sensors use specialized software and hardware to
collect and analyze network traffic. The network-based sensors can be appliances, modules
in a router or a switch or security appliance. There are three common types of IDS/IPS
technologies:
—
Signature-based IPS/IDS look for specific predefined patterns or signatures in
network traffic. Traffic patterns are compared to a database of known attacks and
trigger an alarm or drop traffic if a match is found.
—
An anomaly-based IDS/IPS checks for defects or anomalies in packets or packet
sequences and verifies if there is any anomaly traffic behavior.
—
Policy-based IDS/IPS are configured based on the network security policy and
detect traffic that does not match the policy.
Security management and monitoring infrastructure. Configures the sensors and serves
as the collection point for alarms for security management and monitoring. The
management and monitoring applications performs alert collection, aggregation, and
correlation. Cisco Security Manager is used to centrally provision device configurations
and security policies for Cisco firewalls, virtual private networks (VPNs), and IPS. Cisco
Security Monitoring, Analysis and Response System (MARS) provides security monitoring
for network security devices and host applications. Cisco Intrusion Prevention System
Device Manager (IDM) is a web-based Java application that allows configuration and
management of IPS sensors. IDS Event Viewer is a Java-based application that enables
network managers to view and manage alarms for up to five sensors.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Host-Based Intrusion Prevention Systems
This section reviews host-based intrusion prevention systems (HIPS).
Typical HIPS Components
External Database
(optional)
Admin GUI
Management
Servers
Updates
Downloads
Alerts/Polls
Alerts/Polls
Agents
ARCH v2.0—8-67
© 2007 Cisco Systems, Inc. All rights reserved.
HIPS deployments include two components:
Endpoint Agents—Enforces security policy received from management server. Endpoint
agents send event information to the management server, and interact with the user if
necessary. The goal of an endpoint agent is providing threat protection for end system. Cisco
Security Agent is Cisco’s endpoint agent to provide threat protection for server and desktop
computing systems. Cisco Security Agent consists of host-based agents that report to the Cisco
Management Center for Cisco Security Agents. The Cisco Security Agent software resides
between the applications and the kernel on a PC, enabling maximum application visibility with
minimal impact to the stability and performance of the underlying operating system.
Management Server—Deploys security policies to endpoints. The management server is
responsible for configuring and maintaining the environment. The server receives and stores
events information, and sends alerts to administrators. The management server may deploy
software such as endpoint agent software updates. The interface to a HIPS management server
is typically a GUI console that allows policy configuration and event viewing. For highly
scalable environments it is possible to have a dedicated database running where the
configuration and event information is stored. The Management Center for Cisco Security
Agents provides all management functions for Cisco Security Agent deployments.
Note
© 2007, Cisco Systems, Inc
The majority of this lesson will focus on network-based IDS/IPS.
Designing Security Services
8-59
IPS/IDS Design Considerations
This topic explains design considerations to effectively use intrusion detection and prevention
in the network.
IDS/IPS Design Considerations
ƒ Selecting IDS/IPS
– Inline or promiscuous
ƒ Placement
– Outside firewall
– Inside firewall
– At critical servers
ƒ Traffic impact
– Failure of device
– Latency and performance
Internet
IDS
IPS
Corporate
Network
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—8-67
The underlying security policy should be the same for an IDS or an IPS deployment. An IPS
solution must be deployed inline with the network in order to deny traffic, while an IDS sensor
is connected in promiscuous mode, where packets do not flow through the sensor. The IDS
sensor analyzes a copy of the monitored traffic rather than the actual forwarded packet. If your
security policy does not support denying traffic, then use an IDS deployment.
IDS/IPS sensors are placed in the network where they can effectively support the underlying
security policy. Deployment decisions are often based on where you need to detect or stop an
intrusion as soon as possible. Typical locations include placing the sensors at the perimeter of
the network outside a firewall where the network is most exposed, internal to the network
inside the firewall between boundaries between zones of trust, and at critical servers where an
incident would be most costly.
Traffic impact considerations are increased with inline IPS sensors over IDS deployments. A
failure of the IDS means traffic monitoring has stopped. A failure of the IPS can disrupt
network traffic flow unless bypass methods are implemented. An IPS deployment also impacts
inline traffic. The latency through the IPS sensor should generally be under a millisecond and
as low as possible. The IPS sensors have bandwidth limitations on the amount of traffic that can
be supported through the device. Exceeding the performance of a sensor will result in dropped
packets and a general degradation of network performance.
8-60
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
IDS/IPS Deployments
This topic discusses IDS/IPS deployment recommendations.
Candidate Areas for IDS/IPS Deployment
Data Center
Management
Network
Corporate Network
Remote/Branch Office
Connectivity
Internet
Remote Access
Systems
Extranet
Connections
© 2007 Cisco Systems, Inc. All rights reserved.
Business
Partner
Access
DMZ Connections
ARCH v2.0—8-69
IDS/IPS sensors can be deployed based on the priority of targets. Internet and Extranet
connections are typically secured first due to their exposure. An IDS outside the firewall can
detects all attacks and generate a lot of alarms, but is useful for analyzing what kind of traffic is
reaching the organization and how an attack is executed. An IDS inside the firewall can detect
firewall misconfigurations by showing what kind of traffic passes through the firewall. An IPS
can provide more focused application protection and firewall augmentation for Extranet and
DMZ resources.
Management networks and data centers are often next in priority. A layered approach for
maximum protection is appropriate for the high security areas. There might be one system
installed after the firewall and a second system at the entry point to the high security area such
as the data center. Host specific IDS can detect attacks against a specific server. An IPS can be
used to block application specific traffic which should not reach the server.
IPS deployments at remote and branch offices can both protect the branch from corporate
incidents, and protect the corporate resources from security incidents arising from branch
practices. Remote access systems need protection as well.
© 2007, Cisco Systems, Inc
Designing Security Services
8-61
IPS Appliance Deployment Options
This section looks at deployment options for IPS appliances.
IPS Appliance Deployment Options
ƒ Two Layer 2 devices (no trunk)
ƒ Two Layer 3 devices
ƒ Two VLANs on the same switch
VLAN x
VLAN y
ƒ Two Layer 2 devices (trunked)
.1q Trunk
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—8-71
When placing an IPS sensor in an enterprise networks there are multiple options available
depending on the infrastructure and the desired results:
„
Two Layer 2 devices (no trunk). Sensor placement between two Layer 2 devices without
trunking is a typical campus design. In this deployment the IPS appliance is placed between
two switches. The IPS can be between the same VLAN on two different switches or
between different VLANs with the same subnet on two different switches. Scenarios
include placement between different security zones in a campus environment or between
critical devices in a data center.
„
Two Layer 3 devices. Sensor placement between Layer 3 devices is common in Internet,
campus, and server farm designs. The two Layer 3 devices are in the same subnet. One
advantage in these scenarios is the ease of configuration since the integration can take place
without touching any other device.
„
Two VLANs on the same switch. This design allows a sensor to bridge VLANs together
on the same switch. The sensor brings packets in on one VLAN and out a different VLAN
for traffic in the same subnet.
„
Two Layer 2 devices (trunked). Sensor placement on a trunk port between switches is a
common scenario providing protection of several VLANs from a single location.
Note
8-62
IPS module deployments follow the same general guidelines as for IPS appliances.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Feature: Inline VLAN Pairing
VLAN X
VLAN Y
Trunk port allowing
VLANs X and Y
ƒ IPS bridges VLANs together on the same physical interface.
ƒ Multiple VLAN pairs per physical interface are supported.
Note: VLAN pairing is supported on all sensors that are
compatible with IPS 6.0 except NM-CIDS, AIP-SSM-10, and
AIP-SSM-20.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—8-72
Feature: Inline VLAN Pairing
The IPS can associate VLANs in pairs on a physical interface. Packets received on one of the
paired VLANs are analyzed and then forwarded to the other VLAN in the pair. The sensor
brings packets in on one VLAN and out a different VLAN on the same trunk link for traffic in
the same subnet. The sensor replaces the VLAN ID field in the 802.1q header of each received
packet with the ID of the egress VLAN on which the sensor forwards the packet. This design
supports multiple VLAN pairs per physical interface and reduces the need to have many
physical interfaces per chassis.
Note
© 2007, Cisco Systems, Inc
VLAN pairs are supported on all sensors that are compatible with IPS 6.0 except NMCIDS, AIP-SSM-10, and AIP-SSM-20.
Designing Security Services
8-63
IPS Deployment Challenges
Asymmetric traffic patterns and high availability are challenges for IPS deployments.
IPS Deployment Challenges
Asymmetric Traffic Issue
Stateful Failover Issue
SYN
SynAck
SynAck
SYN
Design Workaround
Mirror
© 2007 Cisco Systems, Inc. All rights reserved.
Mirror
ARCH v2.0—8-72
Traditional packet flows in a network are symmetrical and consist of connections that take the
same path through the network in both directions. Many newer network designs do not
guarantee symmetrical flows, and engineer the network to take advantage of all available links.
This greatly increases the chance that traffic may use multiple paths to and from its destination.
This asymmetric traffic flow can cause problems with inline IPS devices. Since an IPS sensor
inspects traffic statefully and needs to see both sides of the connection to function properly,
asymmetric traffic flows may cause valid traffic to be dropped.
High availability is another deployment challenge. A failure of any redundant component in the
network should not cause an interruption in network availability. This implies that existing
sessions should continue to flow normally and not be dropped.
The current IPS 6.0 solutions do not support asymmetric flows or high availability natively in
the product. A design workaround uses the network to mirror all traffic between two sensors in
a “failover” pair. The IPS sensors in the pair see all packets traversing a point in the network. If
one sensor fails for any reason, the network reroutes all traffic through the other sensor since it
is the only available path. The secondary sensor has already seen all the packets and has built a
complete state table for the flows so traffic is not interrupted. Asymmetric traffic is also
supported by this mirroring technique.
8-64
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
IDS/IPS Management Interface Deployment Options
This section discusses options for deploying the IDS/IPS management interface.
Secure Management – Separate VLAN
DMZ
Inside
Attacker
Internet
Mgmt
ƒ Separate monitoring and management network segment
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—8-73
Monitoring an IDS/IPS solution is one of the crucial elements to provide fast detection of any
suspicious activity and an indication of prevented attacks. IDS/IPS management consolidates
and centralizes alarms from multiple sources in order to provide the required view of the
network.
On the network boundary, the sensors are usually installed adjacent to a firewall. The
monitoring and management interfaces of an IPS sensor can therefore be connected to two
different networks. This is especially critical when the outside sensor needs to communicate
with the inside network.
One option is to connect the monitoring interface to the outside network, and the management
interface is directly connected to the inside network. All management is done in-band over the
internal network. This type of setup is simple, but provides a path around the firewall if the
sensor is compromised. This design is not recommended.
A preferred design places the monitoring interface on the outside network, and the management
interface on a separate inside VLAN. With this setup, the management interface is isolated by
an IPS management VLAN from the rest of the inside network. If the VLAN is sufficiently
trusted, this design provides good separation of the IDS/IPS sensor.
Note
© 2007, Cisco Systems, Inc
Using private VLANs to put all sensors on isolated ports is recommended, because the
sensors do not need to talk to each other except when distributed blocking is used. This
prevents the compromise of a single sensor which helps to prevent other sensors from being
compromised.
Designing Security Services
8-65
In-Band Management Through Tunnels
Another option for deploying IDS/IPS uses a combination of management through an
out-of-band network and management through secure tunnels depending on the location of the
sensors.
In-Band Management Through Tunnels
DMZ
Inside
Mgmt
ƒ Firewall provides connection from IDS/IPS management interface
to management segment for less secure devices
ƒ Encrypted tunnels terminated at firewall or at management station
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—8-74
For devices outside the perimeter firewall, the monitoring interface remains on the outside
network, but the management interface is terminated on a separate demilitarized zone (DMZ).
Management is supported in-band across an encrypted tunnel. The firewall protects the outside
sensor from the inside devices, and provides better separation compared to the previous
solution. For internal devices in more secure areas, management is provided through a separate
management VLAN.
8-66
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
IDS/IPS Monitoring and Management
This topic reviews Cisco applications for monitoring and managing IDS/IPS implementations.
Monitoring and Managing IDS/IPS
CSM
© 2007 Cisco Systems, Inc. All rights reserved.
CS-MARS
ARCH v2.0—8-76
Cisco Security Monitoring, Analysis, and Response System (MARS) and Cisco Security
Manager are part of the Cisco Security Management Suite, which delivers policy administration
and enforcement for the Cisco Self-Defending Network. Both tools should be implemented in
the management VLAN in a protected place such as the server farm or data center.
MARS provides multi-vendor event correlation and proactive response, distributing IPS
signatures to mitigate active threats. MARS proactively identifies active network threats and
distributes IPS signatures to mitigate them.
„
MARS ships with a set of predefined compliance reporting that are easy to customize.
„
MARS stores event information from every type of device. This information can be
grouped in one single report.
For a small to medium sized organization, a centralized MARS implemented as a Local
Controller is a typical deployment.
Cisco Security Manager enables organizations to manage security policies on Cisco security
devices. Security Manager supports integrated provisioning of VPN and firewall services
across IOS routers, PIX and ASA security appliances, and Catalyst 6500/7600 services
modules. It also supports IPS technologies on routers, service modules, and IPS devices.
Security Manager supports provisioning of many platform-specific settings, for example,
interfaces, routing, identity, QoS and logging.
Cisco Security Manager, through its IPS Manager component, supports the management and
configuration of Cisco Intrusion Prevention System (IPS) sensors (appliances, switch modules,
© 2007, Cisco Systems, Inc
Designing Security Services
8-67
network modules, and Security Service modules [SSMs]) and Cisco IOS IPS devices (Cisco
IOS routers with IPS-enabled images and Cisco Integrated Services Routers [ISRs]). You
configure IPS sensors and IOS IPS devices through the use of policies, each of which defines a
different part of the configuration of the sensor. While Security Manager 3.0 allowed you to
cross-launch the IPS Management Center to access IPS functionality, Cisco Security Manager
3.1 provides fully integrated IPS features.
Cisco Security Manager version 3.1 enables you to manage security policies on Cisco security
devices. Cisco Security Manager supports integrated provisioning of firewall, IPS, and VPN
(site-to-site, remote access, and SSL) It provides integrated IPS provisioning services across:
Starting in version 3.1, Cisco Security Manager supports IPS 5.1/6.0 and IOS IPS in IOS
12.4(11)T. It provides support for the following features on IPS 6.0 devices:
8-68
„
Virtual sensors
„
Anomaly detection
„
Passive OS fingerprinting
„
Simplified custom signature creation
„
Signature update wizard, preview and tuning of new signatures
„
IPS signature update license management
„
External product interface (linkage of IPS sensor with CSA MC)
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Scaling CS-MARS with Global Controller Deployment
The CS-MARS Global Controller enables network monitoring scaling.
Scaling CS-MARS with Global Controller
Deployment
CS-MARS 50
US Corporate Office
AsiaPac Office
CS-MARS 200
EMEA Office
CS-MARS GC
CS-MARS 100 CS-MARS GC
© 2007 Cisco Systems, Inc. All rights reserved.
• Communicates over HTTPS using certificates
• Only incidents from global rules are rolled up
• Updates, rules, report templates, access rules,
and queries can be distributed
ARCH v2.0—8-78
If an organization is supporting multiple MARS Local Controllers, they can deploy a
distributed solution using a Global Controller to summarizes the findings of two or more
Local Controllers and manage the Local Controllers.
The Global Controller communicates over HTTPS using certificates. Only incidents from
global rules are rolled up into the Global Controller. The Global Controller can distribute
updates, rules, report templates, access rules, and queries across the Local Controller.
© 2007, Cisco Systems, Inc
Designing Security Services
8-69
Summary
This topic summarizes the key points discussed in this lesson.
Summary
ƒ IDS passively listen to network traffic while IPS are active devices
inline with the traffic path. The two major components in an
IDS/IPS solution are sensors and the security management
infrastructure.
ƒ IDS/IPS sensors are deployed in the enterprise based on the
priority of targets. IPS sensors can be placed between two Layer
2 devices or two Layer 3 devices.
ƒ MARS can proactively identify active network threats and
distribute IPS signatures to mitigate them, as well as support
configuring and managing security policies on Cisco security
devices. Cisco Security Manager supports IPS technologies on
routers, service modules, and IPS devices.
© 2007 Cisco Systems, Inc. All rights reserved.
8-70
Designing Cisco Network Service Architectures (ARCH) v2.0
ARCH v2.0—8-79
© 2007 Cisco Systems, Inc.
Module Summary
This topic summarizes the key points discussed in this module.
Module Summary
ƒ Firewalls provide the first line of defense in network security by
comparing corporate policies about network access rights for
users to the connection information surrounding each access
attempt.
ƒ NAC is a set of technologies and solutions that use the network
infrastructure to enforce security policy compliance on all devices
seeking to access network computing resources.
ƒ IDS/IPS solutions help identify and stop worms, network viruses,
and other malicious traffic.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—8-81
Firewalls have long provided the first line of defense in network security infrastructures. They
accomplish this by comparing corporate policies about network access rights for users to the
connection information surrounding each access attempt. User policies and connection
information must match up, or the firewall does not grant access to network resources.
NAC is a set of technologies and solutions built on an industry initiative led by Cisco Systems.
NAC framework uses the network infrastructure to enforce security policy compliance on all
devices seeking to access network computing resources, thereby limiting damage from
emerging security threats such as viruses, worms, and spyware by using embedded software
modules within NAC-enabled products. Customers using NAC can allow network access only
to compliant and trusted endpoint devices (PCs, servers, and PDAs, for example) and can
restrict the access of noncompliant devices. Cisco NAC Appliance condenses NAC capabilities
into an appliance form where client, server, and manager products allow network
administrators to authenticate, authorize, evaluate, and remediate wired, wireless, and remote
users and their machines prior to allowing users onto the network.
Cisco intrusion detection and prevention solutions are part of the Cisco Self-Defending
Network. Designed to identify and stop worms, network viruses, and other malicious traffic,
these solutions can help protect networks. Cisco provides a broad array of solutions for
intrusion detection and prevention at both the network and at the endpoint.
© 2007 Cisco Systems, Inc.
Security Services Design
8-71
References
For additional information, refer to these resources:
8-72
„
Cisco Systems, Inc. “SEC-2020: Deploying Firewalls” Networkers 2006 presentation
(accessible on a subscription basis) at
http://www.networkersonline.net.
„
Cisco Systems, Inc. “SEC-2030: SEC-2030 Deploying Network-Based Intrusion
Prevention Systems” Networkers 2006 presentation (accessible on a subscription basis) at
http://www.networkersonline.net.
„
Cisco Systems, Inc. “SEC-2040: Understanding and Deploying
Network Admission Control (NAC)” Networkers 2006 presentation (accessible on a
subscription basis) at
http://www.networkersonline.net.
„
Cisco Systems, Inc. Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall
Services Module Configuration Guide Release 3.1(1) at
http://www.cisco.com/application/pdf/en/us/guest/products/ps708/c2001/ccmigration_0918
6a0080577bef.pdf
„
Cisco Systems, Inc. Network Admission Control Framework Deployment Guide at
http://www.cisco.com/application/pdf/en/us/guest/netsol/ns617/c649/cdccont_0900aecd804
17226.pdf
„
Cisco Systems, Inc. Release Notes for Network Admission Control, Release 2.0 at
http://www.cisco.com/univercd/cc/td/doc/product/vpn/ciscosec/ntadctrl/nac20rn1.pdf
„
Cisco Systems, Inc. Cisco NAC Appliance Release Notes at
http://www.cisco.com/en/US/products/ps6128/prod_release_notes_list.html
„
Cisco Systems, Inc. “Switch Support for Cisco NAC Appliance” at
http://www.cisco.com/univercd/cc/td/doc/product/vpn/ciscosec/cca/cca40/switch.htm
„
Cisco Systems, Inc. Cisco NAC Appliance Data Sheet at
http://www.cisco.com/application/pdf/en/us/guest/products/ps6128/c1650/cdccont_0900aec
d802da1b5.pdf
„
Cisco Systems, Inc. Cisco NAC Appliance - Clean Access Server Installation and
Administration Guide Release 4.1 at
http://www.cisco.com/application/pdf/en/us/guest/products/ps7122/c1626/ccmigration_091
86a00807a4090.pdf
„
Cisco Systems, Inc. Cisco Security Appliance Command Line Configuration Guide at
http://www.cisco.com/application/pdf/en/us/guest/products/ps6120/c2001/ccmigration_091
86a0080641f89.pdf
„
Cisco Systems, Inc. Configuring the Cisco Intrusion Prevention System Sensor Using the
Command Line Interface 5.1 at
http://www.cisco.com/application/pdf/en/us/guest/products/ps6120/c2001/ccmigration_091
86a0080641f89.pdf
„
Cisco Systems, Inc. “Cisco Secure Services Client Introduction” at
http://www.cisco.com/en/US/products/ps7034/index.html
„
Cisco Systems, Inc. Installing and Using Cisco Intrusion Prevention System Device
Manager 6.0 at
http://www.cisco.com/application/pdf/en/us/guest/products/ps4077/c2001/ccmigration_091
86a00807a9287.pdf
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007, Cisco Systems, Inc.
„
Cisco Systems, Inc. Cisco Security Agent Version 5.2 Data Sheet at
http://www.cisco.com/application/pdf/en/us/guest/products/ps7237/c1650/cdccont_0900aec
d805baf46.pdf
„
Cisco Systems, Inc. Cisco Trust Agent 2.0 Data Sheet at
http://www.cisco.com/application/pdf/en/us/guest/products/ps5923/c1650/cdccont_0900aec
d80119868.pdf
„
Cisco Systems, Inc. Zone-Based Policy Firewall Design Guide at
http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124sup/zone_dg.pdf
© 2007 Cisco Systems, Inc.
Security Services Design
8-73
8-74
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007, Cisco Systems, Inc.
Module Self-Check
Use the questions here to review what you learned in this module. The correct answers and
solutions are found in the Module Self-Check Answer Key.
Q1)
What is the traditional mode for a firewall? (Source: Firewall Design Considerations)
A)
B)
C)
D)
E)
Q2)
What is a VFW? (Source: Firewall Design Considerations)
A)
B)
C)
D)
E)
Q3)
multiple context topology
active/standby topology
active/passive topology
active/failover topology
active/active topology
What command provides support for asymmetric routing? (Source: Firewall Design
Considerations)
A)
B)
C)
D)
E)
F)
Q5)
a logical separation of multiple firewall security contexts on a single firewall
a physical separation of multiple firewall security contexts in a single chassis
a routed firewall mode
a transparent firewall mode
an administrative context for network connectivity
What topology uses two firewalls that are both actively providing firewall services?
(Source: Firewall Design Considerations)
A)
B)
C)
D)
E)
Q4)
bridged mode
context mode
routed mode
security mode
transparent mode
asr-active interface command on FWSM 2.1
asr-active interface command on FWSM 3.0
asr-group interface command on FWSM 2.1
asr-group interface command on FWSM 3.0
asr-redundancy interface command on FWSM 2.1
asr-redundancy interface command on FWSM 3.0
What are two mechanisms can be used to scale performance with FWSMs? (Chose
two.) (Source: Firewall Design Considerations)
A)
B)
C)
D)
E)
F)
© 2007 Cisco Systems, Inc.
use PBR with multiple VFRs in a chassis
use PBR with multiple VFWs in a chassis
use PBR with multiple FWSMs in a chassis
use ECMP routing with multiple VFRs in a chassis
use ECMP routing with multiple VFWs in a chassis
use ECMP routing with multiple FWSMs in a chassis
Designing IP Multicast Services
8-75
Q6)
What are three components of a PVLAN? (Chose three.) (Source: Firewall Design
Considerations)
A)
B)
C)
D)
E)
F)
Q7)
What are two characteristics of a ZBF model? (Chose two.) (Source: Firewall Design
Considerations)
A)
B)
C)
D)
E)
F)
Q8)
802.1x posture alignment
NAM
NAS
Cisco Trust Agent
NAC posture assessment
SSC
Cisco NAC Appliance Super Manager manages up to how many NAC Appliance
Servers? (Source: Network Admission Control Design)
A)
B)
C)
D)
E)
8-76
802.1x posture alignment
802.1x posture assessment
IBNS authentication
INBS authentication
NAC posture alignment
NAC posture assessment
What are two components of Cisco NAC Appliance? (Chose two.) (Source: Network
Admission Control Design)
A)
B)
C)
D)
E)
F)
Q10)
a design supported by the FWSM
a design supported by the Cisco IOS Firewall feature set
a transparent model with zero security before the firewall
a model that uses a DMZ for intermediate security between the public and
private zones
a model where a security zone is configured for each region of relative security
within the network
a model where an interface is configured for each zone of relative security
within the network
What are two methods to provide network security with access control? (Chose two.)
(Source: Network Admission Control Design)
A)
B)
C)
D)
E)
F)
Q9)
communications VLAN
community VLAN
isolated VLAN
isolation VLAN
primary VLAN
promiscuous VLAN
3
5
20
40
50
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Q11)
What are two characteristics of Virtual Gateway mode? (Chose two.) (Source: Network
Admission Control Design)
A)
B)
C)
D)
E)
F)
Q12)
What are two characteristics of Real-IP Gateway mode? (Chose two.) (Source:
Network Admission Control Design)
A)
B)
C)
D)
E)
F)
Q13)
Cisco Secure Services clients
enforcement devices
printers
scanners
Windows 2000 devices
Windows XP devices
What are two characteristics of an IDS sensor? (Chose two.) (Source: Intrusion
Detection and Prevention Designs)
A)
B)
C)
D)
E)
Q16)
enforcement devices
subjects (NAC appliances)
decision and remediation devices
enforcement and decision devices
subjects (managed or unmanaged hosts)
Clean Access Agents remediation devices
What are two typical NAC agentless hosts? (Chose two.) (Source: Network Admission
Control Design)
A)
B)
C)
D)
E)
F)
Q15)
The NAM has an IP address for every managed VLAN.
The NAM operates as a standard Ethernet bridge, but with added functionality.
The NAS does not operate as the default gateway for untrusted network clients.
The NAS has an IP address for every managed VLAN.
The NAS operates as a standard Ethernet bridge, but with added functionality.
The NAS operates as the default gateway for untrusted network clients.
What are three major architectural components of the Cisco NAC Framework posture
validation process? (Chose three.) (Source: Network Admission Control Design)
A)
B)
C)
D)
E)
F)
Q14)
The NAM has an IP address for every managed VLAN.
The NAM operates as a standard Ethernet bridge, but with added functionality.
The NAS does not operate as the default gateway for untrusted network clients.
The NAS has an IP address for every managed VLAN.
The NAS operates as a standard Ethernet bridge, but with added functionality.
The NAS operates as the default gateway for untrusted network clients.
a permissive interface is used to monitor networks
a promiscuous interface is used to monitor the network
an active device in the traffic path
passively listens to network traffic
traffic arrives on one IDS interface and exits on another
What are two characteristics of an IPS sensor? (Chose two.) (Source: Intrusion
Detection and Prevention Designs)
A)
B)
C)
D)
E)
© 2007 Cisco Systems, Inc.
an active device in the traffic path
passively listens to network traffic
a permissive interface is used to monitor networks
a promiscuous interface is used to monitor the network
traffic arrives on one IPS interface and exits on another
Designing IP Multicast Services
8-77
Q17)
What are three options for placing an IPS sensor in an enterprise network? (Chose
three.) (Source: Intrusion Detection and Prevention Designs)
A)
B)
C)
D)
E)
Q18)
What are two challenges for IPS deployments? (Chose two.) (Source: Intrusion
Detection and Prevention Designs)
A)
B)
C)
D)
E)
Q19)
using secure VLANs to isolate sensors
using secure tunnels
using private VLANs to put all sensors on isolated ports
using asymmetric traffic flows to isolate sensors
using a separate management VLAN
providing an out-of-band path around the firewall
What mechanism can be used to scale MARS deployments? (Source: Intrusion
Detection and Prevention Designs)
A)
B)
C)
D)
E)
8-78
supporting inline VLAN pairing
supporting asymmetric traffic flows
natively supporting symmetric traffic flows
natively bridging VLANs on two switches
supporting failover without dropping valid traffic
What are three mechanisms used to secure management traffic from outside IPS
sensors? (Chose three.) (Source: Intrusion Detection and Prevention Designs)
A)
B)
C)
D)
E)
F)
Q20)
bridging VLANs on two switches
bridging two VLANs on one switch
between two Layer 2 devices with trunking
between two Layer 2 devices without trunking
between a Layer 2 device and a Layer 3 device without trunking
inline VLAN pairing for Local Controllers
symmetric traffic flows to a Central Controller
a Global Controller to summarize multiple Local Controllers
a Central Controller to summarize multiple Local and Global Controllers
HTTPS certificates for each Global Controller
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Module Self-Check Answer Key
Q1)
C
Q2)
A
Q3)
E
Q4)
D
Q5)
C, F
Q6)
B, C, E
Q7)
B, E
Q8)
C, F
Q9)
B, C
Q10)
D
Q11)
C, E
Q12)
D, F
Q13)
A, C, E
Q14)
C, D
Q15)
B, D
Q16)
A, E
Q17)
C, D, E
Q18)
B, E
Q19)
B, C, E
Q20)
C
© 2007 Cisco Systems, Inc.
Designing IP Multicast Services
8-79
8-80
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Module 9
IPsec and SSL VPN Design
Overview
This module reviews virtual private network (VPN) design in the enterprise. VPNs are
networks deployed on a public or private network infrastructure. VPNs are useful for
telecommuters, mobile users, and remote offices as well as for customers, suppliers, and
partners.
For enterprises, VPNs are an alternative WAN infrastructure, replacing or augmenting existing
private networks that utilize dedicated WANs based on leased-line, Frame Relay, ATM, or
other technologies. Increasingly, enterprises are turning to their service providers for VPNs and
other complete service solutions tailored to their particular business.
Module Objectives
Upon completing this module, you will be able to design enterprise solutions using appropriate
VPN technology. This ability includes being able to meet these objectives:
„
Discuss design considerations for remote-access VPNs
„
Discuss design considerations for site-to-site VPNs
„
Discuss technologies for implementing VPNs
„
Discuss managing and scaling VPNS
9-2
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Lesson 1
Remote Access VPN Design
Overview
Remote access virtual private networks (VPNs) permit secure, encrypted connections between
mobile or remote users and their corporate networks through a third-party network, such as a
service provider. Deploying a remote access VPN enables enterprises to reduce
communications expenses by leveraging the local packet switching infrastructures of Internet
service providers. Cisco Remote Access VPN solutions deliver both IP Security (IPsec) and
Secure Sockets Layer (SSL) technologies on a single platform with unified management.
Objectives
Upon completing this lesson, you will be able to design remote-access VPNs. This ability
includes being able to meet these objectives:
„
Provide an overview of remote access VPNs
„
Describe attributes of SSL VPNs
„
Discuss remote access VPN design considerations
Remote Access VPN Overview
Remote access VPNs using IPsec or SSL technologies permit secure, encrypted connections
between mobile or remote users and their corporate network across public networks.
Remote Access VPN Overview
Firewall
Router
Internet VPN
POP
DSL
Cable
Telecommuter
POP
VPN Security Appliance
Mobile
Components:
ƒ Termination device (high number of endpoints)
ƒ Client (mobile or fixed)
Mobile
Consumer
ƒ Technology (IPsec or SSL)
Mechanism for secure communication over IP:
ƒ Authenticity (unforged/trusted party)
ƒ Integrity (unaltered/tampered)
ƒ Confidentiality (unread)
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-4
There are three remote access VPN components:
„
VPN termination device or headend supporting a high number of endpoints
„
End clients that can be mobile of fixed. The remote access client can be built inside of
operating system or application, or be installed as a Layer 3 software client such as the
Cisco VPN Client.
„
Technology that connects the VPN headend and the end clients. The two main protocols
supporting remote access VPNs are IP Security (IPsec) and Secure Socket Layer (SSL):
—
IPsec is used primarily for data confidentiality and device authentication, but
extensions to the standard allow for user authentication and authorization to occur as
part of the IPsec process.
—
The main role of SSL is to provide security for web traffic. With SSL, the browser
client supports the VPN connection to a host. SSL is a default capability in leading
browsers.
Both IPsec and SSL remote access VPNs are mechanisms to provide secure communication:
9-4
„
Authenticity identifies the trusted party by asking for username and password or a
credential.
„
Integrity checking verifies that packets were not altered or tampered with as they travelled
across the network.
„
Confidentiality is supported using encryption to ensure communications were not read by
others.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Example: Easy VPN Client IPsec Implementation
Cisco Easy VPN provides simple IPsec VPN deployments for remote offices and teleworkers.
Example: Easy VPN Client IPsec
Implementation
Remote
SBO
User
IKE Mode Config Allows VPN Parameters
to be Pushed to a Client
Cisco VPN
Client
Internet
VPN Server
Dynamically Updated:
ƒ Central services and
security policy
HQ
HQ
Centralized Control:
• Internal IP Address
• Internal Network Mask
ƒ Offload VPN function
from local devices
• Internal DNS Server
ƒ Client and network
extension mode
• Split Tunneling
• Internal WINS Server
ƒ Configuration and
security policy is
pushed at the time of
the VPN tunnel
establishment.
• IPsec Transforms
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-5
The Cisco Easy VPN Server allows Cisco routers and security appliances to act as IPsec VPN
head-end devices in remote-access and site-to-site VPNs.
Note
IPsec components and features are covered in the prerequisite ISCW course.
For remote access VPNS, the Cisco Easy VPN Server terminates VPN tunnels initiated by
remote workers running the Cisco VPN Client software on PCs. This capability allows mobile
and remote workers to access critical data and applications on their corporate intranet. The Easy
VPN Server pushes configurations and security policies defined at the central site to the remote
client device, helping to ensure that those connections have appropriate information and up-todate policies in place before the connection is established. Easy VPN Server can pass a variety
of information to the client including IP address and mask, information on the internal DNS
and WINS server, and organization policies.
Note
© 2007 Cisco Systems, Inc.
Easy VPN Server is discussed in more detail in the “Remote Access VPN Implementation
Technologies” lesson in this module.
IPsec and SSL VPN Design
9-5
SSL VPNs
SSL is a protocol designed to enable secure communications on an insecure network such as
the Internet.
SSL Overview
ƒ SSL protocol was developed by Netscape for secure
e-commerce:
– Creates a tunnel between web browser and web server.
– Authenticated by digital certificates and encrypted.
– Self-signed root certificates are included in leading browsers.
ƒ SSL VPNs can support more than just web pages:
– Must fit into existing networks and application environments.
– Must support all of the same authentication mechanisms and
often extensive application list as available for IPsec.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-7
SSL is a technology developed by Netscape to provide encryption between a web browser and
a web server. SSL supports integrity of communications along with strong authentication using
digital certificates:
„
Web server certificates are used to authenticate the identity of a website to visiting
browsers. When a user wants to send confidential information to a web server, the browser
will access the server’s digital certificate. The certificate, which contains the public key of
the web server will be used by the browser to authenticate the identity of the web server
and to encrypt information for the server using SSL technology. Since the web server is the
only entity with access to its private key, only the server can decrypt the information.
„
Root certificates are self-signed digital certificates that are generated during the creation of
a certification authority (CA). “Trusted” root certificates refer to CA certificates that are
stored in the trust lists that are natively embedded in the leading web browsers. There are a
limited number of CA certificates which come embedded in the web browsers from
Microsoft and Netscape.
SSL for VPNs can be more than basic web page supporting secure access to the applications
available as static web pages on HTTP servers:
9-6
„
SSL VPNs can fit into existing networks and application environments and provide support
for complex applications such as corporate directory and calendar systems, e-commerce
applications, file sharing, and remote system management.
„
SSL VPNs can support the same authentication mechanisms and often extensive
application list as available for IPsec.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
SSL Access Mechanisms
ƒ Embedded clientless access provides content rewriting and
application translation through Layer 7 features.
ƒ Port forwarding using a thin client provides access to a set of
resources.
ƒ A dynamic VPN client using a thick client provides full network
access.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-8
SSL VPNs have multiple access mechanisms:
„
Content rewriting and application translation using embedded clientless access and Layer 7
features. Clientless access is where a user can connect with little requirements beyond a
basic web browser.
„
Port forwarding which is known as thin client. With a thin client, a small applet or
application, generally less than 100K in size, provides access to a subset of resources.
„
Dynamic VPN client with full network access known as thick client. With a thick client, a
larger client generally around 500K is delivered to the end user. The applications that can
be reached through the thick client are very similar to those available via IPsec VPNs. This
client is delivered via a web page and never needs to be manually distributed or installed.
© 2007 Cisco Systems, Inc.
IPsec and SSL VPN Design
9-7
Clientless Access
This section discusses clientless access for SSL VPNs.
Clientless Access
ƒ Concentrator proxies HTTP and HTTPS over SSL connection:
– Limited support
ƒ HTML pages
ƒ Web-based applications
– Content rewriting:
ƒ Translates content to HTTP.
ƒ Delivers HTML look-and-feel.
ƒ Supports file sharing.
ƒ Clientless access does not require specialized VPN software on
the user desktop.
– Minimal provision and support concerns.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-9
The SSL VPN system supports clientless access by proxying web pages. The system connects
to a web server, downloads and translates a web page, and then transfers it over an SSL
connection to the browser of the end user. The SSL VPN system rewrites or translates content
so that the internal addresses and names on a web page are accessible to the end users.
Only web-enabled and some client-server applications-such as intranets, applications with web
interfaces, e-mail, calendaring, and file servers-can be accessed using a clientless connection.
This limited access is suitable for partners or contractors that need access to a limited set of
resources on the network.
There are several content rewriting functions involved in proxying the remote applications:
„
Translating protocol to HTTP
„
Delivering HTML look-and-feel
„
Supporting file sharing
Clientless access for SSL VPNs does not require specialized VPN software on the user desktop
as all VPN traffic is transmitted and delivered through a standard web browser. Because no
special-purpose VPN software has to be delivered to the user desktop, provisioning and support
concerns are minimized.
9-8
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Thin Client
Thin client supports port forwarding for SSL VPNs with a small applet or application.
Thin Client (Port Forwarding)
Client Workstation
VPN
Appliance
Web
Browser
Hosts
Client
Program
Java
Applet
HTTS Connection
to VPN Appliance
Remote
Server
Protocol Connection
to Remote Server
TCP Connection to
Local Port
ƒ Thin client acts as local proxy:
– Tunnels and forwards application traffic.
ƒ VPN appliance delivers forwarded traffic.
ƒ Port forwarding maintains native application look-and-feel.
ƒ Port forwarding has some limitations:
– Works with predictable non-web applications.
ƒ Generally outbound, TCP-based, with static ports.
ƒ Telnet, SMTP, POP3 are supported.
– ActiveX or Java applet support as well as system permissions may be required.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-10
Organizations that have not implemented web-based applications can often rely on the “thin
clients” that support port forwarding. Port forwarding requires a very small application often in
the form of Java or ActiveX that runs on the end user system. The port forwarder acts as a local
proxy server. The client application listens for connections on a port defined for an application
on a local host address. It tunnels packets that arrive on this port inside of an SSL connection to
the SSL VPN device, which unpacks them and forwards them to the real application server.
Port forwarding maintains the native application look-and-feel for the end user.
Port forwarding is an effective technique, but it also has some limitations. For port forwarding
to work, the applications need to be well-behaved and predictable in their network connectivity
patterns and needs. Examples of applications that are not web-enabled but can be addressed
with port forwarding are common mail protocols, including SMTP, POP3 and MAPI, and
remote shell programs, such as Telnet. ActiveX or Java applet support may also be required on
the client machine, along with the permissions in the browser to run them.
© 2007 Cisco Systems, Inc.
IPsec and SSL VPN Design
9-9
Thick Client
This section discusses the thick client that supports full access through SSL VPN network
extension.
Thick Client (Layer 3 Network Access)
ƒ Supports network extension.
ƒ Traditional-style client delivered
through automatic download
(Active X, Java, and/or EXE).
ƒ Requires administrative
privileges for initial install.
ƒ Provides similar access to
IPsec:
– Better accessibility over
firewalls and NAT
– Smaller installation package
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-11
SSL VPN network extension connects the end user system to the corporate network with access
controls only based on network-layer information, such as destination IP address and port
number. Network extension uses a thick client that provides authorized users with secure access
to the entire corporate LAN.
The thick client is automatically delivered through the web page and does not need to be
manually distributed or installed. The thick client requires administrative access to the local
system. The Layer 3 thick client provides a virtual adapter for the end user typically using
ActiveX and Java. The applications that can be accessed with the thick client are very similar to
those available through an IPsec VPN. The Cisco SSL VPN Client for WebVPN is a Cisco
implementation of the thick client.
Since the SSL VPN network extension runs on top of the SSL protocol, it is simpler to manage
and has greater robustness with different network topologies such as firewalls and network
address translation (NAT) then the higher security of IPsec. The thick client is typically a
smaller installation then the IPsec client.
Thick mode should be used when users need full application access and IT wants tighter
integration with the operating system for additional security and ease of use.
9-10
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Remote Access VPN Design Considerations
This topic discusses some remote access VPN design considerations.
VPN Termination Device and Firewall Placement
The VPN termination device is typically deployed with a firewall at the network edge.
VPN Termination and Firewall Placement
ƒ Limit incoming traffic to IPsec and SSL for FW policy:
– Terminate IPsec tunnel on VPN appliance.
– Possibly send traffic through firewall for additional inspection.
ƒ Enforce endpoint security compliance on remote system.
Parallel
Inline
© 2007 Cisco Systems, Inc. All rights reserved.
DMZ
ARCH v2.0—9-13
The VPN termination device can be deployed in parallel with a firewall, inline with a firewall,
or in a DMZ. For best security, the recommended practice is to place the public side of the
VPN termination device in a DMZ behind a firewall.
Note
The firewall could be the VPN termination device.
The firewall policies should limit incoming traffic to the VPN termination device to IPsec and
SSL. Any IPsec tunnels should terminate on the VPN appliance. For extra security, sending
traffic through another firewall for additional inspection after it passes through the VPN
appliance.
You should also enforce endpoint security compliance on remote system.
© 2007 Cisco Systems, Inc.
IPsec and SSL VPN Design
9-11
Routing Design Considerations
Routing design considerations are mainly a VPN headend consideration for remote access
VPNs.
Routing Design Considerations
Remote
SW Client
Router S RRI: “I Can Reach 10.1.1.1”
Internet
10.1.1.1/32
X
P
Head-End
S
ƒ Most common configuration is a static route for address blocks
pointing to the VPN head-end.
ƒ Reverse Route Injection can populate the routing table of internal
routers for OSPF and RIPv2.
– VPN software clients assigned IP address are added as hosts
routes.
– A hardware client in Network Extension Mode can inject its
protected network address.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-14
For non-local subnet IP addresses, the most common configuration is that the internal routers
use a static route for these address blocks pointing to the private interface of the head-end
device.
Another option is to use Reverse Route Injection (RRI) to populate the routing table of internal
routers through Open Shortest Path First (OSPF) or Routing Information Protocol version 2
(RIPv2). RRI is the ability for static routes to be automatically inserted into the routing process
for those networks and hosts protected by a remote tunnel endpoint. These protected hosts and
networks are known as remote proxy identities.
With RRI, the assigned IP address of VPN software clients are injected as host routes into the
routing table by the VPN head-end. An Easy VPN hardware client will need RRI if it connects
using Network Extension Mode (NEM) to inject its protected network address.
Note
9-12
Smaller organizations typically configure a few static routes to point to the VPN device and
do not need RRI. The RRI function is usually of more benefit to larger organizations that
have more complex requirements, for example that do not have a dedicated scope of DHCP
addresses that are associated to a specific VPN head-end.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Address Assignment Design Considerations
This section discusses some design considerations for address assignment with remote access
VPNs.
Address Assignment Design
Consideration
IPsec, thin, and thick clients access:
ƒ Most common approach is internal address pools.
– ACLs on an internal firewall can use group-based address
pools.
ƒ DHCP assignment is next most common.
ƒ Static assignment requires RADIUS or LDAP to deploy.
Clientless access:
ƒ The head-end device will proxy ARP on behalf of all local subnet
IP addresses.
ƒ Clientless users do not receive their own unique IP address,
instead their traffic will originate from the head-end interface IP.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-15
For IPsec, thin, and thick clients there are three common addressing techniques:
„
The most simple and common address assignment design is to use internal address pools
per VPN head-end and to implement a static route for this subnet to the VPN head-end.
With this approach, ACLs on an internal firewall can support group-based address pools for
incoming user policies.
„
Using DHCP to assign addresses is another popular choice. A recommended practice is to
associate a dedicated scope of DHCP addresses to a specific VPN head-end.
„
For situations where the remote user needs a static IP address assignment to support a
specific application, organizations will need to deploy RADIUS or LDAP with attribute to
assign the user the same IP. In this case, RRI may be needed.
An IP address is not assigned for clientless end user devices:
„
The head-end device will proxy ARP on behalf of all local subnet IP addresses.
„
Since the clientless users do not receive unique IP address, their traffic will originate from
the head-end interface IP. This is good for scalability, but harder to monitor.
© 2007 Cisco Systems, Inc.
IPsec and SSL VPN Design
9-13
Other Design Considerations
Two other design considerations are authentication and access control.
Other Design Consideration
ƒ VPNs can use many types of client authentication.
– More security conscious organizations use one time
passwords.
– Static password databases can also be used.
ƒ Access control rules should be implemented for VPNs.
– Typically are defined at a per-group basis on the VPN
head-end device or on the RADIUS server.
– Tunnel-based VPNs provide Layer 3 control at the
protocol/port and destination IP level.
– Clientless SSL VPNs can provide more granular Layer 7
access control.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-16
Authentication
Although the SSL protocol does not support client authentication methods other than digital
certificates, it is possible to use other authentication methods in conjunction with SSL. The
simplest approach is username and password, but more security conscious organizations use
stronger authentication methods, such as security tokens and one time password (OTP).
Customers focused on convenience sometimes authenticate to an internal NT domain controller
or static RADIUS password database. Any type of static password configuration leaves the
organization vulnerable to brute force password attacks.
Access Control
Access control rules allow organizations to restrict network access. Some companies choose to
maintain all access rules on an internal firewall based on source IP of the client. This scenario
supports addresses that are assigned to a specific pool based on group assignment.
Access control rules can be defined at a per-group basis on the VPN head-end device. This
approach is easy to deploy, but can be more difficult to maintain with large numbers of policies
or across multiple devices. Access control rules can also be defined on the head-end RADIUS
server, although generic RADIUS has a 4K packet size limit. The Cisco Secure ACS offers a
downloadable ACL feature which can be used with Cisco head-end devices to support large
sized policies.
Tunnel-based VPNs (IPsec and SSL VPN clients) provide Layer 3 control at the protocol/port
and destination IP level. Clientless SSL VPNs can provide more granular Layer 7 access
control including URL-based access or file server directory level access control.
9-14
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Example: VPN Architecture
This section discusses an example VPN architecture.
Example: VPN Architecture
Non-Corporate PC
with Web Browser
Employee PC
with IPsec VPN client
Load Balancing
VPN Cluster
AAA Server
Internet
Public
ACME
Internal Resources
Unencrypted Traffic
© 2007 Cisco Systems, Inc. All rights reserved.
Encrypted Traffic
ARCH v2.0—9-17
The figure shows an example architecture for a VPN design supporting employees and
partners. The employees connect across the Internet using an IPsec VPN client. The
non-corporate users connect using SSL. The IPsec or SSL clients are authenticated using the
AAA server. Both IPsec and SSL VPNs come in on the public interface of the VPN cluster and
are terminated. Load balancing is used for resiliency, stateless failover and capacity growth on
the VPN cluster. The private interface of the VPN head-end connects through routers to the
internal corporate network. Inbound ACLs on the internal edge routers provide access control
rules to permit traffic to specific internal resources.
Users organized into various groups with appropriate security policy profiles and user
authentication and authorization information. Both Cisco IPsec VPN and SSL VPN clients are
supported as well as clientless SSL VPN with optional port forwarding feature.
© 2007 Cisco Systems, Inc.
IPsec and SSL VPN Design
9-15
Summary
This topic summarizes the key points discussed in this lesson.
Summary
ƒ Remote access VPNs using IPsec or SSL technologies permit
secure, encrypted connections between mobile or remote users
and their corporate network across public networks.
ƒ SSL technology supports VPNs using clientless access, port
forwarding, and thick mode dynamic VPN clients.
ƒ VPN design considerations include where to deploy VPN
termination devices, when RRI is needed to support remote
clients, address assignment practices for remote clients, and the
importance of authentication and access control.
© 2007 Cisco Systems, Inc. All rights reserved.
9-16
Designing Cisco Network Service Architectures (ARCH) v2.0
ARCH v2.0—9-18
© 2007 Cisco Systems, Inc.
Lesson 2
Site-to-Site VPN Design
Overview
Site-to-site VPNs are an alternative WAN infrastructure used to connect branch offices, home
offices, or business partners to all or portions of an enterprise network. VPNs do not inherently
change private WAN requirements, such as support for multiple protocols, high reliability, and
extensive scalability, but instead meet these requirements more cost-effectively and with
greater flexibility. Site-to-site VPNs utilize the most pervasive transport technologies available
today, such as the public Internet or service provider IP networks, by employing tunneling and
encryption for data privacy and quality of service (QoS) for transport reliability.
Objectives
Upon completing this lesson, you will be able to design simple and complex site-to-site VPNs,
given enterprise VPN needs. This ability includes being able to meet these objectives:
„
Identify typical applications for an enterprise site-to-site VPN
„
Discuss design considerations for enterprise site-to-site VPNs
Site-to-Site VPN Applications
This topic identifies common applications for site-to-site VPNs.
WAN Replacement Using Site-to-Site IPsec VPNs
WAN replacement is one of the biggest reasons organizations implement IPsec VPNs.
WAN Replacement Using
Site-to-Site IPsec VPNs
Central Site
V PN
N
VP
Intranet
Frame
Relay
Internet
WANVPN
Network
Branch/Remote Office
V PN
VP N
POP
VPN
DSL
Cable
Extranet
Mobile Users
Business-to-Business
Teleworkers
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-22
Up to 40 percent of typical enterprise employees work in branch offices, away from the central
sites providing mission-critical applications and services required for business operations. As
these services are extended to branch office employees, requirements increase for bandwidth,
security, and high availability.
IPsec VPNs can provide a cost effective replacement for a private WAN infrastructure. Often
the cost of a relatively high-bandwidth IP connection, such as an ISP connection, IP VPN
provider, or broadband DSL/cable access, is lower than existing or upgraded WAN circuits.
Organizations can use IPsec VPNs to connect remote branches, offices, teleworkers and mobile
users to the corporate resources as the central site. Organizations also use IPsec VPNs to
provide extranet connectivity for business to business applications.
The key components of site-to-site VPN include:
9-18
„
Head-end VPN devices: Serve as VPN head-end termination devices at a central campus
(head-end devices)
„
VPN access devices: Serve as VPN branch-end termination devices at branch office
locations
„
IPSec and GRE tunnels: Interconnect the head-end and branch-end devices in the VPN
„
Internet services from ISPs: Serve as the WAN interconnection medium
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
WAN Backup Using Site-to-Site IPsec VPNs
Another common business application using IPsec VPNs is for backing up an existing WAN.
Example: WAN Backup Using
Site-to-Site IPsec VPNs
Central Site
Frame Relay
WAN Network
Intranet
Branch/Remote Office
VP
VP
N
N
VP
VP
N
N
Internet VPN
PSTN/ISDN
Broadband
Extranet
Business-to-Business
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-23
When a primary network connection malfunctions, the remote branch office can rely on
Internet VPN connectivity while waiting for the primary connection to be restored.
IPsec VPNs over a high-speed ISP connection or broadband cable/DSL access can provide a
very cost-effective secondary WAN connection for branch offices. Many customers continue to
route their most critical traffic across their private WAN circuits, and route higher-bandwidth,
less critical traffic across IPsec VPNs as a secondary connection path. If a failure occurs of
their primary WAN circuit, the IPsec VPN can also function as an established backup path.
© 2007 Cisco Systems, Inc.
IPsec and SSL VPN Design
9-19
Regulatory Encryption Using Site-to-Site IPsec VPNs
Another common business application using IPsec VPNs is for mandatory or regulatory
encryption.
Example: Regulatory Encryption Using
Site-to-Site IPsec VPNs
Intranet
Branch/Remote Office
VP
VP
N
N
VP
VP
N
N
Frame Relay or
MPLS VPNs
Extranet
Business-to-Business
(Financial Data)
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-24
Regulations such as the Health Insurance Portability and Accountability Act (HIPAA), the
Sarbanes-Oxley Act (S-Ox), and the Basel II Agreement recommend or mandate the need for
companies to implement all reasonable safeguards to protect personal, customer, and corporate
information. IPsec VPNs inherently provide a high degree of data privacy through
establishment of trust points between communicating devices, and data encryption with the
Triple Data Encryption Standard (3DES) or Advanced Encryption Standard (AES).
Site-to-site VPNs support regulatory constraints and business policies. As network security
risks increase and regulatory compliance becomes essential, organizations are using IPsec
VPNs to encrypt and protect data such as medical records, corporate or personal financial data,
and sensitive information such as legal, police, and academic records whether using a private
WAN, IP VPN, or the Internet for connectivity.
9-20
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Site-to-Site VPN Design Considerations
This topic identifies some design considerations for site-to-site IPsec VPNs.
IP Addressing and Routing
An IPsec VPN is an overlay on an existing IP network.
IP Addressing and Routing
IP addressing
ƒ IPsec VPN is an overlay on existing IP network:
– VPN device needs routable outside IP address.
– Private IP address space can be used inside VPN.
ƒ VPN addressing designs need to allow summarization.
– NAT may be needed within an organization.
ƒ VPN is typically implemented in tunnel mode.
Routing
ƒ Large-scale networks require dynamic routing.
ƒ IPsec does not inherently support transport of broadcast or IP
multicast packets.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-26
The VPN termination devices need routable IP addresses for the outside Internet connection.
Private IP addresses can be used on the inside of the VPN. Just as good IP network design
support summarization, the VPN address space needs to be designed to allow for network
summarization as well. Network address translation (NAT) may be needed to support
overlapping address space between sites in an organization.
Most IPsec VPNs forward data across the network using IPsec tunnel mode which encapsulates
and protects an entire IP packet. Because tunnel mode encapsulates or hides the IP header of
the pre-encrypted packet, a new IP header is added so that the packet can be successfully
forwarded.
Many larger enterprise WANs need dynamic routing protocols such as Enhanced Interior
Gateway Routing Protocol (EIGRP) and Open Shortest Path First (OSPF) to provide routing
and maintain link state and path resiliency. All Interior Gateway Protocols (IGPs) routing
protocols use either broadcast or IP multicast as a method of transmitting routing table
information. However, basic IPsec designs cannot transport IGP dynamic routing protocols or
IP multicast traffic. When support for one or more of these features is required, IPsec should be
used in conjunction with other technologies such as Generic Route Encapsulation (GRE).
© 2007 Cisco Systems, Inc.
IPsec and SSL VPN Design
9-21
Scaling, Sizing, and Performance
This section describes the critical factors that affect the scalability of an IPsec VPN design.
Scaling, Sizing, and Performance
ƒ Head-end VPN device scaling and sizing considerations:
– Total number of remote sites
– VPN traffic throughput
– Features including routing protocols, GRE, firewall, QoS
ƒ VPN device performance considerations:
– A head-end device should have less than 50% CPU utilization.
– Branch devices should have less than 65% CPU utilization.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-27
Scaling large aggregations while maintaining performance and high availability is challenging,
and requires careful planning and design. Many factors affect scalability of an IPsec VPN
design, including number of route sites, access connection speeds, routing peer limits, IPsec
encryption engine throughput, features to be supported, and applications that will be
transported over the IPsec VPN.
The number of remote sites is a primary factor in determining scalability of a design and affects
the routing plan, high availability design, and ultimately the overall throughput that must be
aggregated by the VPN headend routers. Different routers can support different numbers of
tunnels.
IPsec VPN throughput depends on several factors, including connection speeds, capacity of the
crypto engine, and CPU limits of the router. An IPsec crypto engine in a Cisco IOS router is a
unidirectional device that must process bidirectional packets. Outbound packets must be
encrypted by the IPsec crypto engine, while inbound packets must be decrypted by the same
device. For each interface having packets encrypted, it is necessary to consider the
bi-directional speed of the interface. For example, a T1 connection speed is 1.544 Mbps, but the
IPsec throughput required is 3.088 Mbps.
Cisco has some recommended practices for VPN device performance limits:
9-22
„
Redundant head-end device should be deployed in a configuration that results in CPU
utilization less than 50%. The 50% target includes all overhead incurred by IPsec and any
other enabled features such as firewall, routing, IDS, and logging. This performance limit
will allow the head-end device to handle failover of the other head-end device.
„
Since branch devices will need to support fewer additional tunnels in a failover event,
branch devices can be deployed in a configuration less than 65% CPU utilization.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Cisco Router Performance with IPsec VPNs
This section discusses some IPsec VPN performance numbers for Cisco routers.
Cisco Router Performance with IPsec
VPNs
Cisco VPN Security Router
Max
Tunnels
3DES
Throughput
AES
Throughput
Cisco 850
5
8 Mbps
8 Mbps
Cisco 870
10
30 Mbps
30 Mbps
Cisco 1841 with AIM-VPN/BPII
800
95 Mbps
95 Mbps
Cisco 2801 with AIM-VPN/BPII
1,500
100 Mbps
100 Mbps
Cisco 2811 with AIM-VPN/EPII
1,500
130 Mbps
130 Mbps
Cisco 2821 with AIM-VPN/EPII
1,500
140 Mbps
140 Mbps
Cisco 2851 with AIM-VPN/EPII
1,500
145 Mbps
145 Mbps
Cisco 3825 with AIM-VPN/EPII
2,000
175 Mbps
175 Mbps
Cisco 3845 with AIM-VPN/EPII
2,500
185 Mbps
185 Mbps
Cisco 7200VXR with a Single SA-VAM2+
5,000
260 Mbps
260 Mbps
Cisco 7301 with SA-VAM2+
5,000
370 Mbps
370 Mbps
Cisco Catalyst® 6500/7600 with One IPsec VPN SPA
8,000
2.5 Gbps
2.5 Gbps
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-28
Because IPsec VPN connections do not normally have a bandwidth associated with them, the
overall physical interface connection speeds of both the headend and branch routers largely
determine the maximum speeds at which the IPsec VPN must operate. The figure shows best
case scenarios with minimal features running IPsec VPNs in a lab with 1400 byte packets.
However, the packet per second (pps) rate matters more than throughput bandwidth (bps) for
the connection speeds being terminated or aggregated. In general, routers and crypto engines
have upper boundaries for processing a given number of pps. The size of packets used for
testing and throughput evaluations can understate or overstate true performance. For example,
if a device can support 20 Kpps, then 100-byte packets lead to 16 Mbps throughput, while
1400-byte packets at the same packet rate lead to 224 Mbps. Because of such a wide variance
in throughput, pps is generally a better parameter to consider for scalability than bps.
Each time a crypto engine encrypts or decrypts a packet, it performs mathematical
computations on the IP packet payload using the unique crypto key for the trustpoint, agreed
upon by the sender and receiver. If more than one IPsec tunnel is terminated on a router, the
router has multiple trust points and therefore multiple crypto keys. When packets are to be sent
or received to a different tunnel than the last packet sent or received, the crypto engine must
swap keys to use the right key matched with the trust point. This key swapping can degrade the
performance of a crypto engine, depending on its architecture, and increase the router CPU
utilization. For some Cisco platforms, such as the 7200VXR with SA-VAM2+, as the number
of tunnels increases, throughput of the IPsec crypto engine decreases. For other Cisco
platforms, such as the 7600 with VPN SPA, performance is relatively linear, with relatively the
same throughput for a single tunnel as for 1000 or even 5000.
© 2007 Cisco Systems, Inc.
IPsec and SSL VPN Design
9-23
Cisco Router Security Performance
This section discusses some security performance numbers for Cisco routers.
Performance and Service
Cisco Router Security Performance
Scalable Performance
• Up to 1.1Gbps F/W*
• Up to 185 Mbps IPsec
• Up to 425 Mbps IPS**
• Up to 2,500 tunnels
1.1 Gbps F/W
185 Mbps IPsec VPN
425 Mbps IPS
2,500 Tunnels
855 Mbps F/W
175 Mbps IPsec VPN
325 Mbps IPS
2,000 Tunnels
530 Mbps F/W
145 Mbps IPsec VPN
250 Mbps
1,500 Tunnels
455 Mbps F/W
140 Mbps IPsec VPN
200 Mbps IPS
1,500 Tunnels
130 Mbps F/W
130 Mbps IPsec VPN
70 Mbps IPS
1,500 Tunnels
127 Mbps F/W
100 Mbps IPsec VPN
65 Mbps IPS
1,500 Tunnels
125 Mbps F/W
95 Mbps IPsec VPN
60 Mbps IPS
800 Tunnels
Cisco 3845
Cisco 3825
Cisco 2851
Cisco 2821
Cisco 2811
Cisco 2801
Cisco 1841
* Firewall performance is with NAT and logging enabled
** Branch scenario when tested with optimal traffic conditions
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-29
The Cisco Integrated Service Routers (ISRs) are built with fast processors and crypto to support
high performance security features. The Cisco IOS Advanced Security feature set combines a
rich VPN feature set with advanced firewall, intrusion prevention, and extensive Cisco IOS
Software capabilities including QoS, multiprotocol, multicast, and advanced routing support.
The figure shows some best case performance measures for individual security features. The
VPN throughput numbers are with 1400 byte packets and AIM acceleration cards installed.
Note
9-24
The performance numbers in a production environment may be different.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Cisco ASA 5500 Series Performance
This section discusses some security performance numbers for the Cisco ASA 5500 Series
Adaptive Security Appliances.
Cisco ASA 5500 Series Performance
Model
SSL/IPsec Scalability
Max VPN
Throughput
Cisco ASA 5505
25 simultaneous VPN sessions
100 Mbps
Cisco ASA 5510
250 simultaneous VPN sessions
170 Mbps
Cisco ASA 5520
750 simultaneous VPN sessions
225 Mbps
Cisco ASA 5540
2500 simultaneous SSL VPN sessions;
325 Mbps
5000 simultaneous IPsec VPN sessions;
Cisco ASA 5550
© 2007 Cisco Systems, Inc. All rights reserved.
5000 simultaneous VPN sessions
425Mbps
ARCH v2.0—9-30
Cisco ASA 5500 Series all-in-one adaptive security appliances deliver enterprise-class security
and VPN to small and medium-sized businesses and large enterprise networks in a modular,
purpose-built appliance. The Cisco ASA 5500 Series incorporates a wide range of integrated
security services, including firewall, intrusion prevention system (IPS), and anti-X services
with SSL and IPsec VPN services in an easy-to-deploy, high-performance solution. The Cisco
ASA 5500 Series is Cisco's most feature-rich solution for SSL and IPsec-based remote access,
and supports robust site-to-site connectivity. The series provides higher scalability and greater
throughput capabilities than the widely deployed Cisco VPN 3000 Series Concentrators.
The figure shows some best case performance measures for the Cisco ASA 5500 Series.
Note
© 2007 Cisco Systems, Inc.
The performance numbers in a production environment may be different.
IPsec and SSL VPN Design
9-25
Typical VPN Device Deployments
This table shows where Cisco VPN devices are typically deployed.
Typical VPN Device Deployment
Location
Models
Teleworkers
Cisco 850/870
SOH0
Cisco 850/870
Small Business
Cisco ASA 5505
Cisco 1800
Small Branch
Cisco ASA 5510
Cisco 2800
Medium Branch
Cisco ASA 5520
Cisco 3800
Enterprise Branch
Enterprise Edge
Enterprise Headquarters
Data Center
© 2007 Cisco Systems, Inc. All rights reserved.
Cisco ASA 5540 and 5550
Cisco 7200 and 7301
Catalyst 6500
Cisco 7600
Cisco ASA 5550
ARCH v2.0—9-31
The Cisco ASA 5500 Series supports both IPsec VPNs and SSL-based remote-access VPN
services deployments on a single integrated platform. The Cisco Integrated Services Routers
and Cisco Catalyst Switches support site-to-site IPsec VPNs of any topology-from hub-andspoke to the more complex fully meshed VPNs on networks of all sizes integrating security
services with extensive Cisco IOS Software capabilities including QoS, multiprotocol,
multicast, and advanced routing support.
9-26
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Design Topologies
This section gives a high-level overview of several different IPsec VPN design topologies that
can be deployed.
Design Topologies
ƒ Peer-to-peer
ƒ Hub and spoke
– Is most common topology.
– Has performance penalty due to two encryption/decryption
cycles.
ƒ Partial Mesh
– Adds some direct spoke-to-spoke communications to hub and
spoke topology.
ƒ Full Mesh
– Provides direct spoke-to-spoke communications across
topology.
– Has issues with scaling and provisioning.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-32
A peer-to-peer IPsec VPN provides connectivity between two sites through a tunnel that
secures traffic.
Typically, remote peers are connected to the central site over a shared infrastructure in a
hub-and-spoke topology with tunnels from the multiple spokes to the head-end hub. The
hub-and-spoke topology scales well. However, there is a performance penalty due to two
encryption/decryption cycles for spoke-to-spoke traffic.
A meshed topology may be the appropriate design to use when there are multiple locations with
a large amount of traffic flowing between them. To eliminate the performance penalty due to
two encryption/decryption cycles for spoke-to-spoke traffic, a partial mesh topology can be
used. The partial mesh topology is similar to a hub-and-spoke topology, but supports some
direct spoke-to-spoke connectivity.
The full mesh topology provides direct connectivity between all locations. There are scaling
issues as the number of IPsec tunnels needed grows exponentially as number of sites increases.
This topology is also more difficult to provision.
Note
© 2007 Cisco Systems, Inc.
Design topologies are discussed in more detail in the “VPN Implementation Technologies”
lesson in this chapter.
IPsec and SSL VPN Design
9-27
VPN Device Placement Designs
This section discusses designs for placing the VPN device in the network.
VPN Device Parallel to Firewall
The VPN device can be placed parallel to a firewall in the network.
VPN Device Placement: Parallel to
Firewall
To WAN Edge
To Campus
DMZ
Advantages
ƒ Supports simplified implementation.
ƒ Supports high scalability.
Disadvantages
ƒ IPsec decrypted traffic is not firewall inspected.
ƒ No centralized point of logging/content inspection .
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-33
There are advantages in placing the VPN device parallel to the firewall:
„
Simplified implementation to deploy since firewall addressing does not need to change
„
High scalability since multiple VPN devices can be deployed in parallel with the firewall
There are some disadvantages to placing the VPN device parallel to the firewall:
9-28
„
IPsec decrypted traffic is not firewall inspected. This issue is a major concern if the traffic
is not subject to a stateful inspection.
„
No centralized point of logging or content inspection is implemented.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
VPN Device on a DMZ of Firewall
The VPN device can be placed in the DMZ on the firewall in the network.
VPN Device Placement: In DMZ of
Firewall
DMZ
DMZ
To WAN Edge
To Campus
Advantages
ƒ IPsec decrypted traffic is firewall inspected.
ƒ Has moderate to high scalability.
Disadvantages
ƒ Has increased configuration complexity.
ƒ Firewall may impose bandwidth restrictions.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-34
There are advantages to placing the VPN device in the DMZ of a firewall:
„
The firewall can statefully inspect the decrypted VPN traffic. The design supports the
layered security model and enforces firewall security policies.
„
The design supports moderate-to-high scalability by adding additional VPN devices.
Migration to this design is relatively straightforward with addition of LAN interface to
firewall.
There are disadvantages to placing the VPN device in the DMZ of a firewall:
„
The configuration complexity increases because additional configuration on firewall to
support the additional interfaces. The firewall must support policy routing to differentiate
VPN versus non-VPN traffic.
„
The firewall may impose bandwidth restrictions on stacks of VPN devices.
© 2007 Cisco Systems, Inc.
IPsec and SSL VPN Design
9-29
Integrated VPN and Firewall
Another option is an integrated VPN and firewall device in the network.
VPN Device Placement: Integrated with
Firewall or IPS
To WAN Edge
To Campus
DMZ
Advantages
ƒ IPsec decrypted traffic is firewall inspected.
ƒ Has same or fewer devices to manage.
Disadvantages
ƒ Has scaling concerns.
ƒ Has increased configuration complexity.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-35
There are advantages to integrating the VPN device and the firewall:
„
The firewall can statefully inspect the decrypted VPN traffic. The design supports the
layered security model and enforces firewall security policies.
„
The design may be easier to manage with the same or fewer devices to support.
There are disadvantages to placing the VPN device in the DMZ of a firewall:
9-30
„
Scalability can be an issue as single device must scale to meet performance requirements of
multiple features.
„
The configuration complexity increases because all the configurations are applied to one
device.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Summary
This topic summarizes the key points discussed in this lesson.
Summary
ƒ Site-to-site VPN applications include WAN replacement, WAN
backup, and supporting regulatory mandates.
ƒ Site-to-site VPN design considerations include addressing and
routing practices to support integration with existing networks,
sizing for scaling and performance, and using design topologies
and placement of VPN devices to support required layers of
security.
© 2007 Cisco Systems, Inc. All rights reserved.
© 2007 Cisco Systems, Inc.
ARCH v2.0—9-36
IPsec and SSL VPN Design
9-31
9-32
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Lesson 3
IPsec VPN Technologies
Overview
There are several types of IPsec VPNs that are used to permit secure, encrypted communication
between network devices. This lesson reviews some industry standard and Cisco technologies
used in supporting IPsec VPNs.
Objectives
Upon completing this lesson, you will be discuss technologies used to support IPsec VPN. This
ability includes being able to meet these objectives:
„
Review standard IPsec VPN deployments
„
Discuss EASY VPN
„
Describe Generic Route Encapsulation (GRE) tunneling over IPsec VPN design
considerations
„
Describe Dynamic Multipoint VPN (DMVPN) design considerations
„
Discuss Virtual Tunnel Interface design considerations
„
Describe Group Encrypted Transport VPN (GET VPN) design considerations
IPSec VPN Overeview
IPsec functionality provides data encryption at the IP packet level, offering a robust, standardsbased, security solution.
IPsec VPN Features
ƒ Provides point-to-point tunnel between two peers
ƒ Provides data encryption at the IP packet level
ƒ Several configuration parameters are needed
ƒ Only supports unicast traffic
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-40
IPSec provides secure point-to-point tunnels between two peers, such as two routers. These
tunnels are actually sets of security associations (SAs) that are established between two IPSec
peers. The SAs define which protocols and algorithms should be applied to sensitive packets
and specify the keying material to be used by the two peers. SAs are unidirectional and are
established per security protocol, either Authentication Header (AH) or Encapsulating Security
Payload (ESP).
With IPSec, the network manager can define what traffic should be protected between two
IPSec peers by configuring ACLs and applying these ACLs to interfaces by way of crypto
maps. The ACLs used for IPSec are used only to determine which traffic should be protected
by IPSec, not which traffic should be blocked or permitted through the interface. Separate
ACLs define blocking and permitting at the interface.
IPsec can support certain traffic receiving one combination of IPSec protection (for example,
authentication only) and other traffic receiving a different combination of IPSec protection (for
example, both authentication and encryption), by using two different crypto ACLs to define the
two different types of traffic. These different ACLs are then used in different crypto map
entries, which specify different IPSec policies.
Standard IPsec VPNs only support unicast traftic, which is an issue for deploying them within
an enterprise.
9-34
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Extensions to Standard IPsec VPNs
There are several site-to-site VPN solutions that extend the capabilities of basic IPsec VPNs.
Extensions to Standard IPsec VPNs
ƒ Easy VPN
ƒ GRE tunneling
ƒ Dynamic Multipoint VPN (DMVPN)
ƒ Virtual tunnel interfaces (VTI)
ƒ Group Encrypted Transport VPN (GET VPN).
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-41
Cisco provides several site-to-site VPN solutions that support routing to deliver reliable
transport for complex mission-critical traffic, such as voice and client-server applications.
These solutions are built on five underlying VPN technologies:
„
Easy VPN
„
GRE tunneling
„
Dynamic Multipoint VPN (DMVPN)
„
Virtual tunnel interfaces (VTI)
„
Group Encrypted Transport VPN (GET VPN)
Each technology is customized to meet specific deployment requirements.
Note
© 2007 Cisco Systems, Inc.
This lesson compares these technologies and provides guidance on when to use them.
IPsec and SSL VPN Design
9-35
Cisco Easy VPN
The Cisco Easy VPN solution provides simple VPN deployments for remote offices and
teleworkers.
Easy VPN Implementation
Easy VPN Server
Central Site
Easy VPN Remote
Branch Office 1
Internet
POP
Easy VPN Remote
DSL
Cable
Branch Office 2
ƒ Predefined security policies pushed to
remote sites
ƒ Configuration parameters pushed to
remote sites:
Easy VPN Remote
Teleworker
– Internal IP addresses
– Internal subnet masks,
– DHCP server addresses
– Split-tunneling flags
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-43
Ease of deployment is critical when technical resources are not available for VPN configuration
at remote offices and for teleworkers. The Cisco Easy VPN solution centralizes VPN
management across all Cisco VPN devices and reduces the management complexity of VPN
deployments. The Cisco Easy VPN Remote feature and the Cisco Easy VPN Server feature
offer flexibility, scalability, and ease of use for site-to-site and remote-access VPNs.
The Cisco Easy VPN Remote feature allows Cisco routers running Cisco IOS Release
12.2(4)YA (or later releases), Cisco PIX firewalls, and Cisco hardware clients to act as remote
VPN clients. These devices can receive predefined security policies and configuration
parameters from the VPN head-end at the central site, which minimizes the VPN configuration
required at the remote location. Parameters such as internal IP addresses, internal subnet masks,
DHCP server addresses, WINS server addresses, and split-tunneling flags are all pushed to the
remote device.
The Cisco Easy VPN Server feature, available in Cisco IOS Release 12.2(8)T or later releases,
increases compatibility of Cisco VPN products, and allows Cisco VPN concentrators, Cisco
PIX firewalls, or Cisco routers to act as VPN head-end devices in site-to-site or remote-access
VPNs. Using this feature, security policies defined at the head-end can be pushed to the remote
office devices running the Cisco Easy VPN Remote feature.
9-36
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Overview of Easy VPN Server Wizard on SDM
The Security Device Manager (SDM) Easy VPN Server Wizard can configure the Easy VPN
server on Cisco routers.
Easy VPN Server Wizard on SDM
With the Easy VPN
Server Wizard:
ƒ Select the interface on
which the client
connections will
terminate
ƒ Configure IKE policies
ƒ Configure group policy
lookup method
ƒ Configure user
authentication
ƒ Configure group policies
on local database
ƒ Configure an IPsec
transform set
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-44
Cisco Easy VPN solution is ideal for remote offices with little IT support or for large customer
deployments where it is impractical to individually configure multiple remote devices. This
feature makes VPN configuration as easy as entering a password, which minimizes local IT
support, increases productivity, and lowers costs. The figure shows the starting SDM screen for
the Easy VPN Server Wizard that can configure the Easy VPN server. The Easy VPN Server
Wizard guides network administrators in performing the tasks to successfully configure an
Easy VPN server on a router:
„
Selecting the interface on which the client connections will terminate
„
Configuring Internet Key Exchange (IKE) policies
„
Configuring group policy lookup method
„
Configuring user authentication
„
Configuring group policies on local database, if needed
„
Configuring an IP Security (IPsec) transform set.
Note
© 2007 Cisco Systems, Inc.
SDM supports VPNs with basic IPsec tunnels, Generic Route Encapsulation (GRE) over
IPsec tunnels, and Dynamic Multipoint VPN (DMVPN).
IPsec and SSL VPN Design
9-37
Overview of Easy VPN Remote Wizard on SDM
The SDM Easy VPN Remote Wizard can configure the Easy VPN remote devices.
Easy VPN Remote Wizard on SDM
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-45
The Easy VPN Remote Wizard SDM can configure a remote router that will be connecting to
the Easy VPN Server router. To launch the wizard in SDM, on the configuration Tasks button
list on the left, click “VPN”. Select “Easy VPN Remote” in the tree hierarchy on the left. With
the “Create An Easy VPN Remote” option selected, click the “Launch The Selected Task”
button.
Note
9-38
The Cisco Adaptive Security Device Manager (ASDM) can be used to configure Easy VPN
server or remote operation on the Cisco ASA 5500 Series Adaptive Security Appliances,
Cisco PIX 500 Series Security Appliances (running Cisco PIX Security Appliance Software
Version 7.0 or above) and the Cisco Catalyst 6500 Series Firewall Services Modules
(FWSM version 3.1 or above).
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
GRE over IPsec
This topic discusses Generic Route Encapsulation (GRE) tunneling over IPsec.
Tunnels and IPsec
IP
HDR
Data
IPsec Tunnel
GRE Tunnel
L3
IP GRE
HDR HDR
IP Data
HDR
IP
HDR
ESP
HDR
IP
HDR
GRE
HDR
IP
Data
HDR
Encrypted
IP
HDR
Data
Decapsulate
Twice
ƒ Tunnel mode is recommended over transport mode IPsec:
– Tunnel mode is faster with hardware acceleration.
– Tunnels that transit a NAT or PAT device require it.
– Some new features also require tunnel mode.
ƒ Basic IPsec tunnels only IP unicast traffic.
ƒ GRE tunnels encapsulates non-IP and IP multicast or broadcast
packets into IP unicast packets.
– Hub uses a GRE interface per spoke.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-47
Tunnel mode IPsec works by encapsulating and protecting an entire IP packet. IPsec transport
mode works by inserting the Encapsulating Security Protocol (ESP) header between the IP
header and the next protocol or the transport layer of the packet. Tunnel mode IPsec is
recommended over transport mode IPsec for forwarding traffic across a network because:
„
Tunnel mode is faster with hardware acceleration.
„
If the crypto tunnel transits either a Network Address Translation (NAT) or Port Address
Translation (PAT) device, tunnel mode is required.
„
Some new features such as Look-Ahead Fragmentation also require tunnel mode.
Basic IPsec designs cannot transport IGP dynamic routing protocols or IP multicast traffic
because because the IPsec ESP only tunnels unicast IP traffic. To support the routing or IP
multicast requirements of most enterprises, IPsec should be used in conjunction with other
technologies such as GRE.
GRE tunneling encapsulates non-IP and IP multicast or broadcast packets into IP unicast
packets. These GRE packets can be encrypted by the IPsec tunnel. At the remote end of the
IPsec tunnel, both the IPsec encapsulation and the GRE encapsulation is removed to recover the
original packet. With GRE over IPsec designs, the hub router uses a single GRE interface for
each spoke.
© 2007 Cisco Systems, Inc.
IPsec and SSL VPN Design
9-39
GRE over IPsec Design Recommendations
This section discusses design recommendations for point-to-point GRE over IPsec VPNs.
GRE over IPsec Design Recommendations
s1
h1
Internet
h2
s2
ƒ On failure recovery, the load should be dynamically rebalanced at
the head-end devices.
ƒ In general, the head-end routing protocol can safely scale up to
500 peers
– EIGRP is recommended since it is less CPU intensive than
OSPF.
ƒ GRE keepalives can be used for failure detection in case of static
routing or point-to-point tunnels
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-48
A routing protocol can dynamically rebalance traffic across redundant head-end routers on
failover recovery. Although IPsec can typically scale to thousands of tunnels on some
platforms, a routed point-to-point GRE over IPsec design is generally limited by the routing
protocol being used and the number of routing peers exchanging routing information. In
general, the head-end routing protocol can safely scale up to 500 peers:
„
500 peers for the Cisco 7200VXR with NPE-G1
„
600 peers for the Cisco 7200VXR with NPE-G2
„
1000 peers for the Cisco 7600 (or Catalyst 6500) with Sup720
Enhanced Interior Gateway Routing Protocol (EIGRP) is recommended as the routing protocol
because of its conservative use of router CPU and network bandwidth as well as its quick
convergence times. EIGRP also provides a range of options for address summarization and
default route propagation.
GRE keepalives can be used for failure detection in case of static routing on point-to-point
tunnels. Beginning in Cisco IOS software version 12.2(8)T, the GRE keepalive feature is
available for use on tunnel interfaces. This functionality allows the line protocol of the tunnel
interface to track the reachability between the two tunnel endpoints. If GRE keepalives are sent
and acknowledged by the remote router, the line protocol is “up”. If successive GRE keepalives
are not acknowledged, based on the configured interval and number of retries, the tunnel line
protocol is marked “down”.
9-40
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
GRE over IPsec Design
Recommendations (cont.)
s1
h1
Internet
h2
s2
Designs should avoid asymmetric routing with redundant head-end
routers:
ƒ Change “bandwidth” value for both GRE interfaces
ƒ Watch for unrealistic bandwidth settings
ƒ Consider using the delay command under GRE tunnel interface
Hub-and-spoke is most common point-to-point GRE over IPsec
topology:
ƒ Partial mesh is limited by routing protocol and static IP addressing
ƒ Full mesh is limited routing protocol, static IP addressing, and
administrative overhead
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-49
The figure shows a simple hub-and-spoke network with multiple head-end devices for
redundancy. Point-to-point GRE and crypto tunnels functionally co-exist on the same router
CPU on the head-end devices. The head-ends service multiple point-to-point GRE over IPsec
tunnels for a prescribed number of branch office locations. In addition to terminating the VPN
tunnels at the central site, the head-ends can advertise branch routes using IP routing protocols
such as EIGRP and Open Shortest Path First (OSPF).
In order to avoid asymmetric routing when routing is running over the tunnels, one of the GRE
tunnels between the head-end routers and each remote site must be favored. The routing metric
should be consistent both upstream and downstream to prevent asymmetric routing.
There are options for configuring different paths in this design with slightly different metrics to
provide preference between the tunnels:
„
Change “bandwidth” value for the GRE interface on both ends to create primary and
secondary tunnels
„
Watch for unrealistic bandwidth settings that might affect the flow control of EIGRP
„
Use the delay command under GRE tunnel interface
Hub-and-spoke topologies are the most common topologies in a point-to-point GRE over IPsec
design:
„
Although partial mesh topologies are available, they are limited by both the routing
protocol and the availability of static public IP addresses for the spokes.
„
Full mesh topologies in a point-to-point GRE over IPsec design are available as well and
have the same limitations as partial mesh topologies. With the administrative overhead
involved, a full mesh topology is not recommended in a point-to-point GRE over IPsec
design.
© 2007 Cisco Systems, Inc.
IPsec and SSL VPN Design
9-41
DMVPN
This topic discusses Dynamic Multipoint Virtual Private Networks (DMVPNs).
Drivers for DMVPN
ƒ There are some issues with meshed VPNs:
– All spoke-to-spoke traffic is through hub
– Configuration task complexity
ƒ Single GRE interface for EACH spoke
ƒ All tunnels need to be pre-defined
ƒ Number of IPsec SAs grows exponentially
ƒ Dynamic peer discovery and on-demand tunnel creation needed.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-51
Mesh designs simply do not scale well for greater than 10 sites. With a traditional hub-andspoke topology, all spoke-to-spoke traffic is through the hub. As more nodes are added to a
mesh topology, the configuration task becomes more complex and the number of IPsec security
associations (SAs) grow exponentially as number of spoke sites increases.
In these cases, dynamic peer discovery and on-demand tunnel creation mechanisms are
required. When there is more than 20% spoke-to-spoke traffic or a full mesh VPN topology is
required, a DMVPN solution should be considered.
9-42
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
DMVPN Overview
DMVPN is a technology that supports IPsec VPNs with simplified configuration through
crypto profiles and dynamic discovery of tunnel endpoints.
DMVPN Overview
ƒ Create the spoke-to-spoke tunnels dynamically based on traffic
requirements
– Uses IPsec, GRE, and NHRP
– Backbone supports direct spoke-to-spoke functionality
ƒ Advantages:
– Dynamic mesh with fewer active tunnels on each spoke
– Configuration scales better
– Easy to add a node
– Spokes can have dynamic address or be behind NAT
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-52
DMVPN enables dynamic configuration and reduces the maintenance and configuration on the
hubs. DMVPN is a combination of IPsec, GRE, and next hop routing protocol (NHRP).
DMVPN has a backbone hub-and-spoke topology, but allows direct spoke-to-spoke
functionality using tunneling to enable the secure exchange of data between two branch offices
without traversing the head office.
DMVPN has several advantages:
„
With a dynamic mesh, the number of active tunnels is much lower on each spoke then with
a full mesh design. Smaller routers can be used at the spokes.
„
The configuration scales better because there is no need for static definitions for each
spoke-in-the-hub.
„
It is easier to add a node to the topology since there is no need to configure the new spoke
on all the other nodes
„
The spokes can have dynamic address or be behind NAT
Note
© 2007 Cisco Systems, Inc.
You can use SDM to configure a router as a DMVPN hub, or as a spoke router in a DMVPN
network.
IPsec and SSL VPN Design
9-43
DMVPN Topology
192.168.0.0/24
.1
.
Permanent IPsec + GRE tunnel
Hub
Physical: 172.17.0.1
Tunnel0:
10.0.0.1
Dynamic IPsec + GRE tunnel
Internet
Physical: 172.16.2.1
Tunnel0: 10.0.0.12
SpokeB
.1
Physical: 172.16.1.1
Tunnel0: 10.0.0.11
192.168.2.0 /24
Physical: 172.16.3.1
Tunnel0: 10.0.0.13
.1
SpokeA
192.168.1.0 /24
SpokeC
.1
192.168.3.0 /24
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-53
Example: DMVPN Topology
The figure shows an example DMVPN topology. DMVPN does not alter the standards-based
IPsec VPN tunnels, but it changes their configuration.
The hub router maintains a NHRP database of public interface addresses for each spoke. The
hub uses a single multipoint GRE (mGRE) tunnel interface to support multiple IPsec tunnels.
The spokes have a permanent IPsec tunnel to the hub, but not to the other spokes. The spokes
register as clients of the NHRP server. The spoke learns of all private networks on the other
spokes and the hub through routing updates sent by the hub. A spoke queries the NHRP
database for real addresses of a destination spoke when it needs to communicate to another
destination. The spoke uses the real destination address to build a dynamic IPsec tunnel to the
target spoke. The spoke-to-spoke tunnel is also built over an mGRE interface. After the spoketo-spoke tunnel is built, the IP next-hop for the remote spoke network is the spoke-to-spoke
tunnel interface. After a programmable timeout period, the NHRP entries will age out,
triggering IPsec to break down the dynamic spoke to spoke tunnel.
In the figure, SpokeA uses the real IP address of 172.16.2.1 to bring up a tunnel to SpokeB.
9-44
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
DMVPN Design Recommendations
This section describes the recommended design practices for a DMVPN topology with the hub-andspoke deployment.
DMVPN Design Recommendations
ƒ Use the tunnel protection mode
– Use IPsec in tunnel mode
– Use 3DES or AES
ƒ Use digital certificates/PKI
ƒ Use EIGRP with route summarization for dynamic routing
ƒ Deploy hardware-acceleration of IPsec to minimize router CPU
overhead
ƒ Use a NHRP network ID and password key to prevent unauthorized
nodes from joining the VPN
ƒ Use multiple NHRP servers on multiple hubs for backup
ARCH v2.0—9-54
© 2007 Cisco Systems, Inc. All rights reserved.
Cisco recommends several practices for DMVPN with the hub-and-spoke topology:
„
Use the tunnel protection mode to associate a GRE tunnel with the IPsec profile on the
same router. Tunnel protection specifies that IPsec encryption is performed after the GRE
headers are added to the tunnel packet. Both ends of the tunnel need to be protected.
—
Use IPsec in tunnel mode.
—
Configure Triple DES (3DES) or Advanced Encryption Standard (AES) for
encryption of transported data.
„
Use Digital Certificates or Public Key Infrastructure (PKI) for scalable tunnel
authentication. Typically the certificate authority is located on the private subnet of the
hub.
„
Configure EIGRP with route summarization for dynamic routing.
„
Deploy hardware-acceleration of IPsec to minimize router CPU overhead to support traffic
with low latency and jitter requirements, and for the highest performance for cost.
„
Use a NHRP network ID and password key to prevent unauthorized nodes from joining the
VPN. Provide each mGRE tunnel interface with a unique tunnel key, NHRP network-ID,
and IP subnet address. The mGRE tunnel key configured on the spokes must match the
hub, and it is a recommended practice that the network ID match on both sides of the
tunnel.
„
Use multiple NHRP servers on multiple hubs for backup and redundancy.
© 2007 Cisco Systems, Inc.
IPsec and SSL VPN Design
9-45
VTI Overview
This section discusses IPsec virtual tunnel interfaces (VTIs).
192.168.100.0/30
.1
Tunnel0
.1
.2
192.168.2.0/24
IPsec Static Virtual Tunnel Interfaces
. .
192.168.1.0/24
IPsec Virtual Tunnel Interface Overview
.1
ƒ Provides routable interface type for terminating IPsec tunnels
ƒ Supports QoS, multicast, and other routing functions that previously
required GRE
ƒ Simplifies VPN configuration by eliminating crypto maps, ACLs,
and GRE
ƒ More scalable alternative to GRE
ƒ Offers both static and dynamic VTIs
ƒ Allows VPN interoperability with other vendors
ƒ Available in Cisco Easy VPN
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-56
Another mechanism for supporting VPNs is with IPsec VTI. IPsec VTIs provide a routable
interface type for terminating IPsec tunnels and an easy way to define protection between sites
to form an overlay network. A VTI supports native IPsec tunneling, and allows interface
commands to be applied directly to the IPsec tunnels. The IPsec tunnel endpoint is associated
with a virtual interface. Because there is a routable interface at the tunnel endpoint, many
common interface capabilities can be applied to the IPsec tunnel.
The IPsec VTI supports QoS, multicast, and other routing functions that previously required
GRE. VTIs allow for the flexibility of sending and receiving both IP unicast and multicast
encrypted traffic on any physical interface, such as in the case of multiple paths. Traffic is
encrypted or decrypted when it is forwarded from or to the tunnel interface and is managed by
the IP routing table. Dynamic or static IP routing can be used to route the traffic to the virtual
interface.
VTI simplifies VPN configuration and design. Customers can use the Cisco IOS virtual
template to clone on demand new virtual access interfaces for IPsec. Using IP routing to
forward the traffic to the tunnel interface simplifies the IPsec VPN configuration compared to
the more complex process of using access control lists (ACLs) with the crypto map in native
IPsec configurations. GRE or Layer 2 Tunneling Protocol tunnels are not needed for
encapsulation. DVTIs function like any other real interface so quality of service (QoS),
firewall, and other security services can be applied as soon as the tunnel is active. In addition,
existing management applications now can monitor separate interfaces for different sites.
The use of VTIs improves network scaling. IPsec VTIs use single security associations per site,
which cover different types of traffic and enable improved scaling as compared to GRE. A
major benefit associated with IPsec VTIs is that the configuration does not require a static
mapping of IPsec sessions to a physical interface.
9-46
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Both static VTI (SVTI) and dynamic VTIs (DVTIs) are available. SVTI configurations can be
used for site-to-site connectivity in which a tunnel provides always-on access between two
sites. The advantage of using SVTIs as opposed to crypto map configurations is that users can
enable dynamic routing protocols on the tunnel interface without the extra 4 bytes required for
GRE headers, thus reducing the bandwidth for sending encrypted data. DVTIs can provide
highly secure and scalable connectivity for remote-access VPNs. The DVTI technology
replaces dynamic crypto maps and the dynamic hub-and-spoke method for establishing tunnels.
Dynamic VTIs can be used for both the server and remote configuration.
Note
You can use SDM to configure Easy VPN Server and Easy VPN Remote with IPsec DVTI.
VTIs support interoperability with standard-based IPsec installations of other vendors.
The Cisco Easy VPN for both the Server and Remote configuration support DVTI. The tunnels
provide an on-demand separate virtual access interface for each Easy VPN connection. The
Cisco Easy VPN with DVTI configuration provides a routable interface to selectively send
traffic to different destinations, such as an Easy VPN concentrator, a different site-to-site peer,
or the Internet. IPsec DVTI configuration does not require a static mapping of IPsec sessions to
a physical interface. This allows for the flexibility of sending and receiving encrypted traffic on
any physical interface, such as in the case of multiple paths. Traffic is encrypted when it is
forwarded from or to the tunnel interface.
© 2007 Cisco Systems, Inc.
IPsec and SSL VPN Design
9-47
GET VPN
This topic discusses Group Encrypted Transport VPNs (GET VPNs).
Group Encrypted Transport VPN
ƒ Is a set of software features that secure unicast or multicast group
IP traffic over a private WAN
ƒ Combines the keying protocol Group Domain of Interpretation
(GDOI) with IPsec encryption
ƒ Enables the router to apply encryption to IP multicast and unicast
packets not in a tunnel
ƒ Is supported on Cisco IOS Release 12.4(11)T and on VPN
acceleration modules
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-58
The Cisco IOS Software-based GET VPN set of software features that provides a tunnel-less
technology to provides end-to-end security for voice, video, and data in a native mode for a
fully meshed network. GET VPN can secure IP multicast group traffic or unicast traffic over a
private WAN. It uses the core network's ability to route and replicate the packets between
various sites within the enterprise. Cisco IOS GET VPN preserves the original source and
destination addresses in the encryption header for optimal routing; hence, it is largely suited for
an enterprise running over a private Multiprotocol Label Switching (MPLS)/IP-based core
network.
Cisco IOS GET VPN is enabled in customer edge routers without using tunnels. Cisco IOS
GET VPN uses Group Domain of Interpretation (GDOI) as the keying protocol with IPsec for
efficiently encrypting and decrypting the data packets.
GET VPN enables the router to apply encryption to nontunneled (that is, "native") IP multicast
and unicast packets and eliminates the requirement to configure tunnels to protect multicast and
unicast traffic.
GET VPN is supported on Cisco IOS Release 12.4(11)T and on Cisco VPN acceleration
modules:
9-48
„
Cisco AIM-VPN/SSL Module for Cisco Integrated Services Routers
„
Cisco VPN acceleration Module 2+ for Cisco 7200 series routers and Cisco 7301 series
routers
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
GET VPN Topology
GET VPN uses a group management model where the GDOI protocol operates between a
group member and a group controller or key server.
GET VPN Topology
192.168.0.0/24
.
Key Server
Private
WAN
Group member 2
Group member 1
192.168.2.0 /24
Group member 3
192.168.1.0 /24
192.168.3.0 /24
1. Key and Policy Distribution
2. IPsec Encrypted Packet Exchange
3. Push of Rekey
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-59
The key server establishes security associations (SAs) among authorized group members.
GDOI is protected by a Phase 1 ISAKMP security association.
There are three traffic flows that are necessary for group members to participate in a group:
1. The group member registers with the key server to get the IPsec SA or SAs that are
necessary to communicate with the group. The group member provides the group ID to the
key server to get the respective policy and keys for this group. The key server authenticates
and authorizes the group members and downloads the IPsec policy and keys that are
necessary for them to encrypt and decrypt IP multicast packets. The key server is
responsible to maintain the policy and create and maintain the keys for the group.
2. Group members exchange IP multicast packets that are encrypted using IPsec.
3. Because the key server is also responsible for rekeying the group before existing keys
expire, the key server will pushes a rekey message to the group members. The rekey
message contains new IPsec policy and keys to use when old IPsec SAs expire. Rekey
messages are sent in advance of the SA expiration time to ensure that valid group keys are
always available.
© 2007 Cisco Systems, Inc.
IPsec and SSL VPN Design
9-49
Summary
This topic summarizes the key points discussed in this lesson.
Summary
ƒ Standard IPsec VPNs provide data encryption for IP unicast
packets.
ƒ Easy VPN provides ease of deployment using centralized
management of VPNs for remote offices and teleworkers.
ƒ GRE over IPsec VPNs support IP unicast, multicast and
broadcast packets as well as non IP traffic.
ƒ DMVPN supports spoke-to-spoke IP unicast and multicast traffic
in meshed networks efficiently with dynamic configuration
combining IPsec, GRE, and NHRP.
ƒ VTIs provide a routable interface type for terminating IPsec
tunnels and supporting QoS, multicast, and routing functions
without using GRE.
ƒ GET VPNs provide a tunnel-less technology for end-to-end
security of IP unicast and multicast traffic using IPsec.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-60
Easy VPNs provide simple, unified configuration framework for mix of Cisco VPN products.
Easy VPN should be used when simplifying overall VPN configuration and management is the
primary goal, but only limited networking features are required.
GRE over IPsec can be used when routing needs be supported across the VPN. GRE over IPsec
is typically used for the same functions as hub-and-spoke DMVPN, but requires more detailed
configuration
DMVPNs simplifies configuration for hub-and-spoke VPNs while supporting routing, QoS,
and multicast. DMVPNs provides low-scale, on-demand meshing.
VTIs provide easy way to define protection using native IPsec tunneling between sites to form
an overlay network. The IPsec VTI solutions supports QoS, multicast, and other routing
functions that previously required GRE. VTI simplifies VPN configuration and design.
GET VPN adds encryption to MPLS or IP WANs while preserving any-to-any connectivity and
networking features. GET VPN offers scalable, full-time meshing for IPsec VPNs. It enables
participation of smaller routers in meshed networks, and simplifies encryption key management
while supporting routing, QoS, and multicast.
9-50
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Lesson 4
VPN Management and Scaling
Overview
The Cisco Security Management products and internal processes can be used for scalable VPN
administration and enforcement. Scaling VPNs involves several considerations including
crypto engine performance for real traffic and routing characteristics and metrics. This lesson
will look at both VPN management and scaling considerations.
Objectives
Upon completing this lesson, you will be able to discuss options for managing and scaling
VPNs. This ability includes being able to meet these objectives:
„
Discuss recommendations for managing VPNs
„
Discuss considerations for scaling VPNs
Recommendations for Managing VPNs
This topic discusses some tools and recommendations for managing VPNs.
Cisco Security Management Suite for VPNs
This section discusses some tools for managing VPNs.
Cisco Security Management Suite for
VPNs
Element management on the device:
ƒ Cisco Router and Security Device Manager
ƒ Cisco Adaptive Security Device Manager
ƒ Cisco PIX Device Manager
ƒ CiscoView Device Manager
Multiple device managers:
ƒ Cisco Security Manager
ƒ Cisco Security Monitoring, Analysis, and Response System
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-64
The Cisco Security Management Suite is a framework of products and technologies designed
for scalable policy administration and enforcement for the Cisco Self-Defending Network. This
integrated solution can simplify and automate the tasks associated with security management
operations, including configuration, monitoring, analysis, and response. There are several
components of this suite for managing VPNs:
9-52
„
Cisco Router and Security Device Manager (SDM): Cisco SDM is a web-based devicemanagement tool for Cisco routers that can improve the productivity of network managers;
simplify router deployments for integrated services such as dynamic routing, WAN access,
wireless LAN (WLAN), firewall, VPN, SSL VPN, IPS, and quality of service (QoS); and
help troubleshoot complex network and VPN connectivity issues. Cisco SDM is a single
device element manager that can support a wide range of Cisco IOS Software releases and
is available free of charge on Cisco router models from Cisco 830 Series Routers to Cisco
7301 Routers.
„
Cisco Adaptive Security Device Manager (ASDM): Cisco ASDM provides security
management and monitoring services for the Cisco ASA 5500 Series Adaptive Security
Appliances, Cisco PIX 500 Series Security Appliances (running Cisco PIX Security
Appliance Software Release 7.0 or later) and the Cisco Catalyst 6500 Series Firewall
Services Modules (FWSM version 3.1 or later) through an intuitive, easy-to-use web-based
management interface. Cisco ASDM is an element manager that accelerates security
appliance deployment with intelligent wizards, robust administration tools, and versatile
monitoring services.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
„
Cisco PIX Device Manager (PDM): Cisco PDM security management and monitoring
services for Cisco PIX security appliances (running Cisco PIX Security Appliance
Software Version 6.3 and prior) and the Cisco Catalyst® 6500 Series Firewall Services
Module (FWSM). PDM is an element manager that features an intuitive GUI with
integrated online help and intelligent wizards to simplify setup and ongoing management.
In addition, informative, real-time, and historical reports provide critical insight into usage
trends, performance baselines, and security events. Administrative and device security is
supported through the use of user passwords (with optional authentication via a RADIUS
or TACACS server) and encrypted communications to local or remote devices.
„
CiscoView Device Manager (CVDM). The CVDM for the Cisco® Catalyst® 6500 Series
Switch is a device-management software application that resides on a switch and manages
several Layer 2 and Layer 3 features for a single chassis. A task-based tool, CiscoView
Device Manager eases the initial setup and deployment of end-to-end services across
modules by offering configuration templates based on recommended best practices. It
further enhances the user-friendliness of the Cisco Catalyst 6500 Series through graphical
representation of VLANs, and by providing a single launch point for multiple module
managers including the VPN service module, the SSL service module, and the WebVPN
service module.
„
Cisco Security Manager: Cisco Security Manager is a powerful but easy-to-use solution
for configuring firewall, VPN, and IPS policies on multiple Cisco security appliances,
firewalls, routers, and switch modules. Using a GUI, Cisco Security Manager allows
security policies easily to be configured per device, per device group, or globally.
„
Cisco Security Monitoring, Analysis, and Response System (Cisco Security MARS):
Cisco Security MARS is an appliance-based solution that allows network and security
administrators to monitor, identify, isolate, and counter security threats. Cisco Security
MARS obtains network intelligence by understanding the topology and device
configurations from multiple routers, switches, NetFlow, IPS, firewalls, and other network
devices and by profiling network traffic. The integrated network discovery in the system
builds a topology map containing device configuration and current security policies that
enables Cisco Security MARS to model packet flows through the network. Because the
appliance does not operate in-line and makes minimal use of existing software agents, there
is minimal impact on network or system performance.
© 2007 Cisco Systems, Inc.
IPsec and SSL VPN Design
9-53
Recommendations for Managing VPNs
This section discusses some recommendations for managing VPNs.
Recommendations for Managing VPNs
ƒ Use dedicated management interfaces if possible
ƒ Take precautions when managing a VPN device across the Internet
ƒ Use static address and crypto maps to manage remote devices via a
VPN tunnel
ƒ Use available IPsec information
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-65
There are several recommended practices for managing VPNs:
9-54
„
Use dedicated management interfaces if possible for out-of-band management. If this is not
possible, use a VPN for secure management and restrict access over the tunnel to
management protocols only.
„
Take precautions when managing a VPN device across the Internet. You should use strong
authentication, integrity and encryption practices. You should use a different username for
configuration management and for troubleshooting. If you cannot use IPsec to connect to
remote devices, use SSH/SSL for access.
„
Use static public IP addresses at remote sites and static crypto maps at the head-end in
order to manage remote devices through a VPN tunnel. You need to be aware that some
services such as TFTP do not always use the public IP address as the source address.
„
Use the available IPsec information. IPsec information can be accessed minimally through
syslog information or with the IPsec MIB via SNMP.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Considerations for Scaling VPNs
This topic discusses considerations for scaling VPNs.
Packets Per Second vs. Megabits Per Second
Crypto Performance in Megabits per Second
Traffic Profile:
All 1400 Byte Packets @ 100% CPU
Marketing
IMIX 7:4:1 @ 100% CPU
IMIX
Converged
150M
40M
20M
Converged Traffic @ 80% CPU
ƒ Marketing literature states crypto performance in megabits per
second at 100% CPU with all MTU-sized (~1400 byte) packets
ƒ Actual performance with IMIX or converged traffic is significantly
different
ƒ Crypto performance in pps is the key for sizing the head-end
– Not bps
– Not tunnels
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-67
Scaling VPNs depends on many factors, but the primary issue is offered load, in number of
packets per second (pps), from the branch routers. The pps rate matters more than throughput
bandwidth (bps) for the connection speeds being terminated or aggregated. In general, routers
and crypto engines have upper boundaries for processing a given number of pps. Each time a
crypto engine encrypts or decrypts a packet, it performs mathematical computations on the IP
packet payload using the crypto key for the tunnel. The crypto engine performance measured in
packets per second is the key for sizing the head-end.
Marketing numbers state crypto performance in megabits per second at 100% CPU with all
MTU-sized (~1400 byte) packets to achieve the best results. This is an unrealistic traffic
pattern. Internet mix traffic (IMIX) contains a mixture of frame sizes in a ratio to each other
that approximates the overall makeup of frame sizes observed in real Internet traffic. Using
IMIX traffic provides a better simulation of real network traffic. Converged traffic with a mix
of 30 percent voice traffic at a maximum of 80 percent CPU utilization is the most realistic
simulation of real network traffic for enterprise networks. The figure compares the relative
performance of three types of traffic an a router.
The pps is also a more critical metric than the number of tunnels, although the number of
tunnels impacts the routing processes on the CPU. The number of tunnels also impacts crypto
processing, If more than one IPsec tunnel is terminated on a router, the router has multiple
crypto keys. When packets are to be sent or received to a different tunnel than the last packet
sent or received, the crypto engine must swap keys. This key swapping can degrade the
performance of a crypto engine, depending on its architecture, and increase the router CPU
utilization.
© 2007 Cisco Systems, Inc.
IPsec and SSL VPN Design
9-55
Determining PPS
This section discusses considerations for estimating packets per second for remote branch
enterprise traffic.
Determining PPS
ƒ Are determined by user applications on the network
– High Mbps throughput equates to large bytes per packet
– VoIP decreases the average packet size and increases the
number of PPS.
ƒ Test tools should emulate real application behavior
– Packet blasting tools are poor indicators of real-world
performance
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-68
The pps per connection are determined by user applications on the network. Highs Mbps
throughput in the network typically corresponds to large byte size per packet. The presence of
voice over IP (VoIP) in network decreases the average packet size and increases the number of
PPS.
To correctly simulate network behavior, test tools must emulate real application behavior.
Testing using packet blasting tools are poor indicators of real-world performance.
9-56
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Enterprise WAN Categories
Characterizing enterprise WANs into categories helps estimate the type of traffic to expect
from the remote branches when scaling the VPN.
Enterprise WAN Categories
Point of Sale
Number of
Branches
VoIP Support?
Teleworker/
Teleagent
Integrated
Services Branch
Extra Large
Large
Medium
1,000–10,000
1,000–3,000
Yes, Usually
One Call
500–1,000
Yes, 33%
Bandwidth
No
IP Multicast?
Generally Not
Nice to Have
Yes
Availability?
Required—Async
Dial-Backup
Too costly—Dial
Bandwidth
Insufficient for VoIP
Multiple WAN
Links
Physical Interface
Broadband/POTS
Broadband
Leased Line
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-69
Enterprise WANs can be categorized into three groups:
„
Point of sale WANs. These WANs typically support a high number of retail branches for
credit card and point of sale applications. The number of branches here may be 2,000 or
more. They have low data volume, and do not support VoIP or IP multicast. The WANs
need availability that the routing protocol provides. The physical interface for the remote
sites is typically broadband or dial up plain old telephony service (POTS).
„
Teleworker / Teleagent WANs. These WANs typically support a single user with IP
phone at the remote end. In the Cisco Enterprise Architecture, this is the “Branch of One”
or Teleworker design. There can be large numbers of remote sites to support. Support for
IP multicast is nice to have, but may not be present. Backup availability is typically not
provided, since dial backup bandwidth is insufficient for the VoIP application. The remote
sites typically connect using broadband.
„
Integrated Services Branch WAN. These WANs typically connect remote enterprise
branches to the central site and have high or bursty data volume and relatively high number
of branches from 500 to 1,000. They are likely to support converged applications including
voice and video and IP multicast. VoIP traffic is typically 30% of the bandwidth. Backup
availability is provided with multiple WAN links. The physical interface is typically a
leased line or high speed DSL.
© 2007 Cisco Systems, Inc.
IPsec and SSL VPN Design
9-57
Traffic Profiles Per Branch Router
This section discusses the traffic profile per branch router.
Traffic Profiles Per Branch Router
Point of Sale
TCP
18 HTTP Get
300 Bytes up,
1,000 Bytes down
2 FTP (1 up, 1 down
120K File Size)
Teleworker/
Teleagent
UDP
1 G.729 Voice Call
(100 PPS)
1 DNS
TCP
1 POP3
1 Call Setup (CS3)
1 TN3270 (Best Effort)
1 TN3270 (AF21)
1 HTTP (Best Effort)
1 HTTP (AF21)
1 FTP (1 up 240K File)
Integrated Services
Branch
“Enterprise Mix”
V3PN
UDP
33% BW for G.729 VoIP
(100 pps per call)
9 calls per T1
9 DNS
TCP
4 POP3
6 TN3270 (Best Effort)
6 TN3270 (AF21)
3 HTTP (Best Effort)
3 HTTP (AF21)
4 FTP (2 up, 2 down
768K File)
While Traffic Profiles May Vary—Head-End Scalability Is
Governed by Packets per Second
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-70
The major factor in head-end VPN scaling is the pps load of the hub for switching packets.
Packet switching is impacted by the size of the packets. Based on field testing, the Cisco
Enterprise Systems Engineering group has developed some traffic profiles for representing real
enterprise branch routers in the lab. The average packet size is influenced by the applications in
use in the traffic profile:
„
Does traffic mix include VoIP, video, or IP multicast? What VoIP codec is in use (G.711 at
4kbps versus G.729 at 8 kbps)?
„
Do the workstations have interface Maximum Transmission Unit (MTU) changed? Do
workstations use path MTU discovery? Is the router configured to adjust TCP Maximum
Segment Size (MSS)?
„
What applications are in use? Is application optimization such as HTTP pipelining in
place?
Scaling considerations at the head-end are also impacted by number of neighbors per hub
which impacts path selection overhead.
9-58
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Example: Enterprise Mix Packet Size
Percent of Bytes with Average Packet Size
(Excludes GRE and IPsec Headers/Trailers)
Downstream
Upstream
889 (TN3270)
.9%
45 (FTP Get)
1.9%
89 (TN3270)
.2%
1016 (TN3270-2
Immed)
.9%
1052 (FTP Get)
53.5%
89 (TN3270-2
Immed)
.2%
1044 (FTP Put)
57.6%
60 (VoIP)
22.2%
124 (DNS)
2.1%
44 (FTP Put)
1.0%
462 (POP3)
3.4%
131 (DNS)
2.8%
176 (WWW)
5.9%
377 (WWW-2 Immed)
10.2%
Average Packet Size = 188
60 (VoIP)
27.4%
72 (WWW)
4.2%
45 (POP3)
.3%
109 (WWW-2 Immed)
5.3%
Average Packet Size = 144
NetFlow™ Protocol-Port-ToS Aggregation Exported and Summarized
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-71
Example: Enterprise Mix Packet Size
The figure shows the average packet sizes for representative downstream and upstream traffic
captured with NetFlow. The key point to notice is that the average packet size with VoIP traffic
in the mix is significantly smaller than the 1400 byte packets used to describe marketing
performance.
© 2007 Cisco Systems, Inc.
IPsec and SSL VPN Design
9-59
Estimated PPS Based on Branch Profile
To accurately size the head-end device, you need to measure the average / busy hour pps rate of
the branch routers.
Estimated PPS Based on Branch Profile
Teleworker /
Teleagent
Point of Sale
ip tcp adjust-mss 542
data only - no VoIP
Integrated Services
Branch
Enterprise Mix
V3PN
TCP max segment size 1360
PPS
(both directions)
2,303 pps
2000
9 – VoIP
1 – VoIP G.729
361 Bytes/packet
1000
1 – VoIP
G.711
< 50 pps
144K / 144K
ISDN Digital
Subscriber
Line (IDSL)
1 – VoIP
637 Bytes/packet
795 pps
495 pps
125 pps
256K/1.4M
Broadband
DSL
Internet
18 – VoIP G.729
267 Bytes /pak
384K/1.5M
Broadband
Cable Lab
© 2007 Cisco Systems, Inc. All rights reserved.
768K/3.0M
Broadband
Cable
Internet
900 pps
for VoIP
1800 pps
for VoIP
1.5M/1.5M (T1) 3.0M / 3.0M
Leased Line
Fractional DS3
Lab
ARCH v2.0—9-72
The Enterprise Systems Engineering has some rough pps estimates can be starting point for
VPN scaling:
9-60
„
A point of sale branch on a low speed link that supports only data may only have an
average of 50 pps of traffic.
„
A teleworker on a higher speed link will have higher traffic requirements. The teleworker
may generate 125 pps to 800 pps depending on the link speed and network configuration.
„
The integrated services branch may need to support multiple voice calls. If we use the rule
of thumb that 30 percent of the bandwidth is used for voice, then a T1 line could support 9
voice calls of 100 pps or 50 pps in both directions. The head-end would need to support
900 pps for VoIP traffic plus the data requirements of the remote site.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Determining the PPS Rate
If you are migrating an existing network, you can measure the average / busy hour pps rate of
the existing branch routers.
Determining the PPS Rate
ƒ For migration an existing network, measure the average / busy
hour pps rate of the branch routers
– Knowing 500 branches and a 45Mbps link at the head-end is
not enough
ƒ Can use commands
show interfaces fastEthernet 4 | include rate
ƒ Can use GUI tools with SNMP or Netflow
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-73
Measuring rates at the remote branches at the busy hour will provide useful data. Most network
managers when simply asked will not have any details and may reply “I have 500 branches and
a 45Mbps link at the head-end”.
The measurement can be as simple as using the show interfaces fastEthernet 4 | include rate
command. You can also use network management tools querying SNMP or NetFlow data.
© 2007 Cisco Systems, Inc.
IPsec and SSL VPN Design
9-61
Example: Packet and Application View
Netflow Data Export
Top Ap plicatio n IN – vpn- 871
Application View - Teleworker
Web surfing
HTTP and
other TCP
applications
Conference Call
VoIP G.711
Backup
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-74
Example: Packet and Application View NetFlow Data Export
This example shows a view of the packets per hour and types of packets for a teleworker that
supported a conference call, web based data backup, and some web surfing during the day.
9-62
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Routing Protocol Considerations for IPsec VPNs
This section discusses some routing protocol considerations for scaling VPNs.
Routing Protocol Considerations for
IPsec VPNs
ƒ Either EIGRP or OSPF can be used with non-basic IPsec VPNs
ƒ The distance vector characteristics of EIGRP are better for huband-spoke IPsec VPNs:
– EIGRP can summarize per interface.
– EIGRP is “quiet” and does not need to flood topology
database.
– EIGRP stub eliminates queries to spokes.
ƒ Some disadvantages to the link state characteristics of OSPF for
hub-and-spoke IPsec VPNs:
– OSPF needs to synchronize router databases periodically.
– OSPF brings hierarchy decisions into the hub-and-spoke
topology.
ƒ Increasing the number of neighbors increases process switching.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-76
Both Enhanced Interior Gateway Routing Protocol (EIGRP) and Open Shortest Path First
(OSPF) are appropriate enterprise routing protocols that can be supported on IPsec with GRE
tunnels, DMVPNs, VTI, and GET VPNs.
The distance vector characteristics of EIGRP are typically better for the hub-and-spoke VPN
topology:
„
EIGRP can summarize per interface. By summarizing to the core, and summarizing to the
spoke, the branch routers will have less routes in the routing table.
„
EIGRP is a “quiet” protocol when configured with stubs. There is no need to flood
topology database with EIGRP.
„
EIGRP stub eliminates queries to spokes. As a recommended practice, configure the branch
routers as stubs. The stub routers receive the default route from the head-end router, and
advertise back up the branch subnets.
There are some disadvantages to the link state characteristics of OSPF for hub-and-spoke IPsec
VPNs:
„
OSPF needs to synchronize router databases periodically.
„
OSPF brings hierarchy decisions into the hub-and-spoke topology. The number of routers
per area needs to be allocated. A recommended practice is to use a power of two for best
summarization.
With either protocol, increasing the number of neighbors increases the amount of process
switching the hub routers need to support. Buffer tuning can help maintain network stability by
minimizing the number of buffer misses and failures that may equate to losing or dropping
neighbors.
© 2007 Cisco Systems, Inc.
IPsec and SSL VPN Design
9-63
EIGRP Metric Component Consideration
The EIGRP metric components can have an impact on IPsec VPNs.
EIGRP Metric Considerations
Delay
ƒ EIGRP calculates delay as the cumulative network delay.
ƒ Delay is based on the input interface value of the receiving
router.
Bandwidth
ƒ EIGRP uses the minimum bandwidth for all the links.
ƒ Default bandwidth value for tunnel is 9000.
ƒ EIGRP updates throttled to 50% of bandwidth of the interface.
– Consider matching tunnel bandwidth to physical link value.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-77
EIGRP calculates delay as the cumulative network delay. It adds the delay from all the hops to
the source network. EIGRP delay is based on the input interface value of the receiving router.
EIGRP uses the minimum bandwidth for all the links to a network. The default bandwidth
value for tunnel is 9K. EIGRP updates are throttled to 50% of bandwidth of the interface. You
should consider matching tunnel bandwidth to physical link value if you send more than the
default route and a summary route across a link, because the EIGRP process can be throttled by
the 9K default bandwidth of the tunnel.
9-64
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Summary
This topic summarizes the key points discussed in this lesson.
Summary
ƒ VPNs can be managed with either on the devices element
managers or multiple device managers from the Cisco Security
Management Suite. Dedicated management interfaces and
precautions are recommended to protect VPN devices.
ƒ Scaling VPNs depends on many factors, but the primary issue is
the number of pps that need to be processed by the crypto
engine. Using enterprise WAN categories helps to estimate traffic
from remote branches.
© 2007 Cisco Systems, Inc. All rights reserved.
© 2007 Cisco Systems, Inc.
ARCH v2.0—9-78
IPsec and SSL VPN Design
9-65
9-66
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Module Summary
This topic summarizes the key points discussed in this module.
Summary
ƒ Remote access VPNs permit secure, encrypted connections
between mobile or remote users and their corporate networks
using IPsec and SSL technologies.
ƒ Site-to-site VPNs are an alternative WAN infrastructure used to
connect branch offices, home offices, or business partners to all
or portions of an enterprise network using service provider
networks.
ƒ There are several types of technologies that can support IPsec
VPNs including Easy VPN, GRE over IPsec, DMVPN, VTI, and
GET VPN.
ƒ Both products and internal processes are needed for managing
VPNs. Scaling VPNs involves several considerations including
crypto engine performance for real traffic and routing
characteristics.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—9-80
This module examined how to design enterprise solutions for remote access and site-to-site
VPNs. VPNs enable secure use of cost-effective, high-speed links. VPNs encrypt and
authenticate traffic traversing the WAN to deliver true network security in an insecure,
networked world.
References
For additional information, refer to these resources:
„
Cisco Systems, Inc. “SEC-2010: Deploying Remote-Access IP Security and SSL VPNs”
Networkers 2006 presentation (accessible on a subscription basis) at
http://www.networkersonline.net.
„
Cisco Systems, Inc. “SEC-2011: Deploying Site-to-Site IPSec VPNs” Networkers 2006
presentation (accessible on a subscription basis) at
http://www.networkersonline.net.
„
Cisco Systems, Inc. “SEC-2012: Deploying Dynamic Multipoint VPNs” Networkers 2006
presentation (accessible on a subscription basis) at
http://www.networkersonline.net.
„
Cisco Systems, Inc. “RST-2266: Large-Scale IPsec Aggregation Networks” Networkers
2006 presentation (accessible on a subscription basis) at
http://www.networkersonline.net.
„
Cisco Systems, Inc. Cisco Easy VPN at
http://www.cisco.com/warp/public/cc/so/neso/vpn/ns171/ns27/prodlit/evpnc_qa.pdf
© 2007, Cisco Systems, Inc.
IPsec and SSL VPN Design
9-67
„
Cisco Systems, Inc. IPsec VPN WAN Design Overview at
http://www.cisco.com/application/pdf/en/us/guest/netsol/ns171/c649/ccmigration_09186a0
08074f22f.pdf
„
Cisco Systems, Inc. “Dynamic Multipoint VPN (DMVPN) Introduction” at
http://www.cisco.com/en/US/products/ps6658/products_ios_protocol_option_home.html
„
Cisco Systems, Inc. IPSec Virtual Tunnel Interface at
http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/hsec_c/part17/ch
10/hipsctm.pdf
„
Cisco Systems, Inc. Virtual Tunnel Interface (VTI) Design Guide at
http://www.cisco.com/application/pdf/en/us/guest/netsol/ns171/c649/ccmigration_09186a008073a02
b.pdf
9-68
„
Cisco Systems, Inc. Cisco Group Encrypted Transport VPN at
http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124newft/124t/124t11/ht
getvpn.pdf
„
Cisco Systems, Inc. Cisco IPsec and SSL VPN Solutions Portfolio at
http://www.cisco.com/application/pdf/en/us/guest/products/ps7180/c1031/ccmigration_091
86a00801f0a72.pdf
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Module Self-Check
Use the questions here to review what you learned in this module. The correct answers and
solutions are found in the Module Self-Check Answer Key.
Q1)
In what two ways does the Cisco Easy VPN Server support remote access VPNS?
(Chose two.) (Source: Remote Access VPNs)
A)
B)
C)
D)
E)
Q2)
What is the recommended practice deploying the VPN termination device for best
security? (Source: Remote Access VPNs)
A)
B)
C)
D)
E)
Q3)
to terminate any IPsec tunnels on inline firewall
to place the VPN termination device in line with a firewall
to place the VPN termination device in parallel with a firewall
to place the private side of the VPN termination device in a DMZ behind a
firewall
to place the public side of the VPN termination device in a DMZ behind a
firewall
When might RRI be needed in remote access VPNs? (Source: Remote Access VPNs)
A)
B)
C)
D)
E)
Q4)
by accepting a variety of information from the client including IP address and
mask and information on the internal DNS and WINS server
by sending a variety of information to the client including IP address and mask
and information on the internal DNS and WINS server
by terminating IPsec VPN tunnels initiated by remote workers running the
Cisco VPN Client software on PCs
by terminating SSL VPN tunnels initiated by remote workers running the Cisco
VPN Client software on PCs
by terminating SSL VPN tunnels initiated by remote workers running the Cisco
SSL VPN Client for WebVPN software on PCs
when IPsec tunnels are terminated on inline firewall
when a dedicated scope of DHCP addresses is associated to a specific VPN
head-end
when internal routers use a static route for address blocks pointing to the
private interface of the head-end device
when VPN software clients need to inject their assigned IP address as hosts
routes into the routing table of OSPF and RIPv2
when VPN software clients need to inject their assigned IP address as hosts
routes into the routing table of OSPF and EIGRP
What is the most common address assignment design for remote access VPNs?
(Source: Remote Access VPNs)
A)
B)
C)
D)
E)
© 2007, Cisco Systems, Inc.
using a dedicated scope of DHCP addresses associated to a specific VPN
head-end
using internal address pools per VPN head-end and implementing a static route
for these subnets to the VPN head-end
using RRI when IPsec tunnels are terminated on inline firewall
using static IP address assignment for end users with LDAP and RRI
using static IP address assignment for end users with RADIUS and RRI
IPsec and SSL VPN Design
9-69
Q5)
What are the three access mechanisms for SSL VPNs? (Chose three.) (Source: Remote
Access VPNs)
A)
B)
C)
D)
E)
F)
Q6)
What are two site-to-site VPN applications? (Chose two.) (Source: Site-to-Site VPN
Design)
A)
B)
C)
D)
E)
Q7)
E)
basic IPsec tunnels transporting IP unicast and multicast traffic
full mesh topology with direct connectivity between all locations
partial mesh topology with direct connectivity between many locations
remote peers connected over a shared infrastructure in a spoke-to-spoke
topology
remote peers connected to the central site over a shared infrastructure in a
hub-and-spoke topology
What are two advantages to placing the VPN device in the DMZ of a firewall? (Chose
two.) (Source: Site-to-Site VPN Design)
A)
B)
C)
D)
E)
9-70
Basic IPsec tunnels can transport IP unicast and multicast traffic.
IPsec VPNs are typically implemented in tunnel mode.
IPsec VPNs are typically implemented in transport mode.
VPN devices need a routable outside IP addresses.
VPN devices need a routable inside IP addresses.
What is the typical IPsec deployment design? (Source: Site-to-Site VPN Design)
A)
B)
C)
D)
Q9)
WAN replacement
content rewriting
port forwarding
data privacy through 3DES or AES
mandated or regulatory encryption
What are two addressing considerations in IPsec design? (Chose two.) (Source: Site-toSite VPN Design)
A)
B)
C)
D)
E)
Q8)
content rewriting with a thin client
content rewriting with clientless access
dynamic VPN support with a thick client
dynamic VPN support with a thin client
port forwarding with a thin client
port forwarding with thick client
The design allows moderate-to-high scalability by adding additional VPN
devices.
The design allows firewall to impose bandwidth restrictions on stacks of VPN
devices.
The design supports the layered security model and enforces firewall security
policies.
The design supports remote peers connecting over a shared infrastructure in a
spoke-to-spoke topology
The design supports firewalls that do not need to support policy routing to
differentiate VPN versus non-VPN traffic.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Q10)
What are two characteristics of the Cisco Easy VPN Solution? (Chose two.) (Source:
IPsec VPN Technologies)
A)
B)
C)
D)
E)
Q11)
What are two reasons for implementing GRE tunnels? (Chose two.) (Source: IPsec
VPN Technologies)
A)
B)
C)
D)
E)
Q12)
supports IP broadcast and multicast traffic
provides deterministic mesh with fewer active tunnels on each spoke
provides dynamic mesh with fewer active tunnels on each spoke
creates hub-and-spoke tunnels dynamically based on traffic requirements
creates spoke-to-spoke tunnels dynamically based on traffic requirements
What are two characteristics of the VTI? (Chose two.) (Source: IPsec VPN
Technologies)
A)
B)
C)
D)
E)
Q14)
to support IP broadcast and multicast traffic
to support IP unicast traffic
to support IPsec encryption
to support routing protocols
to avoid asymmetric routing when routing is running over the tunnels
What are two advantages to implementing DMVPN tunnels? (Chose two.) (Source:
IPsec VPN Technologies)
A)
B)
C)
D)
E)
Q13)
uses the GDOI protocol
mesh design scalability for greater than 10 sites
reduced management complexity for VPN deployments
uses Easy VPN Remote and Easy VPN Services features
centralized VPN management across all Cisco VPN devices
uses tunnel mode protection
provides a routable interface type for terminating IPsec tunnels
is a set of software features that provides a tunnel-less technology to provides
end-to-end security
supports QoS, multicast, and other routing functions that previously required
GRE
uses a NHRP network ID and password key to prevent unauthorized nodes
from joining the VPN
What are two characteristics of the GET VPN? (Chose two.) (Source: IPsec VPN
Technologies)
A)
B)
C)
D)
E)
© 2007, Cisco Systems, Inc.
is a set of software features that provides a tunnel-less technology to provides
end-to-end security
provides a routable interface type for terminating IPsec tunnels
secures IP multicast group traffic or unicast traffic over a private WAN
supports interoperability with standard-based IPsec installations of other
vendors
uses a NHRP network ID and password key to prevent unauthorized nodes
from joining the VPN
IPsec and SSL VPN Design
9-71
Q15)
What are two element managers for VPNs? (Chose two.) (Source: VPN Management
and Scaling)
A)
B)
C)
D)
E)
Q16)
What are three recommendations for managing VPNs? (Chose three.) (Source: VPN
Management and Scaling)
A)
B)
C)
D)
E)
F)
Q17)
data center WAN
e-commerce WAN
integrated services branch WAN
point of sale WAN
teleworker WAN
Which routing protocol is recommended for large scale enterprise IPsec VPNs?
(Source: VPN Management and Scaling)
A)
B)
C)
D)
E)
9-72
crypto engine performance for large packets
Mbps capacity of head-end router
number of routes in network
number of tunnels terminated at head-end router
pps from remote routers
What enterprise WAN category typically has 30% VoIP traffic bandwidth? (Source:
VPN Management and Scaling)
A)
B)
C)
D)
E)
Q20)
pps from remote routers
number of routes in network
Mbps capacity of head-end router
crypto engine performance for large packets
number of tunnels terminated at head-end router
What is the primary issue in scaling VPNs? (Source: VPN Management and Scaling)
A)
B)
C)
D)
E)
Q19)
use in-band management if possible
use dedicated management interfaces if possible
use the same username for configuration management and for troubleshooting
use a different username for configuration management and for troubleshooting
use IPsec for access to VPN devices across the Internet instead of SSH/SSL
use SSH/SSL for access to VPN devices across the Internet instead of IPsec
What are three biggest factors to consider in scaling VPNs? (Chose three.) (Source:
VPN Management and Scaling)
A)
B)
C)
D)
E)
Q18)
Cisco ASDM
Cisco PSDM
Cisco SDM
Cisco Security Manager
Cisco Security SDM
BGP
EIGRP
OSPF
RIPv2
static routing
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
© 2007, Cisco Systems, Inc.
IPsec and SSL VPN Design
9-73
Module Self-Check Answer Key
9-74
Q1)
B, C
Q2)
E
Q3)
D
Q4)
B
Q5)
B, C, E
Q6)
A, E
Q7)
B, D
Q8)
E
Q9)
A, C
Q10)
C, E
Q11)
A, D
Q12)
C, E
Q13)
B, D
Q14)
A, C
Q15)
A, C
Q16)
B, D, E
Q17)
A, C, E
Q18)
E
Q19)
C
Q20)
B
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Module 10
IP Multicast Design
Overview
IP multicast provides bandwidth conservation that reduces traffic load by simultaneously
delivering a single stream of information to multiple recipients. Multicasting enables a more
efficient distribution of video conferencing, corporate communications, distance learning,
distribution of software, and other applications. This module reviews IP multicast technology
discussed in the Cisco Building Scalable Cisco Internetworks course. It then provides some
design recommendations for implementing IP multicast. It also discusses some security
consideration for IP multicast designs.
Module Objectives
Upon completing this module, you will be able to design IP multicast intelligent network
services for performance, scalability, and availability, given specified enterprise network needs.
This ability includes being able to meet these objectives:
„
Provide an overview of IP multicast technology
„
Describe design recommendations for IP multicast
„
Discuss security considerations for IP multicast
10-2
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Lesson 1
IP Multicast Review
Overview
Traditional IP communication allows a host to send packets to a single host (unicast
transmission) or to all hosts (broadcast transmission). IP multicast provides a third possibility:
allowing a host to send packets to a subset of all hosts as a group transmission. This lesson
provides an overview of IP multicast.
Objectives
Upon completing this lesson, you will be able to identify the IP multicast implementation
options. This ability includes being able to meet these objectives:
„
Provide an overview of IP multicast technology
„
Explain the purpose and use of IP multicast group membership
„
Discuss Layer 3 multicast routing
„
Discuss multicast forwarding at Layer 2 and control mechanisms
Overview of IP Multicast
This topic provides an overview of IP multicast.
Unicast vs. Multicast
Unicast and multicast technologies use different means to transfer packets from a source to
multiple destinations.
Unicast vs. Multicast
Unicast
Server
Multicast
Server
© 2006 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—10-3
With a unicast design, an application sends one copy of each unicast packet to every client
unicast address. Unicast transmission can require a large amount of bandwidth, as the same
information has to be carried multiple times even on shared links. A large number of clients can
impact the scalability of the network. Intermediate devices in the network path need to replicate
the required number of packets.
IP multicast, as an alternative to unicast and broadcast, sends packets to a subset of network
hosts simultaneously. By requiring only a single copy of each packet to be sent on each
interface, multicast helps reduce network traffic. Multicast packets are replicated in the network
at the point where paths diverge by Cisco routers enabled with Protocol Independent Multicast
(PIM), resulting in the most efficient delivery of data to multiple receivers.
Even low-bandwidth applications can benefit from using IP multicast when there are thousands
of concurrent receivers. High-bandwidth applications, such as MPEG video, may require a
large portion of the available network bandwidth for a single stream. In these applications, IP
multicast is the only practical way to send to more than one receiver simultaneously. IP
multicast provides a reduced load on server, a reduced load on network links, and scales to any
number of receivers.
10-4
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
TCP Contrasted to UDP
IP multicast uses User Datagram Protocol (UDP) for transport.
TCP Contrasted to UDP
TCP - Unicast
ƒ TCP is connection orientated protocol
ƒ Requires 3 way Handshake
ƒ Reliable due to sequence numbers + Ack
ƒ Flow control
UDP - Unicast and Multicast
ƒ Connectionless
ƒ Unreliable
– Can not support some application layer protocols such as ARP
or HSRP
© 2006 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—10-4
Transmission Control Protocol (TCP) supports only unicast transmissions. TCP is a connection
oriented protocol that requires a three way handshake to establish communications. TCP
enforces end-to-end reliability of packet delivery with sequence numbers and
acknowledgements. TCP supports flow control.
In contrast, UDP can support both unicast and multicast transmissions. UDP is a connectionless
protocol that does not use a handshake to establish communication. The UDP transport protocol
has no reliability mechanisms, so reliability issues have to be addressed in multicast
applications where reliable data transfer is necessary. UDP can not support protocols such as
ARP and HSRP.
© 2007 Cisco Systems, Inc.
IP Multicast Design
10-5
Multicast Disadvantages
ƒ Best-effort delivery results in occasional packet drops.
– Can make voice content unintelligible.
– Can cause artifacts and degradation in video.
ƒ Lack of congestion control may result in network congestion.
ƒ Duplicate packets may occasionally be generated.
ƒ Out-of-sequence delivery of packets to the application may
happen.
ƒ Multicast security is still evolving.
© 2006 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—10-5
There are some disadvantages to using IP multicast. Most multicast applications are UDPbased. This foundation results in some undesirable consequences compared to similar unicast
TCP applications.
„
Best-effort delivery results in occasional packet drops. Requesting retransmission of the
lost data at the application layer for multicast applications is not always feasible. Many
multicast applications that operate in real time may be affected by these losses:
—
Heavy drops on voice applications result in jerky, missed speech patterns that can
make the content unintelligible when the drop rate gets too high.
—
Moderate to heavy drops in video are sometimes better tolerated by the human eye
and appear as unusual “artifacts” in the picture. However, some compression
algorithms may be severely affected by low drop rates, which will cause the picture
to become jerky or to freeze for several seconds while the decompression algorithm
recovers.
„
Lack of congestion control may result in overall network degradation as the popularity of
UDP-based multicast applications grow.
„
Duplicate packets may occasionally be generated as multicast network topologies change.
Applications must expect occasional duplicate packets to arrive and must be designed
accordingly.
„
Out-of-sequence delivery of packets to the application may also result during network
topology changes or other network events that affect the flow of multicast traffic.
„
Multicast security is still evolving. The issue of restricting multicast traffic to only a
selected group of receivers to protect against eavesdropping issues has not yet been
sufficiently resolved.
Note
10-6
Some commercial applications become possible only when reliability and security issues are
fully resolved (for example, financial data delivery).
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Multicast Adoption Trends
Multicast applications are emerging as the demand for them grows.
Multicast Adoption Trends
Surveillance
Corporate
Law Enforcement
and Federal
MXU & Content
Communication
Providers
HP, IBM, Intel, Ford,
BMW, Dupont
Fastweb, B2,
Yahoo, BBC, CNN
IPv6 Multicast
NTT, Sony,
Panasonic,
E Learning
Multicast VPN
150 Universities in
US, Hawaii, Oregon,
USC, UCLA, Berkley
C&W, MCI, AT&T,
TI, FT, DT, NTT
Financials
t
en
m
oy
pl
e
D
st
a
c
lti
Mu
NASDAQ, NYSE,
LIFE, Morgan, GS,
Prudential
Early Adopters
NASA, DOD,
Cisco, Microsoft,
Sprint
Research
Community
1992
1996
© 2006 Cisco Systems, Inc. All rights reserved.
1997
z
1986
z
z
MBONE
1998
2000
2001
2002
2003
2004
2005
ARCH v2.0—10-6
Initially, multicast was used primarily by the research community. The first major enterprise
deployments were in the financial service communities. Distant learning and corporate
communication were in the next waves of multicast applications. Content provisioning and
security surveillance are some of the more recent multicast applications.
Real-time applications of multicast include live broadcasts, financial data delivery, whiteboard
collaboration, and videoconferencing. Other applications include file transfer, data and file
replication, and video on demand.
© 2007 Cisco Systems, Inc.
IP Multicast Design
10-7
Cisco Multicast Architecture
The Cisco Multicast Architecture spans from campus multicast to interdomain multicast.
Cisco Multicast Architecture
ISP A
ISP B
MSDP
RP
Multicast Source
X
DR
RP
DR
ISP B
ISP A
IGMP Snooping
IGMP
Multicast Source
Y
MBGP
PIM-SM
Bidir PIM
PIM-SSM
MVPN
Campus Multicast
ƒ End Stations (hosts-to-routers)
DR
Interdomain Multicast
ƒ Multicast routing across domains
– IGMP
ƒ Switches (Layer 2 Optimization)
– MBGP
ƒ Multicast Source Discovery
– IGMP Snooping
ƒ Routers (Multicast Forwarding Protocol)
– MSDP with PIM-SM
ƒ Source Specific Multicast
– PIM Sparse Mode or Bidirectional PIM
– PIM-SSM
© 2006 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—10-7
The figure illustrates the protocols used to support multicast in the enterprise in both campus
multicast solutions and in interdomain multicast solutions:
„
Internet Group Management Protocol (IGMP)
„
Protocol Independent Multicast (PIM)
„
PIM Sparse Mode (PIM-SM)
„
Bidirectional PIM (Bidir PIM)
„
Multiprotocol Border Gateway Protocol (MBGP)
„
Multiprotocol Virtual Private Network (MVPN)
„
PIM Source Specific Multicast (PIM-SSM)
„
Multicast Source Discovery (MSDP)
Note
10-8
The components in the Cisco Multicast Architecture are discussed in the three lessons in
this module.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
IP Multicast Group Membership
This topic explains the purpose and use of IP multicast receiver group membership and
distribution trees.
IP Multicast Group Membership
ƒ You must be a member
of a group to receive its
data.
ƒ If you send to a group
address, all members
receive it.
ƒ You do not have to be a
member of a group to
send to a group.
© 2006 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—10-9
In normal TCP/IP routing, a packet is routed from a source address to a destination address,
traversing the IP network on a hop-by-hop basis.
IP multicast relies on the concept of a virtual group address. In IP multicast, the destination
address of a packet is not assigned to a single destination but to a virtual group address. When
receivers join a multicast group, packets addressed to virtual group address flow to receivers.
All members of the group receive the packet. Devices can send to the group without being a
member of that group. The source address for multicast packets is always the unicast source
address.
In the figure, packets that are sent to group addresses go to all group members, but are not
delivered to non-group members. Non-group members can send packets to a group.
© 2007 Cisco Systems, Inc.
IP Multicast Design
10-9
Multicast Group Address Range
All IP multicast group addresses fall in the range from 224.0.0.0 through 239.255.255.255.
Multicast Group Addresses
224.0.0.0 to 239.255.255.255
ƒ Reserved locally scoped range is 224.0.0.0 to 224.0.0.255.
Predefined addresses include:
– 224.0.0.1
- All hosts
– 224.0.0.2
- All multicast routers
– 224.0.0.4
- All DVMRP routers
– 224.0.0.13
- All PIMv2 routers
– 224.0.0.5, 224.0.0.6, 224.0.0.9, and 224.0.0.10 are used by
unicast routing protocols
ƒ Globally scoped range is from 224.0.1.0 to 238.255.255.255.
– Reserved ranges are 224.0.1.0 to 224.0.1.255, 232.0.0.0/8, and
233.0.0.0/8.
ƒ Administratively scoped range is from 239.0.0.0 to 239.255.255.255.
– Includes site-local and organization-local addresses
ARCH v2.0—10-11
© 2007 Cisco Systems, Inc. All rights reserved.
The Internet Assigned Numbers Authority (IANA) has assigned the IPv4 Class D address space
to be used for IP multicast group addresses. Some addresses in this range are reserved for
specific functions, but most of the addresses are free for dynamic use.
„
„
10-10
Local scope addresses fro m 224.0.0.0 to 224.0.0.255 are reserved. Multicasts in this range
are never forwarded off the local network, regardless of Time to Live (TTL). The TTL is
usually set to 1. There are several predefined local multicast addresses:
—
224.0.0.1
All hosts
—
224.0.0.2
All multicast routers
—
224.0.0.4
All Distance Vector Multicast Routing Protocol (DVMRP) routers
—
224.0.0.5
All Open Shortest Path First Protocol (OSPF) routers
—
224.0.0.6
All OSPF designated routers
—
224.0.0.9
All Routing Information Protocol version 2 (RIPv2) routers
—
224.0.0.10
All Enhanced Interior Gateway Routing Protocol (EIGRP) routers
Globally scoped addresses are addresses 224.0.1.0 through 238.255.255.255. Some of these
addresses have been reserved for use by multicast applications through IANA, including
the range 224.0.1.0 to 224.0.1.255, 232.0.0.0/8, and 233.0.0.0/8. The rest of the addresses
in this range are transient addresses are dynamically assigned and then returned for others
to use when no longer needed
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
„
Administratively scoped addresses are addresses 239.0.0.0/8. Administratively scoped
multicast addresses are for private use within an organization. The address space is further
divided into two ranges. site-local scope (239.255.0.0/16, with 239.252.0.0/16,
239.253.0.0/16, and 239.254.0.0/16 also reserved) and organization-local scope
(239.192.0.0 to 239.251.255.255) addresses. The normal procedure is for the enterprise
network to have "multicast boundaries" configured at the borders of the network so that
traffic in the 239/8 address range can neither enter nor leave the Enterprise network
IP Multicast MAC Address Mapping
IP multicast addresses are mapped to MAC addresses for forwarding through the network.
IP Multicast MAC Address Mapping
(FDDI and Ethernet)
32 Bits
1110
28 Bits
239.255.0.1
5 Bits
Lost
23 Bits
01-00-5e-7f-00-01
25 Bits
23 Bits
48 Bits
© 2006 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—10-11
The Ethernet MAC address range from 01-00-5e-00-00-00 to 01-00-5e-7f-ff-ff is available for
supporting Layer 3 IP multicast addresses. The 0x01005e prefix is used for mapping Layer 3 IP
multicast addresses into Layer 2 MAC addresses. Only the low-order 23 bits of the Layer 2
MAC address are used to map Layer 3 IP addresses.
Because there are 28 bits of unique address space for an IP multicast address (32 minus the first
four bits containing the 1110 Class D prefix), and there are only 23 bits mapped into the IEEE
MAC address, the IP addresses can not be uniquely translated.
© 2007 Cisco Systems, Inc.
IP Multicast Design
10-11
32:1 MAC Address Overlap
32 IP Multicast Addresses
224.1.1.1
224.129.1.1
225.1.1.1
225.129.1.1
.
.
.
238.1.1.1
238.129.1.1
239.1.1.1
239.129.1.1
1 Multicast MAC Address
(FDDI and Ethernet)
0x0100.5E01.0101
ARCH v2.0—10-12
© 2006 Cisco Systems, Inc. All rights reserved.
Multiple Layer 3 addresses map to the same Layer 2 multicast address because the five
unmapped IP address bits result in a 32:1 overlap of Layer 3 addresses to Layer 2 addresses.
The figure shows one mapping of 32 IP multicast addresses to one multicast MAC address.
Another example is that all of the IP multicast addresses in the following table map to the same
Layer 2 multicast of 0x0100.5e0a.0001.
IP Multicast Addresses Mapping to MAC Address 0x0100.5e0a.0001
10-12
224.10.0.1
225.10.0.1
226.10.0.1
227.10.0.1
228.10.0.1
229.10.0.1
230.10.0.1
231.10.0.1
232.10.0.1
233.10.0.1
234.10.0.1
235.10.0.1
236.10.0.1
237.10.0.1
238.10.0.1
239.10.0.1
224.138.0.1
225.138.0.1
226.138.0.1
227.138.0.1
228.138.0.1
229.138.0.1
230.138.0.1
231.138.0.1
232.138.0.1
233.138.0.1
234.138.0.1
235.138.0.1
236.138.0.1
237.138.0.1
238.138.0.1
239.138.0.1
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Multicast Address Assignment
Layer 3 IP multicast addresses are typically assigned statically.
Multicast Address Assignment
Enterprise Internal Group Address Assignment:
ƒ Can be statically assigned by enterprise network administrator
ƒ Can use MADCAP to “lease” multicast addresses
Global Group Address Assignment:
ƒ Can be assigned by IANA
ƒ Can use GLOP addressing as defined in RFC 2770:
– Group range is 233.0.0.0/8 .
– AS number is inserted in middle two octets of address.
– Remaining low-order octet is used for group assignment.
© 2006 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—10-13
Since any multicast source can send to any group address and any multicast client can receive
any group without regard to geography, aggregation and summarization of multicast group
addresses are meaningless. Administrative or private address space can and should be used
within the enterprise unless multicast traffic will be sourced to the Internet which requires a
unique group address. The multicast addresses can be allocated globally or locally:
„
Enterprise Internal Group Address Assignment. Static address allocation methods are
typically used by enterprise network administrators to allocate specific addresses or address
ranges from the administratively scoped address range, 239.0.0.0/8. The Multicast Address
Dynamic Client Allocation Protocol (MADCAP) allows a client workstation to "lease" a
multicast address from a MADCAP server in a manner similar to how it "leases" an IP
address from a DHCP server.
„
Global Group Address Assignment. Static multicast addresses can be assigned by the
IANA on a permanent basis. These are valid everywhere and in all networks. This
technique permits applications and hardware devices to have these addresses "hard-coded"
into their software or microcode. In the late 1990s when native multicast was beginning to
be deployed in the Internet, several content providers planned to begin multicasting some
of their audio and video content. An experimental form of static address allocation was
proposed by the IETF. This allocation methodology, called GLOP addressing, which is
defined in RFC 2770, uses the multicast group range of 233.0.0.0 through 233.255.255.255
(233/8).
Note
© 2007 Cisco Systems, Inc.
GLOB is not an acronym, and does not stand for anything.
IP Multicast Design
10-13
This block was assigned by the IANA and is an experimental, statically assigned range of
multicast addresses intended for use by content providers, ISPs, or anyone wishing to source
content into the global Internet. GLOP addresses set the high order octet to 233 (decimal),
followed by the next two octets which contain the 16-bit ASN of the content provider or ISP
that is sourcing the multicast traffic, followed by remaining octet used for group assignment.
IGMP
Internet Group Management Protocol (IGMP) is used to dynamically register individual hosts
in a multicast group on a particular LAN.
Host-Router Signaling: IGMP
H1
H2
224.1.1.1
H3
Report
ƒ IGMPv1: Host sends IGMP Report to join group
ƒ IGMPv2: Hosts can also send IGMP Leave Group to leave
group
ƒ IGMPv3: Hosts can also indicate sources of expected traffic
so routers can provide source filtering.
© 2006 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—10-14
Hosts send an IGMP messages to their local multicast router indicating that they are interested
in joining a group. Under IGMP, routers listen to IGMP messages and periodically send out
queries to discover which groups are active or inactive on a particular subnet. Members joining
a group do not have to waited for a query to join; they send in an unsolicited report indicating
their interest. This functionality is supported in all versions of IGMP.
IGMP version 2 allows hosts to actively communicate to the local multicast router that they
intend to leave the group with a leave group message.
IGMP Version 3 (IGMPv3) is the third step in the evolution of IGMP. IGMPv3 adds support
for "source filtering," which enables a multicast receiver host to signal to a router the groups
from which it wants to receive multicast traffic, and from which sources this traffic is expected.
This membership information enables Cisco IOS software to forward traffic from only those
sources from which receivers requested the traffic.
10-14
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Multicast Routing
This section explains discusses how multicast routing works.
Multicast Routing
ƒ Multicast routing is concerned about where the packet came from.
– The origination IP address is a known source.
– The destination IP address is an unknown group of receivers.
ƒ Multicast routing is connection-oriented.
– Receivers must first be connected to the source before traffic
begins to flow.
– Connection messages follow unicast routing table toward
multicast source.
– Paths to the source build multicast distribution trees that
determine where to forward packets.
– Distribution trees are rebuilt dynamically in case of network
topology changes.
– RPF forwards traffic away from source.
© 2006 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—10-16
The multicast routing model is backwards from unicast routing. Unicast routing is concerned
about where the packet is going while multicast routing is concerned about where the packet
came from. In multicast transmissions:
„
The origination IP address is a known source.
„
The destination IP address is an unknown group of receivers. Because the destination IP
address of a multicast packet is a group address, it can not be used to directly determine
where to forward the packet.
Multicast routing is connection-oriented since multicast traffic does not flow to the destinations
until connection messages are sent toward the source to set up the flow paths for the traffic.
Note
Multicast sources can just start transmitting.
The collection of these paths form multicast distribution trees that define the path and
replication points in the network for multicast forwarding. The building of the multicast
distribution trees via connection messages is a dynamic process. When network topology
changes occur, the distribution trees are rebuilt around failed links.
Forwarding traffic away from the source, rather than to the receiver, is called Reverse Path
Forwarding (RPF). Multicast routing uses RPF to broadcast packets out from all interfaces
except where packets are incoming from the source.
© 2007 Cisco Systems, Inc.
IP Multicast Design
10-15
Multicast Distribution Tree Creation
Multicast-capable routers create distribution trees that control the path that IP multicast traffic
takes through the network in order to deliver traffic to all receivers.
Multicast Distribution Tree Creation
ƒ Based on source address.
SRC
ƒ Best path to source found in unicast
routing table.
A
ƒ Each router determines where to send
the Join request.
ƒ The Join continues towards source to
build multicast tree.
10.1.1.1
Join
C
B
ƒ Multicast data flows down tree.
D
Join
E1
E0
E
E2
Unicast Route Table
Network
Interface
10.1.0.0/24
E0
© 2006 Cisco Systems, Inc. All rights reserved.
R1
ARCH v2.0—10-17
The figure illustrates the creation of a multicast distribution tree which is based on source
address. A host sends a request to join the source at 10.1.1.1. Router E selects interface E0 as
the best path to the source found in its unicast routing table. E0 gets added to the multicast
routing entry for that particular group. The join request is then forwarded to Router B. Router B
selects the best path to the source found in its unicast routing table. Router B adds the interface
that received the join request as the outgoing interface in the multicast routing table, and the
interface it selects as the best path to the source as the incoming interface. Router B forwards
the join request to Router A. The join request is forwarded to the source and the tree is built
with a forwarding state from the source to the receiver. Multicast data then flows from the
source down the multicast distribution tree to the receiver.
10-16
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
RPF Overview
RPF is a key concept in multicast forwarding.
RPF Overview
ƒ The source address is checked against the unicast routing table.
– If the packet arrives from the interface on the reverse path to
the source, the packet is forwarded.
– Else the packet is dropped.
© 2006 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—10-18
RPF enables routers to correctly forward multicast traffic down the distribution tree. RPF
makes use of the existing unicast routing table to determine the upstream and downstream
neighbors. A router will forward a multicast packet only if it is received on the upstream
interface. This RPF check helps to guarantee that the distribution tree will be loop-free.
When a multicast packet arrives at a router, the router performs an RPF check on the packet:
„
The router looks up the source address in the unicast routing table to determine if the
packet has arrived on the interface that is on the reverse path back to the source.
„
If the packet has arrived on the interface leading back to the source, the RPF check
succeeds and the packet is forwarded.
„
If the RPF check fails, the packet is dropped.
© 2007 Cisco Systems, Inc.
IP Multicast Design
10-17
Multicast Distribution Trees
This section looks at the two types of multicast distribution trees.
IP Multicast Source Distribution Tree
The simplest form of a multicast distribution tree is a source tree with its root at the source and
branches forming a spanning tree through the network to the receivers.
IP Multicast Source Distribution Tree
(Shortest Path Tree)
ƒ Supports optimal paths from source to all receivers
ƒ Minimizes delay
ƒ Uses more memory
© 2006 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—10-19
Because this tree uses the shortest path through the network, it is also referred to as a shortest
path tree (SPT). The figure shows an example of an SPT for group 224.1.1.1 rooted at the
source, host A, and connecting two receivers, hosts B and C.
The special notation of (S,G), which can be thought of as “source comma group” is pronounced
“S comma G,” and enumerates an SPT where S is the IP address of the source and G is the
multicast group address. Using this notation, the SPT for the example shown in the figure
would be (192.168.1.1, 224.1.1.1).
The (S,G) notation implies that a separate SPT exists for each individual source sending to each
group, which is correct. For example, if host B is also sending traffic to group 224.1.1.1 and
hosts A and C are receivers, a separate (S,G) SPT would exist with a notation of (192.168.2.2,
224.1.1.1).
Source trees have the advantage of creating the optimal path between the source and the
receivers. This advantage guarantees the minimum amount of network latency for forwarding
multicast traffic. However, this optimization comes at a cost: the routers must maintain path
information for each source. In a network that has thousands of sources and thousands of
groups, this overhead can quickly become a resource issue on the routers. Memory
consumption from the size of the multicast routing table is a factor that network designers must
take into consideration. The multicast routing table is required to maintain current values,
called state, that determine multicast routing behavior.
10-18
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Shared Distribution Tree
The other multicast distribution tree is a shared tree that use a single common root placed at
some chosen point in the network.
IP Multicast Shared Distribution Tree
ƒ Uses less memory
ƒ May result in sub-optimal paths from source to all receivers
ƒ May introduce extra delay
© 2006 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—10-20
The shared root is called a rendezvous point (RP). The figure shows a shared tree for the group
224.2.2.2 with the root located at router D. This shared tree is unidirectional. Source traffic is
sent towards the RP on a source tree. The traffic is then forwarded down the shared tree from
the RP to reach all of the receivers, unless the receiver is located between the source and the
RP, in which case it will be serviced directly.
With multicast Layer 2 addresses, flowing multicast traffic through an RP saves memory.
Alternatively, the multicast traffic can flow through the RP and then through the SPT.
In the example, multicast traffic from the sources, hosts A and D, travels to the root (router D)
and then down the shared tree to the two receivers, hosts B and C. Because all sources in the
multicast group use a common shared tree, a wildcard notation written as (*,G), pronounced
“star comma G,” represents the tree, followed by an (S,G) entry with a subset outgoing
interface list.
Shared trees have the advantage of requiring the minimum amount of state in each router. The
disadvantage of shared trees is that under certain circumstances the paths between the source
and receivers might not be the optimal paths, which might introduce some latency in packet
delivery. For example, in the figure, the shortest path between host A (source 1) and host B (a
receiver) would be router A and router C. Because we are using router D as the root for a
shared tree, the traffic must traverse routers A, B, D and then C.
© 2007 Cisco Systems, Inc.
IP Multicast Design
10-19
Multicast Forwarding at Layer 2
This section discusses multicast forwarding at Layer 2.
Layer 2 Multicast Frame Switching
ƒ Layer 2 switches by default flood the
frame to every port on the destination
LAN.
ƒ Static entries can sometimes be set to
specify which ports should receive which
group(s) of multicast traffic
ƒ Dynamic configuration of these entries
would cut down on user administration
© 2006 Cisco Systems, Inc. All rights reserved.
PIM
Multicast
ARCH v2.0—10-21
The default behavior for a data link layer switch is to forward all multicast traffic to every port
that belongs to the destination LAN on the switch. This behavior reduces the bandwidth
efficiency of the switch because it does not limit traffic to only the ports that need to receive the
data. Flooding is appropriate for unknown traffic and broadcasts, but IP multicast hosts may
join and be interested in only specific multicast groups. Forwarding multicast traffic out all
ports results in wasted bandwidth on both the segments and on the end stations.
One option is to configure the switch manually to associate a multicast MAC address with
specific ports so that only these ports receive the multicast traffic destined for the multicast
group. Since IP multicast hosts dynamically join and leave groups using IGMP to signal to the
multicast router, a static way of entering the multicast information is not very scalable.
Dynamic configuration of the forwarding table of the switches would be a better idea, and
would decrease user administration requirements.
10-20
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
IGMP Snooping
IGMP snooping is an IP multicast constraining mechanism that runs on a data link layer LAN
switch.
IGMP Snooping
IGMP Snooping
ƒ Switches are “IGMP” aware
ƒ Switch must examine contents of IGMP messages
to determine which ports want what traffic
– IGMP membership reports
– IGMP leave messages
ƒ Switch can forward multicast traffic more efficiently
PIM
Multicast
Hardware Support
ƒ Current Cisco switches support IGMP snooping
hardware.
ƒ Catalyst 6500/4500 switches support multicast
packet replication in hardware.
© 2006 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—10-22
With IGMP snooping, the Layer 2 switches are IGMP aware. IGMP snooping constrains IPv4
multicast traffic at Layer 2 by configuring the Layer 2 LAN ports dynamically to forward IPv4
multicast traffic only to those ports that want to receive it. IGMP snooping requires the LAN
switch to examine, or “snoop,” some network layer information such as IGMP Join and Leave
messages in the IGMP packets sent between the hosts and a router or multilayer switch.
When the switch hears the IGMP host report from a host for a particular multicast group, the
switch adds the port number of the host to the associated multicast table entry. When the switch
hears the IGMP leave group message from a host, the switch removes the table entry of the
host. IGMP Snooping is used on subnets that include end users or receiver clients IGMP
snooping allows a Layer 2 switch to more efficiently handle IP multicast.
IGMP snooping requires special hardware in the switches so the forwarding throughput is
maintained. Current Cisco switches support IP multicast data packet forwarding using
advanced application-specific integrated circuit switching hardware that can distinguish IGMP
information packets from other packets for the multicast group. In addition, the Cisco Catalyst
6500 Series switches and Cisco Catalyst 4500 Series switches support multicast packet
replication in hardware which more efficiently copies multicast packets to the network
interfaces where the multicast path flows diverge.
© 2007 Cisco Systems, Inc.
IP Multicast Design
10-21
Summary
This topic summarizes the key points discussed in this lesson.
Summary
ƒ IP multicast is an alternative to unicast and broadcast that sends
packets to a subset of network hosts simultaneously. By requiring
only a single copy of each packet to be sent on each interface,
multicast helps reduce network traffic.
ƒ The destination of an IP multicast packet is a virtual group
address. Members join a group and receive multicast packets
addressed to that group.
ƒ Multicast routing uses RPF with distribution trees to control the
path that IP multicast traffic takes through the network. IP
multicast packets are replicated only at routers where paths
diverge to reach the intended recipients.
ƒ By default, a data link layer switch will forward all multicast traffic
to every port that belongs to the destination LAN. IGMP snooping
is a multicast control mechanism that limits multicast traffic to the
ports that need to receive the data.
© 2006 Cisco Systems, Inc. All rights reserved.
10-22
Designing Cisco Network Service Architectures (ARCH) v2.0
ARCH v2.0—10-26
© 2007 Cisco Systems, Inc.
Lesson 2
PIM and RP Considerations
Overview
Multicast deployments require three elements: the application, the network infrastructure, and
client devices. This lesson discusses how Protocol Independent Multicast (PIM) is used in the
network infrastructure. It also discusses considerations for deploying rendezvous points (RP) in
multicast networks.
Objectives
Upon completing this lesson, you will be able to design an IP multicast solution in an existing
unicast infrastructure. This includes being able to meet these objectives:
„
Describe the design considerations for deploying Protocol Independent Multicast (PIM)
„
Describe the design considerations for deploying RPs in PIM spare mode networks
PIM Deployment Models
This topic discusses Protocol Independent Multicast (PIM) deployment models used to perform
the multicast forwarding functions.
Major PIM Deployment Models
PIM Any-Source Multicast (Classical PIM-SM)
ƒ Uses RP, SPT, and shared tree.
Bidirectional PIM
ƒ Uses shared tree only, no SPT.
Source Specific Multicast
ƒ Uses SPT only, no RP.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—10-28
PIM uses the unicast routing table to perform the Reverse Path Forwarding (RPF) check
function instead of building up a completely independent multicast routing table. Multicastcapable routers dynamically create distribution trees that control the path the content travels
through the network. PIM uses two types of multicast distribution trees: shared trees and source
trees.
Note
Source trees are also called Shortest Path Trees (SPTs).
There are three main PIM deployments used to support multicast services and applications:
10-24
„
Any-Source Multicast (ASM). ASM uses a combination of the shared and source trees
and rendezvous points (RPs). ASM is the classical PIM Sparse Mode (PIM-SM)
deployment. The majority of deployed multicast networks use this model. Few new
deployments are implementing this model.
„
Bidirectional PIM (Bidir PIM). Bidir PIM exclusively uses shared trees. Bidir PIM is
recommended to support many-to-many host applications. Bidir PIM drastically reduces
the total (S,G) state information needed in network.
„
Source Specific Multicast (SSM). SSM exclusively uses source trees. SSM is
recommended to support one-to-many applications. SSM greatly simplifies the network
and eliminates the need for RP engineering.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Any-Source Multicast
ASM is also known as PIM sparse mode (PIM-SM), the traditional form for PIM deployments.
PIM-SM is described in RFC 2362 .
PIM-SM Shared Tree Join
2
1
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—10-29
PIM-SM forwards multicast traffic only to network segments with active receivers that have
explicitly requested the data. PIM-SM distributes information about active sources by
forwarding data packets on shared trees. Because PIM-SM uses shared trees at least initially, it
requires the use of a RP. The RP must be administratively configured in the network.
Sources register with the RP and then data is forwarded down the shared tree to the receivers.
The edge routers learn about a particular source when they receive data packets on the shared
tree from that source through the RP. The edge router then sends PIM (S,G) Join messages
toward that source. Each router along the reverse path compares the unicast routing metric of
the RP address to the metric of the source address. If the metric for the source address is better,
it will forward a PIM (S,G) Join message towards the source. If the metric for the RP is the
same or better, then the PIM (S,G) Join message will be sent in the same direction as the RP. In
this case, the shared tree and the source tree would be considered congruent.
In the figure, an active receiver has joined multicast group G. The router knows the IP address
of the RP for group G and it sends a (*,G) Join for this group towards the RP. This (*,G) Join
travels hop-by-hop to the RP, building a branch of the shared tree that extends from the RP to
the last-hop router directly connected to the receiver. At this point, group G traffic can flow
from the RP down the shared tree to the receiver.
© 2007 Cisco Systems, Inc.
IP Multicast Design
10-25
PIM-SM Sender Registration
The multicast source registers with the predefined RP using a sender registration.
PIM-SM Sender Registration
6
2
1
3
5
4
3
Traffic Flow
Shared Tree
Source Tree
(S, G) Register
(unicast)
(S, G) Join
(S, G) Register-Stop
(unicast)
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—10-30
As soon as an active source for group G sends a packet to its first-hop router, the router is
responsible for registering the source with the RP and requesting the RP to build a tree back to
that router. During the sender registration process, the source router encapsulates the multicast
data from the source in a special PIM-SM message called the Register message and unicasts
that data to the RP.
When the RP receives the Register message it does two things:
„
The RP unencapsulates the multicast data packet inside of the Register message and
forwards it down the shared tree to receivers in group G.
„
The RP sends an (S,G) Join back towards the source network S to create a branch of an
(S,G) shortest path tree (SPT). This results in (S,G) state being created in all the routers
along the SPT, including the RP.
As soon as the SPT is built from the source router to the RP, multicast traffic begins to flow
from source S to the RP. Once the RP begins receiving multicast data on the SPT from source
S, the RP sends a Register-Stop to the first-hop router of the source to inform it that it can stop
sending the unicast Register messages.
10-26
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
PIM-SM SPT Switchover
SPT Switchover allows PIM-SM to more efficiently support multicast traffic.
PIM-SM SPT Switchover
Traffic Flow
Shared Tree
Source Tree
(S, G) Join
Note: Automatic SPT switchover in Cisco routers is supported by the
default value of 0 for the SPT-threshold.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—10-31
PIM-SM includes the capability for last-hop routers (that is, routers with directly connected
group members) to switch to the SPT and bypass the RP if the traffic rate is above a set
threshold, called the SPT-threshold.
Note
The default value of the SPT-threshold in Cisco routers is zero. If the infinity keyword is
specified, all sources for the specified group use the shared tree, never switching to the
source tree.
This means that the default behavior for PIM-SM leaf routers attached to active receivers is to
immediately join the SPT to the source as soon as the first packet arrives via the (*,G) shared
tree.
In the figure, the last-hop router sends an (S,G) Join message toward the source to join the
shortest path tree and bypass the RP.
The (S,G) Join messages travel hop-by-hop to the first-hop router (the router connected directly
to the source), thereby creating another branch of the shortest path tree. This also creates (S,G)
state in all the routers along this branch of the shortest path tree.
© 2007 Cisco Systems, Inc.
IP Multicast Design
10-27
Bidirectional PIM
Bidirectional PIM (Bidir PIM) is an enhancement of the PIM protocol that was designed for
efficient many-to-many communications within an individual PIM domain.
Bidirectional PIM
There are issues with many-to-many IP multicast in PIM-SM.
ƒ Large number of sources creates huge (S,G) state problem for
PIM-SM.
Bidir PIM addresses these issues:
ƒ Use a bidirectional shared tree to deliver traffic from sources to
the RP and to all other receivers.
Benefits of Bidir PIM:
ƒ Less state in routers
– Only (*, G) state is used.
– SPT is not used.
ƒ Source traffic follows the Shared Tree.
– Flows up the Shared Tree to reach the RP.
– Flows down the Shared Tree to reach all other receivers.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—10-32
The shared trees created in PIM-SM are unidirectional. A source tree must be created to bring
the data stream to the RP (the root of the shared tree) and then it can be forwarded down the
branches to the receivers through the shared tree. Source data cannot flow up the shared tree
toward the RP.
Several multicast applications use a many-to-many model where each participant is receiver
and sender as well. In a PIM-SM deployment, routers that support hosts that are a source as
well as a receiver would need to have a source tree for each host to the RP, as well as a
common shared tree from the RP for each group. In a PIM-SM domain supporting a large
number of many-to-many participants, the (*,G) and (S,G) entries appear everywhere along the
path from participants and the associated RP resulting in increased memory and protocol
overhead. The large number of sources can create a huge (S,G) state problem.
Bidir PIM allows packets to be natively forwarded from a source to the RP using shared tree
state only. In bidirectional mode, traffic is routed through a bidirectional shared tree that is
rooted at the RP for the group. This ensures that only (*,G) entries will appear in multicast
forwarding tables. The SPT between sources and the RP are eliminated, and the (S,G) state
information is eliminated as well. With Bidir PIM, the path taken by packets flowing from the
participant (whether source or receiver) to the RP and back from the RP to the participant will
be the same.
Multicast groups in bidirectional mode can scale to an arbitrary number of sources with only a
minimal amount of additional overhead.
10-28
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Bidir PIM – Example
RP
Receiver
DF
Sender/
Receiver
Source Traffic forwarded
bidirectionally using (*,G) state.
Shared Tree
Source Traffic
Receiver
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—10-33
The figure shows a bidirectional shared tree. Data from the source can flow up the shared tree
(*, G) towards the RP and then down the shared tree to the receiver. There is no registration
process and so source tree (S, G) is not created. Bidir PIM uses a designated forwarder (DF) so
that bidirectional sources can reach the RP.
The main responsibility of the DF is to decide what packets need to be forwarded upstream
toward the rendezvous point. The figure shows a case where the source is also a receiver, and
traffic originating from that host will be traveling against the direction of the shared tree. This
breaks the original assumption that shared trees only accept traffic on their Reverse Path
Forwarding (RPF) interface to the rendezvous point. The same shared tree is now used to
distribute traffic from the rendezvous point to receivers and from the sources to the rendezvous
point, resulting in a bidirectional branch. The algorithm to elect the designated forwarder is
straightforward, all the PIM neighbors in a subnet advertise their unicast route to the
rendezvous point and the router with the best route is elected. This effectively builds a shortest
path between every subnet and the rendezvous point without consuming any multicast routing
state since no (S,G) entries are generated.
The RP in Bidir PIM only serves the function of getting sources and receivers to learn about
each other. The IP address of the RP acts as the key to having all routers establish a loop-free
spanning tree topology rooted in that IP address. This IP address need not be a router address,
but can be any unassigned IP address on a network that is reachable throughout the PIM
domain. Traffic from the source is going to be forwarded hop by hop toward the RP by the DF
mechanism, and joins from the receivers will also be sent to the rendezvous point.
© 2007 Cisco Systems, Inc.
IP Multicast Design
10-29
Source Specific Multicast
Source Specific Multicast (SSM) is an extension of the PIM protocol that allows for an efficient
data delivery mechanism in one-to-many communications.
Source Specific Multicast
SSM uses source trees only.
ƒ Receivers are responsible for source and group discovery.
ƒ Receivers select what traffic they want from a group.
ƒ Receivers use IGMPv3 to signal which (S,G) to join.
ƒ RP and shared trees are not needed in the network.
SSM solves multicast address allocation problems.
ƒ Flows differentiated by both source and group.
ƒ Content providers can use same group ranges.
– Each (S,G) flow is unique.
– Only explicitly request flows are forwarded to receivers.
Note: IGMPv3 is specified in RFC 3376. An overview of SSM is provided in
RFC 3569.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—10-34
In traditional multicast implementations, source applications join to an IP multicast group
address and traffic is distributed to the entire IP multicast group. If two applications with
different sources and receivers use the same IP multicast group address, receivers of both
applications will receive traffic from the both senders. This situation can generate noticeable
levels of unwanted network traffic.
SSM enables a receiving client, once it has learned about a particular multicast source through
a directory service to receive content directly from the source, rather than receiving it using a
shared RP. In SSM, routing of multicast traffic is entirely accomplished with source trees.
There are no shared trees and therefore an RP is not required.
The prerequisite for SSM deployment is a mechanism that allows hosts not only to report the
group they want to join but also the specific source in the group. This mechanism is built into
emerging IGMP version 3 standard. In an SSM-enhanced multicast network, the last-hop router
(the router closest to the receiver) will see a request from a receiver to join to a specific
multicast source in a multicast group. The particular source can be identified by using the
INCLUDE mode in IGMPv3. The multicast router can now send the request directly to the
specific source rather than send the request to a common RP as in PIM sparse mode. The
first-hop router starts forwarding the multicast traffic down the SPT to the receiver as soon as
the SPT is built by receiving first (S,G) Join.
The Internet Assigned Numbers Authority (IANA) has reserved the global address range
232.0.0.0/8 for SSM applications and protocols. This assigned range simplifies the address
allocation for content and service providers. Providers can use the same group range to deliver
content with a unique flow. Routers running in SSM mode will route data streams based on the
10-30
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
full (S, G) address. Assuming that a source has a unique IP address to send on the Internet, any
(S, G) from this source also would be unique.
The ability for SSM to explicitly include and exclude particular sources allows for a limited
amount of security. Traffic from a source to a group that is not explicitly listed on the
INCLUDE list will not be forwarded to uninterested receivers.
Note
IGMPv3 is specified in RFC 3376. An overview of SSM is provided in RFC 3569.
SSM Join Process
1. Receiver learns of source, group/port.
2. Last-hop learns of source, group/port.
3. Last-hop send PIM (S,G) Join.
Source
A
3
PIM (S, G) Join
IGMPv3 (S, G) Join
B
D
C
1
E
Out-of-band
source directory,
example: web server
F
2
Receiver 1
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—10-35
The figure illustrates the SSM Join process. A receiver determines the source and group address
for a multicast source. The receiver sends a source specific IGMPv3 Join request to its closest
router. The last-hop router sends a PIM (S,G) Join request to the first-hop router closest to the
source.
© 2007 Cisco Systems, Inc.
IP Multicast Design
10-31
SSM Shortest Path Tree
Source
Result: SPT rooted
at the source, with no shared tree.
A
B
D
C
E
Out-of-band
source directory,
example: web server
F
Receiver 1
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—10-36
The first-hop router builds the SPT to the last-hop router. The first-hop router starts forwarding
the multicast traffic down the SPT to the receiver.
SSM is easy to install and provision in a network because it does not require the network to
maintain which active sources are sending to multicast groups. SSM is a recommended practice
for Internet broadcast-style applications.
10-32
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
RP Considerations
An RP is required only in networks running PIM-SM and Bidir PIM. This topic discusses
considerations for deploying RPs.
Anycast RP
Anycast RP is a technique for configuring a PIM-SM network to provide for fault tolerance and
load sharing within a single multicast domain.
Anycast RP
Src
RP1
RP2
MSDP
A
10.1.1.1/32
Rec
Src
Rec
SA
B
10.1.1.1/32
SA
Rec
Rec
ƒ Two or more routers share source registration process.
ƒ The RPs act as hot backups for each other.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—10-38
Anycast is a term from IPv6 that refers to an address that is shared by devices performing the
same function. This allows routing to the closest device. There are no defined Anycast
addresses in IPv4. Anycast RP allows two or more RPs to share the load for source registration
and the ability to act as hot backup routers for each other. To perform the Anycast RP function
within IPv4, a unicast host address (/32 mask) is assigned and then is duplicated on loopback
interfaces on the RPs.
All the downstream routers are configured so that the IP address of their local RP is this
loopback address. IP routing automatically selects the topologically closest RP for each source
and receiver. Since some sources might end up using one RP, and some receivers a different
RP, there needs to be some way for the RPs to exchange information about active sources. This
is done with Multicast Source Discovery Protocol (MSDP). MSDP is used to announce sources
sending to a group. All the RPs are configured to be MSDP peers of each other. Each RP will
know about the active sources in the other RP's area. If any of the RPs was to fail, IP routing
will converge and one of the RPs would become the active RP in both areas.
Note
© 2007 Cisco Systems, Inc.
The RPs are only used to setup the initial connection between sources and receivers in
PIM-SM. After the last hop routers join the shortest path tree the RP is no longer necessary.
IP Multicast Design
10-33
Static RP Addressing
Static RP addressing deployments require that every router in the network to be manually
configured with the IP address of a single RP.
Static RP Addressing
ƒ RP address must be configured on every router.
ƒ All routers must have the same RP configuration.
ƒ RP fail-over not possible except through Anycast RPs.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—10-39
If this RP fails, there is no way for routers to fail-over to a standby RP. The exception to this
rule is if Anycast-RPs are in use with MSDP running between each RP in the network.
10-34
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Auto-RP
The Auto-RP protocol is a dynamic way to learn the RP information for every router in the
network.
C-RP
1.1.1.1
C
Announce
Announce
A
Announce
MA
B
Announce
Announce
MA
D
Announce
Announce
Auto-RP: RP Announcements
Announce
C-RP
2.2.2.2
ƒ RP announcements are multicast to 224.0.1.39 group by C-RPs.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—10-40
In Auto-RP, one or more routers are designated as RP mapping agents, which receive the RP
announcement messages from candidate RPs (C-RPs) and arbitrate conflicts. The RP mapping
agent then sends the consistent group-to-RP mappings to all other routers by dense mode
flooding. This process allows all routers automatically to discover which RP to use for the
groups they support. IANA has assigned two group addresses, 224.0.1.39 and 224.0.1.40, for
Auto-RP. All PIM-enabled routers automatically join the Cisco RP discovery group,
224.0.1.40, which allows them to receive all group-to-RP mapping information.
With Auto-RP, the network administrator configures one or more routers in the network to
serve as the C-RPs. The C-RPs announce their willingness to serve as RP for a particular group
range by periodically multicasting Auto-RP Announce messages to the Cisco Announce
multicast group, 224.0.1.39.
© 2007 Cisco Systems, Inc.
IP Multicast Design
10-35
MA
MA
Dis
cov
ery
B
Disc
ov e
ry
C
ove
ry
Dis
cov
ery
A
Disc
Disc
Dis
cov
Dis
cov
ery
C-RP
1.1.1.1
o ve
ery
ry
Auto-RP: RP Discovery Messages
Disc
D
o ve
ry
C-RP
2.2.2.2
ƒ MA selects RP for each group.
ƒ RP discoveries are multicast by MA to the 224.0.1.40 group.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—10-41
The mapping agent is a router that joins the Cisco RP announce group, 224.0.1.39. The
mapping agent listens to all RP candidate announcements and builds a table with the
information. If several RPs announce themselves for a multicast group range, the mapping
agent chooses the RP with the highest IP address. It then advertises the RP to all PIM routers in
the network using an RP discovery message in dense mode flooding. Mapping agents send this
information by default every 60 seconds. When the network routers receive one of these RP
discovery messages, they store the elected RP information in their Group-to-RP mapping cache
so that they know what RP is active for what group range.
Note
10-36
The C-RP and the mapping agent can be on the same router.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Avoiding DM Fallback and DM Flooding
Dense mode fallback (DM fallback) is the condition of the PIM mode falling back from sparse
mode which requires an RP to dense mode which does not use an RP. Dense mode fallback
occurs when RP information is lost. By default, PIM dense mode fallback is enabled and a
multicast group in the absence of RP information will fall to dense mode, regardless of the
interface mode configuration.
Avoiding DM Fallback and DM Flooding
ƒ Older Cisco IOS software needs all interfaces configured in
sparse-dense mode:
– Use the ip pim sparse-dense-mode interface configuration
command.
– Use a “sink RP” or “RP of last resort” to prevent groups other
than 224.0.1.39 and 224.0.1.40 from operating in dense mode.
ƒ New Cisco IOS software command prevents DM fallback:
– Use the no ip pim dm-fallback global configuration command.
– Is available starting with 12.3(4)T, 12.2(28)S, 12.2(33)SRA.
ƒ New Cisco IOS software command prevents DM flooding:
– Use the ip pim autorp listener global configuration command.
– Is available starting with 12.3(4)T, 12.2(28)S, 12.2(33)SRA.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—10-42
A previous requirement of Auto-RP was that all interfaces must be configured in sparse-dense
mode using the ip pim sparse-dense-mode interface configuration command. An interface
configured in sparse-dense mode is treated in either sparse mode or dense mode of operation,
depending on which mode the multicast group operates. If a multicast group has a known RP,
the interface is treated in sparse mode. If a group has no known RP, the interface is treated in
dense mode and data will be flooded over this interface.
To successfully implement Auto-RP and prevent any groups other than 224.0.1.39 and
224.0.1.40 from operating in dense mode with this scenario, Cisco recommends configuring a
"sink RP" which is also known as "RP of last resort". A sink RP is a statically configured RP
that may or may not actually exist in the network. Configuring a sink RP does not interfere with
Auto-RP operation because by default Auto-RP messages supersede static RP configurations.
Note
© 2007 Cisco Systems, Inc.
The ‘override’ keyword permits the statically defined RP address to take precedence over
Auto-RP learned Group-to-RP mapping information.
IP Multicast Design
10-37
Two new Cisco IOS software configuration commands are available to prevent DM flooding
and DM fallback.
„
The ip pim autorp listener global configuration command causes IP multicast traffic for
the two Auto-RP groups 224.0.1.39 and 224.0.1.40 to be PIM dense mode flooded across
interfaces operating in PIM sparse mode. The command supports interfaces configured for
PIM sparse mode operation in order to establish a network configuration where Auto-RP
operates in PIM dense mode and multicast traffic can operate in sparse mode, bidirectional
mode, or SSM mode. This command is available starting with Cisco IOS software releases
12.3(4)T, 12.2(28)S, 12.2(33)SRA.
If the ip pim autorp listener command is not supported on your devices, Cisco
recommends configuring a sink RP for all possible multicast groups in the network,
because it is possible for an unknown or unexpected source to become active. If no RP is
configured to limit source registration, the group will revert to dense mode operation and
be flooded with data.
„
10-38
The ip pim dm-fallback global configuration command disables DM fallback and blocks
all multicast traffic for groups not specifically configured. When IP multicast is used in
mission-critical networks, you should avoid the use of PIM-DM. PIM makes the
determination as to whether a multicast group operates in PIM-DM or PIM sparse-dense
mode based solely on the existence of RP information in the group-to-RP mapping cache.
If Auto-RP is configured or a bootstrap router (BSR) is used to distribute RP information,
there is a risk that RP information can be lost if all RPs, Auto-RP, or the BSR for a group
fails due to network congestion. This failure can lead to the network either partially or fully
falling back into PIM-DM. If a network falls back into PIM-DM, dense mode flooding will
occur. Routers that lose RP information will switch all existing states into dense mode and
any new states that must be created for the failed group will be created in dense mode. This
command is available starting with Cisco IOS software releases 12.3(4)T, 12.2(28)S,
12.2(33)SRA.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
BSR
Bootstrap router (BSR) is another dynamic RP selection protocol that also supports
interoperability between vendors.
BSR Election
BSR
BSR
BSR
Msg
C-BSR
M sg
BSR
Msg
C-BSR
Msg
F
BSR
M
sg
BSR
BSR
BSR
Msg
Msg
BSR
Msg
BSR
Msg
A
D
Msg
C-BSR
BSR
Msg
BSR
M
sg
G
B
C
E
ƒ BSR messages are flooded hop-by-hop.
ƒ C-BSR with highest priority is elected as the active BSR.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—10-43
BSR performs similarly to Auto-RP in that it uses candidate routers for the RP function and for
relaying the RP information for a group. The network administrator configures one or more
routers in the network to serve as Candidate BSRs (C-BSR).
At network startup, all C-BSRs participate in the BSR election process by sending a PIM BSR
message containing its BSR priority out all interfaces. This information is distributed through
link-local multicast messages that travel from PIM router to PIM router. These BSR messages
are flooded hop-by-hop throughout the entire network. At the end of the BSR-Election-Interval,
the BSR with the highest BSR priority is elected as the active BSR.
Note
© 2007 Cisco Systems, Inc.
The BSR election process is similar in nature to the Root-Bridge election mechanism in the
Spanning-Tree protocol.
IP Multicast Design
10-39
C-RPs and BSR Messages
BSR
BSR
M
sg
G
M sg
BSR
A
C
C-RP
t
Msg
m
se
rti )
t
ve
Ad icas
P
n
-R
(u
en
BSR
D
B
BSR
C- Msg
RP
Ad
(u vert
ni
ca isem
st
en
)
t
F
C
C-RP
E
ƒ C-RPs will unicast their C-RP Announcement messages directly
to the active BSR.
ƒ BSR sends entire list of C-RPs in periodic BSR messages.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—10-44
All routers in the network including C-RPs know which C-BSR has been elected as the
currently active BSR. The C-RPs will unicast their C-RP Announcement messages directly to
the active BSR. The active BSR stores all incoming C-RP Announcements in its Group-to-RP
mapping cache. The BSR then sends the entire list of C-RPs from its Group-to-RP mapping
cache in periodic BSR messages which are flooded hop-by-hop throughout the entire network.
As each router receives a copy of these BSR messages, it updates the information in its local
Group-to-RP mapping cache so it knows the IP address of all C-RPs in the network.
However, unlike Auto-RP where the mapping agent elects the active RP for a group range and
announces the election results to the network, the BSR does not elect the active RP for a group.
This task is left to each individual router in the network. Each router in the network will elect
the currently active RP for a particular group range using a well-known hashing algorithm.
Since each router is running the same algorithm against the same list of C-RPs, they all elect
the same RP for a particular group range.
10-40
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Summary
This topic summarizes the key points discussed in this lesson.
Summary
There are three major PIM deployment models:
ƒ SSM should be used for one-to-many applications.
ƒ Bidir should be used for many-to-many applications.
ƒ ASM (Classic PIM-SM) can be used for other general purpose
applications.
An RP is required in networks running PIM-SM. There are four
common methods and technologies for deploying RPs:
ƒ Anycast RP provides fault tolerance and load sharing within a single
multicast domain.
ƒ Static RP addressing requires every router in the network to be manually
configured.
ƒ Auto-RP is a dynamic way to learn the RP information for every router in
the network.
ƒ Bootstrap router (BSR) is another dynamic RP selection model that
supports interoperability between vendors.
© 2007 Cisco Systems, Inc. All rights reserved.
© 2007 Cisco Systems, Inc.
ARCH v2.0—10-45
IP Multicast Design
10-41
10-42
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Lesson 3
IP Multicast Security
Overview
Multicast deployments have additional security considerations as compared unicast routing due
to the multicast architecture. The factors that make multicast routing different are the state
information, replication process, join process, and unidirectional flows. Multicast networks can
use various access control mechanisms to help secure multicast networks. Both multicast
security considerations and access control mechanisms are discussed in this lesson.
Objectives
Upon completing this lesson, you will be able to describe security considerations and access
control mechanisms for an IP multicast network. This includes being able to meet these
objectives:
„
Discuss security considerations specific to multicast networks
„
Describe access control mechanisms that help secure multicast networks
Security Considerations for IP Multicast
This topic describes security considerations for IP multicast implementations.
Security Goals for Multicast
Keep network running under
ƒ Mis-configuration, Malfunction, Attacks
Manage resources
ƒ Sender / Receiver
ƒ Rogue servers
ƒ Rogue RPs
Account for
ƒ Resource utilization, service participation
Note: Wide range of tools and technologies available. No simple
mapping between goals and means.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—10-49
There are different concerns with IP multicast then with unicast routing due to the difference in
routing applications. The main goal for security with multicast networks is to keep the network
running even if there are misconfigurations, malfunctions, or network attacks such as denial of
service (DoS) attacks from unknown servers. Part of multicast security involves managing
network resources and access control for multiple senders and receivers by defining what
multicast traffic should be allowed in the network, and protecting against rogue servers or
rendezvous points (RPs) that should not legitimately be in the network. Managing network
resource utilization includes accounting for multicast state information in the network and
services participating in multicast activity.
There are a wide range of tools and technologies that can be used to manage multicast security.
With the variety of concerns and tools, there is no simple mapping between goals and means to
support these goals.
10-44
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Multicast Control and Enforcement
Policy-Server
AAA Hop-by-Hop
Coordinated
Wh
ere
: Lo
cati
on
Packet level
policing, encryption
Local
Router
switch
t
rge
a
T
at: Service
Wh
Links Content
Network
Device
Data plane
State
creation
d
tho
e
M
:
How
Wh
y: C
Access
ont
ro
l typ
Permission/
Credential Policy
e
Admission
Resource availability
Control plane
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—10-50
Multicast control and enforcement looks at answering four questions:
„
Why control? Network administrators want to control which users and servers have access
to network resources. They can be supporting organization policies, or protecting access to
resources with permissions and controls. Controlling admission helps manage resource
availability.
„
How to control? Control in multicast environments can involve methods such as managing
state creation or providing packet level control by policing, filtering, and encryption
techniques.
„
What are the targets? Multicast networks want to protect the service content, the control
plane of the network devices from being overloaded, and the impacts to the data plane of
the network from overloading the links between the devices.
„
Where to control? Controls can be enforced in multiple locations, but most are configured
locally on a router or switch. These controls may implicit protect the service across the
network. There are also protocols that can be coordinated to provide protection on a
hop-by-hop basis, and mechanisms that rely on policy servers to provide authentication,
authorization, and admission (AAA).
The factors that make multicast routing different from unicast routing are the state information,
replication process, join process, and unidirectional flows in the multicast architecture.
© 2007 Cisco Systems, Inc.
IP Multicast Design
10-45
Unicast and Multicast State Requirements
There are different state requirements for unicast and multicast routing.
Unicast and Multicast State Requirements
Unicast:
ƒ State is the unicast routing table.
– State changes only when network topology changes.
ƒ CPU is active when network topology changes.
– CPU is not impacted by user activity.
ƒ Network design constraint with link bandwidth.
Multicast:
ƒ State is the unicast routing table plus multicast state information.
– State grows when user starts application.
ƒ CPU active when application state changes and when network
topology changes.
– CPU is impacted by user activity.
ƒ Network design constraint is number of applications and sources.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—10-51
For unicast routing, the state in the network is the unicast routing table. The state is fairly
stable, and only changes when the network topology changes. The router CPU is active after
network topology changes. End user activity does not impact amount of state or the activity on
the router other than traffic through the links. The main network design constraint is the
bandwidth requirements on the links.
For multicast routing, the state includes the unicast routing state plus multicast state
information. The multicast state grows when sources and receivers run multicast applications.
The router CPU is active when application state changes or when network topology changes
occur. Protocol Independent Multicast (PIM) and Internet Group Management Protocol (IGMP)
create more periodic activity for the CPU then unicast protocols do. The network design
constraint is worst case application behavior, so the design needs to consider the number of
applications and sources in the network in order to provide a secure network.
10-46
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Multicast State and Replication
There are different state requirements for unicast and multicast routing.
Multicast State and Replication
Ingress state
ƒ per application/sender
Egress state
Multicast
Lookup/Ingress States
Multicast
Egress/Replication
States
ƒ per receiver branch
State limits:
ƒ 5000 … >100,000 in hardware
S1,G1
S2,G2
…
ƒ 100,000 in software
Throughput limits:
ƒ Unicast: Ingress Packet Rate
ƒ Multicast: Egress Packet Rate
– On routers and switches
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—10-52
With IP multicast, there is state information associated with ingress lookups per application on
a server. The memory requirements of ingress state scales with the number of applications per
server.
The egress state information is concerned with replication of packets to multiple interfaces
supporting receiver branches in the distribution tree. The state information scales with the
number of applications across the number of receiver branches on outgoing interfaces.
Hardware acceleration provides the optimal multicast performance, but there are hard limits on
hardware state based on the available chip sets in the platform. There are also much larger soft
limits in memory on software platforms.
Throughput concerns are different in unicast and multicast routing. Unicast routing is
concerned with the amount of traffic received or the ingress packet rate. Multicast routing is
concerned with the egress packet rate and the ability to replicate outgoing packets. Because of
the requirements for packet replication, low input packet rates can potentially overload the
capacity of the router to support the egress load. Egress throughput impacts both routers and
Layer 3 switches supporting IGMP snooping.
© 2007 Cisco Systems, Inc.
IP Multicast Design
10-47
Impact of Replication on Access Control
Multicast replication has an impact on where access control is applied.
Impact of Replication on Access Control
Source X
Example: Inhibit Source X to A traffic
Unicast: can filter anywhere on path
Unicast
Multicast:
Multicast
R1
ƒ Receiver:
R2
– MUST filter after last replication
S1
– Uses egress filtering
ƒ Sources:
– MUST filter before first replication
C
– Uses ingress filtering
A
© 2007 Cisco Systems, Inc. All rights reserved.
B
ARCH v2.0—10-53
In the example, we want to inhibit receiver A from receiving traffic from Source X. For unicast,
we can filter traffic anywhere along the path based on source and receiver addresses. This
model does not work for multicast since the receiver address is a group address.
For multicast, filtering for receivers must always happen after last replication point to potential
other receivers. In the figure, the filtering has to occur at Switch S1 egress to avoid impacting
receiver B. To filter sources, it should happen before first potential replication point. This will
block the source information throughout the network.
10-48
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Attack Traffic in Multicast Networks
This section looks at how attack traffic is forwarded in unicast and multicast networks.
Unicast provides no implicit protection.
ASM/
Bidir
SSM
Unicast
Attack Traffic from Rogue Sources
to Hosts
ƒ Main reason for Firewalls.
Multicast provides implicit protection:
ƒ SSM:
– No attacks possible from unwanted
sources.
– Traffic stops at first-hop router.
RP
ƒ ASM:
– Sources can attack groups.
– No host specific attacks are possible.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—10-54
In unicast routing, any device can send a packet to another device. There is no implicit
protection of receivers from sources. Firewalls and access control lists (ACLs) can be used to
protect against unwanted traffic.
In multicast routing, source devices do not send traffic to specific devices but to a multicast
group. A receiver in a branch of the network needs to explicitly join a multicast group before
traffic is forwarded to that branch. Multicast protects receivers implicitly against packets from
unknown sources or potential attackers:
„
With Source Specific Multicast (SSM), unknown attacks are not possible because receivers
have to join to a specific host in a specific multicast group. Unwanted traffic will only
reach the first-hop router closest to the source, and then be discarded. This traffic will not
even create state information on the first-hop router.
„
With Any-Source Multicast (ASM) and Bidirectional Multicast (Bidir), an end device will
only receive traffic only when it is joined to group. An attacker can not attack a particular
host explicitly but sends attacks against a multicast group as well as the network.
© 2007 Cisco Systems, Inc.
IP Multicast Design
10-49
Attack Traffic from Sources to Networks
Another type of network attack targets network devices.
PIM-SM
PIM-SM:
Bidir
Attack Traffic from Rogue Sources
to Networks without Receivers
ƒ State attack
– Impacts (*,G) on first-hop router
– Impacts (S, G) on RP
First
Hop
router
Bidir-PIM:
ƒ Not a state attack – just traffic
– Similar to unicast attack on RP
ƒ Uses (*,G/m) towards RP.
RP
– Note: IOS IPv4 multicast may still
creates (*,G) state due to legacy
implementations (except 6500/7600).
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—10-55
Denial of service attacks can attack network infrastructure devices. These attacks are often
referred to as control plane attacks or state attacks, and the aim of the attacker is usually to
increase the amount of multicast state information in routers above a manageable level so the
device experiences extremely slow convergence or crashes. State can have an impact on ASM
and Bidir multicast implementations.
Note
SSM will drop traffic from unknown sources at the first-hop router closest to the source.
For the traditional PIM sparse mode (PIM-SM) networks (also known as ASM networks),
attacks from rogue sources increase the (S,G) and (*,G) creation on the first-hop router and the
RP. The first-hop router sends unicast Register messages to the RP as a (*,G) Join that uses
state. The RP joins to the first-hop router as with a (S, G) join. This state information is
relatively short lived, 260 seconds by default. However, if the attacker is able to generate 100
IGMPv3 (S,G) joins a second, each carrying 10 sources, the amount of state after 260 seconds
would be 260,000 state entries. One way to limit this attack is to limit the rate of Register
messages to the RP.
For Bidir networks, all receiver-less traffic is carried across single route to RP which is a
(*,G/M) route. This attack is similar to a unicast traffic attack to the RP. Due to older
implementations, the receiver-less traffic will create new (*, G) state information except on the
Cisco Catalyst 6500 Series switches and the Cisco 7600 series routers.
10-50
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Attack Traffic from Rogue Receivers
Receivers in the network can also attack network devices.
Attack Traffic from Rogue Receivers
Source(s)
ƒ Attack against content:
– Receive unauthorized content
ƒ Attack against bandwidth:
RP
– Overload network bandwidth
and harms legitimate receivers
ƒ Attack against routers/switches:
Join S1,G1
Join G2
Join S2,G2
– Overload state tables and
increase convergence times
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—10-56
Multicast receivers can create state attacks where there is no equivalent action in unicast
networks. There are three types of receiver attacks:
„
Attack against content. The rogue receiver attempts to gain access to content that they are
not unauthorized to review.
„
Attack against bandwidth. The receiver attempts to overload network bandwidth. This is
typically against shared network bandwidth and is actually an attack against other
receivers.
„
Attack against routers and switches. The receiver tries to create more state information than
the router or switch can handle. Processing the multiple join requests from the receiver can
increase the convergence time of other states or cause the network device to reboot.
© 2007 Cisco Systems, Inc.
IP Multicast Design
10-51
Scoped Addresses
Scoping addresses can provide some architectural security.
Scoped Addresses and TTL Boundaries
Unicast:
INTERNET
ƒ RFC-1918 addresses
ƒ Reuse of host addresses
ƒ Provides “privacy” for hosts
Multicast:
ƒ IPv4: 239.0.0.0 / 8 addresses
– Geographic form of access
control for applications.
– Allows reuse of group
addresses
ƒ TTL threshold
– Uses the ip multicast ttl-threshold
command
© 2007 Cisco Systems, Inc. All rights reserved.
COMPANY
REGION
SITE
SITE
239.192/16
239.192/16
SITE
239.192/16
239.193/16
239.194/16
224.0.1.0 –
238.255.255.255
ARCH v2.0—10-57
Unicast networks have two scopes: public Internet addresses and private site addresses.
RFC-1918 defines the private address ranges for IPv4.
Multicast has multiple scopes both as defined by the Internet Assigned Numbers Authority
(IANA) and as deployed within an organization. IPv4 multicast supports administratively
scoped definitions within 239.0.0.0/8 address range. Organizations can use the site-local
addresses and organization-local addresses as a geographic form of access control for
applications with these local addresses. Routers are configured with ACLs to prevent multicast
traffic in this address range from flowing outside an autonomous system (AS) or any userdefined domain. Within an autonomous system or domain, the limited scope address range can
be further subdivided so that local multicast boundaries can be defined. This subdivision is
called address scoping and allows for address reuse between these smaller domains.
Routers can also configure the time-to-live (TTL) threshold of multicast packets being
forwarded out an interface by using the ip multicast ttl-threshold command in interface
configuration mode. This command allows only packets with a TTL value greater than the
threshold to be forwarded out the interface. One example used is setting the TTL threshold on a
border router to 200, which is a very high value. Since most multicast applications generally set
the TTL value to well below 200, no packets will be forwarded out the interface.
10-52
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Multicast Access Control
One mechanism to secure IP multicast networks is with access controls.
Packet Filter Based Access Control
ip access-group [in | out]
DA = 239.10.244.1
SA = 10.0.0.1
DA = 239.244.244.1
SA = 10.0.1.1
Network
Engineer
E0
Allow just
IPmc traffic from a
well known address range
and to a well known group
range
ip access-list extended source
permit ip host 10.0.0.0 0.255.255.255 239.0.0.0 0.127.255.255
deny
ip any
224.0.0.0 15.255.255.255 log
deny
ip any
any log
interface ethernet0
ip address 10.1.1.1 255.255.255.0
ip access-group source in
ƒ ACL is hardware installed on most platforms.
ƒ It filters before multicast routing, so no state creation is needed.
ƒ Typical use is for ingress traffic.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—10-59
Cisco IOS software supports packet filter based ACLs that can help control traffic in a
multicast network. These ACLs are typically implemented in hardware on most router
platforms. Since the packet based ACL filters traffic is deployed at the network ingress
interface on the data plane before multicast processing, there is no state creation for dropped
traffic.
Although packet filters can also filter on outbound side, protocol filtering is typically preferred
for egress traffic.
The main advantage of this approach is simplicity and clarity. The drawback is having to apply
an ACL to any inbound interface a multicast source might be on including all user or server
subnets.
© 2007 Cisco Systems, Inc.
IP Multicast Design
10-53
Host Receiver Side Access Control
IGMP access groups can be used to provide host receiver side access control.
Host Receiver Side Access Control
ip igmp access-group
ƒ Filters group/channels in IGMP
membership reports
ƒ Controls entries into IGMP cache
225.2.2.2
Report
H2
224.1.1.1
H2
Report
ƒ Deny only effective if protocol = ip
ip access-list extended allowed-multicast-igmp
permit ip any host 225.2.2.2
! Like simple ACL
permit ip 10.0.0.0 0.255.255.255 232.0.0.0 0.255.255.255
deny
ip any any
interface ethernet 0
ip igmp access-group allowed-multicast
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—10-60
Network administrators can use the ip igmp access-group command to filter groups from
IGMP reports by use of a standard access list or to filter sources and groups from IGMPv3
reports by use of an extended access list. This command allows filtering to control allowed
receivers and the groups they join or the (S,G) channels.
When an IGMP extended access list is referenced in the ip igmp access-group command on an
interface, the (S, G) pairs in the permit and deny statements of the extended access list are
matched against the (S,G) pair of the IGMP reports received on the interface. The first part of
the extended access list clause controls the source (multicast sender), and the second part of the
extended access list clause controls the multicast group.
Specifically, if an IGMP report with (S1, S2...Sn, G) is received, first the group (0, G) is
checked against the access list statements. If the group is denied, the entire IGMP report is
denied. If the group is permitted, each individual (S, G) pair is checked against the access list.
Denied sources are taken out of the IGMP report, thereby denying any sources that match the
access list from sending to the group.
The ACL in the figure controls entries into the IGMP cache by allowing IGMP from any host
to join group 225.2.2.2, and from any host in network 10.0.0.0/8 to join groups in the 232.x.x.x
range.
10-54
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
PIM-SM Source Control
A candidate RP router can filter PIM register messages using the ip pim accept-register
command in global configuration mode.
PIM-SM Source Control
ip pim accept-register
RP
Register
Register-Stop
ip pim accept-register list 10
access-list 10 permit 192.16.1.1
Unwanted Sender
Source Traffic
First-hop
ƒ Unknown source traffic hits first-hop router.
ƒ First-hop router creates (S,G) state and sends Register to RP.
ƒ RP rejects Register, sends back a Register-Stop.
ƒ Limited RP-based access control for (S,G) in PIM-SM is provided:
– (S,G) state on first-hop router is still created.
– (S,G) traffic still sent to local receivers.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—10-61
This command is used to prevent unauthorized sources from registering with the RP. If an
unauthorized source sends a register message to the RP, the RP will immediately send back a
register-stop message. The filter can be on the source address in a standard ACL or on the (S,G)
pair in an extended ACL.
This allows for a limited form of centralized source control with PIM-SM. However, it does not
inhibit (S,G) state creation on the first-hop router. Receivers on same first-hop router will still
receive traffic from invalid sources.
© 2007 Cisco Systems, Inc.
IP Multicast Design
10-55
Disabling Multicast Groups
Cisco IOS software supports disabling multicast groups by range for IPv6.
Disabling Multicast Groups
New global commands support selectively enabling
multicast groups:
ƒ ipv6 multicast group-range access-list-name (12.4T)
ƒ ip multicast group-range access-list-name (future)
This command disable all operations for groups denied
by the ACL:
ƒ Drop or ignore group in all control packets
ƒ Do not create state information
ƒ Drop all data packets
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—10-62
The ipv6 multicast group-range access-list-name command in global configuration mode
allows a network administrator to specify an authorized group-range. Multicast protocol actions
and traffic forwarding for unauthorized groups or channels is on all the interfaces in a router is
disabled with this command if the group is denied by the ACL:
„
All control packets are dropped.
„
No state information is created.
„
All data packets are dropped on hardware discarding platforms.
The command is supported in Cisco IOS software release 12.4(4)T for IPv6. Support for IPv4
is planned in the future.
10-56
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Summary
This topic summarizes the key points discussed in this lesson.
Summary
Multicast has additional security considerations as
compared to unicast routing:
ƒ Unlike unicast networks, multicast state grows when sources and
receivers run multicast applications.
ƒ Multicast routing is concerned with the egress packet rate and the
ability to replicate outgoing packets.
ƒ SSM deployments provide the most protection from DoS attacks.
ƒ Multicast scoping allows organizations to use site-local addresses
and organization-local addresses as a geographic form of access
control.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—10-63
Summary (Cont.)
Access control mechanisms help secure multicast
networks:
ƒ Packet filter ACLs deny traffic at the network ingress.
ƒ Host receiver side access control filters channels and groups in
IGMP membership reports.
ƒ The PIM accept register provides a limited form of centralized
source control.
ƒ The IPv6 multicast group-range command provides a simple
way to selectively enable multicast groups.
© 2007 Cisco Systems, Inc. All rights reserved.
© 2007 Cisco Systems, Inc.
ARCH v2.0—10-64
IP Multicast Design
10-57
10-58
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Module Summary
This topic summarizes the key points discussed in this module.
Summary
ƒ Multicast communications allows hosts to send packets to a group
of receivers.
ƒ The three major PIM deployment models are SSM used for oneto-many applications, Bidir PIM used for many-to-many
applications, and PIM-SM used for general purpose applications.
ƒ Multicast security considerations include state information, packet
replication process, the join process, and address scoping.
Access control mechanisms can help secure multicast networks.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—10-66
References
For additional information, refer to these resources:
„
Cisco Systems, Inc. “RST-1261: Introduction to IP Multicast” Networkers 2006
presentation (accessible on a subscription basis) at
http://www.networkersonline.net.
„
Cisco Systems, Inc. “RST-2261: Deploying IP Multicast” Networkers 2006 presentation
(accessible on a subscription basis) at
http://www.networkersonline.net.
„
Cisco Systems, Inc. “RST-2262: Multicast Security” Networkers 2006 presentation
(accessible on a subscription basis) at
http://www.networkersonline.net.
„
Cisco Systems, Inc. IP Multicast Technology Overview at
http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/mcst_sol/mcst_ovr.pdf
„
Cisco Systems, Inc. Bidirectional PIM Deployment Guide at
http://www.cisco.com/application/pdf/en/us/guest/products/ps6592/c1244/cdccont_0900aec
d80310db2.pdf
„
Cisco Systems, Inc. Guidelines for Enterprise IP Multicast Address Allocation at
http://www.cisco.com/application/pdf/en/us/guest/products/ps6592/c1244/cdccont_0900aec
d80310d68.pdf
© 2007 Cisco Systems, Inc.
IP Multicast Design
10--59
10-60
„
Cisco Systems, Inc. “Cisco IOS IP Multicast Configuration Guide, Release 12.4” at
http://www.cisco.com/en/US/products/ps6350/products_configuration_guide_book09186a0
080435b9f.html
„
The Internet Engineering Task Force. “RFC 1112: Host Extensions for IP Multicasting”
http://www.ietf.org/rfc/rfc2328.txt
„
The Internet Engineering Task Force. “RFC 3376: Internet Group Management Protocol,
Version 3”
http://www.ietf.org/rfc/rfc3569.txt
„
The Internet Engineering Task Force. “RFC 3569: An Overview of Source-Specific
Multicast (SSM)”
http://www.ietf.org/rfc/rfc3569.txt
Designing Cisco Network Service Architectures (ARCH) v1.2
Copyright © 2004, Cisco Systems, Inc.
Module Self-Check
Use the questions here to review what you learned in this module. The correct answers and
solutions are found in the Module Self-Check Answer Key.
Q1)
What differentiates IP multicast from other transmission modes? (Source: IP Multicast
Review)
A)
B)
C)
D)
Q2)
What is a benefit of using IP multicast to deliver source traffic to multiple receivers?
(Source: IP Multicast Review)
A)
B)
C)
D)
Q3)
unicasts
multicast routers
RPF
OSPF
SPT
What is one potential drawback to source distribution trees compared to shared
distribution trees? (Source: IP Multicast Review)
A)
B)
C)
D)
Q6)
at the source
at the destination
at routers where the paths to the recipients diverge
at each router included in the path to each recipient
In order for a broadcast to flood packets out all interfaces, except those incoming from
the source, multicast routing utilizes _____. (Source: IP Multicast Review)
A)
B)
C)
D)
E)
Q5)
It guarantees packet delivery.
It reduces network bandwidth consumption.
It is highly efficient for sending single stream application traffic.
It replicates packets at all network devices to enable multiple client requests.
Where in the network are IP multicast packets replicated? (Source: IP Multicast
Review)
A)
B)
C)
D)
Q4)
IP multicast sends packets to a single host.
IP multicast sends packets to a subset of hosts.
IP multicast sends packets to all hosts sequentially.
IP multicast sends packets to all hosts simultaneously.
increased latency
increased memory overhead
sub-optimal path calculations
increased bandwidth utilization
What purpose is served by IGMP in IP multicast? (Source: IP Multicast Review)
A)
B)
C)
D)
© 2007 Cisco Systems, Inc.
IGMP performs the RPF check.
IGMP registers hosts in a multicast group.
IGMP provides reliable multicast transport.
IGMP performs the multicast forwarding function.
IP Multicast Design
10-61
Q7)
What is an SPT in multicast networking? (Chose two.) (Source: IP Multicast Review)
A)
B)
C)
D)
E)
F)
Q8)
In what type of environments would PIM-SSM be efficiently used? (Source: PIM and
RP Considerations)
A)
B)
C)
D)
E)
Q9)
RPs are not needed.
It is also known as PIM-SSM.
Deployments use shared distribution trees.
Deployments use source distribution trees.
It is the traditional form for PIM deployments.
What deployment model does not track (S,G) state? (Source: PIM and RP
Considerations)
A)
B)
C)
D)
E)
10-62
RPs are not needed.
It is also known as PIM-SSM.
Deployments use shared distribution trees.
Deployments use source distribution trees.
It is the traditional form for PIM deployments.
What are three characteristics of Bidir PIM? (Chose three.) (Source: PIM and RP
Considerations)
A)
B)
C)
D)
E)
Q12)
deployments that use shared distribution trees
deployments where switches are used pervasively
deployments where only a few receivers need IP multicast content
one-to-many applications
many-to-many applications
What are three characteristics of ASM? (Chose three.) (Source: PIM and RP
Considerations)
A)
B)
C)
D)
E)
Q11)
deployments that use shared distribution trees
deployments where switches are used pervasively
deployments where only a few receivers need IP multicast content
one-to-many applications
many-to-many applications
In what type of environments would Bidir PIM be efficiently used? (Source: PIM and
RP Considerations)
A)
B)
C)
D)
E)
Q10)
shared path tree
shortest path tree
source distribution tree
shared distribution tree
source path tree
spanning path tree
Anycast RP
ASM
Bidir PIM
PIM-SM
SSM
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Q13)
What are three characteristics of Anycast RP? (Chose three.) (Source: PIM and RP
Considerations)
A)
B)
C)
D)
E)
Q14)
What command causes IP multicast traffic for the two Auto-RP groups to be PIM
dense mode flooded across interfaces operating in PIM sparse mode? (Source: PIM and
RP Considerations)
A)
B)
C)
D)
E)
Q15)
Anycast RP
Auto-RP
BSR
C-RP
DM fallback
MSDP
What two protocol use candidate RPs? (Chose two.) (Source: PIM and RP
Considerations)
A)
B)
C)
D)
E)
F)
Q17)
ip pim sparse-dense-mode
ip pim sparse-dense-mode override 224.0.1.39 - 224.0.1.40
ip pim autorp listener
ip pim dm-fallback
no ip pim dm-fallback
What protocol uses mapping agents? (Source: PIM and RP Considerations)
A)
B)
C)
D)
E)
F)
Q16)
It uses the 224.0.1.39 and 224.0.1.40 group addresses.
It uses MSDP.
It uses a unicast host address with a /32 mask.
It is a technique for configuring a PIM-SM network to provide for fault
tolerance and load sharing within a single multicast domain.
It is a technique for configuring a PIM-SM network to provide for fault
tolerance and load sharing across domains.
Anycast RP
Auto-RP
BSR
C-BSR
DM fallback
MSDP
What is the default value of the SPT-threshold in Cisco routers? (Source: PIM and RP
Considerations)
A)
B)
C)
D)
E)
© 2007 Cisco Systems, Inc.
zero
one
two
four
sixteen
IP Multicast Design
10-63
Q18)
What are three characteristics of multicast state information? (Chose three.) (Source: IP
Multicast Security)
A)
B)
C)
D)
E)
F)
Q19)
Which two deployments are more susceptible to attacks from unknown sources?
(Chose two.) (Source: IP Multicast Security)
A)
B)
C)
D)
E)
Q20)
D)
at the network egress interface on the control plane after multicast processing
at the network egress interface on the data plane after multicast processing
at the network ingress interface on the control plane before multicast
processing
at the network ingress interface on the data plane before multicast processing
What command is used to prevent unauthorized sources from registering with the RP?
(Source: IP Multicast Security)
A)
B)
C)
D)
E)
10-64
ASM
Bidir PIM
PIM-SM RP
RP-Switchover
SSM
How is packet filter based access control typically deployed? (Source: IP Multicast
Security)
A)
B)
C)
Q21)
It does not include the unicast routing state information.
It grows when sources and receivers run multicast applications.
It includes the unicast routing state information.
It only changes when the network topology changes.
State changes do not impact CPU utilization.
State changes impact CPU utilization.
ip igmp accept-rp
ip pim register-rp
ip pim accept-register
ip igmp access-group
ip multicast group-range access-list-name
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Module Self-Check Answer Key
Q1)
B
Q2)
B
Q3)
C
Q4)
C
Q5)
B
Q6)
B
Q7)
B, C
Q8)
D
Q9)
E
Q10)
C, D, E
Q11)
A, C
Q12)
C
Q13)
B, C, D
Q14)
C
Q15)
B
Q16)
B, C
Q17)
A
Q18)
B, C, F
Q19)
A, B
Q20)
D
Q21)
C
© 2007 Cisco Systems, Inc.
IP Multicast Design
10-65
10-66
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Module 11
Voice Over WLAN Design
Overview
Wireless LANs (WLANs) are rapidly becoming pervasive among enterprises. The availability
of wireless voice clients, the introduction of dual-mode (wireless and cellular) smart phones,
and the increased productivity realized by enabling a mobile workforce are moving enterprises
to implement voice over WLANs (VoWLANs). This module looks at requirements for
enterprise VoWLAN. It also looks at site surveys and basic core design principles needed when
deploying a wireless LAN infrastructure to support voice applications. While businesses may
not initially take advantage of voice services, having a network that is capable of supporting the
services for future use is important for protecting the upfront investment in infrastructure and
services.
Module Objectives
Upon completing this module, you will be able to design enterprise solutions for IP telephony,
given enterprise network needs. This ability includes being able to meet these objectives:
„
Describe the Cisco voice-ready architecture for supporting VoWLANs
„
Discuss VoWLAN coverage concerns and RF survey requirements
„
Describe VoWLAN infrastructure considerations
11-2
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Lesson 1
VoWLAN in the Enterprise
Overview
This lesson identifies the drivers for voice over WLAN (VoWLAN) in the enterprise. It also
provides an overview of how voice requirements need to be taken into consideration to create a
voice-ready WLAN.
Objectives
Upon completing this lesson, you will be able to discuss drivers for enterprise VoWLAN
solutions. You will also be able to describe voice requirements are supported in a voice-ready
WLAN. This ability includes being able to meet these objectives:
„
Identify drivers for VoWLAN deployments
„
Identify how voice requirements influence a voice-ready WLAN
VoWLAN Drivers
This topic will discuss drivers for VoWLAN. The wireless network infrastructure includes
access points, antennas, and wireless endpoint devices, including wireless network interface
cards (NICs) and wireless phones such as the Cisco 7921G Wireless IP Phone. The
infrastructure can support various client types such as hardware phones and software phones.
Similar to wired LAN networks, 802.11 WLAN networks enable devices to transmit data,
voice, and video at data rates up to 54 Mbps
Cisco Unified Wireless Network Review
The Cisco Unified Wireless Network incorporates advanced features that elevate a wireless
deployment from a means of efficient data connectivity to a secure, converged communications
network for voice and data applications.
Cisco Unified Wireless Network Review
ƒ Mobility services
ƒ Network management
ƒ Network unification
ƒ Access points
ƒ Client devices
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-4
The Cisco Unified Wireless Network is composed of five interconnected elements that work
together to deliver a unified end-to-end enterprise-class wireless solution. Beginning with a
base of client devices, each element adds capabilities as network needs evolve and grow,
interconnecting with the elements above and below it to create a comprehensive, secure WLAN
solution. These are the five interconnected elements of the Cisco Unified Wireless Network
architecture:
„
11-4
Client devices: More than 90 percent of shipping client devices are certified as Cisco
Compatible supporting Cisco infrastructure equipment’s powerful advanced features.
Secure client devices provide out-of-the-box wireless security through Cisco Compatible
Certified components.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
„
Access points: Dynamically configured access points provide ubiquitous network access in
all environments. Enhanced productivity is supported through plug-and play-with
Lightweight Access Point Protocol (LWAPP). Cisco access points are a proven platform
with a large installed base and market share leadership. All Cisco controller based access
points support mobility services, such as fast secure roaming for voice and location services
for real-time network visibility.
„
Network unification: Integration of the wired and wireless network is critical for unified
network control, scalability, security, and reliability. Seamless functionality is provided
through wireless integration into all major switching and routing platforms, including Cisco
Wireless LAN Controller appliances, Cisco Wireless LAN Controller Modules for
Integrated Services Routers, and Cisco Catalyst 6500 Series Wireless Services Module
(WiSM).
„
World-class network management: The same level of security, scalability, reliability,
ease of deployment, and management for WLANs as for wired LANs is provided through
network management systems such as Cisco Wireless Control System (WCS), which
visualizes and helps manage the air space. Location services are provided with the Cisco
Wireless Location Appliance.
„
Mobility services: Unified mobility services deliver enhanced mobility services, including
advanced security threat detection and mitigation, voice services such as those briefly
discussed in this module, location services, and guest access.
Benefits of the Cisco Unified Wireless Network architecture include ease of deployment and
upgrades, reliable connectivity through dynamic RF management, optimized per-user
performance through user load balancing, guest networking, Layer 2 and 3 roaming, an
embedded wireless intrusion detection system (IDS), location services, voice over IP, lowered
total cost of ownership (TCO), and wired and wireless unification.
An enterprise network can start with the base components of client devices, controller based
access points, and wireless LAN controllers (WLCs). As an organization’s wireless networking
requirements grow, the organization can then add additional elements, such as Cisco WCS and
the Cisco Wireless Location Appliance.
Cisco WCS is an optional network management component that works in conjunction with
Cisco controller based access points and Cisco Wireless LAN Controllers. With Cisco WCS,
network administrators have a single solution for RF prediction, policy provisioning, network
optimization, troubleshooting, user tracking, security monitoring, and WLAN systems
management. Cisco WCS includes tools for WLAN planning and design, RF management,
basic location tracking, intrusion detection system (IDS), and WLAN systems configuration,
monitoring, and management.
The Cisco Wireless Location Appliance integrates with Cisco WCS for enhanced location
tracking of many wireless devices to within a few meters. This appliance also records historical
location information that can be used for location trending, rapid problem resolution, and RF
capacity management.
© 2007, Cisco Systems, Inc.
VoWLAN Design
11-5
VoWLAN Drivers in the Enterprise
There are several drivers for VoWLAN in the enterprise.
VoWLAN Drivers in the Enterprise
ƒ WLANs are pervasive among enterprises.
ƒ VoIP provides a rich set of features..
ƒ VoWLAN can improve productivity and
reduce costs:
– Support single access to enterprise
unified communications.
– Eliminates missed calls.
– Leverages least cost call routing.
– Provides consistent user experience.
Note: Infonetics Research, Inc. projects that
voice will be a driver in 30% of all WLAN sales
by the end of 2007.
© 2007 Cisco Systems, Inc. All rights reserved.
5
ARCH v2.0—11-5
Because WLANs are pervasive among enterprises and there is rich set of features available
with voice over IP (VoIP) deployments, organizations are looking combine these technologies
in VoWLAN to improve productivity and reduce costs. VoWLAN deployments provide
multiple benefits:
„
Enable access to enterprise unified communications supporting one phone number and one
voicemail.
„
Help employees eliminate missed calls by providing mobility within a building or campus
„
Help organizations gain control over mobile communications costs by leveraging least cost
call routing and provides call detail recording
„
Provide a consistent user experience for improved user satisfaction
These factors coupled with the availability of wireless voice clients and the introduction
of dual-mode (wireless and cellular) smart phones are moving enterprises to implement
VoWLANs.
Note
11-6
A report by Infonetics Research, Inc. projects that voice will be a driver in 30% of all WLAN
sales by the end of 2007.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Alternative to VoWLAN: Cell Phones
One alternative to VoWLAN is a cell phone solution.
Alternative to VoWLAN: Cell Phones
Advantages
ƒ Good selection of phones
ƒ Multiple carriers
Challenges
ƒ No access to enterprise voice applicatons
– No access to corporate directory
ƒ Multiple phone numbers and mailboxes
ƒ Security concerns
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-6
Cell phones can support the mobility requirements of VoWLAN. Cell phone solutions currently
have a few advantages as compared to VoWLAN:
„
There is a good selection of cell phones available.
„
There are multiple carriers that can provide cell phone service.
However, there are some disadvantages to cell phone solutions:
„
There is no access to enterprise voice applications such as the corporate directory.
„
Use of a cell phone and an VoIP phone leads to multiple phone numbers and multiple
mailboxes. Productivity may decrease as users support duplicate voice mails retrieval.
„
There may be security concerns with mobile phones that are not managed by the
organization.
Although at this time there is no seamless handoff on a dual mode phone, dual mode smart
phones likely will replace cell phones in the future.
Organizations are now looking at making their WLANs voice-ready for current or future uses
to protect the upfront investment in infrastructure and services.
© 2007, Cisco Systems, Inc.
VoWLAN Design
11-7
Voice-Ready Architecture
This topic discusses a voice-ready architecture.
Voice Service Requirements
ƒ Voice has stringent performance requirements.
ƒ Digitized voice is a sampling of an analog signal:
– Is sensitive to delays during transit.
– End-to-end transit time should be < 150 ms.
ƒ Transit delays cause jitter.
– Use end-to-end QoS to minimize delay and jitter.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-8
Voice services place stringent performance requirements on the entire network. Because
digitized voice is a sampling of verbal communication which is an analog signal, the
transmission of digitized voice is very sensitive to delays during transit. Voice requires a
pervasive deployment, which means that the network needs to have continuous coverage
everywhere a client may roam in order to avoid any dead spots or gaps in coverage that may
cause a call to drop. This pervasive coverage differs from the traditional data-only approach
because data applications are far more tolerant of brief network interruptions.
In order for voice to work correctly over any infrastructure, the end-to-end transit time
(cumulative time encoding the packet, leaving the sending client, traversing the network, then
being decoded at the receiving client) must be less than 150 ms.
Quality of service (QoS) for a VoIP call must be maintained, whether the call is being delivered
to a wired or a wireless endpoint. Issues encountered during transit result in variations in
timing, or the time of arrival, of the received signal in the reconstituted signal is known as jitter.
It is critically important to minimize end-to-end delay and jitter for VoIP packets in order to
provide optimal audio quality. To maintain QoS, establishing priority across the VoWLAN and
the translating the packet priority from wireless to wired infrastructure during transit are critical
requirements.
11-8
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Cisco Voice-Ready Architecture
Voice-ready wireless is an end-to-end solutions approach that addresses the convergence of
VoIP and wireless networks and allows enterprises to flexibly extend the mobility benefits of
wireless networks to their voice communications.
Cisco Voice-Ready Architecture
VoWLAN
Clients
Voice-Ready
WLAN
Unified Wired/
Wireless LAN
Infrastructure
Unified
Communications
and Mobility
Applications
More than an Access Point
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-10
The Cisco voice-ready architecture builds upon the highly-scalable, low total cost of ownership
Cisco Unified Wireless Network. The voice-ready architecture is designed to support pervasive
deployments that are typical of customers with mobile voice applications. Additionally,
innovative features in the solution, such as end-to-end quality of service, and fast secure
roaming backed by a portfolio of access points with enhanced radios, make the Cisco Unified
Wireless Network voice-ready. The Cisco voice-ready architecture has four main components:
„
VoWLAN clients. The clients can be wireless IP phones from Cisco or vendors supporting
Cisco Compatible extensions. The IP Communicator software application on a laptop can
also function as a VoWLAN client.
„
Voice-ready WLAN. The wireless network infrastructure includes access points and
antennas. The voice-ready VLAN provides optimized packet handling in the radio
frequency (RF) network.
„
Unified wired/ wireless LAN infrastructure is used to provide wired and wireless end to
end prioritization and classification of voice. It includes management tools to control delay,
roam time, and packet loss.
„
Cisco Unified Communications and mobility applications support increased call capacity,
higher network availability, and improved performance for all clients.
The infrastructure supports converged voice and data on wired and wireless networks for an
end-to-end intelligent integration.
© 2007, Cisco Systems, Inc.
VoWLAN Design
11-9
Voice Impact on WLANs
There are several design considerations due to the impact of voice on WLANs.
Voice Impact on WLANs
ƒ Coverage requirements and deployment planning
ƒ Network infrastructure and logical subnet design
ƒ Wireless "over-the-air" quality of service (QoS)
ƒ Network security architecture
ƒ VoWLAN client requirements
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-9
WLANs are based on a random access protocol and allow clients to roam freely. The WLAN
infrastructure is a shared medium among all wireless devices. WLANs are typically
implemented with security protocols. Adding voice services to a WLAN has implications in
several design areas, including:
„
RF Coverage requirements and deployment planning
„
Network infrastructure and logical subnet design
„
Wireless "over-the-air" quality of service (QoS)
„
Network security architecture
„
VoWLAN client requirements
These topics are discussed in the “VoWLAN Coverage and RF Survey” and the “VoWLAN
Infrastructure Considerations” lessons.
11-10
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Summary
This topic summarizes the key points discussed in this lesson.
Summary
ƒ Organizations are looking combine WLAN and VoIP technologies
in VoWLANs to improve productivity and reduce costs.
ƒ The Cisco voice-ready architecture is an end-to-end solutions
approach that allows enterprises to flexibly extend the mobility
benefits of wireless networks to their voice communications.
© 2007 Cisco Systems, Inc. All rights reserved.
© 2007, Cisco Systems, Inc.
ARCH v2.0—11-11
VoWLAN Design
11-11
11-12
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Lesson 2
VoWLAN Coverage and RF
Survey
Overview
To deploy a WLAN that is voice-services-ready, the design needs to anticipate the mobile
nature of voice clients and the minimum expectation that calls will not get dropped as users
roam across a building or campus. This means that the network must be deployed pervasively,
with continuous coverage in areas where voice services are planned. This lesson identifies the
methodology and the concepts involved to conduct and document a proper site survey for a
supporting a pervasive voice wireless LAN (VoWLAN).
Objectives
Upon completing this lesson, you will be able to determine customer needs as part of
preparation for designing and deploying a VoWLAN. This ability includes being able to meet
these objectives:
„
Identify enterprise VoWLAN coverage considerations
„
Describe steps for performing and verifying a VoWLAN site survey
Enterprise VoWLAN Coverage Considerations
Voice clients are mobile in nature and expect that calls will not get dropped as users roam
across a building or campus.
Pervasive Coverage
File/Supply
Room
(Large Filing or
Metal Cabinets)
Office
Elevator
Shafts
Test Lab
Break Room
(Microwave Ovens
–2450 Mhz)
Conference
Room
Cubes
Stairwells
(Reinforced
Building Area)
© 2007 Cisco Systems, Inc. All rights reserved.
VIP (CEO)
ARCH v2.0—11-15
This means that the network must be deployed pervasively, with continuous coverage in areas
where voice services are planned. Areas such as main lobbies, employee entrance areas,
parking garages/lots, courtyards, and break/copy/supply/storage/cage rooms will need WLAN
coverage when voice clients are deployed on the campus. Additional consideration should be
given to providing coverage in stairwells, walkways, and elevators, since these are areas where
it is reasonable to conduct a business conversation.
The Cisco Unified Wireless Network provides an extensive product line that satisfies the
requirements for coverage areas, ranging from just a floor of a building to complete campus
coverage, both indoors and outdoors.
Equally important to the satisfaction of end users is ensuring that the proper expectations are set
for voice usage. Many customers believe that the coverage expectations have been established
by the cellular network service available onsite and that the WLAN availability and coverage
should be significantly more pervasive than the cellular benchmark.
Creating predictable service is also important. Users expect that Wi-Fi phones will at a
minimum operate with the same quality as a cellular handset, and optimally as well as a land
line phone. This means that the WLAN will have to minimize interference in order to optimize
call quality. Although many network administrators have already performed RF site surveys for
their initial data WLAN deployments, wireless IP phones have somewhat different roaming
characteristics and RF coverage requirements than data devices.
11-14
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Network administrators must perform a second site survey for voice to prepare for the
performance requirements of wireless IP phones. This second survey gives network
administrators the opportunity to tune the access points to ensure that the wireless IP phones
have enough RF coverage and bandwidth to provide proper voice quality. Some of the factors
to look at in the survey include signal-to-noise ratio, and nonoverlapping channel deployment.
© 2007, Cisco Systems, Inc.
VoWLAN Design
11-15
Signal-to-Noise Ratio
Voice-ready wireless service is concerned about the noise level within a wireless cell.
Signal-to-Noise Ratio
ƒ Signal of -67 dBm or higher
ƒ Packet Error Rate no higher than 1%
ƒ Minimum SNR of 25 dB = -92 dBm noise level
Power (dBm)
RSSI /
Signal
Strength
Signal to
Noise
Ratio
Noise
Level
Time (Seconds)
Adding signal does not always increase SNR
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-17
Noise levels vary from site to site and also within different locations of a site. The noise level
affects the ability of a radio to receive data or voice packets. Noise is defined as a signal that is
not in an IEEE 802.11 Direct Sequence Spread Spectrum (DSSS) format but is in the frequency
range of the configured channel for the access point. The noise can originate from an 802.11
2.4-GHz frequency-hopping radio, a 2.4-GHz or 5 GHz wireless phone, a ham radio, a
microwave oven, or a Bluetooth radio. Signals from a distant out-of-network 802.11b/g or
802.11a radio may also be seen as noise. Any signal that the access point cannot decode is
considered noise.
If the signal strength on a valid packet is higher than the receiver threshold of the access point
radio or the client device radio, the data packet is decoded. The received signal sensitivity value
is measured in dBm, an abbreviation for the power ratio in decibel (dB) of the measured power
referenced to one milliwatt. Most 802.11 radios have a receiver sensitivity value of –94 dBm to
–85 dBm at a data rate of 1 Mbps (the lower the dBm value, the better the receiver sensitivity
of the radio). Radio receiver sensitivity changes with data rates; for example, an access point
radio might have a receiver sensitivity of –94 dBm at 1 Mbps, but the radio sensitivity might be
–84 dBm at 11 Mbps.
The access point discards random data traffic, valid packets that can be decoded but which are
not from clients associated to the access point. Random data traffic can originate from a shared
media or from a client device that is transmitting at a data rate that the access point does not
support.
11-16
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Acceptable SNR values will vary depending on the data rate of the signal.
Recommended SNR Values 2.4 GHz
Data Rate
(Mbps)
Data Cell
VoWLAN Cell
Minimum
Signal
Strength
(dBm)
Minimum
SNR
(dB)
Minimum
Signal
Strength
(dBm)
Minimum
SNR
(dB)
54
-71
25
-56
40
36
-73
18
-58
33
24
-77
12
-62
27
11
-82
10
-67
25
6
-89
8
-74
23
2
-91
6
-76
21
1
-94
4
-79
19
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-18
A high data rate signal will need a larger separation from noise than a lower data rate signal.
Also VoWLAN will require additional signal strength and SNR compared to data only cell
coverage. The figure shows recommended SNR values for data only cells and for VoWLAN
cells.
The goal is to target higher data rates exclusively such as 11 Mbps for 802.11b shown above to
improve data throughput, reduce packet delay, and reduce the size of the RF cell size.
© 2007, Cisco Systems, Inc.
VoWLAN Design
11-17
Example: Single-to-Noise Ratio from
Cisco Aironet Site Survey Utility
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-19
The figure shows the noise level, signal strength, and signal-to-noise (SNR) at a specific
location within a wireless cell as measured by Cisco Aironet Desktop Utility and a Cisco a/b/g
client adapter. The signal strength is –74 dBm, the noise level is –95 dBm, and the SNR is 21
dB.
Since the noise level reported by the Aironet Desktop Utility is –95 dBm and the a/b/g receiver
sensitivity at 11 Mbps is –90 dBm, there is a margin of 5 dB at the receiver. A signal strength
value of –74 dBm less the noise value of –95 dBm equals an SNR of 21 dB as reported by the
Aironet Desktop Utility. The higher the SNR value, the better able are the phones to
communicate with the access point.
11-18
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Non-Overlapping Channels
Because the wireless medium is continuous and shared, all clients that are associated with
access points on the same channel will share the bandwidth available in that channel with
reception power (and therefore data rates) diminishing with distance.
802.11 b/g Radio Channels
Nonoverlapping cells are 22 MHz apart.
ƒ 1, 6, 11 (North America)
ƒ 1, 6, 11 or 2, 7, 12, etc. (Europe and Japan)
ƒ Do not have to be exactly 5 channels apart (i.e. 1, 7, 13).
Channels
1
2
2.402 GHz
© 2007 Cisco Systems, Inc. All rights reserved.
3
4
5
6
22 MHz
7
8
9
10
11
12
13
14
2.484 GHz
ARCH v2.0—11-16
Valid data packets from 802.11b/g or 802.11a radios that are not associated to an access point
are considered data traffic. Those packets are decoded by the access point and client devices
but are discarded. They increase the channel utilization on the access point, and limit the
number of voice clients that can associate. If there are numerous clients in an area, or the
supported data applications require significant bandwidth, adding capacity to the network is
accomplished by using more access points on spectrally exclusive (i.e. non-overlapping)
channels since same-channel interference must be minimized.
Fourteen channels are defined in the IEEE 802.11b DSSS channel set. Each DSSS channel
transmitted is 22 MHz wide, but the channel separation is only 5 MHz. This leads to channel
overlap such that signals from neighboring channels can interfere with each other. In the US, 11
DSSS channels are usable, but only three nonoverlapping channels 25 MHz apart are possible,
such as channels 1, 6, and 11. This channel spacing governs the use and allocation of channels
in a multi-access point environment such as an office or campus. Access points are usually
deployed in cellular fashion within an enterprise where adjacent access points are allocated
nonoverlapping channels. Alternatively, access points can be co-located using channels 1, 6,
and 11 to deliver 33 Mbps bandwidth to a single area, but only 11 Mbps to a single client. The
figure shows three non overlapping channels, 1, 6 and 11, in the total of the 11 channels in the
2.402 to 2.483GHz frequency band. A critical issue for voice services is minimizing
the co-channel interference (clients and access points in the same channel interfering with each
other) and maximizing coverage and capacity.
© 2007, Cisco Systems, Inc.
VoWLAN Design
11-19
Cell Overlap Guidelines
When communicating on one channel, wireless endpoints typically are unaware of traffic and
communication occurring on other nonoverlapping channels.
Cell Overlap Guidelines
ƒ Use a 15-20% cell coverage overlap from each of the adjoining cells.
– Provides almost complete redundancy throughout the cell.
The radius
of the cell
should be
-67 dBm.
Yellow
c
Channel 1Yellow
Green
-86dBm
Purple
Purple
Channel 6Purple
Channel
11-Green
The separation of same
channel cells should be
19 dBm.
-67dBm
Yellow
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-20
Access point coverage should be deployed so that minimal or no overlap occurs between access
points configured with the same channel. However, proper access point deployment and
coverage on nonoverlapping channels requires an overlap of 15 to 20 percent from adjoining
cells. This amount of overlap ensures smooth roaming for wireless voice endpoints as they
move between access point coverage cells and provides a near-complete redundancy
throughout the cell. Overlap of less than 15 to 20 percent can result in slower roaming times
and poor voice quality, while overlap of more than 15 to 20 percent can result in too frequent or
constant roaming.
The size of a voice-ready cell is not defined in traditional measurements such as feet or meters,
instead the unit of measurement is the strength or absolute power of the signal. For an ideal
voice-ready wireless cell size, the radius or size of each cell should be -67 dBm. This power
level can be achieved either in very small physical areas or in cells that are quite large,
depending on the RF characteristics of the environment. Separation of 19dBm for the same
channel cells is recommended. The figure shows the recommended cell characteristics for a
typical voice deployment.
In a pervasive network, maintaining this policy of non-overlapping channels requires careful
planning to ensure that the network is prepared to support voice services. In general, for office
and cubical environments, a convenient guideline is to have a single cell that covers
approximately 3000 square feet.
11-20
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Multi-Floor Concerns
2nd Floor
Channel 1
Channel 6
1st Floor
Channel 11
Channel 11
Channel 1
© 2007 Cisco Systems, Inc. All rights reserved.
Channel 6
ARCH v2.0—11-21
Deploying wireless devices in a multi-story building such as an office high-rise or hospital
introduces a third-dimension to wireless access point and channel coverage planning. The 2.4
GHz wave form of 802.11b/g can pass through floors and ceilings as well as walls. For this
reason, not only is it important to consider overlapping cells or channels on the same floor, but
it is also necessary to consider channel overlap between adjacent floors. With only three
channels, proper overlap can be achieved only through careful three-dimensional planning.
The RF coverage is mostly dependant on the access point transmitter power and antenna type
and it’s associated characteristics of gain and directional beam. The above example would
result from omni antennas.
© 2007, Cisco Systems, Inc.
VoWLAN Design
11-21
802.11a Radio Channels
802.11a wireless networks currently support up to twelve nonoverlapping channels.
802.11a Radio Channels
Channel
GHz
Frequency
Channel
GHz
Frequency
36
5.180
60
5.300
40
5.200
64
5.320
44
5.220
149
5.745
48
5.240
153
5.765
52
5.260
158
5.785
56
5.280
161
5.805
ƒ Nonoverlapping cells are 20 MHz apart.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-22
Currently, the majority of enterprises have implemented 802.11b and 802.11g for VoWLAN
deployment, due to their compatibility and the near ubiquity of those standards in various client
devices. More recent deployments are using 802.11a based on its ability to support 12
nonoverlapping channels which is significantly more than the 3 nonoverlapping channels that
801.11b/g deployments support.
11-22
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
802.11a Channel Reuse Design
40
36
161
60
48
153
48
157
64
36
56
153
149
36
161
161
64
36
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-23
The figure illustrates a possible channel deployment of 802.11a products on a floor. The cells
are easier to deploy then 802.11b.g because there are twelve different channels to work with.
Generally the design should provide as much separation as possible. It is recommended that
neighboring cells not be placed on neighboring frequencies or adjacent frequencies. For
example, in the figure there is either a separation of one channel between cells or a separation
of two cells between near channels
© 2007, Cisco Systems, Inc.
VoWLAN Design
11-23
The future architectural direction for VoWLAN is moving towards 802.11a voice solutions.
Advantages to 802.11a for VoWLAN
ƒ A significantly greater number of channels are available with
802.11a.
– 802.11a access point radios can support 14 simultaneous calls.
ƒ The 5GHz spectrum does not suffer as much from RF interference.
ƒ Shorter ranges on the higher frequency radios help prevent floor to
floor bleed-through of the signal.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-24
There are notable advantages of deploying 802.11a for voice and 802.11b/g for data:
11-24
„
A significantly greater number of channels are available for higher density deployments.
With more channels and a higher approximate throughput, 802.11a access point radios can
support 14 simultaneous calls.
„
The 5GHz spectrum does not suffer from as much interference from devices such as
cordless phones and Bluetooth devices.
„
Since the range on the higher frequency radios are generally shorter, the signals will not
travel through walls as well as the lower frequency radios. This feature helps prevent floor
to floor bleed-through of the signal.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
General Recommendations for VoWLANs
This topic discusses general recommendations in VoWLAN designs. A site survey is needed to
measure these values.
General Recommendations for VoWLAN
ƒ Number of phones used in an area determines number of access
points needed.
– Smaller cells with less transmit power use more access points
and support more calls in a given coverage area.
– 802.11a access points support more calls than 802.11b/g
access points with less RF interference.
ƒ Designs should at minimum use 2 access points on
nonoverlapping frequency channels.
ƒ Signal strength will vary with supported data rate:
– 11 or 12 Mbps: use greater than -67 dBm at all times
– 54 Mbps: use greater than -56 dBm at all times
ƒ Channel utilization QBSS load per access point should be less
than 45%.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-25
The first step in developing a VoWLAN design is to define and document what coverage areas
will be established and the number of phones to be used in the areas. The design scope should
be developed with the target user community so that the appropriate network infrastructure is
deployed. The number of phones used in a given area helps determine the transmit power of the
clients and access point. The transmit power can be decreased in order to create smaller
coverage cells, which increases the number of access points and the number of calls supported
in a given floor space. In addition, 802.11a access points can support more calls than 802.11b/g
access points.
Cisco recommends that a minimum design should use 2 access points on nonoverlapping
channels with 15 to 20% coverage overlap.
The received signal strength indication (RSSI) will vary with the supported data rate:
„
For data rates of 11 Mbps, the RSSI should be greater than -67 dBm. An access point data
rate configuration of 11 Mbps minimum for VoWLAN cells is recommended.
„
For data rates of 54 Mbps, the RSSI should be greater than -56 dBm
The channel utilization QoS Basis Service Set (QBSS) load per access point should be less than
45 percent. The QBSS load represents the percentage of time that the channel is in use by the
access point. This channel utilization provides for smoother roaming and a backup access point
if one of the access points suddenly becomes unavailable or busy.
© 2007, Cisco Systems, Inc.
VoWLAN Design
11-25
General Recommendations for VoWLAN
(Cont.)
ƒ PER should be no higher than 1%.
ƒ Transmit power value on the access point should be the same as
on the IP phones.
ƒ All access points should use antenna diversity.
ƒ Call loading varies by access point type:
– Allow no more than seven G.711 or eight G.729 concurrent
phone calls on 802.11b/g access point radios.
– Allow no more than fourteen G.711 concurrent phone calls on
802.11a access point radios.
ƒ Load-balancing access points can support high-usage areas.
– Overlapped BSSs or access points sharing the same RF
channel reduce the number of concurrent calls.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-26
The network should maintain a Packet Error Rate (PER) of no higher than 1 percent (or a
success rate of 99 percent). TCP performance and VoIP calls can suffer substantially when
packet error rates increase beyond a value of about 1%.
The design should use the same transmit power on the access point and on the IP phones. If the
transmit power of the access points varies, set the transmit power of the phones to the highest
transmit power of the access points.
Note
If enabled on the access point and supported by the WLAN device, Dynamic Transmit
Power Control (DTPC) allows the access point to broadcast its transmit power, and clients
can automatically configure themselves to that power while associated with that access
point.
All access point should use antenna diversity. The purpose of diversity is to provide the best
possible throughput by reducing the number of packets that are missed or retried which is
particularly important to voice. With antenna diversity, the access point samples the radio
signal from two integrated antenna ports and chooses a preferred antenna. This diversity creates
robustness where there is multipath distortion. Some WLAN phones such as the Cisco Unified
Wireless IP Phone 7921G support antenna diversity.
The maximum number of phones supported per access point depends on the calling patterns of
individual users and the access point type. Currently, a recommended call loading for
802.11b/g is 7 active voice calls per access point using the voice encoding G.711 codec or 8
active calls using G.729 codec. This number is based on simultaneous requirements for data
clients and quality voice calls with current data rates and packet sizes. Beyond that number of
current calls, when excessive background data is present, the voice quality of all calls becomes
unacceptable. In comparison, 802.11a access point radios can support 14 active voice calls
using the G.711 codec.
11-26
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Channel and modulation type determine the number of concurrent calls. If more concurrent
phone calls are needed in a high-usage area, plan to have load-balancing access points available
during the site survey. Using overlapped basic service sets (BSSs) or access points sharing the
same RF channel reduce the number of concurrent phone calls per access point.
© 2007, Cisco Systems, Inc.
VoWLAN Design
11-27
VoWLAN Site Survey
A well-executed site survey is a required first step to building a robust, voice-ready wireless
network. This topic describes steps for performing a VoWLAN site survey.
RF Site Survey Process
1. Define customer requirements.
2. Identify coverage areas and user density.
3. Determine preliminary access point locations.
4. Perform the actual surveying.
5. Document the findings.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-28
An RF site survey is the first step in the design and deployment of a wireless network and the
most important step to ensure desired operation. When building a network designed to support
voice services, the site survey and implementation steps assume even greater importance due to
the more stringent network and coverage requirements of VoIP. The goal of any site survey
should be to gain a total view of the characteristics of the radio frequency (RF) environment
into which the wireless network will be deployed. Unlicensed frequencies (2.4-GHz and 5GHz, especially the 2.4-GHz) can be "noisy" environments, with microwave ovens to radar
systems to Bluetooth vying for air time. With the advent of emerging RF technologies such as
sensor networks, this trend will continue.
The are several typical steps in an RF site survey:
1. Define customer requirements in terms of devices to support, sites where wireless devices
will be located, and service levels expected. Peak requirements such as support for
conference rooms should also be defined.
2. Obtain a facility diagram to identify the potential RF obstacles. Based on the customer
requirements, identify planned wireless coverage areas. Visually inspect the facility to look
for potential barriers to the propagation of RF signals, such as metal racks, elevator shafts,
and stairwells. Identify user areas that may be intensively used, such as conference rooms,
and areas that may only be used for voice, such as stairwells.
3. Determine preliminary access point locations. These locations include the power and wired
network access, cell coverage and overlap, channel selection, and mounting locations and
antenna.
11-28
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
4. Perform the actual surveying to verify the access point location. Make sure to use the same
access point model for the survey that is in use or that will be used in production. While the
survey is being performed, relocate access points as needed and retest.
5. Document the findings. Record the locations and log signal readings as well as data rates at
outer boundaries.
The site survey should provide a precise view into what other RF activity is present.
Cognio: Reporting Non-802.11 and
802.11 Devices
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-29
A clear view of the RF domain can help mitigate potential sources of interference. A spectrum
analysis tool such as Cognio Spectrum Expert can provide analysis to classify the interference,
determine the impact of the interference on the Wi-Fi network, and enable the administrator to
physically locate the source of interference and take action. The site survey should also identify
areas within the deployment that may require additional capacity due to a concentration of
users or likelihood of co-channel interference.
A site survey should be conducted using the same frequency plan intended for the actual
deployment. This provides a more accurate estimate of how a particular channel at a particular
location will react to the interference and multipath. The site survey should be conducted with
the voice client that will be deployed; each client has a unique RF performance, so different
clients will yield different results. The same is true for the radios and external or internal
antennas in the infrastructure. In summary, access point and client selection should be finalized
prior to the site survey. As new client devices are added, a periodic update to the site survey is a
proactive step to ensure the RF network is optimized.
It is also advisable to conduct several site surveys, varying the times and days to ensure that a
comprehensive view of the RF domain is obtained. RF activity can be variable and depends on
many factors, including employee activity. The site survey should identify sources of RF
interference and variability in RF patterns due to physical building changes (e.g. movement of
machinery, elevator shafts) and employee movements (e.g. weekly all-hands meetings).
© 2007, Cisco Systems, Inc.
VoWLAN Design
11-29
Cisco WCS Deployment Planning Tool
The Cisco Unified Wireless Network integrates Radio Resource Management software, which
works together with the integrated network planning and design features in the Cisco Wireless
Control System (WCS).
Determining Preliminary Access Point
Locations
Default Access Point Placement
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-30
Cisco WCS provides integrated RF prediction tools that can be used to create a detailed
wireless LAN design, including access point placement, configuration, and
performance/coverage estimates. IT staff can import real floor plans into Cisco WCS and
assign RF characteristics to building components to increase design accuracy. The resulting
map can help provide a starting point for quantity and location of access points during a site
survey and initial estimates on quantity of access points. The final site survey will adjust the
actual number and location of access points and associated antennas.
The WCS deployment planning tool is ideal for general open space office environments. For
challenging RF environments such as those found in hospitals and manufacturing plants, Cisco
recommends specialized survey services. In addition, for manual verification of the wireless
network, the Cisco Unified Wireless IP Phone 7920 and the Cisco Unified Wireless IP Phone
7921G integrate site survey tools to enable the IT manager to display a list of access points that
are in range. These tools are useful for validating and troubleshooting specific problem areas.
11-30
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Access Point Location
The location of access points is the most important characteristic in making the network ready
for voice services.
Larger Cells Support Fewer Calls
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-31
The traditional method of access point deployments recommends deploying access points for
greatest range to support data. This approach is limited in the number of voice calls that can be
supported. Other issues result with large cell coverage areas such as down shift of data rate of
VoWLAN clients when reaching the outer end of the coverage cell. Even though the VoWLAN
traffic might have been designed for high data rates, the actual call is receiving far less
throughput due to weak signal causing the down shift in data rate. An increased cell coverage
area increases the chance of RF interference between the access points and its associated
clients.
© 2007, Cisco Systems, Inc.
VoWLAN Design
11-31
Traditional Small Cell Deployment
The voice-services-ready approach recommends deploying for density by implementing as
many access points as possible to cover a given area without creating excessive interference by
using smaller cell sizes.
Smaller Cells Support More Calls
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-32
Smaller, overlapping cells increase average capacity, and provide higher availability in the
event of an access point failure. The cell size is estimated based on the requirements for
VoWLAN phone call capacities. In dense deployments with many access points, the transmit
power of each access point is lowered so as to limit co-channel interference with neighboring
access points. The design should plan for the antennas needed and transmit powers required for
the access points within the site.
Note
It is a good idea to keep the transmit power of the access point and the phone at the same
level in order to avoid one-way audio occurrences, which are a result of a mismatch
between the reach of the signal.
As a guideline and starting point for site surveys, in a voice-ready WLAN, access points should
be deployed approximately one every 3000 square feet, as opposed to 5000 square feet used for
data-only networks. This level of density helps ensure that voice services have the necessary
RF coverage redundancy and throughput required to provide optimal service capacity. There
still should be a site survey to maximize coverage and minimize interference.
11-32
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Alternative Design: Perimeter and Center Deployment
This alternate deployment model places access points with directional antennas around the
perimeter of the floor. It uses staggered access points with omni-directional antennas in the
center of the floor for more complete coverage and greater redundancy to facilitate location
tracking in addition to VoWLAN.
Alterative Design: Perimeter and Center
Deployment
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-33
This deployment requires specific placement of access points during the site survey. A goal for
access point placement is to allow each location on the floor to be able to associate with at least
three access. This alternative access point deployment facilitates location tracking when
combined with the Cisco Wireless Location Appliance along with WCS for visual maps and
reports. The Cisco Wireless Location Appliance performs location computations based on the
RSSI information received from the Cisco wireless LAN controllers.
Once site floor plans and access points are added to the appliance, RF predictions and
heat maps can be generated to graphically display the location of devices on site floor
plans. Cisco WCS Location displays its location information visually, which provides
an immediate location application for customers who want to enhance their RF capacity
management, utilize location based security, and have asset visibility for WLAN
devices.
© 2007, Cisco Systems, Inc.
VoWLAN Design
11-33
Conducting the RF Survey for VoWLAN
After the requirements are defined, the coverage areas are identified, and the preliminary
VoWLAN access point locations are defined, the next step is to conduct the actual RF survey.
Conducting the RF Survey for VoWLAN
Look for:
ƒ Areas to be filled in with additional antennas
ƒ Changes to existing data rate and transmit power settings
ƒ Possible changes to the antenna types
ƒ Impact of multi-floor coverage
ƒ Requirements to survey without an installed network
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-34
When surveying with an existing WLAN or VoWLAN, you should expect that there will be
areas to be filled in and changes will be made to existing data rate and transmit power settings.
You should plan on possible changes to the antenna types. At a multi-floor site, the survey of
the coverage should also include the floor above and below. When doing a manual survey,
record the cell edges of the current floor and then use your survey tool on other floors to
measure and record the signal levels. When doing an automated survey, be sure to include the
access point on the floors above and below while completing the walk-through survey.
When you survey a site without an installed 802.11 network, plan to use two or three access
points to measure cell coverage and cell overlap. For example, the cell edge for the Cisco
Unified Wireless IP Phone 7920 at the 11-Mbps data rate is -67 dBm. The signal strength at the
edge of that cell needs to be 19 dB weaker than the signal from the next cell on the same
channel. That means at the -67 dBm edge of the cell, the next cell on the same channel should
measure -86 dBm.
11-34
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Survey Documentation
After completing the RF survey, you should end with a documented plan for the VoWLAN
infrastructure.
Survey Documentation
ƒ Document antenna placement and types.
ƒ Document coverage patterns and heat maps.
ƒ Verify coverage with a two voice conversation walk around of all
areas.
– Test with known interferences operational.
– Document call results from an analytical tool.
ƒ Do a coverage area call capacity test.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-35
The survey documentation should include the following information:
„
Documented antenna placement and types informational for final implementation.
„
Documented coverage patterns and heat maps for base line data.
„
Verification information on coverage based on at least a two voice conversation walk
around of all areas. The test should be conducted with known interference sources
operational. It is appropriate to document the call results from an analytical tool.
„
Documented coverage area call capacity test results for base line date. You can have seven
users begin by making phone calls in a given area, and then move apart while placing new
calls. You should verify voice quality during this process.
After conducting an RF site survey and configuring the access points and the phones, it is
crucial to conduct verification tests to ensure that everything works as desired. These tests
should be performed throughout the VoWLAN coverage area. Tests may include verify phone
association with the appropriate access point, or that calls can be placed successfully from the
VoWLAN IP phone with acceptable voice quality.
© 2007, Cisco Systems, Inc.
VoWLAN Design
11-35
VoWLAN Steps to Success
VoWLAN deployments are supported by the partner Cisco Steps to Success program. Cisco
partners need both Advanced Unified Communications and Advanced Wireless specializations
to be authorized to resell Cisco VoWLAN phones.
VoWLAN Steps to Success
•
•
•
•
•
VoWLAN Configuration Checklist
VoWLAN Design Checklist
VoWLAN High Level Design
7920 Site Survey Guide
7920 Design and Deployment Guide
Located at:
cisco.com/go/stepstosuccess
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-36
VoWLAN coverage and capacity can vary by deployment due to factors such as physical
access point placement, building materials, antenna selection, and the type of clients used. In
addition, environmental factors such as microwave ovens and cordless analog phones can also
cause interference that may impact VoWLAN performance. The Steps to Success program
provides important templates and tools to assist partners in the proper planning and
implementation of WLAN and VoWLAN installations:
„
Cisco 7920 Wireless IP Phone Design and Deployment Guide - This document provides
design and deployment considerations and guidelines for implementing wireless Cisco IP
telephony solutions based on Cisco Service-Oriented Network Architecture (SONA).
„
Cisco VoWLAN Site Survey Deliverable - This document provides a checklist of all
items that need to be considered prior to a network implementation.
„
VoWLAN Configuration Checklist - This document provides instructions to help partner
apply pertinent configuration information regarding a VoWLAN solution.
„
VoWLAN Design Checklist - This document provides a checklist template to help
partners apply pertinent design information regarding a VoWLAN solution.
„
Voice over Wireless LAN High Level Design for the Cisco VoWLAN Phone - This
document provides required specifications for availability, capacity, and security that will
meet the defined service requirements.
These tools help minimize the chance for improperly or insufficiently designed VoWLAN. As
part of the program, the assessment to quality VoWLAN team reviews each order to ensure that
the proposed solution and partner meet the published and most current Cisco VoWLAN
11-36
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
standards. The team may also help identify potential problem areas and suggest solutions and
assign resources as appropriate.
© 2007, Cisco Systems, Inc.
VoWLAN Design
11-37
Summary
This topic summarizes the key points discussed in this lesson.
Summary
ƒ Enterprise VoWLANs expect pervasive coverage, appropriate
SNR, and 20% coverage overlap of nonoverlapping frequency
channels to support the mobile nature of voice clients and the
minimum expectation that calls will not get dropped as users roam
across a building or campus.
ƒ A well-executed site survey is a first step to building a robust,
voice-ready wireless network. VoWLANs use dense deployment
of access points with smaller cell size to increase average
capacity and provide higher availability. VoWLAN deployments
are supported by the partner Cisco Steps to Success program.
© 2007 Cisco Systems, Inc. All rights reserved.
11-38
Designing Cisco Network Service Architectures (ARCH) v2.0
ARCH v2.0—11-37
© 2007 Cisco Systems, Inc.
Lesson 3
VoWLAN Infrastructure
Considerations
Overview
This lesson identifies the special requirements to support voice in a WLAN. It discusses how
voice requirements need to be taken into consideration to create a voice over WLAN
(VoWLAN) deployment.
Objectives
Upon completing this lesson, you will be able to the unique requirements voice service imposes
on a WLAN deployment. This ability includes being able to meet these objectives:
„
Describe the voice requirements for roaming in a VoWLAN
„
Describe the voice requirements for Quality of Service (QoS) in a VoWLAN
„
Describe the voice requirements for Security in a VoWLAN
„
Describe the requirements for intelligent clients in a VoWLAN
Voice Specific Infrastructure Considerations
Voice support places unique requirements on the WLAN.
Voice Specific Infrastructure
Considerations
ƒ Roaming
ƒ Quality of Service
ƒ Security
ƒ Intelligent Clients
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-41
There are several voice specific requirements to consider when implementing a VoWLAN:
„
Roaming. Voice calls need the ability to maintain network connectivity while the client is
physically moving and removes its association from one access point and reassociates to
another. Voice calls typically move more often than a data only client.
„
Quality of Service (QoS). QoS is essential to ensure that voice traffic receives timely and
reliable treatment with low delay, low jitter, and little or no packet loss on the network.
QoS also includes call admission control (CAC) to police the call capacity on a peraccess-point basis.
„
Security. Wireless IP telephony networks require a carefully planned security
implementation to ensure that the telephony network operates properly and that voice
traffic is secure.
„
Intelligent Clients. A voice-ready WLAN requires an intelligent client capable of
supporting the voice-ready Cisco infrastructure functions for enterprise roaming, QoS,
CAC, and security.
The Cisco Unified Wireless Network supports all these requirements through software
capabilities and technological enhancements in both the infrastructure and in Cisco Compatible
clients.
These capabilities and enhancements are discussed in the rest of this lesson.
11-40
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Roaming
Roaming is integral to voice services on wireless networks.
VoWLAN Roaming
ƒ Three types:
– Intracontroller
– Layer 2
– Layer 3
ƒ Cisco Centralized Key
Management supports
authenticated clients
– Need software
release 4.0.217 or
later on WLCs
Intracontroller
Roam
Layer 3
Roam,
Layer 2
Roam
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-43
One of the obvious benefits of WLAN voice clients is the ability of the user to move from place
to place within the enterprise campus while having a conversation. A wireless voice client must
be able to maintain its association from one access point to another securely and with as little
latency as possible. It is therefore important to understand roaming options:
„
Intracontroller Roaming. When the wireless client moves its association from one access
point to another on the same wireless LAN controller (WLC), the WLC simply updates the
client database with the new associated access point. If necessary, new security context and
associations are established as well. With this roaming type, an IP address refresh is not
needed.
„
Layer 2 Intercontroller Roaming: Layer 2 roaming occurs when the client traffic is
bridged to the same IP subnet provisioned through the LAN interfaces on both WLCs.
„
Layer 3 Intercontroller Roaming: Layer 3 roaming occurs when the client associates to
an access point on a different WLC and the traffic is bridged to a different subnet.
WLAN clients are always reauthenticated by the system in some way on a roam. This process
is necessary to protect against client spoofing. With VoWLANs, Cisco Centralized Key
Management enables authenticated client devices to roam securely from one access point to
another without any perceptible delay during reassociation.
Note
© 2007, Cisco Systems, Inc.
The Cisco Unified Wireless IP Phone 7921G and Cisco Unified Wireless IP Phone 7920
support Cisco Centralized Key Management but not can use proactive key caching (PKC) at
this time. WLCs with a software release 4.0.217 or later also support Cisco Centralized Key
Management.
VoWLAN Design
11-41
With the support of Cisco Centralized Key Management protocol, the wireless IP phone is able
to negotiate the handoff from one access point to another more easily. During the roaming
process, the phone must scan for the nearby access points, determine which access point can
provide the best service, and then reassociate with the new access point. When implementing
stronger authentication methods, such as Wi-Fi Protected Access (WPA) and Extensible
Authentication Protocol (EAP), the number of information exchanges increases and causes
more delay during roaming. To avoid additional delays, use Cisco Centralized Key
Management to manage authentication.
Note
11-42
This course discusses roaming within the enterprise frame work. Handoffs or roaming for
dual mode clients between a cellular wireless network and an enterprise WLAN is not
covered.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Layer 2 Intercontroller Roaming
The VoWLAN design can support intercontroller Layer 2 roaming.
Layer 2 Intercontroller Roaming
WLC-2
ƒ Traffic on same IP subnet
ƒ Client database entry moved
to new WLC
ƒ Reauthenticated and new
security session established
as needed
ƒ No IP address refresh needed
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-44
The figure illustrates an intercontroller Layer 2 roam. A Layer 2 roam occurs when the client
traffic is bridged to the same IP subnet provisioned through the LAN interfaces on both WLCs.
When the client reassociates to an access point connected to a new WLC, the new WLC
exchanges mobility messages with the original WLC, and the client database entry is moved to
the new WLC. New security context and associations are established if necessary, and the
client database entry is updated for the new access point. With Layer 2 intercontroller roaming,
an IP address refresh is not needed. This process is transparent to the end user.
Note
Both forms of intercontroller roaming require the controllers to be in the same mobility group.
When the wireless client moves its association from one access point to another, the controllers
update the client database with the newly associated access point. If necessary, new security
context and associations are established as well. This capability coupled with Cisco Centralized
Key Management helps ensure that time-sensitive applications, such as VoIP, can be fully
mobile and secure with minimal roaming latency. With Lightweight Access Point Protocol
(LWAPP)-enabled Cisco access points configured with a controller, it is possible for a client to
roam from an access point attached to one controller to an access point attached to a second
controller. With intercontroller roaming, the infrastructure must maintain these same roaming
characteristics. The Cisco Unified Wireless Network employs a Mobility Messaging Exchange
protocol that helps enable seamless roaming across physically separate controllers. When the
client associates to an access point joined to a new controller, the new controller exchanges
mobility messages with the original controller, and the client database entry is moved to the
new controller. New security contexts and associations are established if necessary, and the
© 2007, Cisco Systems, Inc.
VoWLAN Design
11-43
client database entry is updated for the new access point. This process, as well as the interaccess point handoff, is transparent to the user
Layer 3 Intercontroller Roaming
In cases where Layer 2 VLAN configuration is difficult, it is highly recommended that the
capability to roam be designed to operate across Layer 3 subnets.
Layer 3 Intercontroller Roaming
WLC-2
ƒ New WLC uses different
subnet; client IP address
does not change
© 2007 Cisco Systems, Inc. All rights reserved.
ƒ Original WLC tagged
as “anchor”
ƒ Client database entry
copied to new WLC,
tagged as “foreign”
ƒ Asymmetric traffic path
ARCH v2.0—11-45
This design eliminates the need to configure Layer 2 VLANs that extend across the entire
enterprise, and reduces the cost of the WLAN infrastructure. To do this, Cisco enables Layer 3
mobility through the use of mobility groups, which provide the mechanism for pooling
resources together to facilitate this desired client behavior. A mobility group does more than
just define the RF connectivity of the client. It defines the infrastructure resources and their
connectivity to each other. If a client needs to seamlessly roam from one location to another,
even across IP subnets, the resources in those locations need to be in the same defined mobility
group.
When the client reassociates to an access point connected to a new WLC, the new WLC
exchanges mobility messages with the original WLC. In this case, instead of moving the client
entry to the client database of the new controller, the original WLC marks the client with an
“anchor” entry in its own client database. The database entry is copied to the new controller
client database, and marked with a “foreign” entry in the new WLC. Security credentials and
context are reestablished if necessary. The roam is still transparent to the wireless client, and
the wireless client maintains its original IP address.
After a Layer 3 roam, the data transferred to and from the wireless client flows in an
asymmetric traffic path. Traffic from the client to the network is forwarded directly into the
network by the foreign WLC. Traffic to the client arrives at the anchor WLC, which forwards
the traffic to the foreign WLC in an Ethernet-in-IP (EtherIP) tunnel. The foreign WLC then
forwards the data to the client. If a wireless client roams to a new foreign WLC, the client
11-44
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
database entry is moved from the original foreign WLC to the new foreign WLC, but the
original anchor WLC is always maintained.
To enable mobility groups, the administrator simply defines which physical locations should be
included. As a general guideline, a single mobility group should encompass an area that covers
80 to 90 percent of user roaming patterns, because clients cannot seamlessly roam across
mobility groups. This means that prior to enabling mobility groups, the deployment team must
have a good understanding of how users move throughout the building and incorporate this into
the creation of each mobility group.
© 2007, Cisco Systems, Inc.
VoWLAN Design
11-45
Enhanced Neighbor Lists
The Cisco voice-ready architecture can use enhanced neighbor lists to improve roaming.
Enhanced Neighbor Lists
ƒ Clients are classified with a roaming type.
ƒ Network parameters are distributed to clients in a neighbor list:
– Authorized access points nearby
– RF parameters of nearby access points
– RF measurements at edge of cell
– Capacity utilization on nearby access points
ƒ Clients select access point based on capacity and network
parameters:
– Clients receive the best audio quality.
ƒ Audio gaps in roams is minimized.
– Overall network capacity is increased through load balancing.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-46
Typically handsets will continually scan the access points in the neighbor list to stay associated
with the best access point. The Cisco VoWLAN solution has the ability to classify clients based
on roaming type and have the clients participate in the roaming process based on information
gathered from the infrastructure.
Examples of enhanced roaming classifications are ‘fast-roam’, ’slow roam’, and ‘a/b/g only’.
The information gathered from the network infrastructure is provided in the form of neighbor
lists. The access points provide to the client a list of neighboring access points that have the
ability to service the client based on the client’s classification. The enhanced neighbor lists
contains information that helps the client make association decisions between potential access
points:
„
Authorized access points nearby
„
RF parameters of nearby access points
„
RF measurements at edge of cell
„
Capacity utilization on nearby access points
Based on the neighbor information, the client can preemptively decide to associate with an
access point with sufficient capacity and RF parameters. Based on the client classification, if
the access point has the ability to service the client, association will occur.
This intelligent roaming process enables the clients to associate to the access point that will
provide them the best audio quality and also helps minimize or eliminate audio gaps in roams.
Overall network capacity is increased through load balancing.
11-46
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
QoS Considerations
QoS is essential to ensure that voice traffic receives timely and reliable treatment with low
delay, low jitter, and little or no packet loss on the network.
End-to-End QoS
802.11e
DSCP
DSCP
Payload
LWAPP Encapsulated
DSCP
Payload
802.1p
DSCP
LWAPP Tunnels
Payload
Si
WLAN Controller
Ethernet Switch
AP
802.11e
DSCP
Payload
802.1p
DSCP
LWAPP Encapsulated
DSCP
802.1p
DSCP
Payload
Payload
ƒ Separate voice and data VLANs are used.
ƒ Over the air packets to the access point are policed.
ƒ Edge switches trust the QoS marking of the packets.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-48
Separate voice and data VLANs can support different security features as well as prioritizing
voice traffic so that it can be dealt with using minimal delay characteristics. As a start,
separating traffic by VLAN and using the QoS profiles for traffic reduces the chance of data
clients crowding the voice WLAN and causing unnecessary traffic overhead and delays.
Using separate data and voice VLANs enables specific QoS settings on all traffic from the
voice VLAN to support end-to-end QoS. This separation of client traffic is best continued into
separate wireless RF spectrum such as 802.11a (5 GHz) for voice and 802.11b/g for data (2.4
GHz). The final selection of which RF spectrum depends on clients hardware capabilities for
2.4 GHz 802.11b/g, 5 GHz 802.11a or possible both radios. Voice deployment in 5 GHz also
assumes that more RF interference is present in a crowded 2.4 GHz RF spectrum.
Note
Separate VLANs are in addition to the RF recommendation of ensuring nonoverlapping
channel frequencies to avoid interference.
If the over the air packets to the access point have trust enforced, the edge switches of the wired
network can trust the QoS marking of the packets from the access point. Since all WLAN
traffic that passes between the access point and the LWAPP wireless LAN controller is
encapsulated, the LWAPP encapsulation maintains the Layer 3 marking in the original packet.
Once the LWAPP packet is de-encapsulated at the access point or wireless LAN controller, the
original Layer 3 marking is again used by QoS mechanisms in the network infrastructure. With
this capability enabled in the LWAPP and the Unified Wireless Network infrastructure, the
© 2007, Cisco Systems, Inc.
VoWLAN Design
11-47
network can achieve end-to-end QoS for the voice traffic both over the air and across the wired
network.
IEEE 802.11e and Wi-Fi Multimedia
QoS on a pervasive WLAN is much more than simply prioritizing one type of packet over
another.
WMM for Differentiated Services
ƒ Select QoS level of
WLAN based on traffic
type:
– Platinum for Voice
– Gold for Video
– Silver for Best Effort
(default)
– Bronze for
Background
ƒ User priority enforces
ceiling on WMM traffic.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-49
The number of active users in any location changes dynamically and cannot be addressed
through the capacity management tools used in wired networks. WLAN traffic is
non-deterministic. The channel access is based on a binary back-off algorithm defined by the
IEEE 802.11 standard (CSMA/CA) and is by nature variable, based on the number of clients
access the network causing difficulties to maintain QoS for VoWLAN more difficult.
To improve the reliability of voice transmissions in this nondeterministic environment, the
IEEE formed the 802.11e specification and standard that adds QoS features and multimedia
support to the existing 802.11b, 802.11g, and 802.11a wireless networks. Before the IEEE
802.11e was ratified, the wireless industry trade association known as the Wi-Fi Alliance
accelerated the use of WLAN QoS through an early certification called Wi-Fi Multimedia
(WMM). The WMM is a partial mirror of IEEE 802.11e features for wireless networks used to
improve the user experience for audio, video and voice applications. WMM adds prioritized
capabilities to wireless networks and optimizes their performance when multiple concurring
applications, each with different latency and throughput requirements, compete for network
resources.
VoWLANs can use Cisco Unified Wireless IP Phone 7920 and Cisco Unified Wireless IP
Phone 7921G devices which support the 802.11e standard and are WMM-certified. In order for
these differentiated services to provide sufficient QoS for voice packets, only a certain amount
of voice bandwidth can be serviced or admitted on a channel at any one time. If the network
can handle "N" voice calls with reserved bandwidth, when the amount of voice traffic is
increased beyond this limit (i.e. to the "N+1" call), the quality of all calls will suffer.
11-48
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Cisco WLANs support four levels of QoS over the air: Platinum/Voice, Gold/Video,
Silver/Best Effort (default), and Bronze/Background. As a recommended practice, configure
the voice traffic WLAN to use Platinum QoS, assign the low-bandwidth WLAN to use Bronze
QoS, and assign all other traffic between the remaining QoS levels.
The WLAN QoS level (platinum, gold, silver, or bronze) defines a specific 802.11e user
priority for over-the-air traffic. This user priority is used to derive the over-the-wire priorities
for non-WMM traffic, and it also acts as the ceiling when managing WMM traffic with various
levels of priorities. An access point uses this QoS-profile-specific user priority to derive the IP
DSCP value that is visible on the wired LAN.
Note
© 2007, Cisco Systems, Inc.
WMM requires Cisco Compatible Extensions version 3 or later.
VoWLAN Design
11-49
Call Admission Control
The Cisco Unified Wireless Network supports Call Admission Control (CAC) to police the call
capacity on a per-access-point basis.
Call Admission Control
ƒ CAC limits the
number of calls on a
channel to a percent
of the bandwidth.
ƒ The remaining
bandwidth percent is
for data.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-50
Cisco Unified Call Manager provides additional CAC features for the wired network, ensuring
an end-to-end CAC implementation. Cisco requires the use of Cisco Compatible clients to
enable the use of the traffic specification (TSpec) of the traffic flows for the calculation of call
limits and proper WLAN load balancing. The TSpec of each voice flow allows the system to
allocate bandwidth to client devices on a first-come, first-served basis and maintains a small
reserve so mobile phone clients can roam into a neighboring access point (even though the
access point could otherwise be at "full capacity"). Once the limit for voice bandwidth is
reached, the next call will be load-balanced to a neighboring access point and the call
completed without affecting the quality of the existing calls on the channel.
With CAC enabled and devices supporting current the Cisco Compatible Extensions, the Cisco
Unified Wireless Network allows the resources to be globally managed by the wireless network
controller across all the adjacent access points. Thus, each access point is not permitted to
admit the same amount of voice traffic as it could if it were operating in isolation. The numbers
of voice calls for the RF channel is limited to a percent of the channel’s bandwidth. A
percentage of the bandwidth is reserved to support roaming, and the rest of the bandwidth can
be available for data calls. Access points employ MAC measurements from clients and
neighboring access points to aid in determining the amount of traffic on the RF channel and
whether a new call should be admitted.
11-50
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Security Considerations
For VoWLAN deployments, security is also a concern.
VoWLAN Authentication and Encryption Recommendations
The strict requirements for voice in terms of packet delivery time and predictability, coupled
with the ability for clients to roam across access points and subnets, presents a challenge to
security architectures.
VoWLAN Authentication and Encryption
Recommendations
ƒ Use EAP-FAST
– TLS tunnel is based on string secrets that are unique to clients.
– Cisco Unified Wireless IP Phone 7920 clients need firmware
release 3.0 or later.
ƒ Use TKIP and MIC
– End to end latency should be < 150 ms.
– Client needs to be compliant with Cisco Compatible
Extensions Version 4 or later.
– MIC ensures that encrypted packets are not being altered .
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-52
To minimize the delay introduced by authenticating roaming clients, Cisco recommends using
the Extensible Authentication Protocol-Flexible Authentication via Secured Tunnel (EAPFAST) with Cisco Centralized Key Management. EAP-FAST is an 802.1x EAP framework for
authentication that encrypts EAP transactions with a Transport Layer Security (TLS) tunnel.
The EAP-FAST tunnel establishment is based upon strong secrets that are unique to clients.
Note
Cisco Unified Wireless IP Phone 7920 clients with a firmware release 3.0 or later support
EAP-FAST. All Cisco Unified Wireless IP Phone 7921G clients support EAP-FAST.
During roaming, reauthentication time back to the RADIUS server alone can take 500 ms or
more. To remedy this, Cisco recommends using Cisco Centralized Key Management to achieve
access point-to-access point roaming latency of less than 100 ms so that end to end latency is
less than 150 ms.. Cisco Centralized Key Management permits the negotiation of a session key
from a cached master key and avoids the need to go back to the authentication, authorization,
and accounting (AAA) server during a roam. When the client roams, it informs the
infrastructure that it has roamed and the infrastructure forwards the keying material to the new
access point.
© 2007, Cisco Systems, Inc.
VoWLAN Design
11-51
The efficiency of EAP-FAST with Cisco Centralized Key Management helps ensure maximum
protection with minimum transaction time. Cisco Centralized Key Management is available
with the Cisco Unified Wireless IP Phone 7920 and 7921G clients, as well as any client that is
compliant with Cisco Compatible Extensions Version 4.
To ensure that voice traffic is secure, Cisco recommends using Temporal Key Integrity
Protocol (TKIP) for encryption. This mechanism encrypts both the signaling (SCCP) packets
and voice (RTP) packets between the access point and the wireless IP phone. TKIP provides
per-packet key ciphering and longer initialization vectors that strengthen encryption. In
addition, a Message Integrity Check (MIC) ensures that encrypted packets are not being altered.
TKIP removes the predictability of the earlier Wired Equivalent Privacy (WEP) that can help
intruders decipher the WEP key.
11-52
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Other Design Recommendations for VoWLAN Security
Cisco VLAN technology separates the physical network into multiple logical networks.
Other Design Recommendations for
VoWLAN Security
ƒ Separate VLANs and SSIDs should be used for voice traffic.
ƒ Separate VLANs provide protection from some threats:
– DoS attacks
– Eavesdropping and interception
– Unauthorized access
ƒ Follow published recommendations for general wireless security
– “Five Steps to Securing Your Wireless LAN and Preventing
Wireless Threats" available at
http://www.cisco.com/en/US/netsol/ns340/ns394/ns348/ns337/
networking_solutions_white_paper0900aecd8042e23b.shtml
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-53
For secure voice calls, Cisco recommends creating separate VLANs and SSIDs for voice. In
turn, associating the voice SSID with the voice VLAN creates a single, unified voice network
across both the wired and wireless networks with consistent security and QoS profiles. The
wireless controller will bridge the traffic from the voice SSIDs to the voice VLANs. The
primary advantage of this physical separation of voice and data traffic is that traffic sent over
the voice network is not visible to insiders or outsiders connected to data network. The
converse is also true.
Following are some of the ways that VLANs protect the voice system from security threats:
„
Denial of service (DoS) attacks. Most DoS attacks originate from a PC; therefore, they
cannot affect IP phones and call-processing servers connected to a separate voice VLAN.
„
Eavesdropping and interception. Hackers typically eavesdrop on conversations using a
PC with special software to connect to the same VLAN as one or more parties in the
conversation. If voice participants are logically cordoned off, however, a hacker cannot
connect to the voice VLAN with a PC.
„
Unauthorized access. Companies can apply different access control policies to their voice
VLAN. They can authorize employees by roles in the organization; for example limiting
manufacturing employees to the data segment but not the voice segment.
© 2007, Cisco Systems, Inc.
VoWLAN Design
11-53
In addition to these voice-specific guidelines, Cisco has published best practices for general
wireless security. The paper "Five Steps to Securing Your Wireless LAN and Preventing
Wireless Threats" discusses best practices in a multilayered approach to secure the network
from unauthorized use through a WLAN link. These practices should be validated against an
organization's own risk-management processes and complemented by a strong security
implementation.
Note
This paper is available at available at
http://www.cisco.com/en/US/netsol/ns340/ns394/ns348/ns337/networking_solution
s_white_paper0900aecd8042e23b.shtml
11-54
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
VoWLAN Clients
To use the voice-ready Cisco infrastructure for enterprise roaming, management, and security
features, Cisco recommends the voice clients be either a Cisco Unified Wireless IP Phone 7920
or 7921G device or a voice-capable device that supports the advanced voice features through
the Cisco Compatible Extensions program.
Cisco Unified Wireless IP Phone 7921G
Overview
ƒ Flexible radio frequencies
802.11 a/b/g
ƒ CCX version 4 compliant
ƒ Enterprise class security
ƒ Extended battery life
ƒ Clear, high quality voice
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-55
The Cisco Unified Wireless IP Phone 7921G is a second-generation Cisco Systems® wireless
IP phone that now supports dual-band 802.11a/b/g radios, a speakerphone, and has a highresolution color display. It has dedicated volume and mute buttons, and an application button
that supports Push-to-talk via XML. The phone is also Cisco Compatible Extensions (CCX)
Version 4.0 compliant.
The phone supports a comprehensive list of enterprise wireless security features including
EAP-FAST, TKIP, MIC, and Cisco Centralized Key Management.
Two types of batteries are available for the phone. The standard lithium-ion (Li-ion) battery
provides up to 10 hours of talk time OR 80 hours of standby. The extended Li-ion battery
provides up to 12 hours of talk time OR 100 hours of standby. The actual battery life varies
based on environmental factors and the display timeout option selected
It supports voice-quality enhancements including 802.11e TSpec, Enhanced Distributed
Channel Access (EDCA), and QBSS. Because the Cisco Unified Wireless IP Phone 7921G is
designed to grow with system capabilities, features will keep pace with new system
enhancements.
© 2007, Cisco Systems, Inc.
VoWLAN Design
11-55
Cisco Compatible Extensions
WMM, Proxy ARP, EAPFAST, & WPA2,
Single Sign-On
Basic QoS
AP assisted roam, CCKM,
Radio measurements,
Transmit power control
Version 2
Scaling
Version 1
Secure
Connectivity
Voice
Ready
Call admission control, UPSD,
Voice metrics, MBSSIDs,
Location, Link tests, NAC
Version 4
Voice Ready
WLAN
Version 3
Performance
& Security
Fast Secure
Roaming
LEAP, WPA, 802.1x &
VLANs per AP TKIP,
WI-FI
2000
2001
2002
2003
2004
2005
2006
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-56
The Cisco Compatible Extensions program for WLAN client devices is a program where Cisco
licenses a specification with the latest WLAN standards and Cisco innovations. A program
participant, such as a maker of a WLAN client adapter or client device, implements support for
all features and then submits the product to an independent lab for rigorous testing. Only by
passing all tests does the device earn the right to be called Cisco Compatible.
The Cisco Compatible Extensions program ensures the widespread availability of client devices
that are interoperable with a Cisco WLAN infrastructure and take advantage of Cisco
innovations for enhanced security, mobility, quality of service, and network management.
There are four versions of the Cisco Compatible specification; each version builds upon its
predecessors:
„
„
11-56
Features of Cisco Compatible V1 include:
—
Compliance with IEEE 802.11 and Wi-Fi
—
Support for the 802.1X authentication type: Cisco LEAP
—
Ability to interoperate with an access point that supports multiple Service Set
Identifiers (SSIDs) tied to multiple VLANs, providing benefits such as flexible
security schemes in a mixed client environment
Features of Cisco Compatible V2 include:
—
Compliance with Wi-Fi Protected Access (WPA), including support for WPA
Temporal Key Integrity Protocol (TKIP) encryption
—
Support for the 802.1X authentication type: Protected EAP (PEAP) with EAP-GTC
—
Fast, secure roaming through support of the 802.1X key management protocol:
Cisco Centralized Key Management (CCKM)
—
Radio frequency (RF) scanning, with scanned data sent to the access point and
ultimately to CiscoWorks Wireless LAN Solution Engine (WLSE) for analysis and
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
performance of RF management functions such as intrusion detection, assisted site
survey, and detection of interference sources
„
„
Features of Cisco Compatible V3 include:
—
Compliance with WPA 2, including support for AES encryption
—
Support for the 802.1X authentication type: EAP-FAST
—
Support for WMM, a subset of the IEEE 802.11e QoS standard defined by the Wi-Fi
Alliance
Features of Cisco Compatible V4 include:
—
Support of Cisco Network Admission Control
—
Call admission control – addressing VoIP stability, roaming, and other QoS related
issues
—
Support for a power-saving mechanism, Unscheduled Automatic Power Save
Delivery (U-APSD), in QoS environments
—
VoIP metrics for reporting to optimize WLAN VoIP performance
—
Enhanced roaming
—
Ability to function as an 802.11 location tag
© 2007, Cisco Systems, Inc.
VoWLAN Design
11-57
Summary
This topic summarizes the key points discussed in this lesson.
Summary
There are several voice specific requirements to consider
when implementing a VoWLAN:
ƒ Roaming is integral to voice services on wireless networks.
ƒ QoS is essential to ensure that voice traffic receives timely and
reliable treatment with low delay, low jitter, and little or no packet
loss on the network. QoS also includes CAC to police the call
capacity on a per-access-point basis.
ƒ VoWLAN deployments require a carefully planned security
implementation to ensure that the network operates properly and
that voice traffic is secure.
ƒ A voice-ready WLAN requires an intelligent client capable of
supporting the voice-ready Cisco infrastructure functions for
enterprise roaming, QoS, CAC, and security.
© 2007 Cisco Systems, Inc. All rights reserved.
11-58
Designing Cisco Network Service Architectures (ARCH) v2.0
ARCH v2.0—11-57
© 2007 Cisco Systems, Inc.
Module Summary
This topic summarizes the key points discussed in this module.
Summary
ƒ The Cisco voice-ready architecture is an end-to-end solution for
combining WLAN and VoIP technologies in a VoWLAN.
ƒ Enterprise VoWLANs expect pervasive coverage, appropriate
SNR, and 20% coverage overlap of nonoverlapping frequency
channels. A well-executed site survey is a first step to building a
robust, voice-ready wireless network.
ƒ Voice specific requirements to consider when implementing a
VoWLAN include roaming, QoS, security, and intelligent clients.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-59
The Cisco voice-ready architecture is an end-to-end solution for combining WLAN and VoIP
technologies in a VoWLAN. Voice services should be on a separate VLAN from data.
Enterprise VoWLANs expect pervasive coverage, appropriate SNR, and 20% overlap coverage
of nonoverlapping frequency channels. A well-executed site survey is a first step to building a
robust, voice-ready wireless network. Overlapping coverage of the access point RF cells
facilitates roaming. To handle the voice load, a denser deployment of access points with
reduced transmission power is needed. When possible, leverage the nonoverlapping channels
and high data rate of 802.11a.
Voice specific requirements to consider when implementing a VoWLAN include roaming,
QoS, security, and intelligent clients. Voice needs over-the-air and wired end-to-end QoS from
the client throughout the infrastructure. Cisco Compatible Extension version 4 ensures the
highest performance for voice clients.
References
For additional information, refer to these resources:
„
Cisco Systems, Inc. “AGG-2017: Designing for Voice over WLAN (VoWLAN) Phones
and Network Configurations” Networkers 2006 presentation (accessible on a subscription
basis) at
http://www.networkersonline.net.
„
Cisco Systems, Inc. “Design Principles for Voice Over WLAN” at
http://www.cisco.com/en/US/netsol/ns340/ns394/ns348/networking_solutions_white_paper
0900aecd804f1a46.shtml
11-60
„
Cisco Systems, Inc. “Cisco Wireless IP Phone 7920 Design and Deployment Guide” at
http://www.cisco.com/en/US/products/hw/phones/ps379/products_implementation_design_
guide_book09186a00802a029a.html
„
Cisco Systems, Inc. “Five Steps to Securing Your Wireless LAN and Preventing Wireless
Threats” at
http://www.cisco.com/en/US/netsol/ns340/ns394/ns348/ns337/networking_solutions_white
_paper0900aecd8042e23b.shtml
„
Cisco Systems, Inc. “Cisco Compatible Extensions Program for Wireless LAN (WLAN)
Client Devices” at
http://www.cisco.com/web/partners/pr46/pr147/partners_pgm_concept_home.html
„
Infonetics Research, Inc. “The Evolution of Voice over IP over Wireless LAN in the
Enterprise”
http://www.infonetics.com/services/whitepapers/Infonetics-VoWLAN-White-PaperAugust-2006.pdf
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Module Self-Check
Use the questions here to review what you learned in this module. The correct answers and
solutions are found in the Module Self-Check Answer Key.
Q1)
What type of deployment best supports VoWLAN? (Source: VoWLAN in the
Enterprise)
A)
B)
C)
D)
Q2)
What are three major components of a VoWLAN? (Choose three.) (Source: VoWLAN
in the Enterprise)
A)
B)
C)
D)
E)
F)
Q3)
dB
dBi
dBm
GHz
Hz
mW
What is the recommended VoWLAN cell edge signal strength value for 11 Mbps data
rate? (Source: VoWLAN in the Enterprise)
A)
B)
C)
D)
E)
Q5)
IP phones
mesh WLAN
unified wired/wireless LAN infrastructure
unified wired/wireless WAN infrastructure
voice-ready WLAN
wireless IP phones
What unit is used to measure the received signal sensitivity? (Source: VoWLAN
Coverage and RF Survey)
A)
B)
C)
D)
E)
F)
Q4)
permissive
pervasive
salt and pepper
wired
18 dB
25 dB
65 dBm
-67 dBm
-92 dBm
What is the recommended minimum SNR for VoWLAN cell at the 11 Mbps data rate?
(Source: VoWLAN Coverage and RF Survey)
A)
B)
C)
D)
E)
© 2007 Cisco Systems, Inc.
18 dB
25 dB
44 dB
-67 dBm
-92 dBm
Designing IP Telephony Solutions
11-61
Q6)
What is the recommended range overlap needed to allow uninterrupted connections by
phones? (Source: VoWLAN Coverage and RF Survey)
A)
B)
C)
D)
E)
Q7)
A separate RF survey is recommended for adding voice to an existing data only
WLAN. (True or False) (Source: VoWLAN Coverage and RF Survey)
A)
B)
Q8)
2
3
5
8
11
12
What are three characteristics of call loading? (Chose three.) (Source: VoWLAN
Coverage and RF Survey)
A)
B)
C)
D)
E)
F)
11-62
2
3
5
8
11
12
How many nonoverlapping 802.11g channels are supported in the US? (Source:
VoWLAN Coverage and RF Survey)
A)
B)
C)
D)
E)
F)
Q10)
True
False
How many nonoverlapping 802.11a channels are supported in the US? (Source:
VoWLAN Coverage and RF Survey)
A)
B)
C)
D)
E)
F)
Q9)
5
10%
15%
20%
25%
A recommended call loading for 802.11a is 8 active voice calls per access
point using the voice encoding G.711 codec.
A recommended call loading for 802.11a is 14 active voice calls per access
point using the voice encoding G.711 codec .
A recommended call loading for 802.11b/g is 7 active voice calls per access
point using the voice encoding G.711 codec.
A recommended call loading for 802.11b/g is 8 active voice calls per access
point using the voice encoding G.729 codec.
The maximum number of phones supported per access point depends on the
calling patterns of individual users and the access point type.
The minimum number of phones supported per access point depends on the
calling patterns of individual users and the access point type.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Q11)
What wireless tool supports integrated network planning and design for VoWLANs?
(Source: VoWLAN Coverage and RF Survey)
A)
B)
C)
D)
E)
Q12)
What are three differences between VoWLAN deployments and data only WLAN
deployments? (Choose three.) (Source: VoWLAN Coverage and RF Survey)
A)
B)
C)
D)
E)
F)
Q13)
bronze
copper
gold
palladium
platinum
silver
What are three correct statements about WMM? (Choose three.) (Source: VoWLAN
Infrastructure Considerations)
A)
B)
C)
D)
E)
F)
Q15)
VoWLAN use larger cell sizes.
VoWLAN use smaller cell sizes.
VoWLANs deploy access points with a higher transmit power.
VoWLANs deploy access points with a lower transmit power.
VoWLANs recommend nonoverlapping cell frequencies.
VoWLANs recommend overlapping cell frequencies.
What is the recommended QoS level for over the air voice traffic? (Source: VoWLAN
Infrastructure Considerations)
A)
B)
C)
D)
E)
F)
Q14)
G.711 codec
RRM
UWN
WCS
WLC
It allows a defined maximum amount of voice bandwidth to be serviced or
admitted on a channel at any one time.
It allows a defined maximum amount of voice bandwidth to be serviced or
admitted on an access point at any one time.
It is a Wi-Fi certification that adds QoS features and multimedia support to the
existing 802.11b, 802.11g, and 802.11a wireless networks.
It is an IEEE specification that adds QoS features and multimedia support to
the existing 802.11b, 802.11g, and 802.11a wireless networks.
It is based on a subset of the IEEE 802.11e wireless QoS specification.
It is based on a superset of the IEEE 802.11e wireless QoS specification.
What protocol is recommended for client authentication in Cisco VoWLAN
deployments? (Source: VoWLAN Infrastructure Considerations)
A)
B)
C)
D)
E)
F)
© 2007 Cisco Systems, Inc.
CKMP
EAP-FAST
MIC
PKC
TKIP
WEP
Designing IP Telephony Solutions
11-63
Q16)
What two protocols are recommended for traffic encryption in Cisco VoWLAN
deployments? (Source: VoWLAN Infrastructure Considerations)
A)
B)
C)
D)
E)
F)
Q17)
What are two recommended voice clients in Cisco VoWLAN deployments? (Chose
two.) (Source: VoWLAN Infrastructure Considerations)
A)
B)
C)
D)
E)
F)
11-64
CKMP
EAP-FAST
MIC
PKC
TKIP
WEP
CCX version 2
CCX version 4
Enhanced CCX version 5
Cisco Unified Wireless IP Phone 1240AG
Cisco Unified Wireless IP Phone 7921G
Cisco Unified Wireless IP Phone 7922G
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Module Self-Check Answer Key
Q1)
B
Q2)
C, E, F
Q3)
C
Q4)
D
Q5)
B
Q6)
D
Q7)
A
Q8)
F
Q9)
B
Q10)
B, C, D
Q11)
D
Q12)
B, D, E
Q13)
E
Q14)
A, C, E
Q15)
B
Q16)
C, E
Q17)
B, E
© 2007 Cisco Systems, Inc.
Designing IP Telephony Solutions
11-65
11-66
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Module 12
Network Management
Capabilities with Cisco IOS
Software
Overview
Cisco IOS Software provides a rich set of features that enable customers to efficiently manage
their networks. This embedded management functionality enables network engineers to achieve
efficient performance, scalability, and availability in their network. It provides critical data for
baseline, capacity planning, bottleneck spotting, and general design-related information. This
module discusses the importance, requirements, and considerations for implementing the Cisco
IOS Software management instrumentation functionality in the overall enterprise design.
Module Objectives
Upon completing this module, you will be able to design discuss design considerations for
using the embedded management functionality in Cisco IOS Software. This ability includes
being able to meet these objectives:
„
Identify the rationale for embedded management functionality in network infrastructure
devices
„
Discuss design considerations for NetFlow
„
Discuss design considerations for Network-Based Application Recognition (NBAR)
„
Discuss design considerations for IP Service Level Agreements (IP SLAs)
12-2
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Lesson 1
Embedded Management
Capabilities
Overview
Network management includes a broad range of policies, procedures, and purpose-built
hardware and software used to manage computer networks. Network management affects the
performance, reliability, and security of the entire network. Embedded management describes
software subsystems within Cisco IOS Software that help manage, monitor, and automate
actions within a router or switch running Cisco IOS Software. Embedded management
capabilities adds a dimension to the management infrastructure by enabling devices to manage
themselves according to policies. It allows devices to automatically take action and collect data,
improving service providers' ability to better manage devices and the network.
Objectives
Upon completing this lesson, you will be able to identify xxx. This ability includes being able
to meet these objectives:
„
Discuss the rationale for embedded management tools within the network infrastructure
„
Discuss considerations for using syslog to support network management
Embedded Management Rationale
This topic identifies some reasons for using embedded management in the network
infrastructure.
Network Management Rationale
ƒ Verify your network is
working well.
ƒ Have the ability to
characterize the
performance.
ƒ Know how much traffic is
flowing and where.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-4
Network management is a set of tools and processes to help manage the network. Network
administrators use network management so they can be confident in the performance of the
network:
12-4
„
They use it to verify the network is working well and behaving in the planned manner
„
They use it to characterize the performance of the network
„
They use it to understand how much traffic is flowing and where it is flowing in the
network
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Enterprise Applications Rely on WAN Links
Enterprise applications rely on WAN links to connect the places in the network.
Enterprise Applications Rely
on WAN Links
Branch
Data
Center
Branch
WAN Links
WAN
TeleWorkers
HQ
Issues:
ƒ Links are expensive.
ƒ Speed mismatches can degrade performance.
© 2007 Cisco Systems, Inc. All rights reserved.
ƒ All traffic is not alike.
ARCH v2.0—11-5
Network management is often used to manage WAN links.. Existing network management
processes may focus on managing WAN links due to scarce bandwidth and susceptibility to
issues. However, there is increasing interest in extending network management to support
application optimization at the data center and throughout the enterprise. There are several
issues with the WAN links:
„
The expense of WAN connections causes organizations to implement low speed lower cost
links.
„
There are speed mismatches between LAN and WAN links that can lead to congestion,
packet loss, and degraded application performance.
„
Different types of application traffic with different delivery requirements use the WAN
links. Real-time applications such as voice and video are especially sensitive to congestion,
and suffer from degraded performance due to delay, jitter, and packet loss.
© 2007 Cisco Systems, Inc.
Network Management Capabilities with Cisco IOS Software
12-5
Cisco IOS Software Supports Network Management
There are many Cisco IOS software tools that network managers use.
Cisco IOS Software Supports Network
Management
Non-managed equipment is difficult to support:
ƒ When something goes wrong, what is the problem and cause?
Cisco IOS Software provides management capabilities:
ƒ Broad range of show commands
ƒ SNMP access to information
– Many SNMP MIBs are supported.
ƒ SDM, ASDM, web tools for managing single devices
ƒ Embedded management software subsystems:
– Syslog
– NetFlow
– NBAR
– IP SLA
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-6
Non-managed equipment is difficult to support. When something goes wrong, it can be
extremely hard to figure out the problem and cause, if the device provides no information or
just RMON data. This is a total cost of ownership issue.
Cisco IOS Software provides extensive management capabilities:
„
A broad range of show commands provide network information that is available for both
in-band and out-of-band management.
„
Cisco devices support many SNMP MIBs. Through these MIBS, SNMP access to vast
amounts of information is supported.
„
Device management applications such as the Cisco Router and Security Device Manager
(SDM) and the Cisco Adaptive Security Device Manager (ASDM) provide web based tools
for managing single devices.
„
Embedded management software subsystems within Cisco IOS Software that help manage,
monitor, and automate network management.
—
Cisco IOS system message logging (syslog)
—
NetFlow
—
Network-Based Application Recognition (NBAR)
—
Cisco IOS IP Service Level Agreement (IP SLA)
Note
12-6
The embedded management software subsystems are the focus of this .module. This lesson
discusses syslog.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Application Optimization and Cisco IOS Technologies
The embedded Cisco IOS technologies provide network management support for application
optimization in the network.
Application Optimization and Cisco IOS
Technologies
Optimize to Meet
Objectives
Baseline Application
Traffic
ƒ NetFlow
ƒ NBAR/NBAR
Protocol Discovery
ƒ IP SLAs
Deploy New
Applications
ƒ NBAR
ƒ NetFlow
ƒ Quality of Service
2
1
ƒ AutoQoS-VoIP
ƒ AutoQoS-Enterprise
Application
Optimization
Cycle
3
Measure, Adjust,
and Verify
ƒ NetFlow
ƒ NBR Protocol
Discovery
4
ƒ IP SLAs
ƒ Syslog
ARCH v2.0—11-7
© 2007 Cisco Systems, Inc. All rights reserved.
Cisco has defined an application optimization cycle:
„
Develop a baseline on the application traffic. In the first phase, a baseline is developed
that measures data. The baseline is used so that the network manager can understand the
basic traffic and application flows and the default network performance. Cisco IOS
software technologies that support this phase include NetFlow, Network-Based Application
Recognition (NBAR) Protocol Discovery, and IP Service Level Agreements (IP SLAs).
„
Optimize to meet objectives. After understanding the baseline, the network manager can
apply policies and prioritize traffic so that the each application has an optimal portion of
network resources. Resources are allocated based on their value to the organization. Quality
of Service (QoS) is used to reduce congestion, prioritize specific traffic, and optimize endto-end performance of critical applications. Cisco IOS software technologies that support
this phase include QoS, NBAR, AutoQoS-VoIP, and AutoQoS-Enterprise.
„
Measure, adjust, verify. In the third phase of the application optimization cycle, the
network manager uses ongoing measurements and proactive adjustments to verify that the
optimization techniques and QoS provide the network resources needed to meet the service
objectives of the applications. This information is also used to resolve network issues that
may occur. There are several Cisco IOS software features that help measure network
performance including NetFlow, NBAR Protocol Discovery, IP SLAs., and Syslog
„
Deploy new applications. In this phase, network engineers determine the service
objectives for new applications, estimate the network resources that will be needed to
support these objectives, and allocate resources for new applications. Network management
tools and process allow the network manager to have the confidence to deploy new
© 2007 Cisco Systems, Inc.
Network Management Capabilities with Cisco IOS Software
12-7
applications based on their understanding of the existing applications. NBAR and NetFlow
are common Cisco IOS technologies that are used to support this phase.
Applying Cisco IOS Technologies for
Measuring Application Traffic
Branch
NetFlow
Monitoring
Data
Center
IP SLA
Measurements
IP SLA
Measurements
Branch
WAN
NBAR
Monitoring
HQ
TeleWorkers
Syslog reporting
on all infrastructure
devices.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-8
The figure highlights where these technologies are commonly deployed in the enterprise
environment.
Networks should be configured for manageability and security. Using a predefined template to
structure network management configuration and reporting information is a recommended
practice.
Note
12-8
This lesson discusses syslog technology considerations. Other Cisco IOS Software
technologies are discussed in the “NetFlow Consideration”, “NBAR Considerations”, and “IP
SLA Considerations” lessons in this module.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Syslog Considerations
This topic will describe how the Cisco IOS system message logging (syslog) can help the
network manager better manage the network.
Syslog Overview
ƒ Allows software subsystems to report and save important error
messages either locally or to a remote logging server.
ƒ Can send messages on UDP port 514.
ƒ Provides very comprehensive reporting mechanism in plain
English text.
ƒ ESM provides a programmable framework to
filter, escalate, correlate, route,
and customize syslog.
ESM
Modules
– Is available in Cisco IOS Software
release 12.3(2)T and later versions.
Buffer Console
© 2007 Cisco Systems, Inc. All rights reserved.
tty
Syslog
Server
ARCH v2.0—11-10
The Cisco IOS system message logging (syslog) process allows a device to report and save
important error and notification messages, either locally or to a remote logging server. Syslog
messages can be sent to local console connections, monitor (TTY) connections, the system
buffer, or to remote syslog servers. Syslog allows text messages to be sent to a syslog server
using UDP port 514.
Syslog provides a very comprehensive reporting mechanism logging system messages in plain
English text. The syslog messages include both messages in a standardized format (called
system logging messages, system error messages, or simply system messages) and output from
debug commands. These messages are generated during network operation to assist with
identifying the type and severity of a problem, or to aid users in monitoring router activity such
as configuration changes.
The Embedded Syslog Manager (ESM) feature provides a programmable framework that
allows a network manager to filter, escalate, correlate, route, and customize system logging
messages prior to delivery by the Cisco IOS system message logger. ESM is available in Cisco
IOS Software release 12.3(2)T and later versions. ESM also allows system messages can be
logged independently as standard messages, XML-formatted messages, or ESM filtered
messages. These outputs can be sent to any of the traditional syslog targets. For example, a
network manager could enable standard logging to the console connection, XML-formatted
message logging to the buffer, and ESM filtered message logging to the monitor. Similarly,
each type of output could be sent to different remote hosts. A benefit of separate logging
processes is that if, for example, there is some problem with the ESM filter modules, standard
logging will not be affected.
© 2007 Cisco Systems, Inc.
Network Management Capabilities with Cisco IOS Software
12-9
Cisco IOS Syslog Message Standard
This section discusses the Cisco IOS Software syslog message standard.
Cisco Syslog Message Standard
%FACILITY-SUBFACILITY-SEVERITY-MNEMONIC: Message-text
%SYS-5-CONFIG_I: Configured from console by
cwr2000 on vty0 (192.168.64.25)
ƒ Documentation for each release explains the meaning of the
messages.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-11
The system messages begin with a percent sign (%) and are structured as shown in the figure:
„
FACILITY is a code consisting of two or more uppercase letters that indicate the hardware
device, protocol, or a module of the system software.
„
SEVERITY is a single-digit code from 0 to 7 that reflects the severity of the condition.
The lower the number, the more serious the situation.
„
MNEMONIC is a code that uniquely identifies the error message.
„
Message-text is a text string describing the condition. This portion of the message
sometimes contains detailed information about the event, including terminal port numbers,
network addresses, or addresses that correspond to locations in the system memory address
space.
The figure shows a typical message that indicates the operating system (facility = SYS) is
providing a notification (SEVERITY = 5) has been configured (MNEUMONIC = CONFIG).
The message text indicates that a user on VTY0 from IP address 192.168.64.25 made this
change.
Note
The documentation for each Cisco IOS Software release explains the meaning of these
messages, such as the information found at
http://www.cisco.com/en/US/products/ps6441/products_system_message_guide_b
ook09186a00806f9890.html
12-10
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Syslog Issues
There are some issues with syslog.
Syslog Issues
ƒ Severity is not consistently used across different Cisco platforms
and Cisco IOS versions:
– For example, the environmental monitor initiated shutdown
event:
ƒ Cisco IOS 11.2 Æ ENVM-1-SHUTDOWN
ƒ Cisco IOS 12.0 Æ ENVM-0-SHUT
ƒ Can be verbose, offering a mix of useful and less useful
messages.
– Can use filters or scripts to pull out the important messages.
ƒ Is not a reliable mechanism (uses UDP for delivery)
– Cisco IOS Release 12.4(11)T provides support for the Reliable
Delivery for Syslog over BEEP.
ƒ Is not a secure mechanism.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-12
The severity of messages is not used consistently across the different Cisco platforms, so
documentation for each Cisco IOS Software release is needed to explain the meaning of these
messages. This can cause confusion when network managers filter to extract certain severity
level information, but are running different software releases.
Syslog is verbose, and can provide too many informational messages along with useful
messages for a specific problem or condition. Network managers can use filters or scripts to
pull out important messages. There are also third party tools that help manage syslog messages
such as Syslog-NG, Kiwi Syslog, and others.
Syslog is based on UDP for its delivery communication mechanism. This is typically not a
problem for a monitoring and alerting tool. However, RFC 3195 provides a specification for a
reliable delivery mechanism for syslog. Cisco IOS Release 12.4(11)T provides support for the
Reliable Delivery for Syslog over Blocks Extensible Exchange Protocol (BEEP) feature that
allows a device to be customized for receipt of syslog messages. This feature provides reliable
and secure delivery for syslog messages using BEEP. Additionally, it allows multiple sessions
to a single logging host, independent of the underlying transport method, and provides a
filtering mechanism called a message discriminator.
Syslog is not a secure mechanism. However, this should not preclude the network manager
from using syslog. Secure practices include establishing access control lists to allow receipt of
syslog packets only from internal resources.
© 2007 Cisco Systems, Inc.
Network Management Capabilities with Cisco IOS Software
12-11
Summary
This topic summarizes the key points discussed in this lesson.
Summary
ƒ Cisco IOS Software includes embedded management tools that
support application optimization, performance measurement, and
SLA verification.
ƒ Syslog is an Cisco IOS Software process that allows a device to
report and save important error and notification messages, either
locally or to a remote logging server. Syslog data helps network
manager track the network status.
© 2007 Cisco Systems, Inc. All rights reserved.
12-12
Designing Cisco Network Service Architectures (ARCH) v2.0
ARCH v2.0—11-13
© 2007 Cisco Systems, Inc.
Lesson 2
NetFlow Considerations
Overview
NetFlow is an important embedded Cisco IOS software technology that provides visibility into
how network assets are being used and the network behavior. This lesson will describe how
both traditional and Flexible NetFlow help the network manager understand the behavior of
traffic in the network.
Objectives
Upon completing this lesson, you will be able to identify design considerations for using
NetFlow technology to help manage the network. This ability includes being able to meet these
objectives:
„
Provide an overview of NetFlow technology
„
Describe the characteristics of a flow
„
Describe flow record creation
„
Describe cache management
„
Discuss data export formats
„
Discuss NetFlow deployment options
NetFlow Technology Overview
This topic describes the basic characteristics of NetFlow.
Cisco IOS NetFlow
ƒ Developed and patented at Cisco
Systems in 1996.
ƒ NetFlow is the defacto standard for
acquiring IP operational data.
– Now available as IETF standard
IPFIX.
ƒ Provides network and security
monitoring, network planning, traffic
analysis, and IP accounting.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-17
\
Cisco IOS NetFlow efficiently provides a key set of services for IP applications, including
network traffic accounting, usage-based network billing, network planning, security, Denial of
Service (DoS) monitoring capabilities, and network monitoring. NetFlow provides valuable
information about network users and applications, peak usage times, and traffic routing. Cisco
invented NetFlow in 1996 and is the leader in IP traffic flow technology
NetFlow answers the questions of what, when, where, and how traffic is flowing in the
network. NetFlow data can be exported to network management applications that further
process the information, resulting in display tables and graphs for accounting and billing or as
an aid for network planning.
The Cisco IOS NetFlow version 9 is now on the IETF standards track in the IP Information
Export (IPFIX) working group. The new generic data transport capability within Cisco routers,
IPFIX export, can be used to transport any performance information from a router or switch.
The main NetFlow focus has always been IP Flow information but this is now changing with
Cisco implementation of a generic export transport format that is an innovative IETF standard.
New information is being exported using the NetFlow version 9 export format including Layer
2 information, new security detection and identification information, IPv6, Multicast, MPLS,
BGP information, and more.
12-14
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Principal NetFlow Uses
Service provider and enterprise environments deploy NetFlow to support different functions.
Principal NetFlow Uses
Service Provider
Enterprise
Peering Arrangements
Internet Access Monitoring
(Protocol Distribution; Where Traffic
Is Going/Coming)
Network Planning
User Monitoring
Traffic Engineering
Application Monitoring
Accounting and Billing
Charge-Back Billing for
Departments
Security Monitoring
Security Monitoring
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-18
\
Organizations use NetFlow in different ways depending on their focus. Both service providers
(SPs) and enterprises use NetFlow to analyzing new applications and their impact on the
network. Understanding who is utilizing the network and the end points of traffic flows is
important for SPs for network planning and traffic engineering, and important to enterprises for
monitoring network resources, users and applications. Organizations can use NetFlow to
determine application ports before writing access control lists (ACLs.)
While an SP is concerned about accounting and billing to its customers, enterprises may be
concerned about charge-back billing for their departments. In addition, NetFlow can help
organizations avoid costly upgrades by identifying the applications causing congestion and help
reduce peak WAN traffic.
Both types of organization use NetFlow for security monitoring and troubleshooting the
network. NetFlow can help in diagnosing slow network performance, bandwidth hogs and
bandwidth utilization in real-time. It can be used to confirm that appropriate bandwidth has
been allocated to each Class of Service (CoS). It can also help detect unauthorized WAN traffic
and support for anomaly detection and worm diagnosis.
© 2007 Cisco Systems, Inc.
Network Management Capabilities with Cisco IOS Software
12-15
Definition of a Flow
Each packet that is forwarded within a router or switch is part of a flow.
\
Definition of a Flow
A flow is a stream of traffic from a source to a destination
that moves across a device.
Seven fields identify flows:
ƒ IP source address
ƒ IP destination address
ƒ Source port number
ƒ Destination port number
ƒ Layer 3 protocol type
ƒ ToS byte
ƒ Input logical interface (ifIndex)
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-19
A flow is a unidirectional stream of packets between a given source and destination—both
defined by a network-layer IP address and transport-layer source and destination port numbers.
Traditionally, a flow in NetFlow is identified as the combination of the following seven key
fields:
„
IP source address. Source address allows the understanding of who is originating the
traffic.
„
IP destination address. Destination address tells who is receiving the traffic.
„
Source port. Ports characterize the application utilizing the traffic up to Layer 4.
„
Destination port. Ports characterize the application utilizing the traffic up to Layer 4.
„
Layer 3 protocol type. Protocol type characterized the application utilizing the traffic.
„
ToS Byte. The type of service (ToS) byte identifies the class of service or priority of the
traffic.
„
ifIndex. The device interface tells how traffic is being utilized by the network device.
All packets with the same source/destination IP address, source/destination ports, protocol,
interface and class of service are grouped into a flow with traditional NetFlow. For each flow,
NetFlow tallies the packets and bytes.
Note
12-16
Cisco IOS Flexible NetFlow is the next-generation in flow technology. Flexible NetFlow
supports additional flexibility, scalability, aggregation of flow data beyond traditional
NetFlow.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Traditional IP Flows
NetFlow examines each packet for a set of IP packet attributes.
Traditional IP Flows
NetFlow Enabled
Device
Traffic
Inspect
1 Packet
NetFlow Cache
• Source IP Address
• Destination IP Address
NetFlow
Key Fields
• Source Port
2•
Destination Port
2
Flow Information
Packets
Bytes/Packet
Address, Ports…
11,000
1,528
…
• Layer 3 Protocol
• ToS Byte (DSCP)
• Input Interface
Create a Flow from the
Packet Attributes
NetFlow
Export
Packets
1. Inspect seven key fields in a packet and identify the values
2. If the set of key field values is unique, create a flow record
or cache entry
3
Reporting
3. When the flow terminates, export the flow to the collector
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-20
\
In the traditional NetFlow implementation, a set of seven key attributes are use to determine if a
packet is unique or similar to other packets. The key attributes methodology of determining a
flow is quite scalable because a large amount of network information is condensed into a
database of NetFlow information called the NetFlow cache.
NetFlow operates by creating a NetFlow cache entry that contains the information for all active
flows. The NetFlow cache is built by processing the first packet of a flow through the standard
switching path. A Flow record is maintained within the NetFlow cache for all active flows.
Each flow record in the NetFlow cache contains key fields that can be later used for exporting
data to a collection device. NetFlow export, unlike SNMP polling, pushes information
periodically to the NetFlow reporting collector. In general, the NetFlow cache is constantly
filling with flows, and software in the router or switch is searching the cache for flows that
have terminated or expired, and these flow records are exported to the NetFlow collector
server.
Each flow record is created by identifying packets with similar flow characteristics and
counting or tracking the packets and bytes per flow. The flow details or cache information is
exported to a flow collector server periodically based upon flow timers. The collector contains
a history of flow information that was switched within Cisco device. NetFlow is very efficient,
the amount of export data being about 1.5% of the switched traffic in the router. NetFlow
accounts for every packet (non-sampled mode) and provides a highly condensed and detailed
view of all network traffic that entered the router or switch.
Network managers review NetFlow information using either Cisco IOS software show
commands or by exporting NetFlow to a collecting server called a “NetFlow Collector.”
© 2007 Cisco Systems, Inc.
Network Management Capabilities with Cisco IOS Software
12-17
Flow Record Creation
This section looks at flow record creation with NetFlow.
Flow Record Creation
Example 1
Example 2
1. Inspect packet for key
field values
2. Compare set of values
to NetFlow cache
3. If the set of values are
unique, create a flow
in cache
4. Inspect the next
packet
Inspect
Packet
Key Fields
Packet 1
Source IP
1.1.1.1
Destination IP
2.2.2.2
Source port
23
Destination port
22078
Layer 3 Protocol
ToS Byte
TCP - 6
0
Input Interface
Ethernet 0
Inspect
Packet
Key Fields
Packet 2
Source IP
3.3.3.3
Destination IP
2.2.2.2
Source port
23
Destination port
22078
Layer 3 Protocol
TCP - 6
ToS Byte
0
Input Interface
Ethernet 0
Add new flow to the NetFlow cache
Create flow record in the cache
Source IP
Dest. IP
Dest. I/F
Protocol
TOS
…
Pkts
1.1.1.1
2.2.2.2
E1
6
0
…
11000
© 2007 Cisco Systems, Inc. All rights reserved.
Source IP
Dest. IP
Dest. I/F
Protocol
TOS
…
Pkts
3.3.3.3
2.2.2.2
E1
6
0
…
11000
1.1.1.1
2.2.2.2
E1
6
0
…
11000
ARCH v2.0—11-21
\
NetFlow inspects packets for key field values. These values are compared to existing flows in
the cache. If the set of values are unique, NetFlow creates a new flow record in the cache.
Additional information is included to the Flow Record in non-key fields in both forms of
NetFlow. Non-key fields are added to the flow entry in the NetFlow cache and exported. The
non-key fields are not used to create or characterize the flows but are exported and just added to
the flow in traditional NetFlow. If a field is non-key, such as the outbound interface, normally
only the first packet of the flow is used for the value in this field.
In the figure, two unique flows are created in the cache because there are different values in the
source IP address key fields.
12-18
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
\
NetFlow Data Before QoS Deployment
Dstlf
DstlPadd
TOS
Pkts
Src
Port
Dst
Port
NextHop
Bytes/
Pkt
Start
End
Time
Time
Fa1/0 173.100.21.2
Fa0/0
10.0.227.12
0
11,000
00A2
00A2
10.0.23.2
1,528
..
..
Fa1/0 173.100.3.2
Fa0/0
10.0.227.12
0
2,491
15
15
10.0.23.2
740
..
..
Fa1/0 173.100.20.2
Fa0/0
10.0.227.12
0
10,000
00A1
00A1
10.0.23.2
1,428
..
..
Fa1/0 173.100.6.2
Fa0/0
10.0.227.12
0
2,210
19
19
10.0.23.2
1,040
..
..
Srclf
SrclPadd
The Flow in Red Before QoS Deployment
ƒ ToS byte is zero because QoS is not deployed.
ƒ This is a small sample of a result. 100,000s of flows are normally
available in the NetFlow cache.
ARCH v2.0—11-22
© 2007 Cisco Systems, Inc. All rights reserved.
Example: NetFlow Data Before QoS Deployment
NetFlow records contain the Type of Service (ToS) field in the IP header as well as application
ports, traffic volumes and timestamps. This information allows the network manager to
understand traffic profiles per class of service (CoS) for traffic including data, voice and video.
The user of NetFlow can verify the QoS levels achieved and optimize bandwidth for specific
classes of service.
This figure and the next figure illustrate how the ToS key field distinguishes between flows.
Before QoS is implemented in the network, the ToS value is 0 for all traffic between a specific
source and destination pair. There is one traffic flow between this pair.
Note
© 2007 Cisco Systems, Inc.
Using show commands allow the cache to be examined in real-time, although collection and
reporting tools provide better visibility into what is going on
Network Management Capabilities with Cisco IOS Software
12-19
NetFlow Data After QoS Deployment
TOS
Pkts
Src
Port
Dst
Port
NextHop
Bytes/
Pkt
Start
End
Time
Time
10.0.227.12
EF
3,020
00A2
00A2
10.0.23.2
1,528
..
..
10.0.227.12
CS6
2,212
00A2
00A2
10.0.23.2
1,528
..
..
Fa0/0
10.0.227.12
AF41
4,000
00A2
00A2
10.0.23.2
501
..
..
Fa1/0 173.100.21.2
Fa0/0
10.0.227.12
CS4
3,333
00A2
00A2
10.0.23.2
93
..
..
Fa1/0 173.100.21.2
Fa0/0
10.0.227.12
CS3
7,474
00A2
00A2
10.0.23.2
82
..
..
Fa1/0 173.100.21.2
Fa0/0
10.0.227.12
AF21
2,828
00A2
00A2
10.0.23.2
111
..
..
Fa1/0 173.100.21.2
Fa0/0
10.0.227.12
CS2
993
00A2
00A2
10.0.23.2
256
..
..
Fa1/0 173.100.21.2
Fa0/0
10.0.227.12
AF11
1,404
00A2
00A2
10.0.23.2
64
..
..
Fa1/0 173.100.21.2
Fa0/0
10.0.227.12
CS1
500
00A2
00A2
10.0.23.2
98
..
..
Fa1/0 173.100.21.2
Fa0/0
10.0.227.12
0
11,000
00A2
00A2
10.0.23.2
98
..
..
Fa1/0 173.100.3.2
Fa0/0
10.0.227.12
0
2,491
15
15
10.0.23.2
740
..
..
Fa1/0 173.100.20.2
Fa0/0
10.0.227.12
0
10,000
00A1
00A1
10.0.23.2
1,428
..
..
Fa1/0 173.100.6.2
Fa0/0
10.0.227.12
0
2,210
19
19
10.0.23.2
1,040
..
..
Srclf
SrclPadd
Dstlf
DstlPadd
Fa1/0 173.100.21.2
Fa0/0
Fa1/0 173.100.21.2
Fa0/0
Fa1/0 173.100.21.2
ƒ The one flow is now 10 because traffic is distributed per class.
ƒ NetFlow analysis now shows each class of service added to the
network.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-23
\
Example: NetFlow Data After QoS Deployment
This figure shows the NetFlow data after QoS is implemented in the network. The multiple ToS
values between a specific source and destination pair lead to multiple flows between the pairs
as traffic is distributed per class. The NetFlow analysis now shows each class of service
between the source and destination pair.
This can be useful for verifying your QoS configuration is working and that bandwidth levels
are set appropriately for the volume of traffic.
12-20
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
NetFlow Cache Management
The key to NetFlow-enabled switching scalability and performance is highly intelligent flow
cache management.
NetFlow Cache Management
1. Create and update flows in NetFlow cache
Srclf
* SrclPadd
Dstlf
* DstlPadd
*Protocol
*ToS
Flgs
Pkts
* Src
Port
Src
Msk
Src
AS
* Dst
Port
Dst
Msk
Dst
AS
NextHop
Bytes/
Pkt
Active
Idle
Fa1/0
173.100.21.2
Fa0/0
10.0.227.12
11
80
10
11,000
00A2
/24
5
00A2
/24
15
10.0.23.2
1,528
1,745
4
Fa1/0
173.100.3.2
Fa0/0
10.0.227.12
6
40
0
2,491
15
/26
196
15
/24
15
10.0.23.2
740
41.5
1
Fa1/0
173.100.20.2
Fa0/0
10.0.227.12
11
80
10
10,000
00A1
/24
180
00A1
/24
15
10.0.23.2
1,428
1,145.
5
3
Fa1/0
173.100.6.2
Fa0/0
10.0.227.12
6
40
0
2,210
19
/30
180
19
/24
15
10.0.23.2
1,040
24.5
14
2. Expire timers
ƒ
ƒ
ƒ
ƒ
Inactive timer expired (15 sec is default)
Active timer expired (30 min (1,800 sec) is default)
NetFlow cache is full (oldest flows are expired)
RST or FIN TCP Flag
* Key Fields
Srclf
* SrclPadd
Dstlf
* DstlPadd
*Protocol
*ToS
Flgs
Pkts
* Src
Port
Src
Msk
Src
AS
* Dst
Port
Dst
Msk
Dst
AS
NextHop
Bytes/
Pkt
Active
Idle
Fa1/0
173.100.21.2
Fa0/0
10.0.227.12
11
80
10
11,000
00A2
/24
5
00A2
/24
15
10.0.23.2
1,528
1,800
4
3. Package flows in export packet
4. Transport flows to reporting server
30 Flows per 1,500 Byte Export Packet
Export
Packet
Header
Non-Aggregated Flows—Export Version 5 or 9
Payload
(Flows)
ARCH v2.0—11-24
© 2007 Cisco Systems, Inc. All rights reserved.
\
The NetFlow cache management software contains a highly sophisticated set of algorithms for
efficiently determining if a packet is part of an existing flow or should generate a new flow
cache entry. The algorithms are also capable of dynamically updating per-flow accounting
measurements residing in the NetFlow cache, and cache aging/flow expiration determination.
Rules for expiring NetFlow cache entries include:
„
Flows which have been idle for a specified time are expired and removed from the cache
„
Long lived flows are expired and removed from the cache (flows are not allowed to live
more than 30 minutes by default, the underlying packet conversation remains undisturbed)
„
As the cache becomes full a number of heuristics are applied to aggressively age groups of
flows simultaneously
„
TCP connections which have reached the end of byte stream (FIN) or which have been
reset (RST) will be expired
The figure shows an example of the NetFlow cache, aggregation cache and timers. Expired
flows are grouped together into "NetFlow Export" datagrams for export from the NetFlowenabled device. NetFlow Export datagrams may consist of up to 30 flow records for NetFlow
version 5 or 9 flow export.
© 2007 Cisco Systems, Inc.
Network Management Capabilities with Cisco IOS Software
12-21
NetFlow Export Versions
There are various versions of NetFlow Export formats.
\
NetFlow Export Versions
NetFlow Version
Comments
1
Original
5
Standard and Most Common
7
Adds IP address of shortcut router for Catalyst 6500
8
Choice of Eleven Aggregation Schemes
Reduces Resource Usage
9
Flexible, Extensible File Export Format to Enable Easier
Support of Additional Fields and Technologies; Coming Out
Now MPLS, Multicast, and BGP Next Hop
IPFIX
IETF IP Flow Information Working Group Standard for Flow
Export; Based on Cisco NetFlow Version 9
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-25
The first versions of NetFlow Export support statically defined fields:
„
Version 1 is the original version.
„
Version 5 is the most popular. It adds autonomous system (AS) data and sequencing info to
the NetFlow data export (NDE) packets. NetFlow version 5 is used with traditional
NetFlow and is a fixed export format with a limited set of information being exported.
„
Version 7 adds a field for the IP address of the shortcut router used by Cisco Catalyst 6500
Series switches.
„
Version 8 is for on-router aggregation. It includes a choice of eleven aggregation schemes.
The latest generation of NetFlow Export supports dynamically defined fields:
„
Version 9 is the new extensible NDE version that allows for new fields without requiring a
new NDE version. With NetFlow version 9, routers send out a template with field IDs and
lengths that define the subsequent NDE packets.
„
IPFIX is the IETF standard mechanism for information export. IPFIX is based on NetFlow
version 9.
The most common format used is NetFlow export version 5. However, version 9 is the latest
format and has some advantages for key technologies such as security, traffic analysis and
multicast. Some reporting tools may prefer unaggregated version 5 to version 9, as version 9
requires more complicated processing.
12-22
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
NetFlow Version 9 Export Packet
Cisco IOS Flexible NetFlow is the next generation flow technology by Cisco.
NetFlow Version 9 Export Packet
Flows from
Interface A
Header
(Version,
# Packets,
Sequence
#,
Source ID)
Template Set
Template
Template
Record
Record
Template ID #1 Template ID #2
(Specific Field,
Types, and
Lengths)
(Specific Field,
Types, and
Lengths)
Flows from
Interface B
Data Set
Data Set
Set ID #1
Set ID #2
Option
Template
Set
Data
Record
Data
Record
Data
Record
Template
ID
(Field
Values)
(Field
Values)
(Field
Values)
(Specific
Field, Types,
and Lengths)
Option Data
Set
Set ID
Option Option
Data
Data
Record Record
(Field
Values)
(Field
Values)
ƒ Version 9 export format allows easily inserted new fields.
– A template describes what is being exported in the export
data sets.
– Matching ID numbers help to associate template to the data
records.
ƒ The network manager can configure what key and non-key fields
define flows.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-26
Flexible NetFlow uses flexible and extensible NetFlow version 9 format to provide enhanced
optimization of the network infrastructure, reduced costs, and improved capacity planning and
security detection beyond other flow based technologies available today. NetFlow version 9
includes a template to describe what is being exported and the export data. The template is
periodically sent to the NetFlow collector telling it what data to expect from the router or
switch. The data is then sent for the reporting system to analyze. Matching ID numbers are used
to help to associate template to the data records.
The NetFlow Version 9 record format consists of a packet header followed by at least one or
more template or data FlowSets. A FlowSet is a generic term for a collection of records that
follow the packet header in an export packet. There are both template and data FlowSets. An
export packet contains one or more FlowSets, and both template and data FlowSets can be
mixed within the same export packet. A template FlowSet provides a description of the fields
that will be present in future data FlowSets. Data FlowSets may occur later within the same
export packet or in subsequent export packets.
Since NetFlow version 9 is configurable and customizable, theoretically any data available in
the device can be sent in NetFlow version 9 format. The network manager can configure what
key and non-key fields define flows.
© 2007 Cisco Systems, Inc.
Network Management Capabilities with Cisco IOS Software
12-23
Flexible NetFlow Advantages
ƒ Flexibility, scalability, aggregation of flow data beyond traditional
NetFlow
ƒ The ability to monitor a wider range of packet information
producing new information about network behavior
ƒ User configurable flow information to perform customized traffic
identification and the ability to focus and monitor specific network
behavior
ƒ Simultaneous multiple NetFlow application support through
multiple Flow Monitors
ƒ Enhanced network anomaly and security detection
ƒ Basis for the IETF standard IPFIX
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-27
The current Flexible NetFlow model has several key advantages over traditional NetFlow:
12-24
„
By flexibly targeting specific information, the amount of information is reduced and the
number of flows being exported can be reduced, allowing enhanced scalability and
aggregation beyond traditional NetFlow.
„
Flexible NetFlow can monitor a wider range of packet information. Flexible NetFlow
enhances the rich feature capabilities of traditional NetFlow by allowing the tracking of
information at Layer 2 for switching environments, Layer 3 and 4 for IP information and up
to Layer 7 with deep packet inspection for application monitoring.
„
In Flexible NetFlow, non-key fields are configurable by the user. Flexible NetFlow will
also allow the user to select what key and non-key fields define flows. This configuration
capability allows the user customization and flexibility beyond traditional NetFlow.
„
Version 9 provides a NetFlow architecture that can track multiple NetFlow applications
simultaneously by using different Flow Monitors. A Flow Monitor describes the NetFlow
cache or information stored in the cache and contains the Flow Records or key and non-key
fields within the cache. Part of the Flow Monitor is the Flow Exporter which contains
information about the export of NetFlow information including the destination address of
the NetFlow collector. The Flow Monitor includes various cache characteristics including
the timers for exporting, the size of the cache and if required, the packet sampling rate. The
user can create simultaneous and separate Flow Monitors for security analysis and for
traffic analysis.
„
Cisco IOS Flexible NetFlow provides enhanced security detection and or network
troubleshooting by allowing customization of flow information. For example, the user can
create a specific Flow Monitor to focus and analyze a particular network issue or incident.
In addition, Flexible NetFlow allows a customizable active timer for the cache that can be
set as low as 1 second as compared to the traditional NetFlow minimum value of 60
seconds. This customizable timer aids in tracking security incidents where open or partial
flows might be recorded (i.e.: SYN flood attack). It provides real-time monitoring with
immediate flow cache capabilities and long term or permanent tracking of flow data.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
„
NetFlow version 9 is the basis for the IETF standard IPFIX associated with the IP Flow and
Information working group in IETF.
Flexible NetFlow is an important technology available in Cisco devices to help with visibility
into how network assets are being used and the network behavior. Flexible NetFlow is an
improved NetFlow bringing better scalability, aggregation of data and user customization.
Flexible NetFlow will enhance the ability to detect security incidents and understand the
behavior of traffic in the network beyond what is possible in other flow based technologies.
© 2007 Cisco Systems, Inc.
Network Management Capabilities with Cisco IOS Software
12-25
NetFlow Deployment
There are a large number of NetFlow collectors including Cisco, freeware and third party
commercial products that report and utilize NetFlow data.
NetFlow Reporting Application Examples
NetQos
AdventNet
IBM Aurora
Partner Links:
http://www.cisco.com/warp/public/732/
Tech/nmp/netflow/partners/commercial/
http://www.cisco.com/warp/public/732/
Tech/nmp/netflow/partners/freeware/
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-28
\
Some reporting systems offer a two-tier architecture where collectors are placed near key sites
in the network and they aggregate and forward the data to a main reporting server. Other
solutions use multiple distributed collectors, a central database, a management server, and a
reporting server. Smaller deployments may have a single server for reporting and collection.
There are many Cisco NetFlow reporting products offered. In recent years, many new partners
and solutions are available on both Windows and Linux operating systems. The typical starting
prices for commercial products range from $3500 to greater than $100,000 depending on size
of the enterprise.
Note
For a list of Cisco partners and freeware NetFlow reporting tools, please reference Table 2
and Table 3 in the Cisco Systems white paper “Introduction to Cisco IOS NetFlow - A
Technical Overview” at
http://www.cisco.com/en/US/products/ps6601/products_white_paper0900aecd8040
6232.shtml
12-26
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Where to Apply NetFlow Monitoring
NetFlow is typically used on a central site because all traffic from the remote sites is
characterized and is available within NetFlow.
Where to Apply NetFlow Monitoring
Branch
Data
Center
Branch
Wide Area
Network
WAN Links
TeleWorkers
Branch
NetFlow
Monitoring
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-29
\
The location where NetFlow is deployed depends on the location of the reporting solution and
the topology of the network. If the reporting collection server is centrally located, then
implementing NetFlow close to the reporting collector server is optimal. NetFlow can also be
enabled at remote branch locations with the understanding that the export data will utilize
bandwidth. The two-tier architecture solutions allow remote aggregation of data and can help
manage WAN bandwidth.
NetFlow is in general an ingress measurement technology which should be deployed on
appropriate interfaces on edge/aggregation or WAN access routers to gain a comprehensive
view of originating and terminating traffic to meet customer needs for accounting, monitoring
or network planning data.
Egress NetFlow accounting is available in newer releases of the Cisco IOS software including
release 12.3(11)T and later. The key mechanism for enhancing NetFlow data volume
manageability is careful planning of NetFlow deployment. NetFlow can be deployed
incrementally (i.e. interface by interface) and strategically (i.e. on well chosen routers) instead
of widespread deployment of NetFlow on every router in the network. The network designer
should determine key routers and key interfaces where NetFlow should be activated based on
the customer's traffic flow patterns and network topology and architecture.
Since about 1-5% of the switched traffic is used for export to the collection server, Cisco
recommends careful planning of NetFlow deployment with NetFlow services activated on
strategically located edge/aggregation routers which capture the data required for planning,
monitoring and accounting applications. Some thought needs to be given to exactly which
interfaces should enable NetFlow collection and export so that flows are not double-counted.
© 2007 Cisco Systems, Inc.
Network Management Capabilities with Cisco IOS Software
12-27
Summary
This topic summarizes the key points discussed in this lesson.
\
Summary
NetFlow technology answers the questions of what,
when, where, and how traffic is flowing in the network:
ƒ Looks at a flow, a unidirectional stream of packets between a
given source and destination with specific attributes.
ƒ Measures and creates flow records for traffic flows that are stored
in a cache
ƒ Uses cache management algorithms to export flow data to
reporting servers
ƒ Exports using multiple formats.
– Version 5 is the traditional and most commonly format
– Version 9 is the latest format with key advantages.
ƒ Reports from export data provided by Cisco, freeware, and
commercial products
© 2007 Cisco Systems, Inc. All rights reserved.
12-28
Designing Cisco Network Service Architectures (ARCH) v2.0
ARCH v2.0—11-30
© 2007 Cisco Systems, Inc.
Lesson 3
NBAR Considerations
Overview
Enterprise applications require different levels of service based upon business requirements.
These requirements can be translated into network policies. Network Based Application
Recognition (NBAR) is an important embedded Cisco IOS software technology that provides
visibility into how network assets are being used by applications. This lesson discusses how
NBAR can classify network traffic so that applications can receive the appropriate policy and
bandwidth in the network.
Objectives
Upon completing this lesson, you will be able to discuss design considerations for using NBAR
to support network management. This ability includes being able to meet these objectives:
„
Provide an overview of NBAR
„
Discuss options for reporting NBAR Protocol Discovery statistics
„
Describe how NBAR can be used with AutoQoS for the Enterprise
NBAR Overview
This topic identifies how Network Based Application Recognition (NBAR) supports enterprise
goals for network management with intelligent traffic classification in the network
infrastructure.
Rationale for NBAR Traffic Classification
Traffic classification can answer many questions:
ƒ What applications run on the network and what is their resources
consumption?
ƒ How is application resource utilization tracked?
ƒ Are users following application usage policies?
ƒ How much bandwidth should be assigned to different QoS
classes?
ƒ What plan will allocate and deploy applications (e.g., VoIP) most
efficiently?
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-34
Traffic classification can help organizations answer many questions about network resources:
„
What applications run on the network and what is their resources consumption?
„
How is application resource utilization tracked?
„
Are users following application usage policies?
„
How much bandwidth should be assigned to different QoS classes?
„
What plan will allocate and deploy applications (e.g., VoIP) most efficiently?
NBAR supports the business requirements of an organization by adding classification to the
network to deliver more granular identification and control over multiple Internet-based and
client/server applications, which other QoS mechanisms cannot differentiate.
12-30
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
NBAR Overview
Network-Based Application Recognition (NBAR) is an embedded Cisco IOS Software
capability that enables precise traffic classification.
NBAR Overview
My Application Is
too Slow!
ƒ NBAR provides full-packet,
stateful inspection that identifies
traffic types.
ƒ NBAR Protocol Discovery
discovers application protocol
statistics on interfaces.
ƒ NBAR enables application of
QoS policies to traffic flows.
E-mail
Backup,
etc.
Voice
Best
Effort
= 25%
P2P
Bulk
RealTime
= 33%
InteractiveVideo
Critical
Data
StreamingVideo
Routing
Net Mgmt
Transactional
Call-Signaling
Mission-Critical
Link Utilization
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-35
NBAR is a classification engine that recognizes and classifies a wide variety of protocols and
applications. NBAR provides full packet stateful inspection that identifies applications and
even protocols that use dynamic TCP/UDP port assignments.
NBAR includes an optional feature called NBAR Protocol Discovery. NBAR Protocol
Discovery analyzes application traffic patterns in real time and discovers which traffic is
running on the network. NBAR develops statistics on protocol traffic on interfaces.
NBAR is the foundation for applying quality of service (QoS) policies to traffic flows in the
network. NBAR gives network administrators the ability to see the variety of protocols and the
amount of traffic generated by each protocol. After gathering this information, NBAR allows
the network administrator to organize traffic into classes. These classes can then be used to
provide different levels of service for network traffic, thereby allowing better network
management by providing the right level of network resources for network traffic. After NBAR
recognizes and classifies a protocol or application, the network can be configured to apply the
appropriate QoS for that application or traffic with that protocol.
© 2007 Cisco Systems, Inc.
Network Management Capabilities with Cisco IOS Software
12-31
NBAR Packet Inspection
The NBAR packet classification engine provides full packet inspection that identify
applications and protocols from with information from Layer 3 through Layer 7.
\
NBAR Packet Inspection
IP Packet
ToS
Protocol
TCP/UDP Packet
Source Dest
IP Addr IP Addr
Src
Port
Dst
Port
Data Packet
Sub-Port and Deep Inspection
NBAR supports methods to identify over 90 applications and
protocols:
ƒ Statically assigned TCP and UDP port numbers
ƒ Dynamically assigned TCP and UDP port numbers using stateful
inspection
ƒ Sub-port and deep packet inspection on content within packet
ƒ Native and nonnative PDLMs
Note: NBAR is enabled when a class map with a match protocol
option is applied to an interface.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-36
NBAR uses five elements to identify a flow per interface:
„
Source IP address
„
Destination IP address
„
Source port
„
Destination port
„
Layer 3 protocol type
Note
Traditional NetFlow uses these identifiers for each interface plus Type of Service (ToS).
NBAR has several classification methods to identify over 90 applications and protocols:
12-32
„
Statically assigned TCP and UDP port numbers. NBAR can classify application traffic
by looking at statically assigned TCP and UDP port numbers. Although access control lists
(ACLs) can also be used for classifying static port protocols, NBAR is easier to configure,
and provides classification statistics that are not available when ACLs are used.
„
Dynamically assigned TCP and UDP port numbers. NBAR can also classify
dynamically assigned TCP and UDP port numbers by using stateful inspection of a
protocol across multiple packets during packet classification. NBAR uses approximately
150 bytes of DRAM for each traffic flow that requires stateful inspection.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
„
Sub-port and deep inspection. NBAR looks beyond the port numbers of a packet to
provide sub-port and deep packet classification by looking into the Layer 3 payload itself
and classifying packets based on content within the payload such as the transaction
identifier, message type, or other similar data.
Deep-packet classification is classification performed at a finer level of granularity. For
instance, if a packet is already classified as HTTP traffic, it may be further classified.
Classification of HTTP traffic by URL, host, or Multipurpose Internet Mail Extension
(MIME) type is an example of deep-packet classification. NBAR classifies HTTP traffic by
text within the URL or host fields of a request using regular expression matching. HTTP
URL matching in NBAR supports most HTTP request methods such as GET, PUT, HEAD,
POST, DELETE, and TRACE. The NBAR engine then converts the specified match string
into a regular expression.
„
NBAR can only monitor applications that it recognizes. However, it does allow adding
application recognition modules known as Packet Description Language Modules
(PDLMs) to support additional applications. A nonnative PDLM is a separate
downloadable file available on www.cisco.com used to add support for a protocol that is
currently not available as part of the native PDLM embedded in the Cisco IOS Software
release.
„
NBAR also provides custom protocol support for static port-based protocols and
applications that are not currently supported in NBAR. Ten custom applications can be
assigned using NBAR, and each custom application can have up to 16 TCP and 16 UDP
ports each mapped to the individual custom protocol. The real-time statistics of each
custom protocol can be monitored using Protocol Discovery.
Note
© 2007 Cisco Systems, Inc.
NBAR is enabled by default when class maps with a match protocol option are applied to
an interface.
Network Management Capabilities with Cisco IOS Software
12-33
NBAR Protocol Discovery
NBAR Protocol Discovery provides protocol traffic discovery and real-time statistics.
NBAR Protocol Discovery
Traffic Discovery and Real-Time Statistics
ƒ Automatically discovers traffic for all protocols known to NBAR
ƒ Provides statistics per application, per interface
– Packet counts
– Byte counts
– Bit rate (bps)
Note: NBAR Protocol Discovery is enabled with the ip nbar
protocol-discovery interface configuration command.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-37
\
NBAR Protocol Discovery discovers any protocol traffic that is supported by NBAR and
gathers statistics that are associated with that protocol. NBAR Protocol Discovery maintains the
following per-protocol statistics for enabled interfaces:
„
Total number of input packets and bytes
„
Total number of output packets and bytes
„
Input bit rates
„
Output bit rates
The statistics can then be used to define classes and traffic policies for each traffic class. The
traffic policies or policy maps are used to apply specific QoS features and functionality to the
traffic classes.
Note
12-34
NBAR Discovery is configured with the ip nbar protocol-discovery interface configuration
command.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
NetFlow and NBAR Differentiation
NetFlow and NBAR are complimentary technologies.
\
NetFlow and NBAR Differentiation
Link Layer
Header
Interface
ToS
NetFlow
Protocol
IP
Header
Source
IP Address
Destination
IP Address
TCP/UDP
Header
Source
Port
Data
Packet
Destination
Port
ƒ Monitors data in Layers 2 through
4.
ƒ Determines applications by port.
ƒ Uses 7 key fields for flow.
ƒ Flow information who, what, when,
where for all traffic.
NBAR
Deep Packet
(Payload)
Inspection
NBAR
© 2007 Cisco Systems, Inc. All rights reserved.
NetFlow
ƒ Uses 5 key fields for flow.
ƒ Examines data from Layers 3 & 4
plus packet inspection through
Layer 7 for classification for traffic it
knows about.
ƒ Supports stateful inspection of
dynamic-port traffic.
ƒ Supports QoS mechanisms.
ARCH v2.0—11-38
The main objective of NetFlow is to provide visibility into how network assets are being used
and the network behavior. In traditional NetFlow, flows are defined by a set of seven key
characteristics that document who is using the which part of the network for what purposes at
what times. NetFlow is a passive technology that monitors network activity typically from OSI
Layers 2 through 4. NetFlow data export allows trending of network records.
Note
Flexible NetFlow can monitor packet information from Layer 2 for switching environments,
Layer 3 and 4 for IP information and up to Layer 7 with deep packet inspection for
application monitoring.
The main objective of NBAR is to identify and classify traffic based on payload attributes and
protocol characteristics. Flows are defined by a set of five key characteristics. NBAR can
support by static and stateful dynamic inspections. QoS mechanisms work on the classified
packets to support optimization of application performance. NBAR is an active technology that
can be used to validate or reclassify ToS marking based on packet inspection in OSI Layers 3
through 7. NBAR Protocol Discovery provides an easy way to discover the application
protocols that are operating on an interface that can be queried through SNMP.
© 2007 Cisco Systems, Inc.
Network Management Capabilities with Cisco IOS Software
12-35
Reporting NBAR Protocol Discovery Statistics
NBAR Protocol Discovery statistics can be viewed from the Cisco IOS Software command line
interface (CLI) or through reporting with third party vendor applications.
Reporting NBAR Protocol Discovery
Statistics from the Command Line
router# show ip nbar protocol-discovery interface FastEthernet 6/0
FastEthernet6/0
Input
Protocol
Packet Count
Byte Count
5 minute bit rate (bps)
----------------------------http
316773
26340105
3000
pop3
4437
2301891
3000
snmp
279538
319106191
0
. . .
Total
17203819
19161397327
4179000
© 2007 Cisco Systems, Inc. All rights reserved.
Output
Packet Count
Byte Count
5 minute bit rate (bps)
-----------------------0
0
0
7367
339213
0
14644
673624
0
151684936
50967034611
6620000
ARCH v2.0—11-40
\
The figure shows a portion of the output from the show ip nbar protocol-discovery command
for one Ethernet interface. This command by default displays statistics for all interfaces on
which NBAR Protocol Discovery is currently enabled. The default output from this command
includes, in the following order, input bit rate (in bits per second), input byte count, input
packet count, and protocol name.
An option on this command is to show the top-n number most active NBAR-supported
protocols, where number is the number of protocols to be displayed. For instance, if top-n 3 is
entered, the three most active NBAR supported protocols will be displayed.
Protocol discovery can be used to monitor both input and output traffic and may be applied
with or without a service policy enabled. NBAR Protocol Discovery gathers statistics for
packets switched to output interfaces.
Note
12-36
These statistics are not necessarily for packets that exited the router on the output
interfaces, because packets may have been dropped after switching for various reasons,
including policing at the output interface, access lists, or queue drops.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
AdventNet NetFlow Analyzer
ARCH v2.0—11-41
© 2007 Cisco Systems, Inc. All rights reserved.
\
Example: AdventNet NetFlow Analyzer
The figure shows a screen shot from AdventNet NetFlow Analyzer application that uses the
NBAR Discovery Protocol information.
© 2007 Cisco Systems, Inc.
Network Management Capabilities with Cisco IOS Software
12-37
Concord|CA eHealth Top Protocol
Distribution
Drill-down
report
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-42
Example: Concord eHealth
The figure shows a screen shot from Concord eHealth application that shows the top protocol
distribution from the NBAR Discovery Protocol statistics.
12-38
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
InfoVista VistaView™
Traffic Monitoring
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-43
Example: InfoVista VistaView
The figure shows a screen shot from the InfoVista VistaView application.
© 2007 Cisco Systems, Inc.
Network Management Capabilities with Cisco IOS Software
12-39
Micromuse Netcool Proviso
Top-N Protocol Statistics
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-44
Example: Micromuse Netcool Proviso
The figure shows a screen shot from Micromuse Netcool Proviso application. It shows the
Top-N 8 protocol statistics. This information allows the network manager to identify the traffic
mix on a specific link, and understand what applications are consuming bandwidth.
12-40
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
MRTG—NBAR Support
MRTG Graphing Support for NBAR
http://www.eatworms.org.uk/cacti/cisco-nbar.php
http://vermeer.org/display_doc.php?doc_id=6
http://www.somix.com/products/denika_nbar.php
ARCH v2.0—11-45
© 2007 Cisco Systems, Inc. All rights reserved.
Example: MRTG Support for NBAR
The figure shows an example screen shot using the Cacti Multi Router Traffic Grapher
(MRTG) freeware to graph NBAR Protocol Discovery statistics. The MRTG tool uses the
Vermeer add-on to report on NBAR data collected through SNMP from routers.
© 2007 Cisco Systems, Inc.
Network Management Capabilities with Cisco IOS Software
12-41
NBAR and AutoQoS
The AutoQoS feature of Cisco IOS Software is supported with NBAR.
\
NBAR and AutoQoS
ƒ Cisco IOS AutoQos feature has two flavors:
– AutoQoS for VoIP creates pre-defined policy maps for voice
traffic.
– AutoQoS Enterprise uses NBAR discovery mode to gather
traffic statistics, then creates a policy map based on the
detected traffic with suggested bandwidth settings per class.
ƒ Two modes to handle traffic classification:
– Trusted mode relies on existing preset DSCP.
– Untrusted mode discovers applications by leveraging NBAR.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-47
Cisco IOS Software includes two features to automate the deployment of QoS in the network:
„
AutoQoS—Voice over IP (VoIP). This feature is available with Cisco IOS Software release
12.2(15)T and later releases. The AutoQoS—VoIP feature provides a means for
simplifying the implementation and provisioning of QoS for VoIP traffic.
„
AutoQoS for the Enterprise. This feature is available with Cisco IOS Software release
12.3(11)T and later releases. The AutoQoS for the Enterprise feature helps automate the
deployment of QoS in a general business environment, particularly for midsize companies
and branch offices of larger companies. It expands on the functionality available with the
AutoQoS—VoIP feature and supports QoS features required for voice, video, and data
traffic. This feature creates class maps and policy maps on the basis of Cisco experience
and "best practices" methodology after using NBAR discovery on lower speed WAN links.
Both of these AutoQoS features can take advantage of the traffic classification functionality of
NBAR. When AutoQoS is configured on an interface with the trust option, the differentiated
services code point (DSCP) markings of a packet are relied on for classification of the voice
traffic. If the optional trust keyword is not specified, the voice traffic is classified using
NBAR, and the packets are marked with the appropriate DSCP value.
12-42
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Cisco AutoQoS for Enterprise
The AutoQoS for the Enterprise feature consists of a two phase configuration process.
Cisco AutoQoS for Enterprise
Two phase procedure:
1. Invoke auto discovery qos
command on the applicable link.
– Use show auto discovery
qos command to view data
collection in progress.
2. Automatically configure the link
with auto qos command.
– Use show auto qos
command to display the QoS
policy settings deployed.
© 2007 Cisco Systems, Inc. All rights reserved.
Traffic Class
DSCP
IP Routing
CS6
Interactive Voice
EF
Interactive Video
AF41
Streaming Video
CS4
Telephony Signaling
CS3
Transaction/Interactive
AF21
Network Management
CS2
Bulk Data
AF11
Best Effort
0
Scavenger
CS1
ARCH v2.0—11-48
\
In the first phase, Auto-Discovery collects data and evaluates traffic in the network. The
Auto-Discovery phase is started by using the auto discovery qos [trust] command:
„
In the untrusted mode, the Auto-Discovery phase uses NBAR protocol discovery to detect
and classify the applications on the network and perform statistical analysis on the network
traffic.
„
In the trusted mode, the Auto-Discovery phase classifies packets based on DSCP values in
the IP header and collects the NBAR Protocol Discovery statistics to calculate bandwidth
and average rate/peak rate and passes that data to the template module.
The data should be collected for several days to a week as desired. The show auto discovery
qos command should be used to display the results of the data collected during the
Auto-Discovery phase.
In the second phase, the AutoQoS template generation and installation process generates
templates from the data collected during the Auto-Discovery phase and installs the templates on
the interface. These templates can be used as the basis for creating the class maps and policy
maps for the network. The recommended policy is based on Auto-Discovery statistics. After the
class maps and policy maps are created with values for bandwidth and scheduling parameters,
they are then installed on the interface.
Note
© 2007 Cisco Systems, Inc.
These class maps and policies should be reviewed by a network manager. Although the
process creates some suggested class maps and policy maps, these are typically
customized by the network manager.
Network Management Capabilities with Cisco IOS Software
12-43
The AutoQoS template generation phase is started by using the auto qos command. The class
maps and policy maps should be reviewed by using the show auto qos command.
Example: AutoQoS Discovery Progress
router# show auto discovery qos
AutoQoS Discovery enabled for applications
Discovery up time: 2 days, 55 minutes
AutoQoS Class information:
Class VoIP:
Recommended Minimum Bandwidth: 517 Kbps/50% (PeakRate)
Detected applications and data:
Application/
AverageRate
PeakRate
Total
Protocol
(kbps/%)
(kbps/%)
(bytes)
rtp audio
76/7
517/50
703104
Class Interactive Video:
Recommended Minimum Bandwidth: 24 Kbps/2% (AverageRate)
Detected applications and data:
Application/
AverageRate
PeakRate
Total
Protocol
(kbps/%)
(kbps/%)
(bytes)
rtp video
24/2
5337/52
704574
Class Transactional:
Recommended Minimum Bandwidth: 0 Kbps/0% (AverageRate)
Detected applications and data:
Application/
AverageRate
PeakRate
Total
Protocol
(kbps/%)
(kbps/%)
(bytes)
citrix
36/3
74/7
30212
sqlnet
12/1
7/<1
1540
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-49
\
Example: AutoQoS Discovery Progress
The figure shows a sample result from the AutoQoS Discovery process.
By default, the NBAR mechanisms do not show unclassified traffic. The show ip nbar
unclassified-port-stats command returns the following error message:
router1# show ip nbar unclassified-port-stats
Port Statistics for unclassified packets is not turned on.
Under carefully controlled circumstances, you can use the debug ip nbar unclassified-portstats command to configure the router to begin tracking on which ports that packets arrive.
Then the show ip nbar unclassified-port-stats command is used to verify the collected
information. The output will display a histogram of the most commonly used ports.
Note
12-44
Using NetFlow is to look at the unclassified traffic is typically a better practice, with less
potential for overloading the router CPU.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Example: AutoQoS Suggested Policy
Suggested AutoQoS Policy for the current uptime:
!
class-map match-any AutoQoS-Voice-Et3/1
match protocol rtp audio
!
class-map match-any AutoQoS-Inter-Video-Et3/1
match protocol rtp video
!
class-map match-any AutoQoS-Signaling-Et3/1
match protocol sip
match protocol rtcp
!
class-map match-any AutoQoS-Transactional-Et3/1
match protocol citrix
!
class-map match-any AutoQoS-Bulk-Et3/1
match protocol exchange
policy-map AutoQoS-Policy-Et3/1
class AutoQoS-Voice-Et3/1
priority percent 1
set dscp ef
class AutoQoS-Inter-Video-Et3/1
bandwidth remaining percent 1
set dscp af41
class AutoQoS-Signaling-Et3/1
bandwidth remaining percent 1
set dscp cs3
ARCH v2.0—11-50
© 2007 Cisco Systems, Inc. All rights reserved.
Example: AutoQoS Suggested Policy
The figure shows a suggested policy from the AutoQoS template generation process.
© 2007 Cisco Systems, Inc.
Network Management Capabilities with Cisco IOS Software
12-45
Summary
This topic summarizes the key points discussed in this lesson.
Summary Information
ƒ NBAR is an embedded Cisco IOS Software capability that
enables precise traffic classification to support QoS functions.
NBAR Protocol Discovery provides protocol traffic discovery and
real-time statistics available through SNMP.
ƒ NBAR Protocol Discovery statistics can be viewed from the
command line or through third party vendors applications.
ƒ The two phase configuration process for AutoQoS for the
Enterprise feature uses data collected from NBAR to create and
templates on the interfaces. These templates are used as the
basis for creating the class maps and policy maps for the network.
© 2007 Cisco Systems, Inc. All rights reserved.
12-46
Designing Cisco Network Service Architectures (ARCH) v2.0
ARCH v2.0—11-51
© 2007 Cisco Systems, Inc.
Lesson 4
IP SLA Considerations
Overview
Enterprises are under increasing pressure to offer Service Level Agreements (SLAs) to their
internal customers or other departments or verify and measure outsourced SLAs. The
embedded Cisco IOS IP SLA measurements capability allows network managers to validate
network performance, proactively identify network issues, and verify service guarantees by
using active monitoring to generate probe traffic in a continuous, reliable, and predictable
manner. This lesson will discuss the integrated IP SLA measurements can be used to support
network management functions.
Objectives
Upon completing this lesson, you will be able to identify design considerations with Cisco IOS
IP SLA measurements. This ability includes being able to meet these objectives:
„
Discuss capabilities of Cisco IOS IP SLA measurements
„
Describe IP SLA measurements deployments
„
Discuss network management applications using IP SLA measurements
IP SLA Technology Overview
This topic describes the basic characteristics of IP SLA measurements.
Service Level Agreement Review
ƒ Companies need predictability with regard to IP services as networks
becoming increasingly important.
ƒ An SLA is a contract between the provider and its customers:
– Provides a guarantee with regard to service level
– Specifies connectivity and performance agreements for an
end-user service
– Supports problem isolation and network planning
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-55
The network has become increasingly critical for customers, and any downtime or degradation
can adversely impact revenue. Companies need some form of predictability with regard to IP
services.
A service level agreement (SLA) is a contract between the network provider and its customers,
or between a network department and internal corporate customers. It provides a form of
guarantee to customers with regard to the level of user experience.
An SLA specifies connectivity and performance agreements for an end-user service from a
provider of service. The SLA will typically outline the minimum level of service and the
expected level of service. The networking department can use the SLAs to verify that the
service provider is meeting its own SLAs, or to define service levels for critical business
applications. An SLA can also be used as the basis for planning budgets and justifying network
expenditures. Administrators can ultimately reduce the mean time to repair by proactively
isolating network issues. They can change the network configuration based on optimized
performance metrics.
12-48
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Typically, the technical components of an SLA contain: a guarantee level for network
availability; network performance in terms of round trip time; and network response in terms of
latency, jitter, and packet loss. The specifics of an SLA varies depending on the applications an
organization is supporting in the network.
Example: Multimedia Service Requirements
Traffic Type
Maximum
One-Way
Latency
150 ms
30 ms
Video-conferencing 1 %
150 ms
30 ms
Streaming video
5s
N/A
VoIP
Maximum
Packet Loss
1%
2%
Max. Jitter
ARCH v2.0—11-56
© 2007 Cisco Systems, Inc. All rights reserved.
Example: Multimedia Service Requirements
For example, converged IP networks must become optimized for performance levels.
Administrators can use a variety of benchmarks, including delay, packet loss, jitter, packet
sequencing and connectivity to gauge the quality of service received by the end user.
One-way delay is the difference between the time the test packet goes out and the time when
the test packet arrives at the responder. Jitter is the variance of delay. The figure shows typical
multimedia media service requirements which are more stringent that data only requirements.
© 2007 Cisco Systems, Inc.
Network Management Capabilities with Cisco IOS Software
12-49
Cisco IOS IP SLA Measurements
Cisco IOS IP SLA network performance measurements within and between Cisco devices
allow Cisco customers to understand IP service levels for IP applications and services.
\
Cisco IOS IP SLA Measurements
Uses
Availability
Network
Performance
Monitoring
VoIP
Monitoring
SLA
Monitoring
Network
Assessment
MPLS
Monitoring
Trouble
Shooting
Measurement Metrics
Latency
Packet
Loss
Network
Jitter
Dist. of
Stats
Connectivity
Operations
Jitter
FTP
DNS DHCP DLSW ICMP
UDP
TCP
HTTP
LDP
H.323
SIP
RTP
IP Server
Cisco IOS
Software
IP SLA
Source
Cisco IOS
Software
IP SLA
IP Server
MIB Data
Active Generated Traffic to
Measure the Network
© 2007 Cisco Systems, Inc. All rights reserved.
Destination
Cisco IOS
Software
IP SLA
Responder
ARCH v2.0—11-57
The IP SLA measurement functionality in Cisco IOS allows configuration of a router to send
synthetic traffic to a host computer or a router that has been configured to respond. One-way
travel times and packet loss data is gathered. Certain measurements also allow jitter data to be
collected.
There are several common functions for IP SLA measurements:
12-50
„
Edge-to-edge network availability monitoring
„
Network performance monitoring and network performance visibility
„
Voice-over-IP (VoIP), video, and VPN network monitoring
„
SLA monitoring
„
IP service network health readiness or assessment
„
Multiprotocol Label Switching (MPLS) network monitoring
„
Troubleshooting of network operation
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Cisco IOS IP SLA measurements uses a variety of operations and actively generated traffic
probes to gather many types of measurement statistics including:
„
Network latency and response time
„
Packet loss statistics
„
Network jitter and voice quality scoring
„
Statistical end-to-end matrix of performance information
„
End-to-end network connectivity
Multiple IP SLA operations (measurements) can be running in a network at one time. Reporting
tools use SNMP to extract the data into a database, and then report on it.
IP SLA measurements allow the network manager to verify service guarantees, increases
network reliability by validating network performance, proactively identifies network issues,
and eases the deployment of new IP services.
© 2007 Cisco Systems, Inc.
Network Management Capabilities with Cisco IOS Software
12-51
Cisco IOS IP SLA Measurements Capability
SLAs that support application solutions are becoming an increasingly common requirement,
and measurement of SLAs in the IP infrastructure are becoming an essential part of optimizing
the network for business.
Cisco IOS IP SLA Measurement Capability
Enterprise and Small Medium Business
Understand Network
Performance and
Ease Deployment
Access
Enterprise
Backbone
Service Providers
Verify Service Levels
Verify Outsourced SLAs
Enterprise
Premise Edge
Measure and provide
SLAs
Service Provider
Aggregation Edge
Service
Provider Core
Cisco IOS Software
ƒ Comprehensive hardware support
ƒ Committed Cisco partner support
ƒ Cisco IOS Software, the world’s leading network infrastructure
software
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-58
\
The embedded Cisco IOS IP SLA measurement capability supports a network that is
"performance-aware". Using IP SLA measurements, Cisco network equipment can verify
service guarantees, validate network performance, improve network reliability, proactively
identify network issues, and react to performance metrics with changes to the configuration and
network.
The Cisco IOS IP SLA measurement capability has comprehensive hardware support. Other
than the Cisco Catalyst 4500 Series switches, all Cisco hardware that run Cisco IOS Software
support Cisco IOS IP SLA measurements. IP SLA measurements data collection and reporting
support is included in several third-party partner performance management products.
Since Cisco IOS IP SLA measurements is embedded within Cisco IOS Software, there is no
additional device to deploy, learn, or manage. As dependable tools used to verify IP service
levels, Cisco IOS IP SLA measurements provide a scalable, cost-effective solution for network
performance measurement.
Note
12-52
Cisco IOS IP SLA measurements, a core part of the Cisco IOS Software portfolio, has grown
from technology previously known as Cisco IOS Service Assurance Agent (SAA). IP SLA
measurements perform active monitoring by generating and analyzing traffic to measure
performance between Cisco IOS Software devices or to network application servers.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
IP SLA Source and Responder
IP SLA operations are divided into two classes, which depend on whether they rely on the IP
SLA Responder component to be running at the target device or not.
IP SLA Source and Responder
IP SLA Source
ƒ Cisco IOS software device that sends data for operation.
– Target device may or may not be a Cisco IOS software device.
– Some operations require an IP SLAs responder.
ƒ IP SLAs source stores results in MIB.
IP SLA Responder
ƒ Greater measurement accuracy is available between a IP SLAs source and
responder.
ƒ IP SLA Responder is a Cisco IOS software device configured to responds to IP
SLA packets based on the ip sla monitor responder configuration command.
IP SLA Operations
ƒ Network manager defines UDP/TCP port for each IP SLA measurement operation.
ƒ IP SLA control protocol is used between source and responder.
ƒ MD 5 authentication is supported between source and responder.
ƒ Results are stored on IP SLA source in the IP SLA MIB.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-59
\
You set up an IP SLA operation to a target device. If the operation is something like DNS or
HTTP, the target device might be any suitable computer. For operations such as testing the port
used by a database, an organization might not want to risk unexpected effects, and would use
the IP SLA Responder functionality to have a router respond in place of the actual database
server. Responder functionality can be enabled in a router with one command, and requires no
complex or per-operation configuration.
The IP SLA Source is where all IP SLA measurements probe operations are configured either
by the command line interface or through an SNMP tool that supports IP SLA operation. The
source is also the Cisco IOS device that sends probe packets. The destination of the probe may
be another Cisco router or another network target such as a web server or IP host.
Although the destination of the probe can be any IP device, the measurement accuracy is
improved with a Cisco IOS IP SLA Responder. An IP SLA Responder is a device that runs
Cisco IOS Software and is configured as an IP SLA measurements responder with the ip sla
monitor responder configuration command.
The network manager configures a target device, protocol, and port number on the IP SLA
Source for each operation. The source uses the IP SLA Control Protocol to communicate with
responder before sending test packets. To increase security on Cisco IOS IP SLA
measurements control messages, the responder can utilize MD5 authentication for securing the
control protocol exchange. Once the operation is finished and the response is received, the
results are stored in the IP SLA MIB on the source, and are retried using SNMP.
© 2007 Cisco Systems, Inc.
Network Management Capabilities with Cisco IOS Software
12-53
IP SLA Operation With Responder
This section discusses an IP SLA operation in a network with a IP SLA Responder.
IP SLA Operation With Responder
IP SLA Source
IP SLA Responder
Control Message Ask Receiver to
Open Port 2020 on UDP
IP SLA-Control
UDP, 1967
Responder Says OK
Control
Phase
Sending Test Packets…
Start Listening on
UDP Port 2020
IP SLA-Test
UDP, 2020
Probing
Phase
Done: Stop Listening
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-60
\
The network manager configures an IP SLA operation by defining a target device, protocol,
and port number on the IP SLA Source. The network manager can also configure reaction
conditions. The operation is scheduled to be run for a period of time to gather statistics. The
following sequence of events occurs for each Cisco IOS IP SLA operation that requires a
responder on the target:
1. At the start of the control phase, the IP SLA Source sends a control message with the
configured IP SLA operation information to IP SLA control port UDP 1967 on the target
router. The control message carries information such as protocol, port number, and
duration.
—
If MD5 authentication is enabled, MD5 checksum is sent with the control message.
—
If the authentication of the message is enabled, the responder verifies it; if the
authentication fails, the responder returns an authentication failure message.
—
If the Cisco IOS IP SLA measurement operation does not receive a response from a
responder, it tries to re-transmit the control message and eventually times out.
2. If the responder processes the control message, it sends an okay message to the source
router and listens on the port specified in the control message for a specified duration. If the
responder cannot process the control message, it returns an error. In the figure, UDP port
2020 will be used for the IP SLA test packets.
Note
12-54
The responder is capable of responding to multiple Cisco IOS IP SLA measurements
operations that try to connect to the same port number.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
3. If the return code of control message is ok, then the Cisco IOS IP SLA operation moves to
the probing phase where it will send one or more test packets to the responder for
response time computations. The return code is available in the show ip sla statistics
command. In the figure, these test message are sent on control port 2020.
4. The responder accepts the test packets and responds. Based on the type of operation, the
responder may add an in timestamp and an out timestamp in the response packet payload to
account for CPU time spent in measuring unidirectional packet loss, latency, and jitter to a
Cisco device. These timestamps help the Cisco IOS IP SLA Source to make accurate
assessments on one-way delay and the processing time in the target routers. The responder
disables the user-specified port once it responds to the Cisco IOS IP SLA measurements
packet, or when a specified time expires.
IP SLA Responder Timestamps
IP SLA Source
IP SLA Responder
T2
T1
T3
T5
T4
CPU
CPU
∆ = T3-T2
ƒ IP SLA Responder takes two timestamps (T2 and T3)
ƒ IP SLA Responder factors out destination processing time,
making results highly accurate.
ƒ IP SLA Responder allows for one-way measurements for latency,
jitter, and packet loss.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-61
\
IP SLA Responder Time Stamps
The figure illustrates the use of IP SLA Responder timestamps in round-trip calculations. The
IP SLA Source will use four timestamps for the round-trip time calculation. The IP SLA Source
sends a test packet at time T1.
The IP SLA Responder includes both the receipt time (T2) and the transmitted time (T3).
Because of other high-priority processes, routers can take tens of milliseconds to process
incoming packets. The delay affects the response times, because the reply to test packets might
be sitting in a queue while waiting to be processed. his time stamping is made with a
granularity of submilliseconds. At times of high network activity, an ICMP ping test often
shows a long and inaccurate response time, while an IP SLA-based responder shows an
accurate response time. The IP SLA Source subtracts T2 from T3 to produce the time spent
processing the test packet in the IP SLA Responder. This time is represented by a delta value.
The delta value is then subtracted from the overall round-trip time.
The same principle is applied by IP SLA Source where the incoming T4 is also taken at the
interrupt level to allow for greater accuracy as compared to T5 when the packet is processed.
© 2007 Cisco Systems, Inc.
Network Management Capabilities with Cisco IOS Software
12-55
An additional benefit of two timestamps at the IP SLA Responder is the ability to track
one-way delay, jitter, and directional packet loss. These statistics are critical because a great
deal of network behavior is asynchronous. To capture one-way delay measurements, the
configuration of both IP SLA Source and IP SLA Responder with Network Time Protocol
(NTP) is required. Both the source and target need to be synchronized to the same clock source.
The Cisco IOS IP SLA Responder provides enhanced accuracy for measurements, without the
need for dedicated third-party external probe devices. It also provides additional statistics,
which are not otherwise available via standard ICMP based measurements.
12-56
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
IP SLA SNMP Features
This section discusses some of the SNMP features of Cisco IOS IP SLA measurements.
\
IP SLA SNMP Features
ƒ Is an active measurement tool.
ƒ Uses RTTMON-MIB for data storage from operations:
– Jitter and packet loss ratio are the two most commonly polled
statistics.
Management
Application
– IP SLAs support classes of services using DSCP.
ƒ Supports proactive notification and actions.
– Thresholds can trigger SLA operation
activation for further analysis.
IP
M
Host ea
SNMP
Trap
su
r
Collect
Present
e
Cisco IOS
IP SLA
© 2007 Cisco Systems, Inc. All rights reserved.
Measure
Measure
(IP SLA Responder)
IP SLADevice
ARCH v2.0—11-62
As compared to NetFlow which passively monitors the network, Cisco IOS IP SLA
measurements actively sends data across the network to measure performance between multiple
network locations on a hop-by-hop basis or across end-to-end network paths. The IP SLA
measurements are accessible through SNMP.
The Cisco Response Time Monitor MIB (Cisco-RTTMON-MIB) is the MIB used with IP SLA
measurements. The data from the Cisco IOS IP SLA operations is stored within the RTTMON
MIB. Network management system applications can retrieve network performance statistics
from this MIB. Network managers can build custom equations to monitor specific statistics.
The MIB can store measurements over a period of time. Cisco IOS IP SLA measurements can
be configured to monitor different classes of services over the same link, if the differentiated
services code point (DSCP) bits are configured with the ToS command. This command is
supported by all Cisco IOS IP SLA measurements operations. The feature is available in
Release 12.2T and all subsequent releases.
In addition, Cisco IOS IP SLA measurements provides a proactive notification feature with an
SNMP trap. Each measurement operation can monitor against a pre-set performance threshold
such as threshold packet loss, latency, and jitter were relevant. Cisco IOS IP SLA
measurements generates an SNMP trap to alert management applications if this threshold is
crossed. Available thresholds include round trip time, average jitter, one-way latency, jitter,
packet loss, mean opinion score (MOS), and connectivity tests. Administrators
can also configure Cisco IOS IP SLA measurements to run a new SNMP operation
automatically when the threshold is crossed after a configurable number of times. For instance,
when latency exceeds a threshold three times this can trigger a secondary operation to measure
hop-by-hop latency to isolate the problem area in the network.
© 2007 Cisco Systems, Inc.
Network Management Capabilities with Cisco IOS Software
12-57
Deploying IP SLA Measurements
Different IP SLA operations are needed to support different deployment profiles.
Deployment Profiles for IP SLAs
Data
Traffic
Requirement
ƒ Minimize
ƒ Minimize
delay,
delay,
packet
packet
loss
loss, jitter
ƒ Verify QoS
IP SLA
Measurement
ƒ Jitter
ƒ Packet
loss
ƒ Latency
SLA
Verification
VoIP
ƒ
ƒ
ƒ
ƒ
Jitter
Packet loss
Latency
MOS voice
Quality
score
ƒ Measure
delay, packet
loss, jitter
ƒ One-way
ƒ
ƒ
ƒ
ƒ
ƒ
Jitter
Packet loss
Latency
One-way
Enhanced
accuracy
ƒ NTP
© 2007 Cisco Systems, Inc. All rights reserved.
Availability
Streaming
Video
ƒ Connectivity ƒ Minimize
testing
delay,
packet loss
ƒ Connectivity ƒ Jitter
tests to IP
ƒ Packet loss
devices
ƒ Latency
ARCH v2.0—11-64
The first step in IP SLA deployment involves answering the question of what needs to be
monitored. A variety of operation types are supported by the Cisco IOS IP SLA measurements.
The most common operation used is UDP jitter which measures IP performance for UDP
performance-sensitive applications. The table shows the requirements and common IP SLA
measurements for several network profiles.
For example, data only deployments typically seek to minimize delay and packet loss. They
may obtain the jitter, packer loss, and latency measurements using the UDP jitter operation.
With the addition of real-time traffic such as VoIP, the focus shifts not just in the reliability of
the network, but also on the delays involved in transmitting the data. Real-time traffic is delay
sensitive. For VoIP traffic, packet loss is manageable to some extent, but frequent losses impair
communication between endpoints. The UDP jitter operation is the again most popular
operation because the user can obtain packet loss, jitter and latency from one operation. This
also includes unidirectional measurements as well. VoIP networks may also measure MOS
Voice Quality scores.
12-58
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Impact of QoS on IP SLA Statistics
The IP SLA statistics is effected by QoS in the network.
IP SLAs Data Before QoS Deployment
DstlPadd
TOS
SD
Latency
DS
Latency
173.100.21.2
10.0.227.12
0
55
45
173.100.3.2
10.0.227.12
0
42
35
173.100.20.2
10.0.227.12
0
66
70
173.100.6.2
10.0.227.12
0
73
69
SrclPadd
SD
Packet
Loss
DS
Packet
Loss
SD
Jitter
DS
Jitter
5
0
28
22
105
30
23
8
144
28
34
22
20
10
11
9
The Flow in Red Will Be Tracked Before QoS Deployment
ƒ One Class of Service is used.
ƒ Results are a statistical sampling over time based on frequency of
measurements.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-65
\
This figure shows the IP SLA statistics for a particular flow before QoS is deployed in the
network. For ToS=0, the results show a statistical sampling over time based on the frequency of
measurements.
© 2007 Cisco Systems, Inc.
Network Management Capabilities with Cisco IOS Software
12-59
IP SLA Data After QoS Deployment
SrclPadd
DstlPadd
TOS
SD
Latency
DS
Latency
SD
Packet
Loss
DS
Packet
Loss
SD
Jitter
DS
Jitter
173.100.21.2
10.0.227.12
EF
15
32
0
0
5
3
173.100.21.2
10.0.227.12
CS6
55
45
20
0
22
21
173.100.21.2
10.0.227.12
AF41
45
48
0
0
32
30
173.100.21.2
10.0.227.12
CS4
48
74
0
0
25
33
173.100.21.2
10.0.227.12
CS3
39
45
0
0
25
28
173.100.21.2
10.0.227.12
AF21
45
75
22
20
41
35
173.100.21.2
10.0.227.12
CS2
99
75
100
45
28
35
173.100.21.2
10.0.227.12
AF11
99
75
75
100
46
35
173.100.21.2
10.0.227.12
CS1
99
75
99
45
33
35
173.100.21.2
10.0.227.12
0
99
75
100
190
51
64
173.100.3.2
10.0.227.12
0
42
35
105
30
23
8
173.100.20.2
10.0.227.12
0
66
70
144
28
34
22
173.100.6.2
10.0.227.12
0
73
69
20
10
11
9
ƒ A measurement is set up for each class of service monitored.
ƒ This demonstrates how QoS is working end-to-end.
ƒ Performance per class verifies QoS working well.
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-66
This figure shows the IP SLA statistics the same operation across multiple flows after QoS is
deployed in the network. In this case, a measurement is developed for each class of service
monitored. The varied results per ToS show that the performance per class is working
end-to-end across the network.
In general, QoS is about preferential treatment for certain traffic classes. If all your traffic is
getting the same treatment, either the network is not congested, or your QoS configuration is
not working properly at some point in the path.
12-60
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Scaling IP SLA Deployments
Processing power for IP SLA operations may be a concern when there is a large amount of
switching traffic passing through an IP SLA source.
Scaling IP SLA Deployments
ƒ Processing power for IP SLA operations is a scaling concern.
ƒ Shadow routers can be dedicated to sourcing Cisco IOS IP SLAs
operations.
– Hub site has in large hub and spoke networks has the shadow
router.
– Spokes respond to the shadow routers IP SLA packets.
ƒ Several advantages to deploying a dedicated router:
– Separate memory and CPU from hardware in switching path
– Easy upgrade of Cisco IOS Software release on the
dedicated router
– Management and deployment flexibility
– Scalability with a large number of endpoints
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-67
In these cases, it is necessary to cut down on the frequency of the sampling interval or use a
dedicated SLA router to perform the IP SLA measurements operations.
The dedicated router (or shadow router) is used when the number of operations is high for an IP
SLA Source, such as for hundreds or thousands of measurements. A shadow router is simply a
router dedicated to sourcing Cisco IOS IP SLA measurements operations. Dedicated routers are
often deployed in large hub and spoke networks at the hub site, where spokes respond to IP
SLA packers from the shadow router. The advantages of deploying a dedicated router include:
„
Separate memory and CPU from hardware in switching path. The dedicated router focuses
on IP SLA operations.
„
Easy upgrade of Cisco IOS Software release on the dedicated router. Upgrades to the
shadow router will not affect production traffic.
„
Management and deployment flexibility. Shadow routers can be deployed at the hub site or
at regional aggregation locations.
„
Allows scalability with a large number of endpoints. A dedicated router provides the
benefit of polling a central source location.
© 2007 Cisco Systems, Inc.
Network Management Capabilities with Cisco IOS Software
12-61
Hierarchical Monitoring with IP SLA Measurements
For a large scale IP SLA enterprise monitoring, a hierarchical strategy may be needed.
Hierarchical Monitoring with IP SLAs
Corp. HQ
Data Center
Regional
Aggregation
Remote
Campus
Home
Office
Retail
Branch
Network Connectivity
Server Connectivity
© 2007 Cisco Systems, Inc. All rights reserved.
Small
Office
ARCH v2.0—11-68
\
If the number of sites is extremely large, then the number of measurements for connectivity to
every remote may be prohibitive for even a dedicated router. You can use dedicated routers at
multiple points in the network. Another method to support large scale enterprises is to have a
series of measurements in a hierarchical design. Many dedicated routers are also used in large
service provider networks for point-of-presence (POP)-to-POP measurements or from the POP
to the customer premises equipment (CPE) routers. The hierarchical approach allows regional
aggregation routers to be the source of IP SLA measurements traffic for access routers in each
region. A centralized router is the source of IP SLA traffic to the regional aggregation routers.
Potential round trip times can be summed to give an approximate answer for end-to-end
measurement. With a hierarchical deployment, the network manager will still look for issues on
individual measurement as the reporting tools might not correlate end-to-end times, but
threshold violations on single links are all that an operations group typically needs to detect
problems.
12-62
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Network Management Applications Using IP SLA
Measurements
Cisco IOS IP SLA is supported by both Cisco applications and a wide range of vendor partners
that report and utilize IP SLA data.
Cisco and Partners IOS IP SLA
Applications
Cisco Network Management Solutions
IP Communications Service
Telephony monitoring
Monitor
Enterprise performance
Internetwork Performance Monitor
measurements
Third Party Products
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-70
The figure shows some of the network management products that use IP SLA measurements.
© 2007 Cisco Systems, Inc.
Network Management Capabilities with Cisco IOS Software
12-63
Example: CiscoWorks IPM Application
© 2007 Cisco Systems, Inc. All rights reserved.
ARCH v2.0—11-71
Example: CiscoWorks IPM Application
The figure shows some images from the CiscoWorks Internetwork Performance Monitor
(IPM). IPM is a network response-time and availability troubleshooting application that
measures network performance based on the traffic-generation technology within Cisco IOS IP
SLA. CiscoWorks IPM facilitates performance measurement of differentiated services (for
example, voice, video, and data) in an enterprise network.
CiscoWorks IPM helps the network engineer to proactively monitor network response time for
problems. CiscoWorks IPM notifies the network engineer when response time degrades or a
monitored link becomes unavailable, and helps pinpoint the link causing the problem.
IPM allows the network manager the ability to define a collector consisting of one or many IP
SLA Sources, many IP SLA Responders, and many IP SLA operations. I
12-64
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Network Management Application Considerations
There are several design considerations involved in selecting a network management
application to use with IP SLA measurements.
Network Management Application
Considerations
Provisioning
ƒ Does the tool provision IP SLA (easily), or do you have to do it via
CLI?
ƒ How much effort in turning on many IP SLA measurements?
Reporting
ƒ What does the tool support for IP SLA data collection and reports?
ƒ Easy to set up and maintain?
Hierarchy
ƒ Does the tool support aggregate of hierarchical measurements for
a more scalable set of measurements?
ARCH v2.0—11-72
© 2007 Cisco Systems, Inc. All rights reserved.
\
Network mangers should consider how the network management application supports
provisioning IP SLA operations:
„
Does the network management tool provision IP SLA easily, or is manual configuration
using CLI needed for every IP SLA source and responder? For large deployments, manual
configuration of every device should be avoided. Looking at the details is important,
because some applications may emphasize reporting over initial configuration.
„
How much effort is involved in enabling many IP SLA measurements? Ease of use will
promote use of applications.
Network mangers should also consider how the network management application supports
reporting on IP SLA operations:
„
What does the application support for IP SLA data collection and reports? A variety of
predefined and customizable reports help provide quick views of the results.
„
Is the application easy to set up and maintain? Again, ease of use is often directly related to
how often the application gets used.
Hierarchical reporting is becoming a more important consideration:
„
Does the tool support aggregation of hierarchical measurements for a more scalable set of
measurements? At this time, there are few if any products that support automated
aggregation of hierarchical IP SLA data.
© 2007 Cisco Systems, Inc.
Network Management Capabilities with Cisco IOS Software
12-65
Summary
This topic summarizes the key points discussed in this lesson.
Summary
ƒ The embedded Cisco IOS IP SLAs capability provides end-to-end
performance measurements by generating traffic. Jitter, packet
loss, and latency are key measurements.
ƒ In IP SLA deployments, IP SLAs measures are performed
between an IP SLA Source and a destination (IP host or IP SLA
Responder.) Dedicated shadow routers and hierarchical
deployments help scale IP SLA.
ƒ Both Cisco and a wide range of vendor partners network
management applications report and utilize IP SLA data.
© 2007 Cisco Systems, Inc. All rights reserved.
12-66
Designing Cisco Network Service Architectures (ARCH) v2.0
ARCH v2.0—11-73
© 2007 Cisco Systems, Inc.
Module Summary
This topic summarizes the key points discussed in this module.
Summary
Cisco IOS Software embedded self-management tools
support application optimization, performance
measurement, and SLA verification:
ƒ Syslog allows a device to report and save important error and
notification messages, either locally or to a remote logging server.
ƒ NetFlow technology answers the questions of what, when, where,
and how traffic is flowing in the network.
ƒ NBAR enables precise traffic classification to support QoS
functions while NBAR Protocol Discovery provides protocol traffic
discovery and real-time statistics available through SNMP.
ƒ IP SLAs capability provides end-to-end performance
measurements including jitter, packet loss, and latency based on
generated traffic.
© 2007 Cisco Systems, Inc. All rights reserved.
75
ARCH v2.0—11-75
This module examined the embedded Cisco IOS Software functionality that enable customers
to efficiently manage their networks. This module discusses the importance, requirements, and
considerations for implementing syslog, NetFlow, NBAR, and IP SLA measurements features
in the overall enterprise design.
References
For additional information, refer to these resources:
„
Cisco Systems, Inc. “APP-1205: Cisco IOS Tools for Application Optimization”
Networkers 2006 presentation (accessible on a subscription basis) at
http://www.networkersonline.net.
„
Cisco Systems, Inc. “NMS-1204 Introduction to Network Performance Measurement with
Cisco IOS IP Service Level Agent (IP SLA)” Networkers 2006 presentation (accessible on
a subscription basis) at
http://www.networkersonline.net.
„
Cisco Systems, Inc. “NMS-3011: Getting the Right Events from Network Elements”
Networkers 2006 presentation (accessible on a subscription basis) at
http://www.networkersonline.net.
„
Cisco Systems, Inc. “NMS-3043: Performance Management with Cisco IOS IP SLAs”
Networkers 2006 presentation (accessible on a subscription basis) at
http://www.networkersonline.net.
„
Cisco Systems, Inc. “NMS-3361:Advanced Accounting and Performance Management
with NBAR” Networkers 2006 presentation (accessible on a subscription basis) at
http://www.networkersonline.net.
© 2007 Cisco Systems, Inc.
Network Management Services Design
12-67
12-68
„
Cisco Systems, Inc. “Cisco IOS Software Releases 12.4 Mainline Error and System
Messages” at
http://www.cisco.com/en/US/products/ps6350/products_system_message_guides_list.html
„
Cisco Systems, Inc. “Cisco IOS Software Releases 12.3T Embedded Syslog Manager” at
http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide09186a0
0801a8516.html
„
Cisco Systems, Inc. “Cisco IOS NetFlow Introduction” at
http://www.cisco.com/go/netflow
„
Cisco Systems, Inc. “NetFlow Services Solutions Guide” at
http://www.cisco.com/en/US/products/sw/netmgtsw/ps1964/products_implementation_desi
gn_guide09186a00800d6a11.html
„
Cisco Systems, Inc. “Introduction to Cisco IOS NetFlow - A Technical Overview” at
http://www.cisco.com/en/US/products/ps6601/products_white_paper0900aecd80406232.sh
tml
„
Cisco Systems, Inc. “Cisco IOS IP Service Level Agreements (SLAs) Introduction” at
http://www.cisco.com/go/ipsla
„
Cisco Systems, Inc. “Network Based Application Recognition (NBAR) Introduction” at
http://www.cisco.com/go/nbar
„
Cisco Systems, Inc. “User Guide for Internetwork Performance Monitor 2.6 (With LMS
2.5.1)” at
http://www.cisco.com/en/US/products/sw/cscowork/ps1008/products_user_guide_book091
86a0080366cf7.html
„
Cisco Systems, Inc. “12.4 T System Message Guide” at
http://www.cisco.com/en/US/products/ps6441/products_system_message_guide_book0918
6a00806f9890.html
„
The Internet Engineering Task Force. “RFC 3195: Reliable Delivery for syslog”
http://www.ietf.org/rfc/rfc3195.txt
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007, Cisco Systems, Inc.
Module Self-Check
Use the questions here to review what you learned in this module. The correct answers and
solutions are found in the Module Self-Check Answer Key.
Q1)
What is a benefit of ESM? (Source: Embedded Self-Management Overview)
A)
B)
C)
D)
E)
Q2)
What is port does syslog use for sending messages to a syslog server? (Source:
Embedded Self-Management Overview)
A)
B)
C)
D)
E)
F)
Q3)
1
3
5
7
15
What are five key fields used to identify a flow in traditional NetFlow? (Choose five.)
(Source: NetFlow Considerations)
A)
B)
C)
D)
E)
F)
G)
H)
I)
Q5)
UDP 514
UDP 520
UDP 1697
UDP 1967
UDP 2020
It is specified in the control message.
Which of the following syslog severity codes indicates the most serious condition?
(Source: Embedded Self-Management Overview)
A)
B)
C)
D)
E)
Q4)
includes NetFlow, NBAR, and IP SLA software subsystems
includes NetFlow, Syslog, and IP SLA software subsystems
provides a predefined framework for filtering and correlating messages
supports multiple MIBs
supports two logging processes so output can be sent in standard and ESM
format
destination IP address
destination MAC address
DLCI flag
ifIndex
ifOutput
Layer 3 protocol type
source IP address
source MAC address
ToS byte
What are three characteristics of the NetFlow cache in traditional NetFlow? (Chose
three.) (Source: NetFlow Considerations)
A)
B)
C)
D)
E)
F)
© 2007 Cisco Systems, Inc.
It maintains Flow records.
It holds SNMP data on flows.
It tracks seven key attributes per flow.
It tracks five key attributes per flow.
It tracks non-key fields with flow entries.
It is unaffected by the introduction of QoS in the network.
Network Management Capabilities with Cisco IOS Software
12-69
Q6)
What are three reasons for expiring NetFlow cache entries? (Chose three.) (Source:
NetFlow Considerations)
A)
B)
C)
D)
E)
Q7)
What is the most common NetFlow export record type? (Source: NetFlow
Considerations)
A)
B)
C)
D)
E)
F)
Q8)
Version 1
Version 5
Version 7
Version 8
Version 9
Version 10
What are three characteristics of the Flexible NetFlow export record? (Chose three.)
(Source: NetFlow Considerations)
A)
B)
C)
D)
E)
12-70
Version 1
Version 5
Version 7
Version 8
Version 9
Version 10
What is the NetFlow export record type does Flexible NetFlow use? (Source: NetFlow
Considerations)
A)
B)
C)
D)
E)
F)
Q9)
As the cache becomes full, a number of heuristics are applied to aggressively
age groups of flows simultaneously.
Flows in the cache are expired and removed from the cache after the default 20
minute timer.
Flows which have been idle for a specified time are expired and removed from
the cache.
TCP connections which have reached the end of byte stream (FIN) will be
expired.
UDP connections which have reached the end of byte stream (FIN) will be
expired.
It always includes a template to describe what is being exported.
It can include a template to describe what is being exported.
It consists of a packet header followed by at least one or more template or data
FlowSets.
Key and non-key fields that define flows can be configured.
Non-key fields are not included in the data FlowSet.
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Q10)
What are three characteristics of the Flexible NetFlow? (Chose three.) (Source:
NetFlow Considerations)
A)
B)
C)
D)
E)
F)
Q11)
What are four fields used to identify a flow in NBAR? (Choose four.) (Source:
NBARConsiderations)
A)
B)
C)
D)
E)
F)
G)
H)
Q12)
It is based on IPFIX.
It is the basis for IPFIX.
It can only monitor applications that it recognizes from a PDLM.
It can monitor a wider range of packet information than traditional NetFlow.
It is enabled with the ip nbar protocol-discovery configuration command.
It is enabled with the ip nbar protocol-match configuration command.
What are three true statements about AutoQoS and NBAR? (Chose three.) (Source:
NBAR Considerations)
A)
B)
C)
D)
E)
F)
Q14)
destination IP address
destination MAC address
ifIndex
Layer 3 payload information
Layer 3 protocol type
source IP address
source MAC address
ToS byte
What are two characteristics of the NBAR? (Chose two.) (Source: NBAR
Considerations)
A)
B)
C)
D)
E)
F)
Q13)
It is based on IPFIX.
It is the basis for IPFIX.
It is the most commonly NetFlow application.
It can monitor a wider range of packet information than traditional NetFlow.
It can track multiple NetFlow applications simultaneously by using different
Flow Sets.
It can track multiple NetFlow applications simultaneously by using different
Flow Monitors.
AutoQoS for the Enterprise has a two phase configuration process.
AutoQoS VoIP has a two phase configuration process.
Both Cisco IOS Software AutoQoS features can take advantage of the traffic
classification functionality of NBAR.
Auto-Discovery collects data and evaluates traffic in the network in AutoQoS
VoIP.
In the untrusted mode, the Auto-Discovery phase uses NBAR protocol
discovery to detect and classify the applications on the network.
In the trusted mode, the Auto-Discovery phase uses NBAR protocol discovery
to detect and classify the applications on the network.
What are two components provide the greatest accuracy with IP SLAs? (Chose two.)
(Source: IP SLA Considerations)
A)
B)
C)
D)
E)
© 2007 Cisco Systems, Inc.
IP SLA Receiver
IP SLA Responder
IP SLA Router
IP SLA Source
IP SLA Target
Network Management Capabilities with Cisco IOS Software
12-71
Q15)
What three devices can be an IP SLA probe target? (Chose three.) (Source: IP SLA
Considerations)
A)
B)
C)
D)
E)
Q16)
What is port does IP SLA use for control messages? (Source: IP SLA Considerations)
A)
B)
C)
D)
E)
F)
Q17)
UDP 514
UDP 520
UDP 1697
UDP 1967
UDP 2020
It is specified in the control message.
What are two advantages to shadow routers? (Chose two.) (Source: IP SLA
Considerations)
A)
B)
C)
D)
E)
12-72
UDP 514
UDP 520
UDP 1697
UDP 1967
UDP 2020
It is specified in the control message.
What is port does IP SLA use for probe messages? (Source: IP SLA Considerations)
A)
B)
C)
D)
E)
F)
Q18)
any host
any IP host
a VoIP phone
a GSM cellular phone
a Cisco switch running CatOS Software
Allows scalability with a large number of endpoints
Cuts down on the frequency of the sampling interval
Is required with hierarchical IP SLA deployments
Provide separate memory and CPU from hardware in switching path
Verifies performance per class when QoS is running in the network
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Module Self-Check Answer Key
Q1)
E
Q2)
A
Q3)
A
Q4)
A, D, F, G, I
Q5)
A, C
Q6)
A, C, D
Q7)
B
Q8)
E
Q9)
B, C, D
Q10)
B, D, F
Q11)
A, D, E, F
Q12)
C, D
Q13)
A, C, E
Q14)
B, D
Q15)
B, C, E
Q16)
D
Q17)
F
Q18)
A, D
© 2007 Cisco Systems, Inc.
Network Management Capabilities with Cisco IOS Software
12-73
12-74
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
ARCH
Course Glossary
The Course Glossary for the Cisco Designing Cisco Network Service Architectures (ARCH)
v2.0 course highlights and defines key terms and acronyms used throughout this course. Many
of these terms are also described in the Cisco Internetworking Terms and Acronyms resource,
available at http://www.cisco.com/univercd/cc/td/doc/cisintwk/ita/.
Acronym or Term
Definition
(*,G)
(all source IP addresses, group multicast address)
(S,G)
(source IP address, group multicast address)
3DES
Triple Data Encryption Standard.
802.11
The IEEE standard that specifies carrier-sense MAC and physical layer specifications for
1- and 2-Mbps wireless LANs operating in the 2.4-GHz band.
802.11a
The IEEE standard that specifies carrier-sense MAC and physical layer specifications for
wireless LANs operating in the 5-GHz frequency band.
802.11b
The IEEE standard that specifies carrier-sense MAC and physical layer specifications for
5.5- and 11-Mbps wireless LANs operating in the 2.4-GHz frequency band.
802.11g
The IEEE standard that specifies carrier-sense MAC and physical layer specifications for
wireless LANs operating in the 2.4-GHz frequency band.
AAA
authentication, authorization, and accounting.
ABR
area border router.
access control list
See ACL.
Access Control Server
See Cisco Secure ACS.
ACE
Application Control Engine.
ACELP
algebraic code-excited linear prediction.
ACL
access control list. Filter list used for services such as security, QoS, and routing. A list
kept by routers to control access to or from the router for a number of services (for
example, to prevent packets with a certain IP address from leaving a particular interface
on the router).
adaptive differential
pulse code modulation
See ADPCM.
Adaptive Security
Appliance
See Cisco ASA.
Adaptive Security
Device Manager
See Cisco ASDM.
Address Resolution
Protocol
See ARP.
ADPCM
adaptive differential pulse code modulation.
ADSL
asymmetric digital subscriber line.
ADSL Transmission
Unit-Remote
See ATU-R.
Advanced Encryption
Standard
See AES.
advanced integration
module
See AIM.
AES
Advanced Encryption Standard.
AIM
advanced integration module.
ALG
application level gateway.
algebraic code-excited
linear prediction
See ACELP.
A-2
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Acronym or Term
Definition
American National
Standards Institute
See ANSI.
ANSI
American National Standards Institute.
AppleTalk Remote
Access
See ARA.
Application Control
Engine
See ACE.
application level
gateway
See ALG.
Application Networking
Services
See Cisco ANS.
Application-Oriented
Networking Software
See Cisco AON.
APS
automatic protection switching.
ARA
AppleTalk Remote Access.
ARCH course
Cisco Designing Cisco Network Service Architectures course.
area border router
See ABR.
ARP
Address Resolution Protocol
ARP inspection
Process that compares the MAC address, IP address, and source interface in all ARP
packets to static entries in the ARP table, and then either forwards or drops the packets.
AS
autonomous system.
ASM
Any-Source Multicast.
ASR group
asymmetric routing group.
asymmetric digital
subscriber line
See ADSL.
Asynchronous Transfer
Mode
See ATM.
ATA
Advanced Technology Attachment
ATA
Advanced Technology Attachment
ATM
Asynchronous Transfer Mode. The international standard for cell relay in which multiple
service types (such as voice, video, or data) are conveyed in fixed-length (53-byte) cells.
Fixed-length cells allow cell processing to occur in hardware, reducing transit delays. ATM
is designed to take advantage of high-speed transmission media, such as E3, SONET,
and T3.
ATU-R
ADSL Transmission Unit-Remote.
authentication,
authorization, and
accounting
See AAA.
automatic protection
switching
See APS.
autonomous system
See AS.
AWFSS course
Cisco Aironet Wireless LAN Fundamentals and Site Survey course.
AWLAT course
Cisco Aironet Wireless LAN Advanced Topics course.
© 2007 Cisco Systems, Inc.
Appendix A—Course Glossary
A--3
Acronym or Term
Definition
Basic Rate Interface
See BRI.
BBC
buffer-to-buffer credit. The number of buffer credits allowed to accumulate before the
source stops sending data due to lack of acknowledgements.
B-channel
bearer channel.
BCMSN course
Cisco Building Cisco Multilayer Switched Networks course.
beacon
A wireless LAN packet that signals the availability and presence of the wireless device.
BEEP
Blocks Extensible Exchange Protocol.
BGP
Border Gateway Protocol. Interdomain routing protocol that replaces EGP. BGP
exchanges reachability information with other BGP systems. It is defined by RFC 1163.
BHT
busy hour traffic.
Bill of Materials
See BoM.
BoM
Bill of Materials.
Border Gateway
Protocol
See BGP.
BPDU
bridge protocol data unit. When STP is enabled, bridges send and receive spanning-tree
frames, called BPDUs, at regular intervals and use the frames to maintain a loop-free
network.
BRI
Basic Rate Interface.
bridge protocol data
unit
See BPDU.
BSCI course
Cisco Building Scalable Cisco Internetworks course.
BSR
bootstrap router
BSS
Basic Service Set
busy hour traffic
See BHT.
cable modem
termination system
See CMTS.
cable television
See CATV.
CAC
call admission control.
call admission control
See CAC.
Call Detail Record
See CDR.
CAR
committed access rate. A traffic policing and marking mechanism. The CAR and DCAR
services limit the input or output transmission rate on an interface or subinterface based
on a flexible set of criteria.
CATV
cable television.
CBAC
context-based access control.
CBC
Cipher Block Chaining.
C-BSR
candidate BSR.
CBWFQ
class-based weighted fair queuing.
CCKM
Cisco Centralized Key Management
CCS
centum call seconds.
A-4
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Acronym or Term
Definition
CDR
Call Detail Record.
cell
The area of radio range or coverage in which the wireless devices can communicate with
the base station. The size of the cell depends on the speed of the transmission, the type
of antenna used, and the physical environment, as well as other factors.
CELP
code-excited linear prediction.
central office
See CO.
centum call seconds
See CCS.
CFIS
Common Information File System
Challenge Handshake
Authentication Protocol
See CHAP.
channel service unit
See CSU.
CHAP
Challenge Handshake Authentication Protocol.
CIDR
classless interdomain routing.
Cipher Block Chaining
See CBC.
CIR
committed information rate. The rate at which a Frame Relay network agrees to transfer
information under normal conditions, averaged over a minimum increment of time. CIR,
measured in bits per second, is one of the key negotiated tariff metrics.
Cisco ANS
Cisco Application Networking Services.
Cisco AON
Cisco Application-Oriented Networking Software.
Cisco ASA
Cisco Adaptive Security Appliance.
Cisco ASDM
Cisco Adaptive Security Device Manager.
Cisco Catalyst 6500
Series FWSM
Cisco Catalyst 6500 Series Firewall Services Module.
Cisco Catalyst 6500
Series IDS Services
Module
See IDSM.
Cisco Centralized Key
Management
Using Cisco Centralized Key Management, authenticated client devices can roam from
one access point to another without any perceptible delay during re-association. An
access point on your network acts as a subnet context manager and creates a cache of
security credentials for client devices on the subnet enabled with Cisco Centralized Key
Management. The subnet context manager's cache of credentials dramatically reduces
the time required for re-association when a client device enabled with this technology
roams to a new access point.
Cisco Discovery
Protocol
CDP is a Layer 2 protocol supported on all Cisco routers, bridges, access servers, and
switches that allows network management applications to discover Cisco devices that are
neighbors of already known devices, in particular..
Cisco Express
Forwarding
An advanced Layer 3 IP switching technology. Cisco Express Forwarding optimizes
network performance and scalability for networks with large and dynamic traffic patterns.
VRF tables use Cisco Express Forwarding technology; therefore, MPLS VPNs must be
enabled to use Cisco Express Forwarding.
Cisco IBNS
Cisco Identity-Based Networking Services.
Cisco IDM
Cisco IPS Device Manager.
Cisco IOS Software
Cisco operating system software that runs on routers and switches. Cisco system
software that provides common functionality, scalability, and security for all products
under the CiscoFusion architecture. Cisco IOS Software allows centralized, integrated,
and automated installation and management of internetworks while ensuring support for a
wide variety of protocols, media, services, and platforms.
© 2007 Cisco Systems, Inc.
Appendix A—Course Glossary
A--5
Acronym or Term
Definition
Cisco Key Integrity
Protocol
The Cisco WEP key permutation technique based on an early algorithm
presented by the IEEE 802.11i security task group.
Cisco NAM
Cisco Network Analysis Module.
Cisco Router and
Security Device
Manager
See Cisco SDM.
Cisco SDM
Cisco Router and Security Device Manager.
Cisco Secure ACS
Cisco Secure Access Control Server.
Cisco Security Agent
Software that provides threat protection for server and desktop computing systems, also
known as endpoints.
Cisco Security MARS
Cisco Security Monitoring, Analysis, and Response System
Cisco Service-Oriented
Network Architecture
See SONA.
Cisco Unified Contact
Center
Software that delivers intelligent contact routing, call treatment, network-to-desktop
computer telephony integration (CTI), and multichannel contact management over an IP
infrastructure
Cisco WAAS
Cisco Wide-Area Application Services. Service that gives remote offices LAN-like access
to centrally hosted applications, servers, storage, and multimedia.
Cisco WAE
Cisco Wide-Area Application Engine. Products that provide global LAN-like access to
enterprise applications and data.
Cisco WCS
Cisco Wireless Control System.
Cisco WiSM
Cisco Catalyst 6500 Series Wireless Services Module.
CiscoWorks RME
CiscoWorks Resource Manager Essentials.
CiscoWorks WLSE
CiscoWorks Wireless LAN Solution Engine.
class of service
See CoS.
class-based weighted
fair queuing
See CBWFQ.
classless interdomain
routing
See CIDR.
CLI
command-line interface.
CLNP
Connectionless Network Protocol.
CMIP
Common Management Information Protocol.
CMTS
cable modem termination system.
CO
central office.
codec
coder-decoder.
code-excited linear
prediction
See CELP.
command-line interface
See CLI.
committed access rate
See CAR.
committed information
rate
See CIR.
Common Management
Information Protocol
See CMIP.
A-6
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Acronym or Term
Definition
Common SpanningTree protocol
See CST.
compressed Real-Time
Transport Protocol
See cRTP.
congestion
Traffic in excess of network capacity.
congestion avoidance
Mechanism by which a network controls the traffic entering the network to minimize
delays. To use resources most efficiently, lower-priority traffic is discarded at the edge of
the network if conditions indicate that it cannot be delivered.
conjugate structure
algebraic code-excited
linear prediction
See CS-ACELP.
Connectionless
Network Protocol
See CLNP.
context-based access
control
See CBAC.
control plane
The software that manages all operational aspects of a router or switch except the perpacket analysis and forwarding through the device. These operations can include
updating routing tables and managing interfaces.
control plane policing
See CoPP.
CoPP
control plane policing. CoPP increases security on infrastructure devices by protecting the
CPU from unnecessary or DoS attack traffic and giving priority to important control plane
and management traffic. CoPP can be used to protect most of the CPU-bound traffic and
ensure routing stability, reachability, and packet delivery.
CoS
class of service. The methods that provide differentiated service, in which the network
delivers a particular kind of service based on the CoS specified for each packet. CoS
provides specific categories of service such as gold, silver, and best-effort service
classes.
CoS is a set of concrete device features in which a single network router treats traffic in
different classes differently. CoS techniques provide a means of specifying policies to
control network resource allocation in support of customer and applications requirements.
The implementation of CoS techniques delivers measurable QoS.
CPE
customer premises equipment.
CQ
custom queuing.
CRC
cyclic redundancy check.
C-RP
candidate RP.
cRTP
compressed Real-Time Transport Protocol.
CS-ACELP
conjugate structure algebraic code-excited linear prediction.
CSM
Content Switching Module.
CSNAT
client source NAT.
CSS
Content Services Switch.
CST
Common Spanning-Tree protocol.
CST
Common Spanning Tree.
CSU
channel service unit.
CSVPN course
Cisco Secure Virtual Private Networks course.
custom queuing
See CQ.
© 2007 Cisco Systems, Inc.
Appendix A—Course Glossary
A--7
Acronym or Term
Definition
customer premises
equipment
See CPE.
CUWN course
Cisco Unified Wireless Networking course.
CVF course
Cisco Voice over IP Fundamentals course.
CVOICE course
Cisco Voice over IP course.
CWDM
coarse wavelength-division multiplexing. A technology that increases the information
carrying capacity of existing fiber optic infrastructure by transmitting and receiving data on
different light wavelengths on a single strand of fiber
CWLAT course
Cisco Wireless LAN Advanced Topics course.
CWLF course
Cisco Wireless LAN Fundamentals course.
CWMN course
Cisco Wireless Mesh Networking course.
cyclic redundancy
check
See CRC.
DAS
directly attached storage. A topology where the storage devices connect directly to the
server.
Data Encryption
Standard
See DES.
data plane
Services and settings related to the data passing through a router or switch (as opposed
to that directed to it). The data plane is for forwarding all traffic not in the control or
management planes.
Data Security Standard
See DSS.
data service unit
See DSU.
data-link connection
identifier
See DLCI.
Data-over-Cable
Service Interface
Specifications
See DOCSIS.
dB
decibel
dBm
power ratio in decibel (dB) of the measured power referenced to one milliwatt
DCAR
distributed committed access rate.
DCF
Distributed Coordination Function.
D-channel
data channel.
DDoS
distributed denial of service.
DDR
dial-on-demand routing.
demilitarized zone
See DMZ.
denial of service
See DoS.
dense wavelengthdivision multiplexing
See DWDM.
DES
Data Encryption Standard.
DHCHAP
DHCHAP is an authentication protocol that authenticates the devices connecting to a
switch. Fibre Channel authentication allows only trusted devices to be added to a fabric,
thus preventing unauthorized devices from accessing the switch.
A-8
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Acronym or Term
Definition
DHCP
Dynamic Host Configuration Protocol. A protocol available with many operating systems
that automatically issues IP addresses within a specified range to devices on the network.
The device retains the assigned address for a specific administrator-defined period.
DHCP snooping
A security feature that filters untrusted DHCP messages and builds and maintains a
DHCP snooping binding table. An untrusted message is a message that is received from
outside the network or firewall.
dial-on-demand routing
See DDR.
DID
Direct Inward Dialing.
differentiated services
code point
See DSCP.
DiffServ
differentiated services.
Diffusing Update
Algorithm
See DUAL.
Digital Private Network
Signaling System
See DPNSS.
digital signal processor
See DSP.
digital subscriber line
See DSL.
Direct Inward Dialing
See DID.
distributed denial of
service
See DDoS.
distributed weighted
random early detection
See DWRED.
DLCI
data-link connection identifier. Value that specifies a PVC or an SVC in a Frame Relay
network. In the basic Frame Relay specification, DLCIs are locally significant (connected
devices might use different values to specify the same connection). In the LMI extended
specification, DLCIs are globally significant (DLCIs specify individual end devices).
DMVPN
Dynamic Multipoint VPN.
DMZ
demilitarized zone. A secured network zone between the private (inside) network and a
public (outside) network.
DNS
Domain Name System. A server that translates text names into IP addresses. The server
maintains a database of host alphanumeric names and their corresponding IP addresses.
DOCSIS
Data-over-Cable Service Interface Specifications.
Domain Name System
See DNS.
DoS
denial of service.
DPNSS
Digital Private Network Signaling System.
DPT
Dynamic Packet Transfer. A RPR technology designed for SPs to deliver scalable Internet
service, reliable IP-aware optical transport, and simplified network operations principally
for metropolitan area applications. DPT is based on Spatial Reuse Protocol (SRP), a
Cisco-developed MAC-layer protocol for ring-based packet internetworking.
© 2007 Cisco Systems, Inc.
Appendix A—Course Glossary
A--9
Acronym or Term
Definition
DR
designated router: The router in a PIM-SM tree that instigates the Join/Prune message
cascade upstream to the rendezvous point in response to IGMP membership information
it receives from IGMP hosts.
DSCP
differentiated services code point. In the IP header, the DSCP octet classifies the packet
service level. The DSCP maps to a particular observable forwarding behavior called a
per-hop behavior. The DSCP replaces the ToS octet in the IPv4 header, and the Class
octet in the IPv6 header. Currently, only the first six bits are used, allowing up to 64
classifications for service levels. The DSCP is unstructured, but it does reserve some
values to maintain limited backward compatibility with the IP precedence bits in the ToS
octet.
DSL
digital subscriber line.
DSL access multiplexer
See DSLAM.
DSLAM
DSL access multiplexer.
DSP
digital signal processor.
DSS
Data Security Standard.
DSSS
Direct Sequence Spread Spectrum
DSTM
Dual Stack Transition Mechanism.
DSU
data service unit.
DTMF
dual tone multifrequency.
DTP
Dynamic Trunking Protocol.
DTPC
Dynamic Transmit Power Control
DTPC
Dynamic Transmit Power Control
DUAL
Diffusing Update Algorithm.
Dual Stack Transition
Mechanism
See DSTM.
dual tone
multifrequency
See DTMF.
DVMRP
Distance Vector Multicast Routing Protocol
DVTI
Dynamic VTI.
DWDM
dense wavelength-division multiplexing. A technology that increases the information
carrying capacity of existing fiber optic infrastructure by transmitting and receiving data on
different light wavelengths on a single strand of fiber
DWRED
distributed weighted random early detection.
Dynamic Host
Configuration Protocol
See DHCP.
Dynamic Trunking
Protocol
See DTP.
E&M
ear and mouth (or recEive and transMit).
E1
A European transmission circuit of 32 channels running at 64 kbps sampled at 8000 times
per second for 2.048 Mbps.
E3
A European transmission circuit of 512 channels running at 64 kbps sampled at 8000
times per second (or 16 E1s) running at 34.368 Mbps.
EAP
Extensible Authentication Protocol. An optional IEEE 802.1X security feature ideal for
organizations with a large user base and access to an EAP-enabled RADIUS server.
A-10
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Acronym or Term
Definition
EAP-FAST
EAP-Flexible Authentication via Secure Tunneling.
EAP-Flexible
Authentication via
Secure Tunneling
See EAP-FAST.
ear and mouth (or
recEive and transMit)
See E&M.
EBGP
External BGP. EBGP communicates among different network domains or autonomous
systems. The primary function of EBGP is to exchange network reachability information
between autonomous systems, including information about the list of autonomous system
routes. The autonomous systems use EBGP border edge routers to distribute the routes,
which include label-switching information. Each border edge router rewrites the next-hop
and MPLS labels.
EDCA
Enhanced Distributed Channel Access
EFDA
Erbium Doped Fiber Amplifier. A form of fiber optical amplification that transmits a light
signal through a section of erbium-doped fiber and amplifies the signal with a laser pump
diode. EDFA is used in transmitter booster amplifiers, in-line repeating amplifiers, and in
receiver preamplifiers.
EGP
Exterior Gateway Protocol.
EIGRP
Enhanced Interior Gateway Routing Protocol.
EIRP
Effective Isotropic Radiated Power . EIRP is the combination of radio transmit power,
antenna cable loss, and antenna gain. For example, if the 100 mW transmit power of the
radio equals 20 dBm, the loss of a 100-foot cable is 6 dB, and the gain of an antenna is 3
dBi, the result is an EIRP of 17 dBm.
EISL
Enhanced ISL. Frame format used by MDS 9000 to support trunking of VSANs.
E-LAN
Ethernet LAN. Multipoint Ethernet service defined by the MEF.
E-LINE
Ethernet Line. Point-to-point Ethernet service defined by the MEF.
EMS
Ethernet Multipoint Service. A multipoint-to-multipoint port-based E-LAN service that is
used for transparent LAN applications.
Encapsulated Security
Protocol
See ESP.
Enhanced Interior
Gateway Routing
Protocol
See EIGRP.
enterprise resource
planning
See ERP.
EOT
Enhanced Object Tracking.
EPL
Ethernet Private Line. A port-based point-to-point E-Line service that maps Layer 2 traffic
directly onto a TDM circuit.
ERMS
Ethernet Relay Multipoint Service. A multipoint-to-multipoint VLAN-based E-LAN service
that is used primarily for establishing a multipoint-to-multipoint connection between
customer routers.
ERP
enterprise resource planning.
© 2007 Cisco Systems, Inc.
Appendix A—Course Glossary
A--11
Acronym or Term
Definition
ERS
Ethernet Relay Service. A point-to-point VLAN-based E-Line service, that is used
primarily for establishing a point-point connection between customer routers.
ESM
Embedded Syslog Manager. A feature that provides a programmable framework that
allows a network manager to filter, escalate, correlate, route, and customize system
logging messages prior to delivery.
ESP
Encapsulated Security Protocol.
EtherIP
Ethernet-in-IP
EVC
Ethernet Virtual Circuit.
EWS
Ethernet Wire Service. A point-to-point port-based E-Line service that is used primarily to
connect geographically remote LANs over an SP network.
Extensible
Authentication Protocol
See EAP.
Exterior Gateway
Protocol
See EGP.
External BGP
See EBGP.
failover group
A logical group of one or more security contexts.
fault, configuration,
accounting,
performance, and
security management
See FCAPS.
FCAPS
fault, configuration, accounting, performance, and security management. ISO network
management model defining five functional areas of network management.
FCIP
Fibre Channel over IP. FCIP is used primarily for SAN Extension across a wide area
network.
FCP
Fibre Channel Protocol.
FE
Sometimes used as an acronym for “Fast Ethernet.”
FHR
first-hop router. Router closest to multicast source.
FHRP
first hop redundancy protocol.
fiber connection
See FICON.
Fibre Channel
A serial data transfer architecture with very high level of scalability and bandwidth that
supports the extension of SCSI technologies.
FICON
fiber connection.
FIFO
first in, first out.
File Transfer Protocol
See FTP.
FIN
TCP end of byte flag
Firewall Services
Module
See Cisco Catalyst 6500 Series FWSM.
first in, first out
See FIFO.
fixed-length subnet
mask
See FLSM.
FLSM
fixed-length subnet mask.
FM
frequency modulation.
A-12
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Acronym or Term
Definition
Foreign Exchange
Office
See FXO.
Foreign Exchange
Station
See FXS.
FQDN
fully qualified domain name.
Frame Relay
Industry-standard, switched, data-link layer protocol that handles multiple virtual circuits
using HDLC encapsulation between connected devices. Frame Relay is more efficient
than X.25, the protocol for which it generally is considered a replacement.
Frame Relay traffic
shaping
See FRTS.
frequency modulation
See FM.
FRTS
Frame Relay traffic shaping. Queuing method that uses queues on a Frame Relay
network to limit surges that can cause congestion. Data is buffered and sent into the
network in regulated amounts to ensure that the traffic can fit within the promised traffic
envelope for the particular connection.
FTP
File Transfer Protocol.
fully qualified domain
name
See FQDN.
FXO
Foreign Exchange Office.
FXS
Foreign Exchange Station.
Gateway Load
Balancing Protocol
See GLBP.
GBIC
gigabit interface converter. A swappable transceiver that converts serial electrical signals
to serial optical signals, and optical signals to electrical signals.
GDOI
Group Domain of Interpretation.
GE
Sometimes used as an acronym for “Gigabit Ethernet.”
General Packet Radio
Service
See GPRS.
generic routing
encapsulation
See GRE.
generic traffic shaping
Provides a mechanism to control the traffic flow on a particular interface. It reduces
outbound traffic flow to avoid congestion by constraining specified traffic to a particular bit
rate (also known as the “token bucket” approach), while queuing bursts of the specified
traffic. Thus, traffic adhering to a particular profile can be shaped to meet downstream
requirements, eliminating bottlenecks in topologies with data-rate mismatches.
generic traffic shaping
See GTS.
GET VPN
Group Encrypted Transport VPN.
gigabit interface
converter
See GBIC.
GLBP
Gateway Load Balancing Protocol.
Global Positioning
Systems
See GPS.
Global System for
Mobile
Communications
See GSM.
GPRS
General Packet Radio Service.
© 2007 Cisco Systems, Inc.
Appendix A—Course Glossary
A--13
Acronym or Term
Definition
GPS
Global Positioning System.
graphical user interface
See GUI.
GRE
generic routing encapsulation. Tunneling protocol that was developed by Cisco that can
encapsulate a wide variety of protocol packet types inside IP tunnels and thus create a
virtual point-to-point link to Cisco routers at remote points over an IP internetwork. By
connecting multiprotocol subnetworks in a single-protocol backbone environment, IP
tunneling using GRE allows network expansion across a single-protocol backbone
environment.
GSLB
Global Server Load Balancing.
GSM
Global System for Mobile Communications.
GSS
Cisco Global Site Selector.
GTS
generic traffic shaping.
GUI
graphical user interface.
GWGK course
Cisco Implementing Cisco Voice Gateways and Gatekeepers course.
Hash-Based Message
Authentication Code
with Message Digest 5
See HMAC-MD5.
Hash-Based Message
Authentication Code
with Secure Hash
Algorithm
See HMAC-SHA.
HBA
host bus adapter
HDLC
High-Level Data Link Control.
Health Insurance
Portability and
Accountability Act
See HIPAA.
High-Level Data Link
Control
See HDLC.
high-speed WAN
interface card
See HWIC.
HIPAA
Health Insurance Portability and Accountability Act.
HIPS
host-based intrusion prevention system.
HMAC-MD5
Hash-Based Message Authentication Code with Message Digest 5.
HMAC-SHA
Hash-Based Message Authentication Code with Secure Hash Algorithm.
host-based intrusion
prevention system
See HIPS.
Hot Standby Router
Protocol
See HSRP.
H-REAP
Hybrid Remote Edge Access Point.
HSRP
Hot Standby Router Protocol.
HWIC
high-speed WAN interface card.
Hybrid Remote Edge
Access Point
See H-REAP.
IANA
Internet Assigned Numbers Authority.
A-14
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Acronym or Term
Definition
IBGP
Internal BGP. IBGP communicates internally within an autonomous system. The primary
function of IBGP is to exchange BGP information between multiple BGP routers within an
autonomous system. Routers communicating with IBGP must be connected in a full mesh
to prevent loops, or you can use route reflectors or confederations.
IDE
Integrated Drive Electronics
IDE
Integrated Drive Electronics
Identity-Based
Networking Services
See Cisco IBNS.
IDS
intrusion detection system.
IDSM
Cisco Catalyst 6500 Series IDS Services Module.
IETF
Internet Engineering Task Force. Task force that consists of more than 80 working groups
responsible for developing Internet standards. The IETF operates under the auspices of
the Internet Society.
IGMP
Internet Group Management Protocol. IGMP is the protocol used by IPv4 systems to
report their IP multicast group memberships to neighboring multicast routers.
IGMP Query
IGMP messages originating from the router(s) to elicit multicast group membership
information from its connected hosts.
IGMP Report
Report: IGMP messages originating from the hosts that are joining, maintaining or leaving
their membership in a multicast group.
IGMP Snooping
Snooping requires the LAN switch to examine, or "snoop," some layer 3 information in the
IGMP packet sent from the host to the router. When the switch hears an IGMP Report
from a host for a particular multicast group, the switch adds the host's port number to the
associated multicast table entry. When it hears an IGMP Leave Group message from a
host, it removes the host's port from the table entry.
IGP
Interior Gateway Protocol.
IIS
Microsoft Internet Information Server.
IKE
Internet Key Exchange.
InfiniBand
InfiniBand is an architecture specification to offload data movement from the CPU to
dedicated hardware to address the problem of server performance with respect to I/O.
InfiniBand is a high-performance switched fabric communications link primarily including
QoS and failover, and it is designed to be scalable. It defines a connection between
processor nodes and high-performance I/O nodes such as storage devices.
in-service software
upgrade
See ISSU.
Integrated Services
Digital Network
See ISDN.
integrated services
router
See ISR.
interactive voice
response
See IVR.
Interior Gateway
Protocol
See IGP.
Intermediate Systemto-Intermediate System
routing protocol
See IS-IS.
intermix
A common Fibre Channel transport network and I/O infrastructure used by mixed systems
implementing FICON and Fibre Channel using Fibre Channel Protocol (FCP).
Internal BGP
See IBGP.
© 2007 Cisco Systems, Inc.
Appendix A—Course Glossary
A--15
Acronym or Term
Definition
International
Telecommunication
Union
See ITU.
Internet Assigned
Numbers Authority
See IANA.
Internet Engineering
Task Force
See IETF.
Internet Group
Management Protocol
See IGMP.
Internet Key Exchange
See IKE.
Internet Protocol
See IP.
Internet service
provider
See ISP.
Internetwork Packet
Exchange
See IPX.
intrusion detection
system
See IDS.
intrusion prevention
system
See IPS.
IntServ
Integrated Services.
IP
Internet Protocol. Network layer protocol in the TCP/IP stack offering a connectionless
internetwork service. IP provides features for addressing, ToS specification, fragmentation
and reassembly, and security. Defined in RFC 791.
IP precedence
A 3-bit value in the ToS byte that is used for assigning precedence to IP packets.
IP Security
See IPsec.
IPIX
IP Information Export
IPS
intrusion prevention system.
IPS course
Cisco Implementing Cisco Intrusion Prevention System course.
IPS Device Manager
See Cisco IDM.
IPsec
IP Security. A framework of open standards that provides data confidentiality, data
integrity, and data authentication among participating peers. IPsec provides these
security services at the IP layer. IPsec uses IKE to handle the negotiation of protocols and
algorithms based on local policy and to generate the encryption and authentication keys
to be used by IPsec. IPsec can protect one or more data flows between a pair of hosts,
between a pair of security gateways, or between a security gateway and a host.
IPTD course
Cisco IP Telephony Design course.
IPTT course
Cisco IP Telephony Troubleshooting course.
IPX
Internetwork Packet Exchange.
iSCSI
SCSI over IP or Internet SCSI. iSCSI is a protocol used to carry SCSI commands,
responses and data over an IP network.
ISCW course
Cisco Implementing Secure Converged Wide Area Networks course.
ISDN
Integrated Services Digital Network.
IS-IS
Intermediate System-to-Intermediate System routing protocol.
ISL
Inter-Switch Link. Interconnection between switches.
A-16
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Acronym or Term
Definition
iSLB
iSCSI Server Load Balancing. Feature in Cisco MDS 9000 SAN-OS Software Release 3.0
that provides consolidation of Gigabit Ethernet ports and further simplifies configuration.
ISP
Internet service provider. Provider of internet access and services through a single BGP
autonomous system.
ISR
integrated services router.
ISSU
in-service software upgrade.
ITU
International Telecommunication Union.
IVR
interactive voice response.
IVR
Inter-VSAN routing. Allows a resource on any individual VSAN to be shared by users of a
different VSAN without merging the fabrics. IVR is also known as fabric routing.
JBOD
Just a Bunch of Disks
L2F
Layer 2 Forwarding Protocol. Protocol that supports the creation of secure VPDNs over
the Internet.
L2TP
Layer 2 Tunneling Protocol. Protocol that is used for implementing VPDNs and VPNs by
tunneling PPP with multivendor interoperability and acceptance. This protocol was
proposed as an alternative to IPsec but is often used with IPsec for authentication. This
protocol merges the Microsoft PPTP and Cisco L2F technologies.
label
A header that is used by a label switch router to forward packets. The header format
depends on network characteristics. In router networks, the label is a separate, 32-bit
header. In ATM networks, the label is placed into the VCI/VPI cell header. In the core,
LSRs read only the label, not the packet header. One key to the scalability of MPLS is
that labels have only local significance between two devices that are communicating.
Label Distribution
Protocol
See LDP.
label imposition
The act of putting the first label on a packet.
label information base
See LIB.
label switch router
See LSR.
label-switched path
See LSP.
LAG
link aggregation.
LAN
local area network. High-speed, low-error data network that covers a relatively small
geographic area (up to a few thousand meters). LANs connect workstations, peripherals,
terminals, and other devices in a single building or other geographically limited area. LAN
standards specify cabling and signaling at the physical and data-link layers of the OSI
model. Ethernet, FDDI, and Token Ring are widely used LAN technologies.
Layer 2 Forwarding
Protocol
See L2F.
Layer 2 Tunneling
Protocol
See L2TP.
LBS
location-based services.
LCP
link control protocol.
LD-CELP
Low-delay code-excited linear prediction.
LDP
Label Distribution Protocol. Provides communication between edge and core devices. It
assigns labels in edge and core devices to establish LSPs in conjunction with routing
protocols such as OSPF, IS-IS, EIGRP, or BGP.
LEAP
Lightweight Extensible Authentication Protocol.
© 2007 Cisco Systems, Inc.
Appendix A—Course Glossary
A--17
Acronym or Term
Definition
LED
light-emitting diode.
LFI
link fragmentation and interleaving.
LH Ethernet
long haul Ethernet. Ethernet supported over a single-mode fiber up to 100 km.
LHR
last-hop router. Router closest to multicast packet destination.
Li-on
Lithium ion
LIB
label information base. A database that is used by an LSR to store labels that are learned
from other LSRs, as well as labels that are assigned by the local LSR.
light-emitting diode
See LED.
Lightweight Access
Point Protocol
See LWAPP.
Lightweight Extensible
Authentication Protocol
See LEAP.
link aggregation
See LAG.
link control protocol
See LCP.
link fragmentation and
interleaving
See LFI.
link-state advertisement
See LSA.
LLQ
low latency queuing.
LMI
Local Management Interface.
local area network
See LAN.
Local Management
Interface
See LMI.
location-based services
See LBS.
Long-Reach Ethernet
See LRE.
low latency queuing
See LLQ.
Low-delay code-excited
linear prediction
See LD-CELP.
LRE
Long-Reach Ethernet.
LSA
link-state advertisement.
LSP
label-switched path. A sequence of hops (R0 ... Rn) in which a packet travels from R0 to
Rn through label-switching mechanisms. An LSP can be established dynamically, based
on normal routing mechanisms, or it can be established through configuration.
LSR
label switch router. The core device that switches labeled packets according to
precomputed switching tables. It can also be a switch or a router.
LWAPP
Lightweight Access Point Protocol.
MAC
Media Access Control. A unique 48-bit number used in Ethernet data packets to identify
an Ethernet device such as an access point or a client adapter.
MADCAP
Multicast Address Dynamic Client Allocation Protocol
MAN
metropolitan-area network.
Management Center for
Cisco Security Agents
Core management software that provides a central means of defining and distributing
policies, providing software updates, and maintaining communications to the agents.
A-18
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Acronym or Term
Definition
Management
Information Base
See MIB.
management plane
Services, settings, and data streams related to setting up and examining the static
configuration of a router or switch and the authentication and authorization of
administrators and operators.
MAP
mesh access point.
MBGP
Multiprotocol Border Gateway Protocol.
MBSA
Microsoft Baseline Security Analyzer.
MC
multipoint controller.
MCU
multipoint control unit.
mean opinion score
See MOS.
MED
multi-exit discriminator.
Media Access Control
See MAC.
Media Gateway Control
Protocol
See MGCP.
MEF
Metro Ethernet Forum
mesh access point
See MAP.
message integrity
check
See MIC.
message waiting
indication
See MWI.
metropolitan-area
network
See MAN.
MGCP
Media Gateway Control Protocol.
MIB
Management Information Base. Database of network management information that is
used and maintained by a network management protocol, such as SNMP or CMIP. The
value of a MIB object can be changed or retrieved using SNMP or CMIP commands,
usually through a GUI NMS. MIB objects are organized in a tree structure that includes
public (standard) and private (proprietary) branches.
MIC
message integrity check.
MIC
message integrity check
Microsoft Baseline
Security Analyzer
See MBSA.
Microsoft Challenge
Handshake
Authentication Protocol
See MS-CHAP.
Microsoft Internet
Information Server
See IIS.
MIME
Multipurpose Internet Mail Extension
Modular QoS CLI
See MQC.
MOH
music on hold.
Monitoring, Analysis,
and Response System
See Cisco Security MARS.
© 2007 Cisco Systems, Inc.
Appendix A—Course Glossary
A--19
Acronym or Term
Definition
MOS
mean opinion score.
MP
multipoint processor.
MP-BGP
multiprotocol BGP.
MPLS
Multiprotocol Label Switching. Switching method that forwards IP traffic using a label. This
label instructs the routers and the switches in the network where to forward the packets
based on pre-established IP routing information.
MPLS VPN
The MPLS VPN solution is a set of provider edge routers that are connected via a
common backbone network to supply private IP interconnectivity between two or more
customer sites for a given customer.
MQC
Modular QoS CLI. A CLI structure that allows users to create traffic policies and attach
these policies to interfaces. A traffic policy contains a traffic class and one or more QoS
features. A traffic class is used to classify traffic, while the QoS features in the traffic
policy determine how the classified traffic is treated.
MRTG
Multi Router Traffic Grapher.
MRTG
Multi Router Traffic Grapher
MS-CHAP
Microsoft Challenge Handshake Authentication Protocol.
MSDP
Multicast Source Discovery Protocol. A mechanism to connect multiple PIM-SM domains.
MSDP allows multicast sources for a group to be known to all rendezvous points in
different domains. Each PIM-SM domain uses its own rendezvous points and does not
need to depend on them in other domains. A rendezvous point runs MSDP over TCP to
discover multicast sources in other domains. MSDP is also used to announce sources
sending to a group. These announcements must originate at the domain's Rendezvous
Point. MSDP depends heavily on MP-BGP for interdomain operation.
MSFC
Multilayer Switched Feature Card. The card in the Cisco Catalyst 6500 Series switch or
the Cisco 7600 Series router that provides the multilayer functions including routing.
MST
Multiple Spanning Tree.
MTBF
Mean Time Between Failures. MTBF is a measure of how often failures occur. MTBF can
be used to project how often failures are expected
MTTR
Mean Time to Repair. MTTR is a measure of how long it takes to repair failures.
MTTY
mean time to repair
Multi Router Traffic
Grapher
See MRTG.
multipoint control unit
See MCU.
multipoint controller
See MC.
multipoint processor
See MP.
Multiprotocol Label
Switching
See MPLS.
music on hold
See MOH.
MWI
message waiting indication.
NAA
Cisco NAC Appliance Agent
NAC
Network Admission Control.
NAM
Cisco NAC Appliance Manager
NANP
North American Numbering Plan.
NAP
network access provider.
A-20
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Acronym or Term
Definition
NAS
network access server.
NAS
network attached storage. A topology where the storage devices connect to the network.
NAS
Cisco NAC Appliance Server
NAT
Network Address Translation.
NBA
network bus adapter
NBAR
Network-Based Application Recognition. NBAR is an embedded Cisco IOS software
capability that enables precise traffic classification.
NBMA
nonbroadcast multiaccess.
NCP
Network Control Protocol.
NDE
NetFlow Data Export
NDS
Novell Directory Service.
NEBS
Network Equipment Building System.
network access
provider
See NAP.
network access server
See NAS.
Network Address
Translation
See NAT.
Network Admission
Control
See NAC.
Network Analysis
Module
See Cisco NAM.
Network Control
Protocol
See NCP.
Network Equipment
Building System
See NEBS.
network interface card
See NIC.
network management
system
See NMS.
Network Mapper
See NMAP.
network service
provider
See NSP.
Network-Based
Application Recognition
See NBAR.
network-based
intrusion detection
system
See NIDS.
NHRP
Next Hop Routing Protocol.
NIC
network interface card.
NIDS
network-based intrusion detection system.
NMAP
Network Mapper.
NM-CIDS
Order code for the Cisco IDS Network Module.
NM-NAM
Order code for the Cisco NAM.
© 2007 Cisco Systems, Inc.
Appendix A—Course Glossary
A--21
Acronym or Term
Definition
NMS
network management system.
NOC
network operations center
nonbroadcast
multiaccess
See NBMA.
nonstop forwarding
See NSF.
North American
Numbering Plan
See NANP.
not-so-stubby area
See NSSA.
Novell Directory
Service
See NDS.
NPA
numbering plan area.
N-PE
network-provider edge
NSF
nonstop forwarding.
NSF
non-stop forwarding.
NSP
network service provider.
NSSA
not-so-stubby area.
numbering plan area
See NPA.
OADM
optical add/drop multiplexer.
OC
optical carrier.
OER
Optimized Edge Routing.
omnidirectional
Typically refers to a primarily circular antenna radiation pattern.
one-time password
See OTP.
ONT course
Cisco Optimizing Converged Cisco Networks course.
Open Shortest Path
First
See OSPF.
Open Systems
Interconnection
See OSI.
optical carrier
See OC.
OSA
Open Systems Adapters
OSI
Open Systems Interconnection.
OSPF
Open Shortest Path First.
OTAP
over-the-air provisioning.
OTP
one-time password.
overlay VPN
A VPN model in which the service provider provides virtual circuits between customer
sites as a replacement for dedicated point-to-point links.
over-the-air
provisioning
See OTAP.
PAC
Protected Access Credentials.
A-22
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Acronym or Term
Definition
packet
Logical grouping of information that includes a header containing control information and
(usually) user data. Packets most often are used to refer to network layer units of data.
The terms datagram, frame, message, and segment also are used to describe logical
information groupings at various layers of the OSI reference model and in various
technology circles.
packet over SONET
See POS.
packet voice DSP
module
See PVDM.
packets per second
See PPS.
PAgP
Port Aggregation Protocol.
Pairwise Master Key
See PMK.
PAM
pulse amplitude modulation.
PAP
Password Authentication Protocol.
Password
Authentication Protocol
See PAP.
PAT
Port Address Translation.
payload
Portion of a cell, frame, or packet that contains upper-layer information (data).
Payment Card
Industry
See PCI.
PBR
policy-based routing. Routing scheme that forwards packets to specific interfaces based
on user-configured policies. Such policies might specify that traffic sent from a particular
network should be forwarded out one interface, while all other traffic should be forwarded
out another interface.
PBX
private branch exchange.
PCI
Payment Card Industry. The PCI DSS was developed to ensure safe handling of
sensitive payment information, such as storage and transfer of credit card information.
PCI is the umbrella program for other programs, such as Visa Cardholder Information
Security Program (CISP) and MasterCard Site Data Protection (SDP) Program.
PCM
pulse code modulation.
PDLM
Packet Description Language Modules
PEAP
Protected Extensible Authentication Protocol.
PEAP-Generic Token
Card
See PEAP-GTC.
PEAP-GTC
PEAP-Generic Token Card.
peer-to-peer VPN
A VPN model in which the service provider actively participates in customer routing.
PER
packet error ratio.
Per VLAN Spanning
Tree Plus protocol
See PVST+.
Perceptual Speech
Quality Measurement
See PSQM.
permanent virtual
circuit
See PVC.
© 2007 Cisco Systems, Inc.
Appendix A—Course Glossary
A--23
Acronym or Term
Definition
PGM
Pragmatic General Multicast.
PGM
Pragmatic General Multicast. PGM is a reliable multicast transport protocol for
applications that require ordered, duplicate-free, multicast data delivery from multiple
sources to multiple receivers. PGM guarantees that a receiver in a multicast group either
receives all data packets from transmissions and retransmissions, or can detect
unrecoverable data packet loss. PGM is intended as a solution for multicast applications
with basic reliability requirements.
PIM
Protocol Independent Multicast. Multicast routing architecture that allows the addition of
IP multicast routing on existing IP networks. PIM is independent of unicast routing
protocols and can be operated in two modes: dense and sparse.
PIM-SM
PIM sparse mode. Form of PIM that delivers multicast traffic only to network segments
with active receivers that have explicitly requested the data.
PKC
Proactive Key Caching.
PKI
public key infrastructure.
plain old telephone
service
See POTS.
PMK
Pairwise Master Key. For EAP-TLS authentication, the PMK is the key from the RADIUS
MS-MPPE-Recv-Key attribute. For pre-shared key authentication, the PMK is the preshared key.
PoE
Power over Ethernet.
point of presence
See POP.
Point-to-Point Protocol
See PPP.
Point-to-Point
Tunneling Protocol
See PPTP.
policy-based routing
See PBR.
pop
MPLS action, removing a label.
POP
point of presence. Service POPs groom traffic from the customer network, perform edge
packet switching when IP services are enabled, and perform backbone switching when
POPs are interconnected. Service POPs are also hubs of high-value Internet services
such as web content, DNS servers to ISPs, VPN services, and other applications
deployed on a range of flexible, scalable, high-performance IP routers.
Port Address
Translation
See PAT.
Port Aggregation
Protocol
See PAgP.
POS
packet over SONET
POTS
plain old telephone service
Power over Ethernet
See PoE.
PPDIOO
prepare, plan, design, implement, operate, optimize.
PPP
Point-to-Point Protocol. Successor to SLIP that provides router-to-router and host-tonetwork connections over synchronous and asynchronous circuits. SLIP was designed to
work with IP, but PPP was designed to work with several network layer protocols, such as
IP, IPX, and ARA. PPP also has built-in security mechanisms, such as CHAP and PAP.
PPP relies on two protocols: LCP and NCP.
PPS
packets per second.
PPTP
Point-to-Point Tunneling Protocol. RFC 2637 describes PPTP.
A-24
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Acronym or Term
Definition
PQ
priority queuing.
prepare, plan, design,
implement, operate,
optimize
See PPDIOO.
PRI
Primary Rate Interface.
Primary Rate Interface
See PRI.
priority queuing
See PQ.
private branch
exchange
See PBX.
Proactive Key Caching
See PKC.
Protected Access
Credentials
See PAC.
Protected Extensible
Authentication Protocol
See PEAP.
Protocol Independent
Multicast
See PIM.
PSQM
Perceptual Speech Quality Measurement.
PSTN
public switched telephone network.
public key infrastructure
See PKI.
public switched
telephone network
See PSTN.
pulse amplitude
modulation
See PAM.
pulse code modulation
See PCM.
push
MPLS action imposing or inserting a label.
PVC
permanent virtual circuit (or connection, in ATM terminology). Virtual circuit that is
permanently established. PVCs save bandwidth that is associated with circuit
establishment and teardown in situations where certain virtual circuits must exist all the
time.
PVDM
packet voice DSP module.
PVST+
Per VLAN Spanning Tree Plus protocol.
PW
pseudo-wire. A logical point-to-point connection between pairs of PE routers used to
emulate services like Ethernet over an underlying core MPLS network through
encapsulation into a common MPLS format.
Q Signaling
See QSIG.
QBSS
QoS Basis Service Set
QoS
quality of service. The goal of QoS is to provide better and more predictable network
service by providing dedicated bandwidth, controlled jitter and latency, and improved loss
characteristics. QoS achieves these goals by providing tools for managing network
congestion, shaping network traffic, using expensive wide-area links more efficiently, and
setting traffic policies across the network.
QOS course
Cisco Implementing Cisco Quality of Service course.
QoS Policy
Propagation on BGP
See QPPB.
© 2007 Cisco Systems, Inc.
Appendix A—Course Glossary
A--25
Acronym or Term
Definition
QPPB
QoS Policy Propagation on BGP.
QSIG
Q Signaling.
quality of service
See QoS.
rack unit
See RU.
radio frequency
See RF.
Radio Resource
Management
See RRM.
RAID
Redundant Array of Independent Disks. A technology where by disk drives are combined
and configured to provide increased performance and fault tolerance.
random early detection
See RED.
RAP
rooftop access point.
Rapid Per VLAN
Spanning Tree Plus
protocol
See RPVST+.
Rapid Spanning Tree
Protocol
See RSTP.
RAS
registration, admission, and status.
RC4
Rivest Cipher 4.
RDP
Router Discovery Protocol.
Real-Time Transport
Protocol
See RTP.
REAP
Remote Edge Access Point.
received signal strength
indication
See RSSI.
RED
random early detection. This class of algorithms is designed to reduce congestion in
networks before it becomes a problem. RED works by monitoring traffic load at points in
the network and randomly discarding packets if the congestion begins to increase. The
result of the drop is that the source detects the dropped traffic and slows its transmission.
RED is designed to work primarily with TCP in IP internetwork environments.
registration, admission,
and status
See RAS.
Remote Edge Access
Point
See REAP.
Remote Monitoring
protocol
See RMON.
Resilient Packet Ring
See RPR.
Resource Manager
Essentials
See CiscoWorks RME.
Resource Reservation
Protocol
See RSVP.
return on investment
See ROI.
RF
radio frequency. A generic term for radio-based technology.
A-26
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Acronym or Term
Definition
RHI
route health injection. Allows a CSM in a Cisco Catalyst 65000 to install a host route in
the MSFC if the virtual server is in the Operational state. The CSM and the MSFC must
share a client-side VLAN.
Rivest Cipher 4
See RC4.
RMON
Remote Monitoring protocol.
roaming
A feature of some access points that allows users to move through a facility while
maintaining an unbroken connection to the enterprise network.
ROI
return on investment.
rooftop access point
See RAP.
round-trip time
See RTT.
Router Discovery
Protocol
See RDP.
RP
rendezvous point. The multicast router that is the root of the PIM-SM shared multicast
distribution tree.
RPF
Reverse Path Forwarding
RPR
Resilient Packet Ring.
RPR
resilient packet ring.
RPVST+
Rapid Per VLAN Spanning Tree Plus protocol.
RRI
reverse route injection. The ability for static routes to be automatically inserted into the
routing process for those networks and hosts protected by a remote tunnel endpoint.
These protected hosts and networks are known as remote proxy identities.
RRM
Radio Resource Management.
RSSI
received signal strength indication.
RSSI
received signal strength indication.
RST
TCP reset flag
RSTP
Rapid Spanning Tree Protocol.
RSVP
Resource Reservation Protocol. Protocol that supports the reservation of resources
across an IP network. Applications running on IP end systems can use RSVP to indicate
to other nodes the nature (bandwidth, jitter, maximum burst, and so on) of the packet
streams that they want to receive. RSVP depends on IPv6. Also known as Resource
Reservation Setup Protocol.
RTCP
RTP Control Protocol.
RTP
Real-Time Transport Protocol. Commonly used with IP networks. RTP is designed to
provide end-to-end network transport functions for applications that transmit real-time
data, such as audio, video, or simulation data, over multicast or unicast network services.
RTP provides such services as payload type identification, sequence numbering, time
stamping, and delivery monitoring to real-time applications.
RTP Control Protocol
See RTCP.
RTSP
Real-Time Streaming Protocol.
RTT
round-trip time.
RU
rack unit.
SAA
Service Assurance Agent.
SAINT
Security Administrator's Integrated Network Tool.
© 2007 Cisco Systems, Inc.
Appendix A—Course Glossary
A--27
Acronym or Term
Definition
SAN
storage area networking or storage area network.
SAN fabric
The hardware that connects workstations and servers to storage devices in a SAN.
SAN island
A completely physically isolated switch or group of switches used to connect hosts to
storage devices.
Sarbanes-Oxley Act of
2002
See SOX.
SCCP
Skinny Client Control Protocol.
SCP
Secure Copy Protocol. SCP is a means of securely transferring computer files between a
local and a remote host or between two remote hosts, using the SSH protocol.
SCSI
Small Computer System Interface
SCSI initiator
A SCSI initiator is typically the storage device in a SAN system.
SCSI target
A SCSI target is typically the storage device in a SAN system.
SDF
signature definition file.
SDH
Synchronous Digital Hierarchy. A European standard for digital optical link
Secure Copy Protocol
See SCP.
Secure Real-Time
Transport Protocol
See SRTP.
Secure Shell protocol
See SSH.
Secure Socket Layer
protocol
See SSL.
Security Administrator's
Integrated Network
Tool
See SAINT.
Serial Line Internet
Protocol
See SLIP.
Service Assurance
Agent
See SAA.
service class
Collection of service types that are required for a specific service that is being offered.
Each service class includes the attributes and values that define the type or QoS that is
associated with a given class. For example, data connectivity is a service class that you
might define that includes the service type “data bandwidth.”
service level agreement
See SLA.
service multiplexing
Ability to support multiple instances of services or EVCs on a single customer
UNI.
service set identifier
See SSID.
service-oriented
architecture
See SOA.
session initiation
protocol
See SIP.
SFP
small form-factor pluggable. A compact optical transceiver used in optical
communications. SFP was designed after the GBIC interface, and allows greater port
density (number of transceivers per inch along the edge of a motherboard) than the GBIC.
SFTP
SSH FTP.
Shortest Path First
See SPF.
A-28
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Acronym or Term
Definition
signature definition file
See SDF.
Simple Mail Transfer
Protocol
See SMTP.
Simple Network
Management Protocol
See SNMP.
SIP
session initiation protocol.
Skinny Client Control
Protocol
See SCCP.
SLA
service level agreement. Negotiated contracts between service providers and their
subscribers. An SLA defines the criteria for the specific services that the subscriber
expects the provider to deliver. The SLA is the only binding mechanism that the
subscriber has to ensure that the service provider delivers the services as agreed.
SLB
Server Load Balancer.
SLIP
Serial Line Internet Protocol.
small form-factor
pluggable
See SFP.
small office, home
office
See SOHO.
SMDS
Switched Multimegabit Digital Service. SMDS is a fast packet-switching service offered by
telephone companies that enables organizations to connect geographically separate
LANs into a single WAN. SMDS provides packet-switched bandwidth, on demand, in
increments up to 34 Mb
SMTP
Simple Mail Transfer Protocol.
SNA
Systems Network Architecture.
SNAP
Subnetwork Access Protocol.
SND course
Cisco Securing Cisco Network Devices course.
SNMP
Simple Network Management Protocol.
SNPA course
Cisco Securing Networks with PIX and ASA course.
SNR
signal-to-noise ratio.
SNR
signal-to-noise ratio
SNRD
Cisco Securing Networks with Cisco Routers and Switches course.
SOA
service-oriented architecture.
SOHO
small office, home office.
Solutions Reference
Network Design
See SRND.
SONA
Cisco Service-Oriented Network Architecture. A Cisco architectural framework that guides
the evolution of enterprise networks to a more intelligent infrastructure.
SONET
Synchronous Optical Network. North American high-speed baseband digital transport
standard specifying incrementally increasing data stream rates for movement across
digital optical links.
source routing
Routing based on the traffic source that overrides the Interior Gateway Protocol (IGP)created routing table in each of the intermediate routers. Source routing requires the host
to create the IP packets requesting source routing and is not an available tool for TE.
© 2007 Cisco Systems, Inc.
Appendix A—Course Glossary
A--29
Acronym or Term
Definition
SOX
Sarbanes-Oxley Act of 2002. A U.S. federal law that establishes new or enhanced
auditing and financial standards for all U.S. public company boards, management, and
public accounting firms. The act contains 11 sections, ranging from additional corporate
board responsibilities to criminal penalties, and it requires the U.S. Securities and
Exchange Commission to implement rulings on requirements to comply with the new law.
Spanning Tree Protocol
See STP.
SPF
Shortest Path First.
SPR
Spatial Reuse Protocol. A Cisco-developed MAC-layer protocol for ring-based
packet internetworking.
SPT
shortest path tree. Also known as source tree. A multicast distribution path that directly
connects the source's and receivers' Designated Routers (or the rendezvous point) to
obtain the shortest path through the network. Results in most efficient routing of data
between source and receivers, but may result in unnecessary data duplication throughout
network if built by anyone other than the rendezvous point.
SRND
Solutions Reference Network Design.
SRST
Survivable Remote Site Telephony.
SRTP
Secure Real-Time Transport Protocol.
SSH
Secure Shell protocol. SSH provides a secure replacement for the suite of Berkeley
r-tools such as rsh, rlogin, and rcp. (Cisco IOS Software supports rlogin.) The protocol
secures the sessions using standard cryptographic mechanisms, and the application can
be used similarly to the Berkeley rexec and rsh tools.
SSH FTP
See SFTP.
SSID
service set identifier. (Also referred to as “radio network name”). A unique identifier used
to identify a radio network and which stations must use to be able to communicate with
each other or to an access point. The SSID can be any alphanumeric entry up to a
maximum of 32 characters.
SSID
service set identifier. (Also referred to as “radio network name”). A unique identifier used
to identify a radio network and which stations must use to be able to communicate with
each other or to an access point. The SSID can be any alphanumeric entry up to a
maximum of 32 characters.
SSL
Secure Socket Layer protocol. The main role of SSL is to provide security for web traffic.
Security includes confidentiality, message integrity, and authentication. SSL achieves
these elements of security through the use of cryptography, digital signatures, and
certificates.
SSM
Source Specific Multicast.
SSM
Source Specific Multicast
SSO
stateful switchover. With redundant supervisor engines, SSO establishes one of the
supervisor engines as active while the other supervisor engine is designated as standby,
and then SSO synchronizes information between them. A switchover from the active to
the redundant supervisor engine occurs when the active supervisor engine fails, is
removed from the switch, or is manually shut down for maintenance. This type of
switchover ensures that Layer 2 traffic is not interrupted.
SSO
stateful switchover.
stateful switchover
See SSO.
storage area
networking
See SAN.
STP
Spanning Tree Protocol.
Subnetwork Access
Protocol
See SNAP.
A-30
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Acronym or Term
Definition
Survivable Remote Site
Telephony
See SRST.
SVC
switched virtual circuit. SVCs are established on demand through a call setup request
from the customer edge device.
SVTI
Static VTI.
Switched Multimegabit
Digital Service
See SMDS.
switched virtual circuit
See SVC.
Synchronous Digital
Hierarchy
See SDH.
Synchronous Optical
Network
See SONET.
syslog
system log.
syslog
system message logging.
Systems Network
Architecture
See SNA.
T1
A North American or Japanese transmission circuit of 24 channels running at 64 kbps
sampled at 8000 times per second for 1.544 Mbps.
T3
A North American or Japanese transmission circuit of 672 channels running at 64 kbps
sampled at 8000 times per second (or 28 T1s) running at 44.736 Mbps.
TCO
total cost of ownership.
TCO
total cost of ownership
TCP
Transmission Control Protocol. Connection-oriented transport layer protocol that provides
reliable full-duplex data transmission. TCP is part of the TCP/IP protocol stack.
TCP
TCP Offload Engine
TDM
time-division multiplexing.
TDMA
time-division multiple access.
TE
traffic engineering. The techniques and processes that are used to cause routed traffic to
travel through a network on a path other than the one that would have been chosen if
standard routing methods had been used.
Temporal Key Integrity
Protocol
See TKIP.
Time to Live
See TTL.
time-division multiple
access
See TDMA.
time-division
multiplexing
See TDM.
TKIP
Temporal Key Integrity Protocol.
TLS
Transport Layer Security protocol.
TLV
type, length, value.
TopN
The Switch TopN Reports utility allows network administrators to collect and
analyze data for each physical port on a switch.
ToS
type of service. A byte in the IPv4 header.
© 2007 Cisco Systems, Inc.
Appendix A—Course Glossary
A--31
Acronym or Term
Definition
total cost of ownership
See TCO.
TPC
Transmit Power Control
traffic engineering
See TE.
Transmission Control
Protocol
See TCP.
Transport Layer
Security protocol
See TLS.
TSpec
traffic specification
TTL
Time to Live.
TTLS
Tunneled Transport Layer Security protocol.
tunnel
Secure communication path between two peers, such as two routers.
Tunneled Transport
Layer Security protocol
See TTLS.
tunneling
Architecture that provides the services that are necessary to implement any standard
point-to-point data encapsulation scheme.
type of service
See ToS.
type, length, value
See TLV.
U-APSD
Unscheduled Automatic Power Save Delivery.
UA
user agent.
UAC
user agent client.
UAS
user agent server.
uBR
universal broadband router.
UDP
User Datagram Protocol. Connectionless transport layer protocol in the TCP/IP protocol
stack. UDP is a simple protocol that exchanges datagrams without acknowledgments or
guaranteed delivery, requiring that error processing and retransmission be handled by
other protocols. UDP is defined in RFC 768.
UMTS
Universal Mobile Telecommunications Service.
UNI
user network interface.
Unicast Reverse Path
Forwarding
See uRPF.
universal broadband
router
See uBR.
Universal Mobile
Telecommunications
Service
See UMTS.
U-PE
user-provider edge
uRPF
Unicast Reverse Path Forwarding.
user agent
See UA.
user agent client
See UAC.
user agent server
See UAS.
User Datagram
Protocol
See UDP.
A-32
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Acronym or Term
Definition
VACL
VLAN ACL.
VAD
voice activity detection.
variable-length subnet
mask
See VLSM.
video on demand
See VoD.
VIP
virtual IP address..
virtual circuit
Logical circuit created to ensure reliable communication between two network devices. A
virtual circuit is defined by a VPI/VCI pair and can be either a PVC or an SVC. Virtual
circuits are used in Frame Relay and X.25. In ATM, a virtual circuit is called a “virtual
channel.” Sometimes abbreviated “VC.”
virtual fabric trunking
Enables interconnect ports to transmit and receive frames in more than one VSAN over
the same physical link.
virtual LAN
See VLAN.
virtual path
A collection of virtual circuits with a common VPI.
virtual path
identifier/virtual circuit
identifier
See VPI/VCI.
virtual private dial-up
network
See VPDN.
virtual private network
See VPN.
Virtual Private Network
version 4
See VPNv4.
Virtual Router
Redundancy Protocol
See VRRP.
virtual routing and
forwarding
See VRF.
VLAN
virtual LAN. Group of devices on one or more LANs that are configured (using
management software) so that they can communicate as if they were attached to the
same wire, when in fact they are located on a number of different LAN segments.
Because VLANs are based on logical instead of physical connections, they are extremely
flexible.
VLH Ethernet
very long haul Ethernet.
VLSM
variable-length subnet mask.
VoD
video on demand.
voice activity detection
See VAD.
Voice over IP
See VoIP.
voice over WLAN
See VoWLAN.
VoIP
Voice over IP. The ability to carry normal telephony-style voice over an IP-based internet
with POTS-like functionality, reliability, and voice quality. VoIP enables a router to carry
voice traffic (for example, telephone calls and faxes) over an IP network. In VoIP, the DSP
segments the voice signal into frames, which then are coupled in groups of two and
stored in voice packets. These voice packets are transported using IP in compliance with
ITU-T specification H.323.
VoWLAN
voice over WLAN.
VPDN
virtual private dial-up network.
© 2007 Cisco Systems, Inc.
Appendix A—Course Glossary
A--33
Acronym or Term
Definition
VPI/VCI
virtual path identifier/virtual circuit identifier. The VPI is an 8-bit field in the header of an
ATM cell. The VCI is a 16-bit field in the header of an ATM cell. The VCI, together with the
VPI, is used to identify the next destination of a cell as it passes through a series of ATM
switches on its way to its destination.
VPLS
Virtual Private LAN Services. A class of VPN that supports the connection of multiple sites
in a single bridged domain over a managed IP/MPLS network.
VPN
virtual private network. Enables IP traffic to travel securely over a public TCP/IP network
by encrypting all traffic from one network to another. A VPN uses tunneling to encrypt all
information at the IP level.
VRF
virtual routing and forwarding.
VRRP
Virtual Router Redundancy Protocol.
VSAN
virtual storage area network. A VSAN is a logical SAN that provides isolation among
devices that are physically connected to the same fabric.
VTI
virtual tunnel interface.
WAN
wide area network. Data communications network that serves users across a broad
geographic area and often uses transmission devices that are provided by common
carriers. Frame Relay, SMDS, and X.25 are examples of WANs.
weighted fair queuing
See WFQ.
weighted random early
detection
See WRED.
WEP
Wired Equivalent Privacy. A simple mechanism defined within the 802.11 standard
designed to make the link integrity of wireless devices equal to that of a cable. This
mechanism is not secure enough for enterprise networks.
WFQ
weighted fair queuing. Congestion-management algorithm that identifies conversations (in
the form of traffic streams), separates packets that belong to each conversation, and
ensures that capacity is shared fairly among these individual conversations. WFQ is an
automatic way of stabilizing network behavior during congestion and results in increased
performance and reduced retransmission.
wide area network
See WAN.
Wide-Area Application
Engine
See Cisco WAE.
Wide-Area Application
Services
See Cisco WAAS.
Wi-Fi Protected Access
See WPA.
Wired Equivalent
Privacy
See WEP.
Wireless Control
System
See Cisco WCS.
wireless LAN
See WLAN.
Wireless LAN Solution
Engine
See CiscoWorks WLSE.
Wireless Services
Module
See Cisco WiSM.
WLAN
wireless LAN. A LAN that is used to provide network connectivity over radio waves.
WLAN controller
See WLC.
WLC
WLAN controller.
A-34
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.
Acronym or Term
Definition
WMM
Wi-Fi-Multimedia
WPA
Wi-Fi Protected Access. A security solution from the Wireless Ethernet Compatibility
Alliance. WPA relies on the interim version of IEEE standard 802.11i. WPA supports WEP
and TKIP encryption algorithms as well as 802.1X and EAP for simple integration with
existing authentication systems. WPA key management uses a combination of encryption
methods to protect communication between client devices and the access point.
WRED
weighted random early detection.
© 2007 Cisco Systems, Inc.
Appendix A—Course Glossary
A--35
A-36
Designing Cisco Network Service Architectures (ARCH) v2.0
© 2007 Cisco Systems, Inc.