Troubleshoot CBQoS issues

10/19/2018 9:50 PM

8/13/2025 1:21 PM

Record detailed results as you perform these steps. Doing so will help expedite a resolution should you need to contact SolarWinds Support about your CBQoS issue.

Netflow Traffic Analyzer

To troubleshoot a CBQoS issue:

Note: In particular, the SolarWinds Orion Module Engine service enables polling of CBQoS. The NTA SolarWinds NetFlow service takes the data the Orion poller obtains from the device through SNMP and writes it into the NetFlow database table; and if this service is not working, polled CBQoS data will sit in a queue and eventually get dropped.

1. Use packet capture on the relevant interface of the Orion server to verify SNMP (port 161) communication with relevant device(s).
2. Use SolarWinds MIB Viewer to check the status of CBQoS on your device.

   Support is determined by cbQosConfigIndex="1.3.6.1.4.1.9.9.166.1.5.1.1.2"

   If you see any value in your MIB viewer for this OID, then CBQoS data is being successfully pulled.

3. Make sure all SolarWinds services are running:
   1. Open the Orion Service Manager in the SolarWinds Orion > Advanced Features program folder.
   2. If some SolarWinds services are not running, click Start Everything.
4. If CBQoS resources show "No data", verify that the CBQos Polling is enabled on the Interface from CBQoS polling management

Basic CBQoS Troubleshooting 

