What is CBQoS ?

CBQoS (Class Based Quality of Service) is a Cisco feature set that is part of the IOS 12.4(4)T and above. This information is retreived using SNMP and provides information about the QoS policies applied and class based traffic patterns within an enterprise's network.

Why do I need CBQoS ?

Typically, networks operate on the basis of best-effort delivery, in which all traffic has equal priority and an equal chance of being delivered. When congestion results, all traffic has an equal chance of being dropped. QoS selects network traffic, prioritizes it according to its relative importance, and uses congestion avoidance to provide priority-indexed treatment; CBQoS can also limit the bandwidth used by network traffic. CBQoS can make network performance more predictable and bandwidth utilization more effective. Network administrators implement CBQoS policies to ensure that their business-critical applications receive the highest priority on the network. CBQoS provides you indepth visibility into the policies applied on your links and the traffic patterns in your various class of traffic. The pre-policy, post-policy and drops in different traffic class along with the queuing status enables you to validate the efficiency of your QoS settings.


Creating a traffic class

Creating a traffic policy

Attaching a Traffic Policy to an Interface

Verifying the Traffic Class and Traffic Policy Information


How do I start CBQoS data collection ?

Configuring Policies on the router


Initially CBQoS has to be enabled on the router manually. Further, policies have to be defined on the router. Usually, Traffic Policies are dependent on the type of the enterprise and its business needs.( heavy voice traffic, heavy document transfer, heavy streaming video traffic etc ). The policy (classification ) can be done on the basis of Class Maps and Policy Maps.


A class map is a mechanism that you use to isolate and name a specific traffic flow (or class) from all other traffic. The class map defines the criterion used to match against a specific traffic flow to further classify it; the criteria can include matching the access group defined by the ACL or matching a specific list of DSCP or IP precedence values. If you have more than one type of traffic that you want to classify, you can create another class map and use a different name. After a packet is matched against the class-map criteria, you can specify the QoS actions via a policy map. A policy map specifies the QoS actions for the traffic classes. Actions can include trusting the CoS or DSCP values in the traffic class; setting a specific DSCP or IP precedence value in the traffic class; or specifying the traffic bandwidth limitations and the action to take when the traffic is out of profile. Before a policy map can be effective, you must attach it to an interface.


After a packet is classified and has an internal DSCP value assigned to it, the policing and marking process has to be done. Policing involves creating a policy that specifies the bandwidth limits for the traffic. Packets that exceed the limits are out of profile or nonconforming. Each policer specifies the action to take for packets that are in or out of profile. These actions, carried out by the marker, include passing through the packet without modification, dropping the packet, or marking down the packet with a new DSCP value that is obtained from the configurable policed-DSCP map.


Fetching Policy details from the router

Under the QoS Configuration tab the interfaces that have policies applied on them are displayed along with the router names and specific IN and OUT Policies. To facilitate the NetFlow Analyzer application to recognise the policies applied at each router level, click on the check_status icon. This invokes a new window with the List of all routers, along with their Read Community & Port details. By clicking on "Check Status" or "Check All Status" it is possible to fetch the policy details from the router about each individual interface.


Once the policy details have been fetched from the routers the following message is displayed: "Policy Details Updated". If any policy is not found the the "Not Available" message is diaplayed.


Polling for CBQoS data


After setting the policies on the router and fetching the policy details polling can be started. Click on the "Modify Interfaces" button to select/unselect the interfaces on which polling has to be done. The Polling Parameters namely Polling Interval and Time Out can also be modified. The Polling interval can take any value from 5, 10, 15, 25, 30, 60. Time Out can take values from 5, 10, 15. After selecting/unselecting the list of interfaces on which Polling has to be done and after the Polling Parameters have been set click on "Update" to start the polling action.

Creating a traffic class


To create a traffic class, use the class-map command. The syntax of the class-map command is as follows:

class-map [match-any | match-all] class-name
no class-map [match-any | match-all] class-name

The match-all and match-any Keywords

The match-all and match-any keywords need to be specified only if more than one match criterion is configured in the traffic class.

The match-all keyword is used when all of the match criteria in the traffic class must be met in order for a packet to be placed in the specified traffic class.

