© 2006 Cisco Systems, Inc. All rights reserved. QOS Lecture 5 - QOS Policy Models.
-
Upload
antony-gilmore -
Category
Documents
-
view
215 -
download
0
Transcript of © 2006 Cisco Systems, Inc. All rights reserved. QOS Lecture 5 - QOS Policy Models.
© 2006 Cisco Systems, Inc. All rights reserved.
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 best-effort model is appropriate.
Integrated Services
(IntServ)
Applications signal to the network that the applications require certain QoS parameters.
Differentiated Services
(DiffServ)
The network recognizes classes that require QoS.
© 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
Flow Identification Packet Scheduler
Data Plane
Routing Selection Admission Control
Reservation Setup
Control Plane
Reservation Table
© 2006 Cisco Systems, Inc. All rights reserved.
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 Receivers
RSVP Tunnel
Provides divergent performance requirements for multimedia applications:
Rate-sensitive traffic
Delay-sensitive traffic
© 2006 Cisco Systems, Inc. All rights reserved.
RSVP Daemon
PolicyControl
AdmissionControl
Packet Classifier
PacketScheduler
Routing
RSVPDaemon
Reservation
Data
© 2006 Cisco Systems, Inc. All rights reserved.
Reservation Merging
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.
R5 R4
R3
R5 R4
R1
R2Sender
© 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
Edge
Interior
Edge
DiffServ Domain
End Station
End Station
© 2006 Cisco Systems, Inc. All rights reserved.
Methods for Implementing QoS Policy
Method Description
Legacy CLI – 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 – Application for simple QoS configurations
© 2006 Cisco Systems, Inc. All rights reserved.
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
For interactive traffic, you can use CQ and TCP header compression.
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
© 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.
class-map [match-all | match-any] class-map-name
router(config)#
description description
router(config-cmap)#
Use at least one condition to match packets.
Use descriptions in large and complex configurations. The description has no operational meaning.
match any
router(config-cmap)#
match not match-criteria
© 2006 Cisco Systems, Inc. All rights reserved.
Classifying Traffic with ACLs
Standard ACL
access-list access-list-number {permit | deny | remark} source [mask]
router(config)#
access-list access-list-number {permit | deny} protocol source source-wildcard [operator port] destination destination-wildcard [operator port] [established] [log]
router(config)#
match access-group access-list-numberrouter(config-cmap)#
Extended ACL
Use an ACL as a match criterion
© 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.
policy-map policy-map-name
router(config)#
class {class-name | class-default}
router(config-pmap)#
class class-name condition
router(config-pmap)#
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.
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.
© 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
service-policy {input | output} policy-map-namerouter(config-if)#
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
Service policies can be applied to an interface for inbound or outbound packets
© 2006 Cisco Systems, Inc. All rights reserved.
Modular QoS CLI Configuration Example
router(config)# class-map match-any business-critical-trafficrouter(config-cmap)# match protocol http url “*customer*”router(config-cmap)# match protocol http url citrix
router(config)# policy-map myqos policyrouter(config-pm am)# class business-critical-trafficrouter(config-pm am-c)# bandwidth 1000
router(config)# interface serial 0/0router(config-if)# service-policy output myqos policy
1
2
3
© 2006 Cisco Systems, Inc. All rights reserved.
Boolean Nesting
Salaries
HockeyPlayers
FootballPlayers
Goal: Find books that cover the salaries of either football players or hockey players.
Solution: Boolean (salaries AND [football players OR hockey players]).
Goal
© 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 100class-map Application match access-group 101!policy-map QoS-Policy class VoIP priority 100 class Application bandwidth 25 class class-default fair-queue!interface Serial0/0 service-policy output QoS-Policy!access-list 100 permit ip any any precedence 5access-list 100 permit ip any any dscp efaccess-list 101 permit tcp any host 10.1.10.20access-list 101 permit tcp any host 10.1.10.40
Classification
QoS Policy
QoS Policy on Interface
Classification
© 2006 Cisco Systems, Inc. All rights reserved.
Basic Verification Commands
Display the class maps
show class-map
router#
show policy-map
router#
show policy-map interface type number
router#
Display the policy maps
Display the applied policy map on the interface
© 2006 Cisco Systems, Inc. All rights reserved.
Cisco AutoQoS
© 2006 Cisco Systems, Inc. All rights reserved.
Cisco AutoQoS Features in a WAN
Feature Benefit
Autodetermination of WAN Settings
Eliminates the need to know QoS theory and design in common deployment scenarios
Autoclassification of VoIP Settings
Automatically classifies RTP payload and VoIP control packets (H.323, H.225 unicast, Skinny, SIP), and MGCP
Initial Policy Generation
Reduces the time needed to establish an initial, feasible QoS policy solution
VoIP LLQ Provisioning
Provisions LLQ for the VoIP bearer and bandwidth 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 bandwidth 1540 ip address 10.10.100.1 255.255.255.0 auto qos voip
IP CEF and Bandwidth
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.
2.
3.
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.
2.
A
B
© 2006 Cisco Systems, Inc. All rights reserved.
Comparing QoS Implementation Methods
Legacy CLI MQCCisco
AutoQoSCisco SDM QoS Wizard
Ease of use PoorModerately
easySimple 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