The cbQosConfigIndex, cbQosObjectsIndex, and cbQosPolicyIndex are volatile because when a networking device reboots, the index
numbers may change. This happens because system rebooting can cause the order of the Modular QoS CLI (MQC) configuration to
differ from the actual configuration order, which is user-driven and unpredictable. As a result, you must read the MIB frequently
to extract statistical and configuration information. Therefore, once a reload has occurred, the MIB has to be repolled to
reestablish the indexes to the data stored in the CBQoS MIB.
Traditionally, MIB persistence is handled by Cisco IOS APIs, which save the index and key information to NVRAM. The data is
then retrieved and repopulated after reloading. However, this approach does not work well for the current implementation of
the cbQosObjectsIndex because of the large amount of information that needs to be saved.
An index encoding scheme based on configuration entries instead of operational sequence is being implemented to provide persistent
indexes on router reload so that MIB information retains the same set of object values each time that a networking device
reboots.
The index encoding scheme has been changed to handle the performance/scalability issue. Each service policy is uniquely identified
by an index called cbQosPolicyIndex, and its cbQosObjectsIndex is uniquely identified under the service policy.
Note |
As a result of this change in the index encoding scheme, an application must not assume that the cbQosPolicyIndex is usually
identical to its cbQosObjectsIndex as a policy-map.
|