Модуларен QoS CLI

AutoQoS
 Modular QoS CLI
• The MQC provides a
modular approach to
configuration of QoS
mechanisms.
• First, build modules
defining classes of
traffic.
• Then, build modules
defining QoS policies
and assign classes to
policies.
• Finally, assign the policy
modules to interfaces.
 Modular QoS CLI Components

Define Classes of Define QoS Policies for Apply a Service Policy

Traffic Classes
“What will be done to “Where will this policy
“What traffic do we this traffic?” be implemented?”
care about?” Defines a policy map,
which configures the Attaches a service
Each class of traffic is QoS features associated policy configured with a
defined using a class with a traffic class policy map to an
map. previously identified interface.
using a class map.
 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
– If more than one match command exists in the traffic class, an
instruction on how to evaluate these match commands
• 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.
• Multiple traffic classes can be configured as a single traffic
class (nested).
 Classification Using Class Maps

• Match-all requires all conditions to return a positive answer. If

one condition is not met, the class map will return a “no
match” result.
• Match-any requires at least one condition to return a positive
answer. If no condition is met, the class map will return a “no
match” result.
 Example nested class maps
• Router(config)# class-map match-all class3
• Router(config-cmap)# match protocol ip
• Router(config-cmap)# match qos-group 4
• Router(config-cmap)# exit
• Router(config)# class-map match-any class4
• Router(config-cmap)# match class-map class3
• Router(config-cmap)# match destination-address mac 1.1.1
• Router(config-cmap)# match access-group 2
• Router(config-cmap)# exit
• Router(config)# policy-map policy1
• Router(config-pmap)# class class4
• Router(config-pmap-c)# police 8100 1500 2504 conform-action
transmit exceed-action set-qos-transmit 4
• Router(config-pmap-c)# exit
 Policy Maps
• “What will be done to this traffic?”
• Defines a traffic policy, which configures the QoS
features associated with a traffic class previously
identified using a class map.
• A traffic policy contains three major elements:
– A case-sensitive name
– A traffic class
– The QoS policy 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.
 Example policy map
• class-map match-all Test1
• match protocol http
• match access-group 100
• class-map match-any Test2
• match protocol http
• match access-group 101
• !
• policy-map Test
• class Test1
• bandwidth 100
• class Test2
• bandwidth 200
• class Test3 access-group 100
• bandwidth 300
• !
• access-list 100 permit tcp any host 10.1.1.1
• access-list 101 permit tcp any host 10.1.1.2
 Hierarchical (Nested) Policy Maps
• Policy maps are normally applied to interfaces.
• Nested policy maps can be applied directly inside
other policy maps to influence sequence of QoS
actions.
• For example: Shape all traffic to 2 Mbps; queue
shaped traffic to provide priority and bandwidth
guarantees.
 Hierarchical (Nested) Policy Maps
Example

• Example policy:
– Shape all traffic on FastEthernet to 2 Mbps.
– Out of the 2 Mbps, guarantee 1 Mbps to HTTP traffic.
 Service Policy
• “Where will this policy be implemented?”
• Attaches a traffic policy configured with a policy
map to an interface.
• Service policies can be applied to an interface for
inbound or outbound packets.
 Summary
• MQC is a modular approach to designing and
implementing an overall QoS policy.
• Applying an overall QoS policy involves three steps:
defining class maps to identify classes of traffic,
defining QoS policy maps, and assigning the policy
maps to interfaces.
• Each class of traffic is defined in a class map module.
• The class-map global configuration command is used
to create a class map and enter the class-map
configuration mode. The show class-map command
lists all class maps with their match statements.
 Summary (Cont.)
• A policy map module defines a traffic policy,
which configures the QoS features associated
with a traffic class previously identified using a
class map.
• The service-policy command assigns a single
policy map to multiple interfaces or assigns
multiple policy maps to a single interface (a
maximum of one in each direction, inbound and
outbound).
• A service policy attaches a traffic policy
configured with a policy map to an interface.
 Example: Complete MQC
Configuration
• two traffic classes are created and their match
criteria are defined.
• For the first traffic class, called class1, access
control list (ACL) 101 is used as the match
criterion.
• For the second traffic class, called class2, ACL 102
is used as the match criterion.
• Packets are checked against the contents of these
ACLs to determine if they belong to the class.
 Traffic Classes Defined
