Fetch capability of mirror before configuring it#4089
Fetch capability of mirror before configuring it#4089qiluo-msft merged 6 commits intosonic-net:masterfrom
Conversation
Signed-off-by: Stephen Sun <[email protected]>
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Signed-off-by: Stephen Sun <[email protected]>
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
Failure is caused by rebasing the commit to the latest master. Investigating. |
Depends on sonic-net/sonic-swss#3934 |
Signed-off-by: Stephen Sun <[email protected]>
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
Depends on sonic-net/sonic-swss#3934 |
|
@qiluo-msft Can you help review this change? Thanks |
config/main.py
Outdated
| def is_port_mirror_capability_supported(direction, namespace=None): | ||
| """ Check if port mirror capability is supported for the given direction """ | ||
| try: | ||
| state_db = SonicV2Connector(host='127.0.0.1') |
There was a problem hiding this comment.
Could you use unix socket which has better performance? #Closed
config/main.py
Outdated
| return False | ||
|
|
||
| return True | ||
| except Exception: |
There was a problem hiding this comment.
Could you use more specific exception type? #Closed
There was a problem hiding this comment.
Removed as we do not expect any exception here.
There was a problem hiding this comment.
Pull Request Overview
This PR adds ASIC capability checking for port mirror direction support before allowing mirror session configuration. The change prevents users from configuring mirror sessions with directions (rx/tx/both) that are not supported by the underlying ASIC hardware.
- Added
is_port_mirror_capability_supported()function to query STATE_DB for ASIC capabilities - Integrated capability validation into
validate_mirror_session_config() - Added comprehensive test coverage for capability checking functionality
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| config/main.py | Added capability checking function and validation logic to prevent unsupported mirror directions |
| tests/config_mirror_session_test.py | Added test cases for capability checking and removed trailing whitespace |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Signed-off-by: Stephen Sun <[email protected]>
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
It's weird that pretest passed locally but failed in the github |
What I did Fetch capability of ingress/egress mirror before configuring it and avoid configuring ingress/egress mirror on a platform that does not support it. How I did it Check the capability in PORT_INGRESS_MIRROR_CAPABLE and PORT_EGRESS_MIRROR_CAPABLE in STATE_DB table SWITCH_CAPABILITY. The capability of ingress/egress mirror is inserted to STATE_DB by orchagent during initialization. How to verify it Manual test and unit test
)" This reverts commit ad0a3d3.
|
@stephenxs this change causes test failure when advancing sonic-utilities submodule. We need to revert to move forward. |
|
@stephenxs this change is causing show_techsupport/test_techsupport.py to fail at multi-asic deployment. But this is a good change to have. I will see if that is the only failure. if it is, then I am leaning towards file an issue to xfail it and let you work on a fix. Please stay tuned. |
Could you please share the test link? Thanks |
Draft a PR to fix it: #4159 |
What I did Fetch capability of ingress/egress mirror before configuring it and avoid configuring ingress/egress mirror on a platform that does not support it. How I did it Check the capability in PORT_INGRESS_MIRROR_CAPABLE and PORT_EGRESS_MIRROR_CAPABLE in STATE_DB table SWITCH_CAPABILITY. The capability of ingress/egress mirror is inserted to STATE_DB by orchagent during initialization. How to verify it Manual test and unit test
|
Cherry-pick PR to 202511: #4204 |
The legacy 'config mirror_session add' command calls add_erspan() with direction=None and src_port=None. After PR sonic-net#4089 added port mirror capability checking, validate_mirror_session_config() checks PORT_INGRESS_MIRROR_CAPABLE and PORT_EGRESS_MIRROR_CAPABLE in STATE_DB when direction is None. On platforms where orchagent does not populate these keys, this causes the legacy command to fail with 'Port mirror direction both is not supported by the ASIC'. The fix skips the capability check when src_port is not specified, since legacy ERSPAN sessions don't use port-based mirroring and should not be subject to the port mirror capability check. Fixes: sonic-net#4318 Signed-off-by: Ying Xie <[email protected]>
…sessions ## What I did Fixed is_port_mirror_capability_supported() so that ERSPAN sessions (direction=None) are not blocked by the PORT_INGRESS_MIRROR_CAPABLE / PORT_EGRESS_MIRROR_CAPABLE capability check. ## Root cause PR sonic-net#4089 added a capability check that reads PORT_INGRESS_MIRROR_CAPABLE and PORT_EGRESS_MIRROR_CAPABLE from STATE_DB SWITCH_CAPABILITY|switch. For ERSPAN sessions, direction=None was treated as 'check both', but: 1. These capability flags only apply to SPAN (port mirror) sessions, not ERSPAN (which uses source/destination IPs, not ports) 2. Platforms that don't populate these STATE_DB keys return None, which != 'true', so the function incorrectly returns False (unsupported) PR sonic-net#4159 partially addressed the multi-ASIC namespace issue but did not fix the fundamental problem for ERSPAN sessions with no src/dst port specified. ## How I fixed it - **For ERSPAN (direction=None)**: Return True immediately. PORT_INGRESS/EGRESS_MIRROR_CAPABLE does not apply to ERSPAN sessions. - **For SPAN (direction != None)**: Treat absent STATE_DB key (None value) as 'supported' for backward compatibility with platforms that don't populate SWITCH_CAPABILITY table entries. ## How to verify it Unit tests updated in ests/config_mirror_session_test.py: - Added Test 4 to verify behavior when STATE_DB keys are absent (all return True) - Updated Test 2 and Test 3 assertions for direction=None to expect True Fixes: sonic-net/sonic-mgmt#21690 Signed-off-by: Sonic Build Admin <[email protected]>
…sessions (#4368) ## What I did Fixed is_port_mirror_capability_supported() so that ERSPAN sessions (direction=None) are not blocked by the PORT_INGRESS_MIRROR_CAPABLE / PORT_EGRESS_MIRROR_CAPABLE capability check. ## Root cause PR #4089 added a capability check that reads PORT_INGRESS_MIRROR_CAPABLE and PORT_EGRESS_MIRROR_CAPABLE from STATE_DB SWITCH_CAPABILITY|switch. For ERSPAN sessions, direction=None was treated as 'check both', but: 1. These capability flags only apply to SPAN (port mirror) sessions, not ERSPAN (which uses source/destination IPs, not ports) 2. Platforms that don't populate these STATE_DB keys return None, which != 'true', so the function incorrectly returns False (unsupported) PR #4159 partially addressed the multi-ASIC namespace issue but did not fix the fundamental problem for ERSPAN sessions with no src/dst port specified. ## How I fixed it - **For ERSPAN (direction=None)**: Return True immediately. PORT_INGRESS/EGRESS_MIRROR_CAPABLE does not apply to ERSPAN sessions. - **For SPAN (direction != None)**: Treat absent STATE_DB key (None value) as 'supported' for backward compatibility with platforms that don't populate SWITCH_CAPABILITY table entries. ## How to verify it Unit tests updated in ests/config_mirror_session_test.py: - Added Test 4 to verify behavior when STATE_DB keys are absent (all return True) - Updated Test 2 and Test 3 assertions for direction=None to expect True Fixes: sonic-net/sonic-mgmt#21690 Signed-off-by: Sonic Build Admin <[email protected]>
What I did
Fetch capability of ingress/egress mirror before configuring it and avoid configuring ingress/egress mirror on a platform that does not support it.
How I did it
Check the capability in
PORT_INGRESS_MIRROR_CAPABLEandPORT_EGRESS_MIRROR_CAPABLEinSTATE_DBtableSWITCH_CAPABILITY.The capability of ingress/egress mirror is inserted to STATE_DB by orchagent during initialization.
How to verify it
Manual test and unit 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)