Transcript Lecture 5 - QOS Policy Models

QOS
Lecture 5 - QOS Policy Models
© 2006 Cisco Systems, Inc. All rights reserved.
Three QoS Models
Model
Characteristics
Best effort
No QoS is applied to packets. If it is not
important when or how packets arrive, the besteffort model is appropriate.
Integrated
Services
Applications signal to the network that the
applications require certain QoS parameters.
(IntServ)
Differentiated
Services
The network recognizes classes that require
QoS.
(DiffServ)
© 2006 Cisco Systems, Inc. All rights reserved.
Best-Effort Model
 Internet was initially based on a best-effort packet
delivery service.
 Best-effort is the default mode for all traffic.
 There is no differentiation among types of traffic.
 Best-effort model is similar to using standard mail—
“The mail will arrive when the mail arrives.”
 Benefits:
Highly scalable
No special mechanisms required
 Drawbacks:
No service guarantees
No service differentiation
© 2006 Cisco Systems, Inc. All rights reserved.
Integrated Services (IntServ) Model Operation
 Ensures guaranteed delivery and
predictable behavior of the network for
applications.
 Provides multiple service levels.
 RSVP is a signaling protocol to
reserve resources for specified QoS
parameters.
 The requested QoS parameters are
then linked to a packet stream.
 Streams are not established if the
required QoS parameters cannot be
met.
 Intelligent queuing mechanisms
needed to provide resource
reservation in terms of:
Guaranteed rate
Controlled load (low delay, high
throughput)
© 2006 Cisco Systems, Inc. All rights reserved.
IntServ Functions
Control Plane
Routing Selection
Admission Control
Reservation Setup
Reservation Table
Data Plane
Flow Identification
© 2006 Cisco Systems, Inc. All rights reserved.
Packet Scheduler
Benefits and Drawbacks of the IntServ Model
 Benefits:
Explicit resource admission control (end to end)
Per-request policy admission control (authorization object,
policy object)
Signaling of dynamic port numbers (for example, H.323)
 Drawbacks:
Continuous signaling because of stateful architecture
Flow-based approach not scalable to large implementations,
such as the public Internet
© 2006 Cisco Systems, Inc. All rights reserved.
Resource Reservation Protocol (RSVP)
 Is carried in IP—protocol ID
46
 Can use both TCP and UDP
port 3455
 Is a signaling protocol and
works with existing routing
protocols
 Requests QoS parameters
from all devices between the
source and destination
Sending
Host
RSVP
Tunnel
RSVP Receivers
 Provides divergent performance requirements for multimedia
applications:
Rate-sensitive traffic
Delay-sensitive traffic
© 2006 Cisco Systems, Inc. All rights reserved.
RSVP Daemon
Policy
Control
Admission
Control
RSVP
Daemon
Reservation
Routing
Data
© 2006 Cisco Systems, Inc. All rights reserved.
Packet
Classifier
Packet
Scheduler
Reservation Merging
R3
R5
R5
R4
R4
Sender
R2
R1
 R1, R2 and R3 all request the same reservation.
 The R2 and R3 request merges at R4.
 The R1 request merges with the combined R2 and R3 request at R5.
 RSVP reservation merging provides scalability.
© 2006 Cisco Systems, Inc. All rights reserved.
RSVP in Action
 RSVP sets up a path through the network with the requested QoS.
 RSVP is used for CAC in Cisco Unified CallManager 5.0.
© 2006 Cisco Systems, Inc. All rights reserved.
The Differentiated Services Model
 Overcomes many of the limitations best-effort and IntServ models
 Uses the soft QoS provisioned-QoS model rather than the hard QoS
signaled-QoS model
 Classifies flows into aggregates (classes) and provides appropriate QoS for
the classes
 Minimizes signaling and state maintenance requirements on each network
node
 Manages QoS characteristics on the basis of per-hop behavior (PHB)
 You choose the level of service for each traffic class
