The feature "polling only configured ports buffer queue" will break SNMP #17448

qiluo-msft · 2023-12-08T01:09:21Z

Description

The issue is found after the feature sonic-net/sonic-swss#2143 is available on 202205 branch. Since the original PR is reverted, and reworked and merged. Please make sure the feature is in the image and enabled by configuration if needed.

Steps to reproduce the issue:

Device HwSKU: Mellanox-SN2700
Make sure not all buffer queues are enabled by checking buffer queue counter. All buffer queues on this platform mean UC0~UC7 plus MC0~MC7. I removed the true counter values because they are not relevent.

$ show queue counters Ethernet96
      Port    TxQ    Counter/pkts    Counter/bytes    Drop/pkts    Drop/bytes
----------  -----  --------------  ---------------  -----------  ------------
Ethernet96    UC0              
Ethernet96    UC1    
Ethernet96    UC2      
Ethernet96    UC3           
Ethernet96    UC4    
Ethernet96    UC5        
Ethernet96    UC6

Query SNMP ciscoSwitchQosMIB
I did not check pg counters via SNMP, maybe similar bug
Stream Telemetry seems working well with virtual DB on buffer queue counters or pg counters, however there is test gap with the feature.

Describe the results you received:

$ snmpwalk -v2c -c msft 10.64.247.240 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.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.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.5 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.4.6 = Counter64: 0

Describe the results you expected:

$ snmpwalk -v2c -c msft 10.64.247.240 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.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.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.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.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.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.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.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.7.1 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.7.2 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.7.5 = Counter64: 0
iso.3.6.1.4.1.9.9.580.1.5.5.1.4.1.2.7.6 = Counter64: 0

Output of `show version`:

20220531.27

Output of `show techsupport`:

ignored

The text was updated successfully, but these errors were encountered:

lguohan · 2023-12-08T01:16:15Z

telemetry has same issue?

qiluo-msft · 2023-12-11T23:08:46Z

telemetry has same issue?

Updated in original text.

liat-grozovik · 2023-12-18T16:00:53Z

@qiluo-msft i see you provided step by step for repro but is there a sonic-mgmt test that can run to reproduce and confirm it will no longer be an issue not just for 202205?

prabhataravind · 2023-12-20T16:26:36Z

@qiluo-msft to review the PR.