• Router(config)# class-map class1
• Router(config-cmap)# match access-group 101
• Router(config-cmap)# exit
• Router(config)# class-map class2
• Router(config-cmap)# match access-group 102
• Router(config-cmap)# exit
 Traffic Policy Created
• a traffic policy called policy1 is defined to contain
policy specifications for the two classes: class1
and class2. The match criteria for these classes
was defined in the traffic classes.
• For class1, the policy includes a bandwidth
allocation request and a maximum packet count
limit for the queue reserved for the class.
• For class2, the policy specifies only a bandwidth
allocation request.
• Router(config)# policy-map policy1
• Router(config-pmap)# class class1
• Router(config-pmap-c)# bandwidth 3000
• Router(config-pmap-c)# queue-limit 30
• Router(config-pmap-c)# exit
• Router(config-pmap)# class class2
• Router(config-pmap-c)# bandwidth 2000
• Router(config-pmap-c)# exit
 Traffic Policy Attached to an Interface
• After a traffic policy is defined with the policy-
map command, the traffic policy can be attached
to one or more interfaces to specify the traffic
policy for those interfaces by using the service-
policy command in interface configuration mode.
• Although the same traffic policy can be assigned
to multiple interfaces, each interface can have
only one traffic policy attached at the input and
a single traffic policy attached at the output.
• Router(config)# interface e1/1
• Router(config-if)# service-policy output policy1
• Router(config-if)# exit
• Router(config)# interface fa1/0/0
• Router(config-if)# service-policy output policy1
• Router(config-if)# exit
CISCO AUTO QOS VOIP
 AutoQoS
• Ability to deploy QoS features for converged IP
telephony and data networks
– simplifies and automates the MQC, definition of
traffic classes, and the creation and configuration of
traffic policies.
• Generates traffic classes and policy map CLI
templates.
• When it is configured at the interface, the traffic
receives the required QoS treatment
automatically.
 When to use AutoQoS
• Small- to medium-sized businesses that must deploy IP
telephony quickly, but lack the experience and staffing to
plan and deploy IP QoS services.
• Large enterprises that need to deploy Cisco telephony
solutions on a large scale while reducing the costs,
complexity, and time frame for deployment, and ensuring
that the appropriate QoS for voice applications is being set
in a consistent fashion.
• International enterprises or service providers requiring
QoS for VoIP in different regions of the world where little
expertise exists and where provisioning QoS remotely and
across different time zones is difficult.
• Service providers requiring a template-driven approach for
delivering managed services and QoS for voice traffic to
many customer premise devices.
 AutoQoS (Cont.)
• Application Classification - NBAR
– Automatically discovers
applications and provides
appropriate QoS treatment
• Policy Generation
– Automatically generates initial
and ongoing QoS policies
• Configuration
– Provides high-level business
knobs, and multi-device/domain
automation for QoS
• Monitoring & Reporting
– Generates intelligent, automatic
alerts and summary reports
• Consistency
– Enables automatic, seamless
interoperability among all QoS
features and parameters across
a network topology – LAN, MAN,
and WAN
 AutoQoS VoIP: Switch Platforms
• You can meet the voice QoS requirements
without extensive knowledge about:
– Trust boundary
– CoS-to-DSCP mappings
– WRR & PQ scheduling parameters
• Generated parameters and configurations are
user-tunable
 AutoQoS VoIP: Switch Platforms
(Cont.)
• Single command at the interface level configures
interface and global QoS
– Support for Cisco IP Phone & Cisco SoftPhone
– Trust boundary is disabled when IP Phone is moved
– Buffer allocation and egress queuing dependent on
interface type (Gigabit Ethernet/Fast Ethernet)
• Supported on static, dynamic-access, voice VLAN
access, and trunk ports
• CDP must be enabled for AutoQoS to function
properly
 Configuring AutoQoS VoIP:
Prerequisites for Using AutoQoS VoIP
• CEF must be enabled at the interface
• This feature cannot be configured if a QoS policy
(service policy) is attached to the interface.
• An interface is classified as low-speed if its
bandwidth is less than or equal to 768 kbps. It is
classified as high-speed if its bandwidth is greater
than 768 kbps.
– The correct bandwidth should be configured on all
interfaces or subinterfaces using the bandwidth
command.
– If the interface or subinterface has a link speed of 768
kbps or lower, an ip address must be configured using the
ip address command.
 Configuring AutoQoS VoIP:
