SNMP QoS MIB only shows queues 1-6 on platform with 8 ucast/4 mcast queues (sonic-mgmt/test_snmp_queue.py::test_snmp_queue fails)

dgodwin-nokia commented 2 months ago

Description

Observed that sonic-mgmt/test_snmp_queue.py::test_snmp_queue fails on Nokia-IXR7220-H4.

The mib that is being used is in:

https://github.com/sonic-net/sonic-snmpagent/blob/master/src/sonic_ax_impl/mibs/vendor/cisco/ciscoSwitchQosMIB.py

The code assumes there is an equal number of multicast and unicast queues, but that is not the case for some platforms. TH4/TH5 based platforms will have 8 ucast and 4 mcast queues by default.

Code from above referenced file:

# The first half of queue id is for ucast, and second half is for mcast
            # To simulate vendor OID, we wrap queues by max priority groups
            port_max_queues = Namespace.dbs_get_all(self.db_conn, mibs.STATE_DB,
                                                    mibs.buffer_max_parm_table(self.oid_name_map[if_index]))['max_queues']
            pq_count = math.ceil(int(port_max_queues) / 2)

Output of "max_queues" from BUFFER_MAX_PARM_TABLE referenced on TH4 based platform:

    "BUFFER_MAX_PARAM_TABLE|Ethernet132": {
        "type": "hash",
        "value": {
            "max_headroom_size": "0",
            "max_priority_groups": "8",
            "max_queues": "12"
        },
    },

Since max_queues is 12 (8 ucast + 4 mcast), the code in ciscoSwitchQosMIB.py wraps on queue 6, and ends up only generating queue 1-6 as shown in the output above.

I am not sure if "max_priority_groups" could be used as a value to key on instead.

Steps to reproduce the issue:

Run sonic-mgmt/test_snmp_queue.py::test_snmp_queue.

Describe the results you received:

Test failure:

            # Check if queue index in QUEUE table in config_db
            # is present in SNMP result
            if intf in q_interfaces:
                for queue_idx in q_interfaces[intf]:
                    # queue_idx starts with 0, queue_idx in OID starts with 1
                    # Increment queue_idx by 1 to form the right OID.
                    snmp_q_idx = int(queue_idx) + 1
                    if str(snmp_q_idx) not in v['queues'][direction_type]:
                       pytest.fail("Expected queue index %d not present in \
                                     SNMP result for interface %s" % (snmp_q_idx, v['name']))
                       Failed: Expected queue index 7 not present in                                      SNMP result for interface fourhundredGigE1/1

Can also be seen with the following snmp command:

snmpwalk -v2c -c public 100.117.58.30 1.3.6.1.4.1.9.9.580.1.5.5.1.4.1
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.1.1 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.1.2 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.1.5 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.1.6 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.2.1 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.2.2 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.2.5 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.2.6 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.3.1 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.3.2 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.3.3 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.3.4 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.3.5 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.3.6 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.3.7 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.3.8 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.4.1 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.4.2 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.4.3 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.4.4 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.4.5 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.4.6 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.4.7 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.4.8 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.5.1 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.5.2 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.5.3 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.5.4 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.5.5 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.5.6 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.5.7 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.5.8 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.6.1 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.6.2 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.6.3 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.6.4 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.6.5 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.6.6 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.6.7 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.6.8 = Counter64: 0

Describe the results you expected:

Expected to see queues 1-8 in SNMP MIB. (MIB output above shows only 1-6 (second to the last digit in object).

Additional information:

gechiang commented 2 months ago

@qiluo-msft can help review your potential fix PR. @dgodwin-nokia Thanks!

dgodwin-nokia commented 2 days ago

This issue was fixed by a seperate PR (https://github.com/sonic-net/sonic-snmpagent/commit/c5301b2cf94304deb8e09959d67af6a089155507) but there is still an issue remaining that fails when "config_only_db_buffers" is used. Will file a new issue/PR for that.

sonic-net / sonic-buildimage