The match-any keyword is used when only one of the match criterion in the traffic class must be met in order for a packet to be placed in the specified traffic class.

If neither the match-all nor match-any keyword is specified, the traffic class will behave in a manner consistent with match-all keyword.


About The match not Command


The match not command, rather than identifying the specific match parameter to use as a match criterion, is used to specify a match criterion that prevents a packet from being classified as a member of the class. For instance, if the match not qos-group 6 command is issued while you configure the traffic class, QoS group 6 becomes the only QoS group value that is not considered a successful match criterion. All other QoS group values would be successful match criteria.




To create a traffic class containing match criteria, use the class-map command to specify the traffic class name. Then use one or more match commands to specify the appropriate match criteria. Packets matching the criteria you specify are placed in the traffic class.



In the following steps, a number of match commands are listed. The specific match commands available vary by platform and Cisco IOS release. For the match commands available, see the Cisco IOS command reference for the platform and Cisco IOS release you are using.


Configuration steps


Command or Action


Step 1

Router> enable

Enables privileged EXEC mode.

Step 2

Router # configure terminal

Enters global configuration mode.

Step 3 

Router(config)# class-map [match-all | match-any] class-name

Creates a class to be used with a class map, and enters class-map configuration mode. The class map is used for matching packets to the specified class.


Note : The match-all keyword specifies that all match criteria must be met. The match-any keyword specifies that one of the match criterion must be met.


Use one or more of the following match commands, as applicable.

Step 4

Router(config-cmap)# match access-group

{access-group | name access-group-name

(Optional) Configures the match criteria for a class map on the basis of the specified access control list (ACL).


Note: Access lists configured with the optional log keyword of the access-list command are not supported when configuring a traffic class.

Step 5 

Router(config-cmap)# match any

(Optional) Configures the match criteria for a class map to be successful match criteria for all packets.

Step 6 

Router config-cmap)# match class-map class-name

(Optional) Specifies the name of a traffic class to be used as a matching criterion (for nesting traffic class [nested class maps] within one another).

Step 7

Router(config-cmap)# match cos cos-number

(Optional) Matches a packet based on a Layer 2 class of service (CoS) marking.

Step 8 

Router(config-cmap)# match destination-address mac address

(Optional) Uses the destination Media Access Control (MAC) address as a match criterion.

Step 9 

Router(config-cmap)# match discard-class class-number

(Optional) Matches packets of a certain discard class.

Step 10 

Router(config-cmap)# match [ip] dscp

dscp-value [dscp-value dscp-value dscp-value

dscp-value dscp-value dscp-value dscp-value]

(Optional) Identifies a specific IP differentiated service code point (DSCP) value as a match criterion. Up to eight DSCP values can be included in one match statement.

Step 11 

Router(config-cmap)# match field protocol

protocol-field {eq [mask] | neq [mask] |

gt | lt | range range | regex string}

value [next next-protocol]

(Optional) Configures the match criteria for a class map on the basis of the fields defined in the protocol header description files (PHDFs).

Step 12

Router(config-cmap)# match fr-dlci dlci-number

(Optional) Specifies the Frame Relay data-link connection identifier (DLCI) number as a match criterion in a class map.

Step 13 

Router(config-cmap)# match input-interface interface-name

(Optional) Configures a class map to use the specified input interface as a match criterion.

Step 14 

Router(config-cmap)# match ip rtp starting-port-number port-range

(Optional) Configures a class map to use the Real-Time Protocol (RTP) protocol port as the match criterion.

Step 15

Router(config-cmap)# match mpls experimental mpls-values

(Optional) Configure a class map to use the specified value of the Multiprotocol Label Switching (MPLS) experimental (EXP) field as a match criterion.

Step 16

Router(config-cmap)# match mpls experimental topmost values

(Optional) Matches the MPLS EXP value in the topmost label.

Step 17

Router(config-cmap)# match not match-criteria

(Optional) Specifies the single match criterion value to use as an unsuccessful match criterion.

Step 18

Router(config-cmap)# match packet length

{max maximum-length-value

[min minimum-length-value]

| min minimum-length-value

[max maximum-length-value]}

