Cisco Class-Based QoS MIB
**********************************
Overview
**********************************
This MIB provides read access to Quality of Service (QoS)
configuration and statistics information for Cisco
platforms that support the Modular Quality of Service
Command-line Interface (Modular QoS CLI). We recommend
users of this MIB to review the user documentation of
MQC based QoS features.
Configuration information available through this MIB includes
all ClassMap, PolicyMap, Match Statements, and Feature
Actions configuration parameters. The definitions of each
objects mentioned above are explained in the QoS objects
section.
Statistics available through this MIB include summary
counts/rates by traffic class before and after any configured
QoS policies are enforced. In addition, detailed
feature-specific statistics are available for select
PolicyMap features.
Contact your Cisco representative to determine on which
platforms the MIB is currently supported.
**********************************
QoS Acronyms
**********************************
BECN: Frame Relay Backward Explicit Congestion Notification
CIR : Committed Information Rate
DSCP: Differentiated Service Code Point
EB : Estimate Bandwidth
ECN : Explicite Congestion Notification
FECN: Frame Relay Forward Explicit Congestion Notification
IPHC: Internet Protocol Header Compression
IPSLAs: IP Service Level Agreement Technologies
PIR : Peak Information Rate
PREC: Precedence
QoS : Quality Of Services
RED : Random Early Detect
SRP : Spatial Reuse Protocol
WRED: Weighted Random Early Detect
C3PL: Cisco Common Classification Programming Language
**********************************
MIB Objects
**********************************
This MIB consists of the following object groups:
1 : cbQosServicePolicy
2 : cbQosInterfacePolicy
3 : cbQosFrameRelayVCPolicy
4 : cbQosATMPVCPolicy
5 : cbQosObjects
6 : cbQosPolicyMapCfg
7 : cbQosClassMapCfg
8 : cbQosMatchStmtCfg
9 : cbQosQueueingCfg
10: cbQosREDCfg
11: cbQosREDClassCfg
12: cbQosPoliceCfg
13: cbQosTSCfg
14: cbQosSetCfg
15: cbQosClassMapStats
16: cbQosMatchStmtStats
17: cbQosPoliceStats
18: cbQosQueueingStats
19: cbQosTSStats
20: cbQosREDClassStats
21: cbQosPoliceActionCfg
22: cbQosIPHCCfg
23: cbQosIPHCStats
24: cbQosSetStats
25: cbQosPoliceColorStats
26: cbQosTableMapCfg
27: cbQosTableMapValueCfg
28: cbQosTableMapSetCfg
29: cbQosEBCfg
30: cbQosEBStats
31: cbQosMeasureIPSLACfg
32: cbQosC3plAccountCfg
33: cbQosC3plAccountStats
**********************************
Definitions
**********************************
A logical interface in the context of this MIB is either
a main-interface, a sub-interface, a Frame Relay DLCI,
an ATM virtual circuit or the control-plane on the router.
The (aggregate) control-plane on the router is defined as
a collection of processes running at process level on the
platform (route) processor. This includes the functions
related to networking control capabilities such as routing,
signaling, provisioning, as well as resource and service
discovery. Also includes process switched traffic on the
device.
The term distributed control plane, in the context of
this mib, represents the control-plane functionality at
the level of individual linecards. This is only
applicable for the case of distributed platforms.
**********************************
QoS Objects
**********************************
To understand Class-Based QoS features and how to navigate
the MIB tables above, the key element is to comprehend the
relationships among the different QoS objects. QoS objects
consist of ClassMaps, Match Statements and PolicyMaps,
and each Feature Actions.
Match Statement - The specific match criteria to identify
packets for classification purposes.
ClassMap - A user-defined traffic class that contains
one or many match statements used to classify packets into
different categories.
Feature Action - An action is a QoS feature. Features
include police, traffic-shaping, queueing, random detect
and packet marking(set). After the traffic is being
classified, based on the traffic classification, we can
apply these action to each traffic class.
PolicyMap - A user-defined policy that associates each QoS
action to the user-defined traffic class (ClassMap).
Service Policy - Service policy is a policymap
that is being attached to a logical interface. Because a
policymap can also be a part of the hierarchical structure
(inside a classmap), only a policymap that is directly
attached to a logical interface is considered a service
policy. Each service policy is uniquely identified by an
index called cbQosPolicyIndex. This number is usually
identical to its cbQosObjectsIndex as a policymap.
*****************************************
Runtime Instance vs Configuration objects
*****************************************
Each QoS objects have 2 sets of behaviours :
1: A configuration instance
- Each QoS objects has it's configuration portion of
information attached to it. This information does
not change whether this object is attached on multiple
logical interfaces and used multiple times. We
uniquely identify each QoS object with identical
configuration with the same index - cbQosConfigIndex.
This index is used in all configuration related
tables.
2: A runtime instance
- Each QoS objects has it's statistical portion of
information attached to it. This information changes
when this object is attached on multiple logical
interfaces and used in various different places. We
uniquely identify each QoS runtime object instance
with an index that is unique across multiple
instances of the identical object - cbQosObjectsIndex.
This index is used in all statistical related tables.
In summary, a QoS object has 2 indexes associated with it:
cbQosConfigIndex is used to identify it's configuration,
which does not change regardless of number of times and
where it is being used; and cbQosObjectsIndex is used
to identify it's runtime statistics, depending on which
logical interface and where in a given PolicyMap hierarchy
this object is used, it may have multiple unique
identifiers to distinguish each unique usage (instance) of
the same object.
**********************************
Navigation
**********************************
The recommended method of navigating through all of the MIB
tables is to start by learning the cbQosServicePolicyTable
and cbQosObjectsTable MIB tables. In particular, Cisco
Systems recommends understanding the cbQosObjectsIndex and
cbQosParentObjectsIndex of each QoS feature.
The cbQosPolicyIndex and cbQosObjectsIndex are
system-assigned numbers that identify each unique instance
of a QoS feature. These indexes are never reused between
router reboots, even when changes are made to the QoS
configuration. The cbQosPolicyIndex is designed to identify
the service policies attached to logical interfaces, while
the cbQosObjectsIndex is designed to identify each QoS
feature on a specified device.
The cbQosParentObjectsIndex is designed to show the
hierarchical relationship of each QoS feature.
**********************************
cbQosServicePolicyTable
**********************************
Accessing cbQosServicePolicyTable requires
cbQosPolicyIndex. This index is a system-assigned number
to uniquely identify each service policy hanging off of
each logical interface. Given cbQosPolicyIndex the tables
provide the type of logical interface/media type on which
this policy is applied, the direction in which this policy
is enforced, and the SNMP interface index and/or the entity
index of the underlying interface/entity. In the case of a
policy being applied on a Frame Relay DLCI, the cbQosFrDLCI
gives you the Frame Relay DLCI number to which this policy
is attached. In the case of policy being attached to an ATM
VC, cbQosAtmVPI and cbQosAtmVCI display the VPI and VCI of
the ATM interface respectively.
**********************************
cbQosObjectsTable
**********************************
Accessing cbQosObjectsTable requires two indexes,
cbQosPolicyIndex and cbQosObjectsIndex.
Given a particular service policy on a given logical
interface, there could be PolicyMaps, ClassMaps, Match
Statements and Feature Actions being used. Each instance
of these objects is uniquely identified by
cbQosObjectsIndex.
Users need to decide which QoS object is interesting
and use the cbQosPolicyIndex and cbQosObjectsIndex to
locate the right element of interest. This tables provides
cbQosObjectsType, cbQosConfigIndex, and
cbQosParentObjectsIndex.
To understand the relationship of cbQosObjectsIndex,
cbQosParentObjectsIndex and the hierarchical relationship
of the QoS objects, consider the following QoS
configuration example:
Interface ethernet 0/1
Input Service Policy cntlWebTraffic
ClassMap http
match ip http
set ip precedence 5
Output Service Policy cntlSNMP_Telnet
ClassMap snmp
match ip snmp
shape average 8000 32 32
ClassMap Telnet
match ip telnet
shape average 10000 32 32
Interface ethernet 0/2
Input Service Policy cntlWebTraffic
ClassMap http
match ip http
set ip precedence 5
Output Service Policy cntlSNMP_Telnet
ClassMap snmp
match ip snmp
shape average 8000 32 32
ClassMap Telnet
match ip telnet
shape average 10000 32 32
*** In Ethernet 0/1 ***
Assume the router assigned a cbQosConfigIndex=1024 and
cbQosObjectsIndex=1084 to Policy cntlWebTraffic.
Because it is attached to an interface, it has no parent
QoS object, and thus cbQosParentObjectsIndex=0.
In addition, because cntlWebTraffic is also the service
policy of the interface, it has a unique cbQosPolicyIndex
assigned to it. In most cases, it would be the same as
the cbQosObjectsIndex, which is 1084 in this case.
Therefore, the indexes are:
cbQosPolicyIndex = 1084
cbQosObjectsIndex = 1084
cbQosConfigIndex = 1024
Assuming the router assigned a cbQosObjectsIndex=1085
and cbQosConfigIndex=1025 to ClassMap http, it is
directly being used by Policy cntlWebTraffic, and therefore
the cbQosParentObjectsIndex of ClassMap http will be 1084.
Assuming the router assigned a cbQosConfigIndex=1026 and
cbQosObjectsIndex=1086 to match ip http, it is directly
used by ClassMap http, therefore the
cbQosParentObjectsIndex of match ip http will be 1085.
Assuming the router assigned a cbQosConfigIndex=1027 and
cbQosObjectsIndex=1087 to set ip precedence 5, it is
directly used by ClassMap http, therefore the
cbQosParentObjectsIndex of match ip http will be 1085.
Assuming the router assigned a cbQosConfigIndex=1028 and
cbQosObjectsIndex=1088 to Policy cntlSNMP_Telnet.
Because it is attached to an interface, it has no parent
QoS object, and thus cbQosParentObjectsIndex=0.
In addition, because cntlSNMP_Telnet is also the service
policy of the interface, it has a unique cbQosPolicyIndex
assigned to it. In most cases, it would be the same as
the cbQosObjectsIndex, which is 1088 in this case.
Assuming the router assigned a cbQosConfigIndex=1029 and
cbQosObjectsIndex=1089 to ClassMap snmp, it is
directly being used by Policy cntlSNMP_Telnet, and
therefore the cbQosParentObjectsIndex of ClassMap snmp
will be 1088.
Assuming the router assigned a cbQosConfigIndex=1030 and
cbQosObjectsIndex=1090 to match ip snmp, it is directly
used by ClassMap snmp, and therefore the
cbQosParentObjectsIndex of match ip snmp will be 1089.
Assuming the router assigned a cbQosConfigIndex=1031 and
cbQosObjectsIndex=1091 to shape average 8000 32 32,
it is directly used by ClassMap snmp, therefore the
cbQosParentObjectsIndex of match ip snmp will be 1089.
Assuming the router assigned a cbQosConfigIndex=1032 and
cbQosObjectsIndex=1092 to ClassMap Telnet, it is
directly being used by Policy cntlSNMP_Telnet, and
therefore the cbQosParentObjectsIndex of
ClassMap Telnet will be 1088.
Assuming the router assigned a cbQosConfigIndex=1033 and
cbQosObjectsIndex=1093 to match ip telnet, it is
directly used by ClassMap Telnet, and therefore the
cbQosParentObjectsIndex of match ip telnet will be 1092.
Assuming the router assigned a cbQosConfigIndex=1034 and
cbQosObjectsIndex=1094 to shape 10000 32 32, it is
directly used by ClassMap telnet, therefore the
cbQosParentObjectsIndex of match ip telnet will be 1092.
*** In Ethernet 0/2 ***
Every objects will have a unique combination of
cbQosPolicyIndex and cbQosObjectsIndex, but
cbQosConfigIndex will be shared across the same
objects that are applied in different places.
**********************************
All Config Tables
**********************************
Accessing config related tables requires the same index
- cbQosConfigIndex. (Per precedence based tables requires
a second index, which is IP precedence value) Users
should have already gone through the cbQosObjectsTable
at this point and understood each cbQosConfigIndex and the
corresponding QoS objects. Users can uniquely identify
each QoS object defined on the router and query the
entries in each stats table on a per QoS object basis.
**********************************
All Stats Tables
**********************************
Accessing all stats related tables requires the same
2 indexes. They are cbQosPolicyIndex and cbQosObjectsIndex.
(Per precedence based tables requires a third index, which
is IP precedence value) Users should have already gone
through the cbQosObjectsTable at this point and understood
the relationship of each cbQosPolicyIndex and
cbQosObjectsIndex pair and the corresponding QoS objects.
Users can uniquely identify each QoS object defined on the
router and query the entries in each stats table on a per
QoS object basis.
ciscoCBQosMIB
cbQosServicePolicyTable 
cbQosServicePolicyEntry 
cbQosPolicyIndex