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.