Optional) Specifies the Layer 3 packet length in the IP header as a match criterion in a class map.

Step 19

Router(config-cmap)# match port-type {routed | switched}

{routed | switched} (Optional) Matches traffic on the basis of the port type for a class map.

Step 20

Router(config-cmap)# match [ip] precedence precedence-value [precedence-value precedence-value precedence-value]

(Optional) Identifies IP precedence values as match criteria.

Step 21 

Router(config-cmap)# match protocol protocol-name

(Optional) Configures the match criteria for a class map on the basis of the specified protocol.


Note: There is a separate match protocol (NBAR) command used to configure network-based application recognition (NBAR) to match traffic by a protocol type known to NBAR.

Step 22 

Router(config-cmap)# match protocol citrix [app application-name-string] [ica-tag ica-tag-value]

(Optional) Configures NBAR to match Citrix traffic

Step 23 

Router(config-cmap)# match protocol fasttrack file-transfer "regular-expression"

(Optional) Configures NBAR to match FastTrack peer-to-peer traffic.

Step 24

Router(config-cmap)# match protocol gnutella file-transfer "regular-expression"

(Optional) Configures NBAR to match Gnutella peer-to-peer traffic.

Step 25 

Router(config-cmap)# match protocol http [url url-string | host hostname-string | mime MIME-type | c-header-field c-header-field-string | s-header-field s-header-field-string]

(Optional) Configures NBAR to match Hypertext Transfer Protocol (HTTP) traffic by URL, host, Multipurpose Internet Mail Extension (MIME) type, or fields in HTTP packet headers.

Step 26

Router(config-cmap)# match protocol rtp [audio | video | payload-type payload-string]

(Optional) Configures NBAR to match Real-Time Transfer Protocol (RTP) traffic.

Step 27

Router(config-cmap)# match qos-groupqos-group-value

qos-group-value (Optional) Identifies a specific QoS group value as a match criterion.

Step 28 

Router(config-cmap)# match source-address mac address-destination

(Optional) Uses the source MAC address as a match criterion.

Step 29 

Router(config-cmap)# match start {l2-start | l3-start} offset number size number {eq | neq | gt | lt | range range | regex string} {value [value2] | [string]}

(Optional) Configures the match criteria for a class map on the basis of the datagram header (Layer 2) or the network header (Layer 3).

Step 30 

Router(config-cmap)# match tag {tag-name}

(Optional) Specifies tag type as a match criterion.

Step 31

Route(config-cmap)# exit

(Optional) Exits class-map configuration mode.




Creating a traffic policy

To configure a traffic policy (sometimes also referred to as a policy map), use the policy-map command. The policy-map command allows you to specify the traffic policy name and also allows you to enter policy-map configuration mode (a prerequisite for enabling QoS features such as traffic policing or traffic shaping).

Associate the Traffic Policy with the Traffic Class

After using the policy-map command, use the class command to associate the traffic class (created in the "Creating a Traffic Class" section) with the traffic policy.


The syntax of the class command is as follows:


class class-name
no class class-name


For the class-name argument, use the name of the class you created when you used the class-map command to create the traffic class (Step 3 of the "Creating a Traffic Class" section).


After entering the class command, you are automatically in policy-map class configuration mode. The policy-map class configuration mode is the mode used for enabling the specific QoS features.




To create a traffic policy (or policy map) and enable one or more QoS features, perform the following steps.



This procedure lists many of the commands you can use to enable one or more QoS features. For example, to enable Class-Based Weighted Fair Queuing (CBWFQ), you would use the bandwidth command. Not all QoS features are available on all platforms or in all Cisco IOS releases. For the features and commands available to you, see the Cisco IOS documentation for your platform and version of Cisco IOS software you are using.


Configuration Steps


Command or Action


Step 1

Router> enable

Enables privileged EXEC mode.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3 

Router(config)#  policy-map policy-name

Creates or specifies the name of the traffic policy and enters policy-map configuration mode.

Step 4

Router(config-pmap)#  class {class-name |class-default}

Specifies the name of a traffic class (previously created in the "Creating a Traffic Class" section) and enters policy-map class configuration mode.