Routers

• Configures the AutoQoS VoIP feature.

• Untrusted mode by default.
• trust: Indicates that the DSCP markings of a packet
are trusted (relied on) for classification of the voice
traffic.
• fr-atm: For low-speed Frame Relay DLCIs
interconnected with ATM PVCs in the same network,
the fr-atm keyword must be explicitly configured in
the auto qos voip command to configure the
AutoQoS VoIP feature properly
Monitoring AutoQoS VoIP:
Routers
QoS info at interface level on switch
Maps generate internal DSCP value
DiffServ Functions Automated
 AutoQoS functions performed in a WAN:
• Automatically classifies Real-Time Transport Protocol
(RTP) payload and VoIP control packets
• Builds service policies for VoIP traffic that are based
on Cisco MQC
• Provisions low-latency queuing (LLQ)—priority
queuing (PQ) for VoIP bearer and bandwidth
guarantees for control traffic
• Enables WAN traffic shaping that adheres to Cisco
best practices, where required
• Enables link efficiency mechanisms such as LFI and
cRTP where required
• Provides SNMP and syslog alerts for VoIP packet
drops
 AutoQoS functions performed in a LAN:
• Enables Cisco Catalyst strict PQ (also known as
expedited queuing) with weighted round robin
(WRR) scheduling for voice and data traffic,
where appropriate
• Configures queue admission criteria (maps CoS
values in incoming packets to the appropriate
queues)
• Modifies queue sizes and weights where required
• Enforces the trust boundary on Cisco Catalyst
switch access ports
 Summary
• You can enable QoS on a network by a single
command per interface using AutoQoS.
• There are several prerequisites for using AutoQoS.
AutoQos automatically configures and enables the
DiffServ mechanisms necessary for QoS.
• You can use the show auto qos command to verify
the contents of the interface configurations, policy
maps, class maps, and ACLs.
• Cisco AutoQoS performs several functions on both
WAN and LAN.
AUTO QOS ENTERPRISE
 AutoQoS Enterprise
• automates the deployment of QoS policies in a
general business environment
• The policies deployed by AutoQoS Enterprise are
not solely focused on VoIP convergence, but also
on convergence of voice, video, and data
applications
• generally deployed in midsize companies and
branch offices of larger companies
• used to provide best-practice QoS policy
generation for voice as well as to provide for
classification of up to ten traffic classes.
traffic classes that can be classified by
AutoQoS Enterprise
 Configuring AutoQoS Enterprise
• Before configuring AutoQoS Enterprise, remove
any existing service policies on an interface.
• AutoQoS Enterprise requires cef to be enabled at
the interface level
• The correct bandwidth must be configured on all
interfaces or subinterfaces using the bandwidth
command.
• If the interface or subinterface has a link speed of
768 kbps or lower, an ip address must be
configured using the ip address command.
 Summary
• AutoQoS Enterprise is enabled by two commands
(auto discovery and auto qos).
• Auto Discovery phase 1 detects traffic and builds
statistics for phase 2 of the configuration.
• Auto QoS phase 2 generates policies based on
the traffic statistics gathered in phase 1, and
installs the service QoS policy on the interface.
• AutoQoS Enterprise is used on router interfaces
and applies best-practices QoS automation. Ten
traffic types are detected.
 Module Summary
• Modular QoS is a three-step building-block approach to implementing
QoS in a network.
• Each class of traffic is defined in a class-map module.
• A policy-map module defines a traffic policy which configures the QoS
features associated with a traffic class previously identified using a class
map.
• A service policy attaches a traffic policy configured with a policy map to
an interface.
• AutoQoS can be enabled on a network by entering one or two
commands on an interface.
• AutoQoS VoIP works on a variety of Cisco routers and switches and
automatically configures and enables the mechanisms necessary for
deploying QoS for VoIP.
• AutoQoS Enterprise works on a variety of Cisco routers and
automatically configures and enables the mechanisms necessary for
deploying up to 10 traffic classes, including VoIP.