1. Make sure indexing is being done properly and that the device can read the OID's correctly via SNMP  Walk. We currently do not support SNMPv3 for CBQoS at this time and will be a feature request. ​Verify that CBQoS data is being receive by checking that the “Last Received CBQoS” under “Netflow Sources” is being updated.
2. If the time stamp is being updated but no data is showing up in the charts verify the direction the charts are set to show. (NOTE: In most cases CBQoS policies are only configured in the “Output (Egress)” direction and NTA chart are set for Ingress by default.  If the charts are set as the default (Ingress) Change to “Egress” to see if data is displayed. 
3. If data is displayed then the policies are only configured in the Output direction.  The customer can change the default direction for CBQoS charts in the NTA setting page under the section below.  The default can be set to Ingress, Egress orBoth.                            Charting and Graphing Settings                                                                     Default flow direction for CBQoS resources:       BothIngressEgress 
4. Verify all services are up and running
5. CBQoS polling uses Job Engine v2 and Netflow service
6. Once this has been verified and data is still not being displayed verify the correct interfaces are added as Netflow sources than the ones configured with CBQoS policies
7. Launch UnDP Create a new UnDP poller with the following OID “cbQosIfIndex="1.3.6.1.4.1.9.9.166.1.1.1.1.4" (NOTE: This OID returns the interface ifIndex values that are configured with CBQoS policies)
8. Click next
9. Select one of the nodes they are having issues with and press “Test”
10. The results below with return the interface ifindex for all interfaces that have a policy configured.  If there are multiple values for the same interface this means that the interface has the policy configured in both directions, Input and Output
11. 
12. Verify the returned values match the ifIndex values of the interfaces added as Netflow sources.  You can do this by going to the NPM Interface details page or the Interfaces table in the SQL database. NOTE:  A very common issue is when the customer has assigned the CBQoS policies to the physical interface but they have added the sub-interfaces as Netflow sources.  Depending on the IOS this is the only way to get this data and they will need to add the physical interface as a Netflow source. Sub interfaces, tunnels etc.. are not supported as CBQoS sources.The source must be physical.
13. If all steps have been verified and all seems to be correct but still not displaying any CBQoS data the next step is to ask a few more questions in order to narrow down the issue.
14. Has there been any changes made to the CBQoS policies and/or Class maps
15. Increase CBQoS logging and search the NodeID in the NTABusisnessLayerhost.log file and verify the node is being polled and see if the data is being processed but not written into the database.
16. Also a Wireshark and MIB walk will be helpful in further troubleshooting the issue.

Make sure indexing is being done properly and that the device can read the OID's correctly via SNMP  Walk. We currently do not support SNMPv3 for CBQoS at this time and will be a feature request. ​

OID NAME	OID	DESCRIPTION	VERSION
cbQosIfType	1.3.6.1.4.1.9.9.166.1.1.1.1.2	Type of interface to which this policy is attached
cbQosPolicyDirection	1.3.6.1.4.1.9.9.166.1.1.1.1.3	Direction of traffic to which this policy is applied
cbQosIfIndex	1.3.6.1.4.1.9.9.166.1.1.1.1.4	Interface index to which this policy is attached
cbQosConfigIndex1	1.3.6.1.4.1.9.9.166.1.5.1.1.2	Configuration index of each object (e.g. class map, policy map, etc).
cbQosObjectsType	1.3.6.1.4.1.9.9.166.1.5.1.1.3	Type of QoS object (e.g. class map, policy map, etc)
cbQosParentObjectsIndex	1.3.6.1.4.1.9.9.166.1.5.1.1.4	Index of parent object. Used to determined objects hierarchy (policy map - class map relation, nested policies).
cbQosPolicyMapName	1.3.6.1.4.1.9.9.166.1.6.1.1.1	Policy map name
cbQosPolicyMapDesc	1.3.6.1.4.1.9.9.166.1.6.1.1.2	Policy map description
cbQosCMName	1.3.6.1.4.1.9.9.166.1.7.1.1.1	Class map names
cbQosCMDesc	1.3.6.1.4.1.9.9.166.1.7.1.1.2	Class map descriptions
cbQosCMInfo	1.3.6.1.4.1.9.9.166.1.7.1.1.3	Class map configuration information
cbQosCMPrePolicyByte64	1.3.6.1.4.1.9.9.166.1.15.1.1.6	Count of bytes befor applying QoS policies for each class
cbQosCMPostPolicyByte64	1.3.6.1.4.1.9.9.166.1.15.1.1.10	Count of bytes after executing QoS policies for each class
cbQosCMDropByte64	1.3.6.1.4.1.9.9.166.1.15.1.1.17	Count of dropped bytes per class
cbQosCMNoBufDropPkt64	1.3.6.1.4.1.9.9.166.1.15.1.1.21	Count of dropped packets
cbQosPoliceCfgRate	1.3.6.1.4.1.9.9.166.1.12.1.1.1	The committed policing rate. This is the sustained rate permitted by policing.	4.1.1+
cbQosPoliceCfgRate64	1.3.6.1.4.1.9.9.166.1.12.1.1.11	The committed policing rate. This is the sustained rate permitted by policing. 64-bit version.	4.1.1+
cbQosPoliceCfgRateType	1.3.6.1.4.1.9.9.166.1.12.1.1.12	The rate type that configured for CIR & PIR (1-bps, 2-percentage, etc).	4.1.1+
cbQosPoliceCfgPercentRateValue	1.3.6.1.4.1.9.9.166.1.12.1.1.13	The committed policing rate in percentage. Its value is valid only when cbQosPoliceCfgRateType equals to 2.	4.1.1+
cbQosTSCfgRate	1.3.6.1.4.1.9.9.166.1.13.1.1.1	The committed traffic-shaping rate. This is the sustained rate permitted by the traffic-shaping.	4.1.1+
cbQosTSCfgRate64	1.3.6.1.4.1.9.9.166.1.13.1.1.11	The committed shape rate. This is the sustained rate permitted by shaping. This object represents the 64 bit value of object cbQosTSCfgRate.	4.1.1+
cbQosTSCfgRateType	1.3.6.1.4.1.9.9.166.1.13.1.1.7	The rate type that configured for traffic-shaping. 1 means rate is configured in bps, 2 means rate is configured in percentage, etc.	4.1.1+
cbQosTSCfgPercentRateValue	1.3.6.1.4.1.9.9.166.1.13.1.1.8	The committed traffic-shaping rate in percentage. Its value is valid only when cbQosTSCfgRateType equals to 2.	4.1.1+
cbQosQueueingCfgBandwidth	1.3.6.1.4.1.9.9.166.1.9.1.1.1	If the cbQosQueueingCfgBandwidthUnits value is 'kbps(1)' or  'percentage(2)', this object represents the configured bandwidth allocated to this traffic class.	4.1.1+
cbQosQueueingCfgBandwidthUnits	1.3.6.1.4.1.9.9.166.1.9.1.1.2	Units of the accompanying cbQosQueueingCfgbandwidth parameter	4.1.1+
cbQosQueueingCfgBandwidth64	1.3.6.1.4.1.9.9.166.1.9.1.1.13	If the cbQosQueueingCfgBandwidthUnits value is 'kbps(1)' or  'percentage(2)', this object represents the configured bandwidth allocated to this traffic class. 64-bit variant of cbQosQueueingCfgBandwidth value.	4.1.1+

¹ - This OID is used by availability job - NTA uses this OID to determine whether the device supports CBQoS.

INTERFACE MAPPING     TECHNOLOGY / VENDOR	OID NAME	OID	DESCRIPTION
NetStream (equivalent to NetFlow) / Huawei	hwifNet32BitIndex	1.3.6.1.4.1.2011.5.25.110.1.2.1.2	Mapping table between NetStream interface index and SNMP interface index
NetFlow / Alcatel	vRtrIfGlobalIndexvRtrIfIndex	1.3.6.1.4.1.6527.3.1.2.3.37.1.2	Mapping table between NetFlow interface index and SNMP interface index

Note: Alcatel support was added in NTA 3.9.

Quick example of CBQoS snmp walk investigation:  

Here are basic steps of how to investigate that some policy is sending values to NTA:

1.  Find OID .1.3.6.1.2.1.2.2.1.2.[X] for this OID will be displayed interface name and [X] is interface index.

• For example: 

.1.3.6.1.2.1.2.2.1.2.11 = STRING: "GigabitEthernet0/1.3"

2.  Now find OID 1.3.6.1.4.1.9.9.166.1.1.1.1.4.[Y] = [interface index], we will later match [Y] with policy.

• For example : 

.1.3.6.1.4.1.9.9.166.1.1.1.1.4.176 = INTEGER: 11

• Based on polled SNPM OID by NTA you cal also obtain policy/class names

3. Find OID 1.3.6.1.4.1.9.9.166.1.15.1.1.21. This OID is for drops and if you match it with [Y] you can get values that device send.

• For example:.1.3.6.1.4.1.9.9.166.1.15.1.1.21.176.8323105 = COUNTER64: 0

.1.3.6.1.4.1.9.9.166.1.15.1.1.21.176.15388929 = COUNTER64: 0

Please also ensure that the CBQoS value types shown in the SNMP walk are GAUGE64 rather than GAUGE32 as 32-bit counters are not supported.

How to Turn on Logging for CBQoS: 
Open up Log Adjuster:

Set CBQoS to Verbose and hit Apply:

 

Verbose: This shows the Node ID that is being assigned and the polling engine that it is assigned to. Be careful to look for the wrong polling engine being assigned. 
Debug: This will provide the OIDs in the logs.

CBQoS Explained and Example Configuration: 

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 retrieved 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 in depth 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.

Example Configuration Resource