Edge
End Station
Edge
Interior
Edge
DiffServ Domain
© 2006 Cisco Systems, Inc. All rights reserved.
End Station
Methods for Implementing QoS Policy
Method
Legacy CLI
Description
– Coded at the CLI
– Requires each interface to be individually
configured
– Time-consuming
MQC
– Coded at the CLI
– Uses configuration modules
– Best method for QoS fine tuning
Cisco AutoQoS
– Applies a possible QoS configuration to the
interfaces
– Fastest way to implement QoS
Cisco SDM QoS wizard
© 2006 Cisco Systems, Inc. All rights reserved.
– Application for simple QoS configurations
Configuring QoS at the CLI
 Uses the CLI via console and Telnet
 Traditional method
 Nonmodular
 Cannot separate traffic classification from policy
definitions
 Time-consuming and potentially error-prone task
 Used to augment and fine-tune newer Cisco AutoQoS
method
© 2006 Cisco Systems, Inc. All rights reserved.
Guidelines for Using the CLI
Configuration Method
 Build a traffic policy:
Identify the traffic pattern.
Classify the traffic.
Prioritize the traffic.
Select a proper QoS mechanism:
Queuing
Compression
 Apply the traffic policy to the interface.
© 2006 Cisco Systems, Inc. All rights reserved.
Legacy CLI QoS Example











interface multilink
ip address 10.1.61.1 255.255.255.0
load-interval 30
custom-queue-list 1
ppp multilink
ppp multilink fragment-delay 10
ppp multilink interleave
multilink-group 1
ip tcp header-compression iphc-format
!
queue-list 1 protocol ip 2 tcp 23
 For interactive traffic, you can use CQ and TCP header compression.
© 2006 Cisco Systems, Inc. All rights reserved.
Modular QoS CLI
 A command syntax for configuring QoS policy
 Reduces configuration steps and time
 Configures policy, not “raw” per-interface commands
 Uniform CLI across major Cisco IOS platforms
 Uniform CLI structure for all QoS features
 Separates classification engine from the policy
© 2006 Cisco Systems, Inc. All rights reserved.
Modular QoS CLI Components
© 2006 Cisco Systems, Inc. All rights reserved.
Step 1: Creating Class Maps:
“What Traffic Do We Care About?”
 Each class is identified using a class map.
 A traffic class contains three major elements:
A case-sensitive name
A series of match commands
An instruction on how to evaluate the match commands if more
than one match command exists in the traffic class
 Class maps can operate in two modes:
Match all: All conditions have to succeed.
Match any: At least one condition must succeed.
 The default mode is match all.
© 2006 Cisco Systems, Inc. All rights reserved.
Configuring Class Maps
 Enter class-map configuration mode. Specify the matching strategy.
router(config)#
class-map [match-all | match-any] class-map-name
 Use at least one condition to match packets.
router(config-cmap)#
match any
match not match-criteria
 Use descriptions in large and complex configurations. The
description has no operational meaning.
router(config-cmap)#
description description
© 2006 Cisco Systems, Inc. All rights reserved.
Classifying Traffic with ACLs
 Standard ACL
router(config)#
access-list access-list-number {permit | deny | remark}
source [mask]
 Extended ACL
router(config)#
access-list access-list-number {permit | deny} protocol
source source-wildcard [operator port] destination
destination-wildcard [operator port] [established] [log]
 Use an ACL as a match criterion
router(config-cmap)#
match access-group access-list-number
© 2006 Cisco Systems, Inc. All rights reserved.
Step 2: Policy Maps:
“What Will Be Done to This Traffic?”
 A policy map defines a traffic policy, which configures
the QoS features associated with a traffic class that
was previously identified using a class map.
 A traffic policy contains three major elements:
A case-sensitive name
A traffic class
The QoS policy that is associated with that traffic class
 Up to 256 traffic classes can be associated with a
single traffic policy.
 Multiple policy maps can be nested to influence the
sequence of QoS actions.
© 2006 Cisco Systems, Inc. All rights reserved.
Configuring Policy Maps
 Enter policy-map configuration mode. Policy maps are identified by a
case-sensitive name.
router(config)#
policy-map policy-map-name
 Enter the per-class policy configuration mode by using the name of a
previously configured class map. Use the class-default name to configure
the policy for the default class.
router(config-pmap)#
class {class-name | class-default}
 Optionally, you can define a new class map by entering the condition after