Use one or more of the following commands to enable the specific QoS feature you want to use.

Step 5 

Router(config-pmap-c)# bandwidth {bandwidth-kbps | percent percent }

(Optional) Specifies a minimum bandwidth guarantee to a traffic class in periods of congestion. A minimum bandwidth guarantee can be specified in kbps or by a percentage of the overall available bandwidth.

Step 6 

Router(config-pmap-c)# fair-queue number-of-queues

(Optional) Specifies the number of queues to be reserved for a traffic class.

Step 7

Router (config-pmap-c)# police bps [burst-normal][burst-max] conform-action action exceed-action action [violate-action action]

(Optional) Configures traffic policing.

Step 8 

Router(config-pmap-c)# priority {bandwidth-kbps | percent percentage} [burst]

(Optional) Gives priority to a class of traffic belonging to a policy map.

Step 9 

Router(config-pmap-c)# queue-limit number-of-packets

(Optional) Specifies or modifies the maximum number of packets the queue can hold for a class configured in a policy map.

Step 10 

Router(config-pmap-c)# random-detect [dscp-based | prec-based]

(Optional) Enables Weighted Random Early Detection (WRED) or distributed WRED (DWRED).

Step 11 

Router(config-pmap-c)# set atm-clp

(Optional) Sets the cell loss priority (CLP) bit when a policy map is configured.

Step 12

Router(config-pmap-c)# set cos {cos-value | from-field [table table-map-name]}

(Optional) Sets the Layer 2 class of service (CoS) value of an outgoing packet.

Step 13 

Router(config-pmap-c)# set discard-class value

(Optional) Marks a packet with a discard-class value.

Step 14 

Router(config-pmap-c)# set [ip] dscp {dscp-value | from-field [table table-map-name]}

(Optional) Marks a packet by setting the differentiated services code point (DSCP) value in the type of service (ToS) byte.

Step 15

Router(config-pmap-c)# set fr-de

(Optional) Changes the discard eligible (DE) bit setting in the address field of a Frame Relay frame to 1 for all traffic leaving an interface.

Step 16

Router(config-pmap-c)# set precedence {precedence-value | from-field [table table-map-name]}

(Optional) Sets the precedence value in the packet header.

Step 17

Route(config-pmap-c)# set mpls experimental value

(Optional) Designates the value to which the MPLS bits are set if the packets match the specified policy map.

Step 18

Router (config-pmap-c)# set qos-group {group-id | from-field [table table-map-name]}

(Optional) Sets a QoS group identifier (ID) that can be used later to classify packets.

Step 19

Router(config-pmap-c)# service-policy policy-map-name

(Optional) Specifies the name of a traffic policy used as a matching criterion (for nesting traffic policies [hierarchical traffic policies] within one another).

Step 20

Router(config-pmap-c)# shape {average | peak } mean-rate [burst-size [excess-burst-size ]]

(Optional) Shapes traffic to the indicated bit rate according to the algorithm specified.

Step 21 

Router(config-pmap-c)# exit

(Optional) Exits policy-map class configuration mode.


Traffic policy can be nested with another traffic policy using the service-policy command, called as Hierarchical traffic policy.The policy which holds another policy is the parent policy and the nested one is called child policy.

Sample configuration of policy with parent-child relationship:

      Router(config)# policy-map child

      Router(config-pmap)# class voice

      Router(config-pmap-c)# priority 50

      Router(config)# policy-map parent

      Router(config-pmap)# class class-default

      Router(config-pmap-c)# shape average 10000000

      Router(config-pmap-c)# service-policy child

      Router(config-pmap-c)# exit

Attaching a Traffic Policy to an Interface


To attach a traffic policy to an interface, use the service-policy command. The service-policy command also allows you to specify the direction in which the traffic policy should be applied (either on packets coming into the interface or packets leaving the interface).


The service-policy command syntax is as follows:


service-policy {input | output} policy-map-name
no service-policy {input | output} policy-map-name





To attach a traffic policy to an interface, perform the following steps.



Depending on the platform and Cisco IOS release you are using, a traffic policy can be attached to an ATM permanent virtual circuit (PVC) subinterface, a Frame Relay data-link connection identifier (DLCI), or another type of interface.




