Fix issue that namespace is not correctly fetched in Multi ASIC environment for mirror capability checking

[stephenxs]

What I did

Fix issue sonic-net/sonic-mgmt#21690

How I did it

The logic to check the mirror capability is:

1. orchagent exposes capability to SWITCH_CAPABILITY table in STATE_DB during initialization
2. CLI (config mirror) fetches capability from the table when a CLI command is issued by a user.

On the multi ASIC environment, the table is in ASIC's namespace. But the CLI command fetches the capability from the host. As a result it always treats mirror is unsupported and fails the test.

Fixed by checking the mirror capability from the namespaces based on source and destination ports.

How to verify it

Manual test.

Previous command output (if the output of a command-line utility has changed)

New command output (if the output of a command-line utility has changed)

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Junchao-Mellanox]

do you need a UT?

[stephenxs]

The failing test now passes with this fix link https://elastictest.org/scheduler/publictestplan/694290ffb443f607a1230cd5?searchTestCase=show&testcase=show_techsupport%2Ftest_techsupport.py&type=log

AnsibleModule::command, args=["config mirror_session add test_session_1 1.1.1.1 10.0.0.33 8 1 25944 0"], kwargs={}
17/12/2025 12:31:44 base._run                                L0111 DEBUG  | /var/src/sonic-mgmt/tests/common/devices/multi_asic.py::_run_on_asics#151: [vlab-08] AnsibleModule::command Result => {"changed": true, "stdout": "", "stderr": "", "rc": 0, "cmd": ["config", "mirror_session", "add", "test_session_1", "1.1.1.1", "10.0.0.33", "8", "1", "25944", "0"], "start": "2025-12-17 12:31:44.060053", "end": "2025-12-17 12:31:44.703195", "delta": "0:00:00.643142", "msg": "", "invocation": {"module_args": {"_raw_params": "config mirror_session add test_session_1 1.1.1.1 10.0.0.33 8 1 25944 0", "_uses_shell": false, "expand_argument_vars": true, "stdin_add_newline": true, "strip_empty_ends": true, "argv": null, "chdir": null, "executable": null, "creates": null, "removes": null, "stdin": null}}, "stdout_lines": [], "stderr_lines": [], "_ansible_no_log": false, "failed": false}

[liat-grozovik]

@oleksandrivantsiv FYI. let me know if you have any comments.

[bingwang-ms]

@stephenxs I'm little confused about this change. Per my understanding, the issue mentioned in sonic-net/sonic-mgmt#21690 is regarding erspan (mirror session), while the change in this PR is about port mirror capability check. Can you help me understand how is this related?

[stephenxs]

@stephenxs I'm little confused about this change. Per my understanding, the issue mentioned in sonic-net/sonic-mgmt#21690 is regarding erspan (mirror session), while the change in this PR is about port mirror capability check. Can you help me understand how is this related?

Sure @bingwang-ms
The mirror command is for both normal mirror and ERSPAN session

[bingwang-ms]

@stephenxs I'm little confused about this change. Per my understanding, the issue mentioned in sonic-net/sonic-mgmt#21690 is regarding erspan (mirror session), while the change in this PR is about port mirror capability check. Can you help me understand how is this related?

Sure @bingwang-ms The mirror command is for both normal mirror and ERSPAN session

Thanks for the reply. If if's for ERSPAN session, why do we need to call is_port_mirror_capability_supported?

[stephenxs]

@stephenxs I'm little confused about this change. Per my understanding, the issue mentioned in sonic-net/sonic-mgmt#21690 is regarding erspan (mirror session), while the change in this PR is about port mirror capability check. Can you help me understand how is this related?

Sure @bingwang-ms The mirror command is for both normal mirror and ERSPAN session

Thanks for the reply. If if's for ERSPAN session, why do we need to call is_port_mirror_capability_supported?

@bingwang-ms This is because ERSPAN is implemented using SAI mirror object.
It creates a mirror object with ERSPAN specific attributes and then applies the mirror object to a port (usually on which the neighbor is learnt).

[bingwang-ms]

To my knowledge, function is_port_mirror_capability_supported was added for port mirroring recently. There was no capability check for erspan (everflow) before that. I suggest keeping the existing behavior, i.e., run is_port_mirror_capability_supported for only port mirroring.
Please let me know how do you think. Thanks