the name of the new class map. Uses the match-any strategy.
router(config-pmap)#
class class-name condition
© 2006 Cisco Systems, Inc. All rights reserved.
Step 3: Attaching Service Policies:
“Where Will This Policy Be Implemented?”
 Attach the specified service policy map to the input or
output interface
router(config-if)#
service-policy {input | output} policy-map-name
class-map HTTP
match protocol http
!
policy-map PM
class HTTP
bandwidth 2000
class class-default
bandwidth 6000
!
interface Serial0/0
service-policy output PM
© 2006 Cisco Systems, Inc. All rights reserved.
Service policies
can be applied to
an interface for
inbound or
outbound
packets
Modular QoS CLI Configuration Example
1
router(config)# class-map match-any business-critical-traffic
router(config-cmap)# match protocol http url “*customer*”
router(config-cmap)# match protocol http url citrix
2
router(config)# policy-map myqos policy
router(config-pm am)# class business-critical-traffic
router(config-pm am-c)# bandwidth 1000
interface serial 0/0
3 router(config)#
router(config-if)# service-policy output myqos policy
© 2006 Cisco Systems, Inc. All rights reserved.
Boolean Nesting
Goal
Salaries
Football
Players
Goal:
Hockey
Players
Find books that cover the salaries of either
football players or hockey players.
Solution: Boolean (salaries AND [football players OR
hockey players]).
© 2006 Cisco Systems, Inc. All rights reserved.
MQC Example
 Voice traffic needs priority, low delay, and constant
bandwidth.
 Interactive traffic needs bandwidth and low delay.
© 2006 Cisco Systems, Inc. All rights reserved.
MQC Configuration
hostname Office
!
class-map VoIP
match access-group 100
Classification
class-map Application
match access-group 101
!
policy-map QoS-Policy
class VoIP
priority 100
class Application
QoS Policy
bandwidth 25
class class-default
fair-queue
!
interface Serial0/0
QoS Policy on Interface
service-policy output QoS-Policy
!
access-list 100 permit ip any any precedence 5
access-list 100 permit ip any any dscp ef
Classification
access-list 101 permit tcp any host 10.1.10.20
access-list 101 permit tcp any host 10.1.10.40
© 2006 Cisco Systems, Inc. All rights reserved.
Basic Verification Commands
 Display the class maps
router#
show class-map
 Display the policy maps
router#
show policy-map
 Display the applied policy map on the interface
router#
show policy-map interface type number
© 2006 Cisco Systems, Inc. All rights reserved.
Cisco AutoQoS
© 2006 Cisco Systems, Inc. All rights reserved.
Cisco AutoQoS Features in a WAN
Feature
Autodetermination of
WAN Settings
Autoclassification of
VoIP Settings
Benefit
Eliminates the need to know QoS theory and design
in common deployment scenarios
Automatically classifies RTP payload and VoIP
control packets (H.323, H.225 unicast, Skinny, SIP),
and MGCP
Initial Policy
Reduces the time needed to establish an initial,
Generation
feasible QoS policy solution
VoIP LLQ
Provisions LLQ for the VoIP bearer and bandwidth
Provisioning
guarantees for control traffic
WAN Traffic Shaping Enables WAN traffic shaping (FRTS, CIR and burst)
Link Efficiency
Enables link efficiency mechanisms (LFI and cRTP)
as appropriate
Management
Provides SNMP and syslog alerts for VoIP packet
drops
© 2006 Cisco Systems, Inc. All rights reserved.
Cisco AutoQoS Features in a LAN
Feature
Benefit
Simplified
Configuration
One-command voice configuration does not affect other network
traffic. Can be fine tuned.
Queue
Configuration
Configures queue admission criteria, Cisco Catalyst strict-priority
queuing with WRR scheduling, modifies queue sizes and
weights.
Automated &
Secure
Detects Cisco IP Phones and enables AutoQoS settings.
Protects against malicious activity during Cisco IP phone
relocations and moves.
Optimal VoIP
Performance
Leverages decades of networking experience and uses all
advanced QoS capabilities of the Cisco Catalyst switches.
End-to-End
Interoperability
Works with AutoQoS settings on all other Cisco switches and
routers.
Trust Boundary
Enforcement
Enforces the trust boundary on Cisco Catalyst switch access
ports, uplinks, and downlinks
NBAR Support
Enables NBAR for different traffic types
© 2006 Cisco Systems, Inc. All rights reserved.
Cisco AutoQoS Use Guidelines
 Make sure that:
Any QoS configurations on the WAN interface are removed.
CEF is enabled.
NBAR is enabled.
Correct bandwidth statement is configured on the interface.
Cisco AutoQoS is enabled on the interface.
© 2006 Cisco Systems, Inc. All rights reserved.
Cisco AutoQoS Example
 Enable Cisco AutoQoS on relevant devices (such as LAN switches and WAN
routers) that need to perform QoS.
© 2006 Cisco Systems, Inc. All rights reserved.
Cisco AutoQoS Example (Cont.)
 interface Serial1/3
 ip cef
IP CEF and Bandwidth
 bandwidth 1540
 ip address 10.10.100.1 255.255.255.0
 auto qos voip
AutoQoS for VoIP Traffic Recognized by NBAR
© 2006 Cisco Systems, Inc. All rights reserved.
Cisco Security Device Manager (SDM)
© 2006 Cisco Systems, Inc. All rights reserved.
Steps 1 to 4: Creating a QoS Policy
1.
3.
2.
4.
© 2006 Cisco Systems, Inc. All rights reserved.
Step 5: Launching the QoS Wizard
© 2006 Cisco Systems, Inc. All rights reserved.
Step 6: Selecting the Interface
© 2006 Cisco Systems, Inc. All rights reserved.
Step 7: Generating a QoS Policy
© 2006 Cisco Systems, Inc. All rights reserved.
Reviewing the QoS Configuration
© 2006 Cisco Systems, Inc. All rights reserved.
Completing the Configuration: Command
Delivery Status
© 2006 Cisco Systems, Inc. All rights reserved.
Monitoring QoS Status
1.
A
B
2.
© 2006 Cisco Systems, Inc. All rights reserved.
Comparing QoS Implementation Methods
Legacy CLI
MQC
Cisco
AutoQoS
Cisco SDM
QoS Wizard
Ease of use
Poor
Moderately
easy
Simple
Simple
Ability to
fine-tune
Acceptable
Very good
Limited
Limited
Time to
implement
Longest
Average
Shortest
Short
Modularity
Poor
Excellent
Excellent
Very good
© 2006 Cisco Systems, Inc. All rights reserved.
Network-Based Application Recognition
(NBAR)
•NBAR is a new classification engine in Cisco IOS®
Software that can recognize a wide variety of
applications
•Including Web-based applications and client/server
applications that dynamically assign TCP or User
Datagram Protocol (UDP) port numbers
•After the application is recognized, the network can
invoke specific services for that particular application.
•NBAR currently works with quality-of-service (QoS)
features to help ensure that the network bandwidth is
best used to fulfil your business objectives.
© 2006 Cisco Systems, Inc. All rights reserved.
Why NBAR is used
•Today's applications require high performance to help ensure
competitiveness in an increasingly fast-paced business
environment.
•The network can provide a variety of services to help ensure
that your mission-critical applications receive the bandwidth
they need to provide this performance.
•The difficulty is that today's Internet-based and client-server
applications make it difficult for the network to identify and
provide the proper level of control you need.
•NBAR solves this problem by adding intelligent network
classification to your infrastructure.
© 2006 Cisco Systems, Inc. All rights reserved.
NBAR fits into the Content Networking
framework
•NBAR provides intelligent network classification that can
be used to determine which services the network should
provide.
•NBAR currently works with QoS features so that one can
provide differentiated classes of service (CoSs) to different
applications.
© 2006 Cisco Systems, Inc. All rights reserved.
Advantages of NBAR
•Help Ensure Performance for Mission-Critical Applications
•Reduce WAN Expenses
•Manage Web Response
•Improve VPN Performance
•Improve Multiservice Performance
© 2006 Cisco Systems, Inc. All rights reserved.