…b_buffers is set to true (#303) This happened because the MIB assumed that half the queues configured are for mcast. When create_only_config_db_buffers is set to true this is not the case **- What I did** The ciscoSwitchQosMIB MIB assumed that all the counter are configured and that half of the configured queues are for mcast. This is no longer true, the feature "polling only configured ports buffer queue" make it possible for port to not have MC counters. This wrong assumption caused issue sonic-net/sonic-buildimage#17448 To fix this, I instead used the BUFFER_MAX_PARAM_TABLE to find the max possible queues **- How I did it** **- How to verify it** Inside the SNMP docker run snmp walk: $ snmpwalk -v2c -c msft 10.64.247.240 1.3.6.1.4.1.9.9.580.1.5.5.1.4.1 Check that the results is not missing counters from any queue

…b_buffers is set to true (sonic-net#303) This happened because the MIB assumed that half the queues configured are for mcast. When create_only_config_db_buffers is set to true this is not the case **- What I did** The ciscoSwitchQosMIB MIB assumed that all the counter are configured and that half of the configured queues are for mcast. This is no longer true, the feature "polling only configured ports buffer queue" make it possible for port to not have MC counters. This wrong assumption caused issue sonic-net/sonic-buildimage#17448 To fix this, I instead used the BUFFER_MAX_PARAM_TABLE to find the max possible queues **- How I did it** **- How to verify it** Inside the SNMP docker run snmp walk: $ snmpwalk -v2c -c msft 10.64.247.240 1.3.6.1.4.1.9.9.580.1.5.5.1.4.1 Check that the results is not missing counters from any queue

…b_buffers is set to true (#303) This happened because the MIB assumed that half the queues configured are for mcast. When create_only_config_db_buffers is set to true this is not the case **- What I did** The ciscoSwitchQosMIB MIB assumed that all the counter are configured and that half of the configured queues are for mcast. This is no longer true, the feature "polling only configured ports buffer queue" make it possible for port to not have MC counters. This wrong assumption caused issue sonic-net/sonic-buildimage#17448 To fix this, I instead used the BUFFER_MAX_PARAM_TABLE to find the max possible queues **- How I did it** **- How to verify it** Inside the SNMP docker run snmp walk: $ snmpwalk -v2c -c msft 10.64.247.240 1.3.6.1.4.1.9.9.580.1.5.5.1.4.1 Check that the results is not missing counters from any queue

…b_buffers is set to true (sonic-net#303) This happened because the MIB assumed that half the queues configured are for mcast. When create_only_config_db_buffers is set to true this is not the case **- What I did** The ciscoSwitchQosMIB MIB assumed that all the counter are configured and that half of the configured queues are for mcast. This is no longer true, the feature "polling only configured ports buffer queue" make it possible for port to not have MC counters. This wrong assumption caused issue sonic-net/sonic-buildimage#17448 To fix this, I instead used the BUFFER_MAX_PARAM_TABLE to find the max possible queues **- How I did it** **- How to verify it** Inside the SNMP docker run snmp walk: $ snmpwalk -v2c -c msft 10.64.247.240 1.3.6.1.4.1.9.9.580.1.5.5.1.4.1 Check that the results is not missing counters from any queue

…b_buffers is set to true (#303) (#305) This happened because the MIB assumed that half the queues configured are for mcast. When create_only_config_db_buffers is set to true this is not the case **- What I did** The ciscoSwitchQosMIB MIB assumed that all the counter are configured and that half of the configured queues are for mcast. This is no longer true, the feature "polling only configured ports buffer queue" make it possible for port to not have MC counters. This wrong assumption caused issue sonic-net/sonic-buildimage#17448 To fix this, I instead used the BUFFER_MAX_PARAM_TABLE to find the max possible queues **- How I did it** **- How to verify it** Inside the SNMP docker run snmp walk: $ snmpwalk -v2c -c msft 10.64.247.240 1.3.6.1.4.1.9.9.580.1.5.5.1.4.1 Check that the results is not missing counters from any queue Co-authored-by: DavidZagury <[email protected]>

## Approach #### What is the motivation for this PR? ADO : 26336010 Modify test to detect issue sonic-net/sonic-buildimage#17448. #### How did you do it? Currently test_snmp_queue only verifies that each interface does have queue counters associated with it. It does not verify if all the expected queue counters are present. Modify test_snmp_queue to add 2 additional checks: 1. Ensure that queue index with queue configuration in config_db, is present for each interface. 2. Ensure that the number of Unicast queue counters for each interface in 'show queue counters <interface name> is the same as the number of queue indexes in the SNMP result. #### How did you verify/test it? Test case passes for single-asic/multi-asic/Chassis platforms. Test case passed with: 202205/202305/202311/master images Test case fails when run on device with image which has the issue: sonic-net/sonic-buildimage#17448. ``` 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'])) E Failed: Expected queue index 6 not present in SNMP result for interface Ethernet13/3 .. snmp/test_snmp_queue.py:87: Failed -------------------------------------------------------------------------------------------------- generated xml file: /data/sonic-mgmt-int/tests/logs/tr.xml -------------------------------------------------------------------------------------------------- =================================================================================================================== short test summary info ==================================================================================================================== FAILED snmp/test_snmp_queue.py::test_snmp_queues[str3-7060-acs-1] - Failed: Expected queue index 6 not present in SNMP result for interface Ethernet13/3 ================================================================================================================== 1 failed in 248.30 seconds ================================================================================================================== INFO:root:Can not get Allure report URL. Please check logs ```

…t#11180) ## Approach #### What is the motivation for this PR? ADO : 26336010 Modify test to detect issue sonic-net/sonic-buildimage#17448. #### How did you do it? Currently test_snmp_queue only verifies that each interface does have queue counters associated with it. It does not verify if all the expected queue counters are present. Modify test_snmp_queue to add 2 additional checks: 1. Ensure that queue index with queue configuration in config_db, is present for each interface. 2. Ensure that the number of Unicast queue counters for each interface in 'show queue counters <interface name> is the same as the number of queue indexes in the SNMP result. #### How did you verify/test it? Test case passes for single-asic/multi-asic/Chassis platforms. Test case passed with: 202205/202305/202311/master images Test case fails when run on device with image which has the issue: sonic-net/sonic-buildimage#17448. ``` 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'])) E Failed: Expected queue index 6 not present in SNMP result for interface Ethernet13/3 .. snmp/test_snmp_queue.py:87: Failed -------------------------------------------------------------------------------------------------- generated xml file: /data/sonic-mgmt-int/tests/logs/tr.xml -------------------------------------------------------------------------------------------------- =================================================================================================================== short test summary info ==================================================================================================================== FAILED snmp/test_snmp_queue.py::test_snmp_queues[str3-7060-acs-1] - Failed: Expected queue index 6 not present in SNMP result for interface Ethernet13/3 ================================================================================================================== 1 failed in 248.30 seconds ================================================================================================================== INFO:root:Can not get Allure report URL. Please check logs ```

## Approach #### What is the motivation for this PR? ADO : 26336010 Modify test to detect issue sonic-net/sonic-buildimage#17448. #### How did you do it? Currently test_snmp_queue only verifies that each interface does have queue counters associated with it. It does not verify if all the expected queue counters are present. Modify test_snmp_queue to add 2 additional checks: 1. Ensure that queue index with queue configuration in config_db, is present for each interface. 2. Ensure that the number of Unicast queue counters for each interface in 'show queue counters <interface name> is the same as the number of queue indexes in the SNMP result. #### How did you verify/test it? Test case passes for single-asic/multi-asic/Chassis platforms. Test case passed with: 202205/202305/202311/master images Test case fails when run on device with image which has the issue: sonic-net/sonic-buildimage#17448. ``` 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'])) E Failed: Expected queue index 6 not present in SNMP result for interface Ethernet13/3 .. snmp/test_snmp_queue.py:87: Failed -------------------------------------------------------------------------------------------------- generated xml file: /data/sonic-mgmt-int/tests/logs/tr.xml -------------------------------------------------------------------------------------------------- =================================================================================================================== short test summary info ==================================================================================================================== FAILED snmp/test_snmp_queue.py::test_snmp_queues[str3-7060-acs-1] - Failed: Expected queue index 6 not present in SNMP result for interface Ethernet13/3 ================================================================================================================== 1 failed in 248.30 seconds ================================================================================================================== INFO:root:Can not get Allure report URL. Please check logs ```

…b_buffers is set to true (sonic-net#303) This happened because the MIB assumed that half the queues configured are for mcast. When create_only_config_db_buffers is set to true this is not the case **- What I did** The ciscoSwitchQosMIB MIB assumed that all the counter are configured and that half of the configured queues are for mcast. This is no longer true, the feature "polling only configured ports buffer queue" make it possible for port to not have MC counters. This wrong assumption caused issue sonic-net/sonic-buildimage#17448 To fix this, I instead used the BUFFER_MAX_PARAM_TABLE to find the max possible queues **- How I did it** **- How to verify it** Inside the SNMP docker run snmp walk: $ snmpwalk -v2c -c msft 10.64.247.240 1.3.6.1.4.1.9.9.580.1.5.5.1.4.1 Check that the results is not missing counters from any queue

…b_buffers is set to true (#303) (#309) This happened because the MIB assumed that half the queues configured are for mcast. When create_only_config_db_buffers is set to true this is not the case **- What I did** The ciscoSwitchQosMIB MIB assumed that all the counter are configured and that half of the configured queues are for mcast. This is no longer true, the feature "polling only configured ports buffer queue" make it possible for port to not have MC counters. This wrong assumption caused issue sonic-net/sonic-buildimage#17448 To fix this, I instead used the BUFFER_MAX_PARAM_TABLE to find the max possible queues **- How I did it** **- How to verify it** Inside the SNMP docker run snmp walk: $ snmpwalk -v2c -c msft 10.64.247.240 1.3.6.1.4.1.9.9.580.1.5.5.1.4.1 Check that the results is not missing counters from any queue Co-authored-by: DavidZagury <[email protected]>

## Approach #### What is the motivation for this PR? ADO : 26336010 Modify test to detect issue sonic-net/sonic-buildimage#17448. #### How did you do it? Currently test_snmp_queue only verifies that each interface does have queue counters associated with it. It does not verify if all the expected queue counters are present. Modify test_snmp_queue to add 2 additional checks: 1. Ensure that queue index with queue configuration in config_db, is present for each interface. 2. Ensure that the number of Unicast queue counters for each interface in 'show queue counters <interface name> is the same as the number of queue indexes in the SNMP result. #### How did you verify/test it? Test case passes for single-asic/multi-asic/Chassis platforms. Test case passed with: 202205/202305/202311/master images Test case fails when run on device with image which has the issue: sonic-net/sonic-buildimage#17448. ``` 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'])) E Failed: Expected queue index 6 not present in SNMP result for interface Ethernet13/3 .. snmp/test_snmp_queue.py:87: Failed -------------------------------------------------------------------------------------------------- generated xml file: /data/sonic-mgmt-int/tests/logs/tr.xml -------------------------------------------------------------------------------------------------- =================================================================================================================== short test summary info ==================================================================================================================== FAILED snmp/test_snmp_queue.py::test_snmp_queues[str3-7060-acs-1] - Failed: Expected queue index 6 not present in SNMP result for interface Ethernet13/3 ================================================================================================================== 1 failed in 248.30 seconds ================================================================================================================== INFO:root:Can not get Allure report URL. Please check logs ```

…b_buffers is set to true (sonic-net#303) This happened because the MIB assumed that half the queues configured are for mcast. When create_only_config_db_buffers is set to true this is not the case **- What I did** The ciscoSwitchQosMIB MIB assumed that all the counter are configured and that half of the configured queues are for mcast. This is no longer true, the feature "polling only configured ports buffer queue" make it possible for port to not have MC counters. This wrong assumption caused issue sonic-net/sonic-buildimage#17448 To fix this, I instead used the BUFFER_MAX_PARAM_TABLE to find the max possible queues **- How I did it** **- How to verify it** Inside the SNMP docker run snmp walk: $ snmpwalk -v2c -c msft 10.64.247.240 1.3.6.1.4.1.9.9.580.1.5.5.1.4.1 Check that the results is not missing counters from any queue

…b_buffers is set to true (#303) This happened because the MIB assumed that half the queues configured are for mcast. When create_only_config_db_buffers is set to true this is not the case **- What I did** The ciscoSwitchQosMIB MIB assumed that all the counter are configured and that half of the configured queues are for mcast. This is no longer true, the feature "polling only configured ports buffer queue" make it possible for port to not have MC counters. This wrong assumption caused issue sonic-net/sonic-buildimage#17448 To fix this, I instead used the BUFFER_MAX_PARAM_TABLE to find the max possible queues **- How I did it** **- How to verify it** Inside the SNMP docker run snmp walk: $ snmpwalk -v2c -c msft 10.64.247.240 1.3.6.1.4.1.9.9.580.1.5.5.1.4.1 Check that the results is not missing counters from any queue

## Description of PR This test is checking that buffer queue counters inside snmp docker are inline when using create_only_config_db_counters optimization. Summary: Accompanies "Fix SNMP dropping some of the queue counter when create_only_config_db_buffers is set to true" (sonic-net/sonic-snmpagent#303) which fixes the issue: "The feature "polling only configured ports buffer queue" will break SNMP" (sonic-net/sonic-buildimage#17448). ### Type of change - [ ] Bug fix - [ ] Testbed and Framework(new/improvement) - [x] Test case(new/improvement) ## Approach #### What is the motivation for this PR? To enhance the bug fix mentioned above, solving an issue with buffer queue counters optimization. #### How did you do it? - Set "create_only_config_db_buffers" to true in config db, to create only relevant counters - Remove one of the buffer queues, Ethernet0|3-4 is chosen arbitrary - Using snmpwalk compare number of queue counters on Ethernet0, assuming there will be 8 less after removing the buffer. (Assuming unicast only, 4 counters for each queue in this case) #### How did you verify/test it? Run the test multiple times on various setups. Run the test while reverting the fix mentioned above to see the different result. ### Supported testbed topology if it's a new test case? Any

qiluo-msft assigned moshemos Dec 11, 2023

qiluo-msft added the NVIDIA label Dec 11, 2023

DavidZagury self-assigned this Dec 14, 2023

moshemos added Request for 202205 Branch Request for 202305 Branch Request for 202311 Branch and removed Request for 202205 Branch Request for 202305 Branch Request for 202311 Branch labels Dec 17, 2023

liat-grozovik unassigned moshemos Dec 18, 2023

This was referenced Dec 19, 2023

Fix SNMP dropping some of the queue counter when create_only_config_d… DavidZagury/sonic-snmpagent#1

Closed

Fix SNMP dropping some of the queue counter when create_only_config_d… sonic-net/sonic-snmpagent#303

Merged

prabhataravind added the Triaged this issue has been triaged label Dec 20, 2023

SuvarnaMeenakshi mentioned this issue Jan 3, 2024

[SNMP]: Modify test to verify all queue indexes are present sonic-net/sonic-mgmt#11180

Merged

7 tasks

mssonicbld mentioned this issue Jan 9, 2024

[action] [PR:303] Fix SNMP dropping some of the queue counter when create_only_config_db_buffers is set to true (#303) sonic-net/sonic-snmpagent#304

Merged

DavidZagury closed this as completed Jan 9, 2024

mssonicbld mentioned this issue Jan 9, 2024

[action] [PR:303] Fix SNMP dropping some of the queue counter when create_only_config_db_buffers is set to true (#303) sonic-net/sonic-snmpagent#305

Merged

mssonicbld mentioned this issue Jan 17, 2024

[action] [PR:11180] [SNMP]: Modify test to verify all queue indexes are present sonic-net/sonic-mgmt#11306

Merged

7 tasks

This was referenced Jan 17, 2024

[action] [PR:11180] [SNMP]: Modify test to verify all queue indexes are present sonic-net/sonic-mgmt#11307

Merged

[action] [PR:11180] [SNMP]: Modify test to verify all queue indexes are present sonic-net/sonic-mgmt#11308

Merged

mssonicbld mentioned this issue Jan 20, 2024

[action] [PR:303] Fix SNMP dropping some of the queue counter when create_only_config_db_buffers is set to true (#303) sonic-net/sonic-snmpagent#309

Merged

mssonicbld mentioned this issue Jan 23, 2024

[action] [PR:303] Fix SNMP dropping some of the queue counter when create_only_config_db_buffers is set to true (#303) sonic-net/sonic-snmpagent#310

Merged

This was referenced Mar 6, 2024

Test PG counters is accurate when using create_only_config_db_buffers… arfeigin/sonic-mgmt#1

Closed

Test polling only configured buffer queue counters sonic-net/sonic-mgmt#11941

Merged

arfeigin mentioned this issue May 6, 2024

Add buffer queue counters test case to telemetry test sonic-net/sonic-mgmt#12735

Merged

8 tasks

mssonicbld mentioned this issue Jun 10, 2024

[action] [PR:12735] Add buffer queue counters test case to telemetry test sonic-net/sonic-mgmt#13207

Merged

8 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

The feature "polling only configured ports buffer queue" will break SNMP #17448

The feature "polling only configured ports buffer queue" will break SNMP #17448

qiluo-msft commented Dec 8, 2023 •

edited

Loading

lguohan commented Dec 8, 2023

qiluo-msft commented Dec 11, 2023

liat-grozovik commented Dec 18, 2023

prabhataravind commented Dec 20, 2023

The feature "polling only configured ports buffer queue" will break SNMP #17448

The feature "polling only configured ports buffer queue" will break SNMP #17448

Comments

qiluo-msft commented Dec 8, 2023 • edited Loading

Description

Steps to reproduce the issue:

Describe the results you received:

Describe the results you expected:

Output of show version:

Output of show techsupport:

lguohan commented Dec 8, 2023

qiluo-msft commented Dec 11, 2023

liat-grozovik commented Dec 18, 2023

prabhataravind commented Dec 20, 2023

qiluo-msft commented Dec 8, 2023 •

edited

Loading

Output of `show version`:

Output of `show techsupport`: