[T2][VOQ]: bgp/test_bgp_queue.py fails with assert (get_queue_counters(asichost, ifname, q) == 0)

[arista-nwolfe]

Issue Description

In test_bgp_queue.py we are checking that the queues 0-6 are zero for all ports with eBGP neighbors.
However, we don't appear to be skipping iBGP correctly on VOQ systems.

                    for q in range(0, 7):
>                       assert (get_queue_counters(asichost, ifname, q) == 0)
E                       AssertionError

(Pdb) p ifname
'Ethernet-IB0'
(Pdb) get_queue_counters(asichost,ifname,q)
Monday 28 October 2024  21:55:12 +0000 (0:04:00.674)       0:27:56.593 ********
11745
(Pdb) p k
'10.0.254.3'
(Pdb) p v["peer group"]
'VOQ_CHASSIS_V4_PEER'

> docker exec -i bgp0 vtysh -c "show ip bgp neighbor"
...
BGP neighbor is 10.0.254.3, remote AS 65100, local AS 65100, internal link
  Local Role: undefined
  Remote Role: undefined
 Description: ASIC1
Hostname: cmp206-4
 Member of peer-group VOQ_CHASSIS_V4_PEER for session parameters

Results you see

We aren't skipping iBGP neighbors on VOQ chassis

Results you expected to see

We should skip iBGP neighbors on VOQ chassis

Is it platform specific

generic

Relevant log output

No response

Output of show version

No response

Attach files (if any)

No response

[abdosi]

@mlok-nokia : Nokia to check if this is functional issue with DNX SAI/SDK

[saksarav-nokia]

@vmittal-msft
There was an issue with SAI 11.2 and BCM fixed it . With this fix, the control packets from CPU will be sent to Queue 7. But the received packets in the second the pass will be assigned queue based on dscp-to-tc map and it will not be based on copp rules or to queue 7. As per BCM, the rx packets will go to either queue 0 or queue 4 based on the default dscp-to-tc mapping.
So we should n't be making any test side fix since this is SAI issue.

 [SAI_BRANCH rel_ocp_sai_11_2] [CSP CS00012363592] SONIC-94873 to 11.2 Changes to apply the KNET bypass rule on RCY ports

JIRA# SONIC-94873

Issue Summary: Changes to apply the KNET bypass rule on RCY ports

[arista-nwolfe]

Confirmed that on 202205 (from old runs) we saw queue7 increasing instead of queue0 on the Ethernet-IB0 port

24/02/2024 06:28:13 base._run                                L0063 DEBUG  | /data/tests/common/devices/sonic_asic.py::command#393: [nfc407-7] AnsibleModule::command, args=["show queue counters Ethernet-IB0"], kwargs={}
24/02/2024 06:28:15 base._run                                L0082 DEBUG  | /data/tests/common/devices/sonic_asic.py::command#393: [nfc407-7] AnsibleModule::command Result => {"stderr_lines": [], "cmd": ["show", "queue", "counters", "Ethernet-IB0"], "end": "2024-02-24 06:28:16.097345", "_ansible_no_log": false, "stdout": "Last cached time was 2024-02-24 06:26:  55.527055
        Port    TxQ    Counter/pkts    Counter/bytes    Drop/pkts    Drop/bytes
------------  -----  --------------  ---------------  -----------  ------------
Ethernet-IB0    UC0               0                0            0             0
Ethernet-IB0    UC1               0                0            0             0
Ethernet-IB0    UC2               0                0            0             0
Ethernet-IB0    UC3               0                0            0             0
Ethernet-IB0    UC4               0                0            0             0
Ethernet-IB0    UC5               0                0            0             0
Ethernet-IB0    UC6               0                0            0             0
Ethernet-IB0    UC7             104            9,100            0             0
Ethernet-IB0    MC8               0                0            0             0
Ethernet-IB0    MC9               0                0            0             0
Ethernet-IB0   MC10               0                0            0             0
Ethernet-IB0   MC11               0                0            0             0
Ethernet-IB0   MC12               0                0            0             0
Ethernet-IB0   MC13               0                0            0             0
Ethernet-IB0   MC14               0                0            0             0
Ethernet-IB0   MC15               0                0            0             0

@saksarav-nokia I don't have access to the CSP, do you know if BRCM's fix has made it into 202405?

[saksarav-nokia]

@arista-nwolfe , Yes, the fix is in SAI 11.2.13.1

[arista-nwolfe]

Thanks @saksarav-nokia
I'm upgraded to SAI11.2.13.1 and we now see packets going to queue7 and queue0 now

Ethernet-IB0 Last cached time was 2024-11-01T16:43:38.209151
        Port    TxQ    Counter/pkts    Counter/bytes    Drop/pkts    Drop/bytes
------------  -----  --------------  ---------------  -----------  ------------
Ethernet-IB0    UC0           2,135          192,760            0             0
Ethernet-IB0    UC1               0                0            0             0
Ethernet-IB0    UC2               0                0            0             0
Ethernet-IB0    UC3               0                0            0             0
Ethernet-IB0    UC4               0                0            0             0
Ethernet-IB0    UC5               0                0            0             0
Ethernet-IB0    UC6               0                0            0             0
Ethernet-IB0    UC7           2,440          213,500            0             0
Ethernet-IB0    MC8               0                0            0             0
Ethernet-IB0    MC9               0                0            0             0
Ethernet-IB0   MC10               0                0            0             0
Ethernet-IB0   MC11               0                0            0             0
Ethernet-IB0   MC12               0                0            0             0
Ethernet-IB0   MC13               0                0            0             0
Ethernet-IB0   MC14               0                0            0             0
Ethernet-IB0   MC15               0                0            0             0

So the test will still fail on SAI11.2.13.1.
I'm guessing these packets going to queue0 are the rx packets you referred to that go to queue4 or queue0?
If so do you know if BRCM is working on moving these also to queue7 or do we need to update the test to account for this?

[saksarav-nokia]

Hi @arista-nwolfe ,
I am still discussing with @vmittal-msft how to handle the second pass on the recycle port. With default dscp-to-tc mapping in SAI, the rx packets go to either q0 or q4. So if we decide to apply dscp-to-tc map, then these packets will go the queue based on dscp-to-tc and tc-q map. So we will need to change the test based on this decision.

[arista-nwolfe]

Hi @arista-nwolfe , I am still discussing with @vmittal-msft how to handle the second pass on the recycle port. With default dscp-to-tc mapping in SAI, the rx packets go to either q0 or q4. So if we decide to apply dscp-to-tc map, then these packets will go the queue based on dscp-to-tc and tc-q map. So we will need to change the test based on this decision.

Thanks @saksarav-nokia for the update