Command or Action


Step 1

Router> enable

Enables privileged EXEC mode.

Step 2

Router# configure terminal

Enters global configuration mode

Step 3 

Router(config)# interface serial0

Configures an interface type and enters interface configuration mode.

Step 4

Router(config-if)#  service-policy output [type access-control] {input | output} policy-map-name

Attaches a policy map to an interface.

Step 5

Router (config-if)# exit

(Optional) Exits interface configuration mode.



Multiple traffic policies on tunnel interfaces and physical interfaces are not supported if the interfaces are associated with each other. For instance, if a traffic policy is attached to a tunnel interface while another traffic policy is attached to a physical interface with which the tunnel interface is associated, only the traffic policy on the tunnel interface works properly.


Verifying the Traffic Class and Traffic Policy Information


To display and verify the information about a traffic class or traffic policy, perform the following steps.



Command or Action


Step 1

Router> enable

Enables privileged EXEC mode.

Step 2

Router# show class-map [type {stack | access-control}] [class-map-name]

(Optional) Displays all class maps and their matching criteria.

Step 3 

Router# show policy-map policy-map class class-name

(Optional) Displays the configuration for the specified class of the specified policy map.

Step 4

Router# show policy-map policy-map

(Optional) Displays the configuration of all classes for a specified policy map or all classes for all existing policy maps.

Step 5

Router# show policy-map interface [type access-control] type number [vc [vpi/] vci] [dlci dlci] [input | output]

(Optional) Displays the packet statistics of all classes that are configured for all service policies either on the specified interface or subinterface or on a specific permanent virtual circuit (PVC) on the interface.

Step 6

Router# exit

(Optional) Exits privileged EXEC mode.


Add Device

From the Collector QoS configuration page, the administrator can add the policy enabled device which does not exporting any netflows to the NetFlow Analyzer manually for exclusively monitoring the device's QoS policies.

Once the router name/ IP and the valid SNMP parameters are given it scans for policy applied interfaces and list them. The user can select the interface(s) they wish to monitor by clicking the Add button. Once the device added successfully it can be added for polling. If the device doesn't have any policy attached to it currently or not reachable (due to time-out) then the device adding will be failed.


Using the CBQoS data

Once Polling has been started, reports can be viewed under the CBQoS tab. Reporting is available in terms of Volume of Traffic, Number of Packets, Traffic Speed and Queue. The pre-policy, post-policy and drops in different traffic class along with the queuing status enables you to validate the efficiency of your QoS settings.Individual graphs are displayed for Pre Policy, Post Policy and Dropped. Pre Policy refers to the state before the CBQoS policy was applied. Post Policy refers to the state after the CBQoS policy is applied. Dropped gives information on the packets that are dropped as a result of applying the policies.

For each traffic classes, its match statements statistics are also listed out which gives deep inception about the traffic and used to determine because of which traffic  the QoS policy gets violated in the network. This also helps to make decision that the traffic is genuine or not.

For the hierarchical policy the CBQoS data for the parent and child policy  are shown separately. The child policy's parent policy name and through which traffic class  it is attached to the parent are mentioned along with it.

Based on these information suitable correction can be done to the policies to make it best suit the business goals of the organization.


View Configuration

In CBQoS tab, view configuration displays the last updated policy configuration tree  in NFA-EE. The policy tree shows the policy attached , its traffic classes, match-statements used for classifying the class  and its actions. The child policy(if present) are also listed out under the class through which it is attached to the parent policy.

The configuration shows only the basic details of the QoS actions:





Bandwidth alloted, maximum allowed queue size for the traffic class and the status of fair-queue and priority queue if enabled.

Traffic Policing

The committed policing rate (normal rate),Normal burst size , excess burst size , conform action, exceed action and violate action.

Traffic Shaping

The committed traffic-shaping rate, burst size, excess burst size , adaptive traffic shaping rate (if enabled) and the limit type (peak rate / average rate).


Displays the DSCP ,IP Precedence,CoS,Discard Class and QoS group and MPLS Experimental value if set.

Copyright © 2019, ZOHO Corp. All Rights Reserved.