[bgp/test]: Add config_reload after suppress-fib-pending changes#22916
Open
mike-dubrovsky wants to merge 4 commits into
Open
[bgp/test]: Add config_reload after suppress-fib-pending changes#22916mike-dubrovsky wants to merge 4 commits into
mike-dubrovsky wants to merge 4 commits into
Conversation
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
This was referenced Mar 12, 2026
mike-dubrovsky
force-pushed
the
fib-suppression
branch
from
March 25, 2026 22:58
480b882 to
90b0d55
Compare
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
yxieca
previously approved these changes
Mar 31, 2026
yxieca
left a comment
yxieca
left a comment
Collaborator
There was a problem hiding this comment.
AI agent on behalf of Ying. Reviewed; no issues found.
deepak-singhal0408
requested review from
deepak-singhal0408
and removed request for
cyw233 and
lolyu
April 6, 2026 06:34
Contributor
|
@mike-dubrovsky please help resolve the conflicts.. @rawal01 please help take a look as well.. thanks, |
mike-dubrovsky
force-pushed
the
fib-suppression
branch
from
April 8, 2026 22:32
90b0d55 to
ebcd06e
Compare
Collaborator
|
/azp run |
|
Azure Pipelines will not run the associated pipelines, because the pull request was updated after the run command was issued. Review the pull request again and issue a new run command. |
mike-dubrovsky
force-pushed
the
fib-suppression
branch
from
April 9, 2026 02:21
ebcd06e to
95ce9cf
Compare
Collaborator
|
/azp run |
mike-dubrovsky
force-pushed
the
fib-suppression
branch
from
May 20, 2026 18:32
1dba229 to
382302a
Compare
Collaborator
|
/azp run |
1 similar comment
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
1 similar comment
|
Azure Pipelines successfully started running 1 pipeline(s). |
Contributor
Author
mike-dubrovsky
force-pushed
the
fib-suppression
branch
from
July 14, 2026 02:36
382302a to
ee01af9
Compare
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
config suppress-fib-pending now requires a config reload to take effect. - conftest.py: Add config reload (with wait_for_bgp) after CLI change in config_bgp_suppress_fib fixture so that changes become operational. - test_bgp_peer_shutdown.py, test_bgp_update_timer.py: Remove redundant delete_running_config teardown that is no longer needed. Signed-off-by: mike-dubrovsky <mdubrovs@cisco.com>
Update test plans to reflect that config suppress-fib-pending requires a config reload to become operational. - Add a general note that changing the suppress-fib-pending configuration requires a reload to take effect. - Remove Test case sonic-net#4 (BGP route suppress in multiple VRF scenario), which was not implemented in the test script. - Renumber subsequent test cases accordingly. - Redesign Test case sonic-net#6 (stress): enable suppress once, flap routes to stress the pipeline, suspend orchagent, verify queued/blackholing, then restore orchagent and verify offloaded state and traffic forwarding. - Update T2-Chassis testplan to match T1 testplan changes. Signed-off-by: mike-dubrovsky <mdubrovs@cisco.com>
… block When orch_northbond_route_zmq_enabled is true, fpmsyncd uses ZMQ instead of TCP to communicate with orchagent. Pausing orchagent (SIGSTOP) blocks ZMQ send, which causes fpmsyncd to time out and prevents route updates from being received - breaking tests that intentionally stop orchagent to simulate route install delays. Add a module-scoped autouse fixture disable_zmq_for_fib_suppress that: - Reads the current orch_northbond_route_zmq_enabled value from CONFIG_DB - If enabled, sets it to false and reloads the config - Restores the original value after the test module completes Also add the resulting ZMQ error to the loganalyzer ignore list so that tests do not fail due to spurious ZMQ errors on devices where ZMQ is not active. Signed-off-by: mike-dubrovsky <mdubrovs@cisco.com>
mike-dubrovsky
force-pushed
the
fib-suppression
branch
from
July 14, 2026 07:59
ee01af9 to
f11e616
Compare
Collaborator
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
Collaborator
|
/azp run |
|
Azure Pipelines will not run the associated pipelines, because the pull request was updated after the run command was issued. Review the pull request again and issue a new run command. |
Collaborator
|
Hi, the Pre_test Static Analysis pre-checker is failing on this PR due to a flake8 lint error in your change:
|
…ib_stress config_bgp_suppress_fib: - Add idempotency: skip CLI change and reload if CONFIG_DB state already matches the desired state. - Add config save and config reload (with wait_for_bgp) after CLI change so the setting becomes operational. - Restore multi-ASIC validation loop in the validate_result block. restore_bgp_suppress_fib fixture: - Change to scope="module", autouse=True to run once per module and avoid repeated expensive reloads. - Iterate over all DUTs (duthosts) so that both upstream and downstream hosts are covered in multi-DUT topologies. - Assert on rc != 0 instead of silently assuming enabled state. test_suppress_fib_stress: - Remove ptfhost and tcpdump_helper dependencies. - Enable suppress-fib-pending once at the start (module fixture restores). - Flow: route flap stress -> suspend orchagent -> announce routes -> verify QUEUED state and blackholing -> restore orchagent -> verify OFFLOADED state and traffic forwarded to T0. - Use validate_route_states and validate_traffic helpers consistent with other tests in the module. test_credit_loop: - Remove stale "Restore orchagent process" step; config_bgp_suppress_fib now performs a config_reload which implicitly restarts orchagent. test_bgp_route_with_suppress: - Remove redundant config save after config_bgp_suppress_fib calls. Signed-off-by: mike-dubrovsky <mdubrovs@cisco.com>
mike-dubrovsky
force-pushed
the
fib-suppression
branch
from
July 14, 2026 19:42
f11e616 to
3889341
Compare
Collaborator
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
StormLiangMS
pushed a commit
that referenced
this pull request
Jul 16, 2026
#26175) (#26176) ### Description of PR Summary: Fixes #26175 Temporarily skip the whole `bgp/test_bgp_suppress_fib.py` module for the suppress-fib-pending **dynamic-toggle race**. The module toggles `suppress-fib-pending` dynamically at runtime (via the shared `config_bgp_suppress_fib()` helper, no `config reload`). That triggers a race between **orchagent, fpmsyncd and FRR** where routes are intermittently **not marked offloaded in FRR** / **not propagated to the upstream VM** within the wait window, failing essentially every case in the module. The root-cause fix makes `suppress-fib-pending` **static** (takes effect only after a `config reload`), removing the race — [sonic-swss#4333](sonic-net/sonic-swss#4333), [sonic-buildimage#26151](sonic-net/sonic-buildimage#26151), [sonic-utilities#4361](sonic-net/sonic-utilities#4361), [sonic-mgmt#22916](#22916), [SONiC#2335](sonic-net/SONiC#2335). > **The product fix is master-only and is not backported.** Because of that, the skip uses **two different lift semantics**, expressed as separate conditions: > > - **`master`** — gated on the tracking issue: `release in ['master'] and https://github.com/sonic-net/sonic-mgmt/issues/26175`. When the fix lands on master and #26175 is closed, the skip **auto-lifts** on master and coverage returns — no manual edit needed. > - **`202505` / `202511` / `202605`** — a plain `release in [...]` condition with **no issue gate**. These branches never receive the product fix, so the module is skipped for the life of the branch (same nature as the existing pre-202411 "not supported" condition). > > **Per-branch effect still requires cherry-picking this skip.** Each release branch's nightly runs its own `sonic-mgmt` checkout, so this YAML change must be cherry-picked to 202505/202511/202605 for the skip to take effect there. The identical diff matches on each branch via its own `release` token. > > If a release branch ever does receive the product fix, drop that branch's token from the `release in [...]` list — a deliberate per-branch edit. #26175 tracks the lifecycle. ### Type of change - [ ] Bug fix - [x] Testbed and Framework(new/improvement) - [ ] New Test case - [ ] Skipped for non-supported platforms - [ ] Test case improvement ### Back port request - [ ] 202205 - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [x] 202505 - [x] 202511 (also 202605 — not listed in the template checkboxes; cherry-pick required there as well.) ### Approach #### What is the motivation for this PR? The `test_bgp_suppress_fib` module is a persistent nightly-noise source across master and the active release branches. The dynamic runtime toggle of `suppress-fib-pending` races orchagent/fpmsyncd/FRR, so routes are intermittently left un-offloaded / un-propagated and nearly every case in the module fails intermittently. Skipping the module de-noises the nightly signal while the product-layer fix rolls out on master. #### How did you do it? Extended the existing `bgp/test_bgp_suppress_fib.py` skip block with `conditions_logical_operator: or` and split the affected releases by lift semantics: ```yaml conditions: - "release in ['201811', '201911', '202012', '202205', '202211', '202305', '202311', '202405']" - "release in ['202505', '202511', '202605']" - "release in ['master'] and #26175" ``` The `conditional_mark` plugin replaces the issue URL with `True`/`False` based on the issue's open/closed state and `eval()`s the condition, so the master line auto-lifts when #26175 closes while the release-branch line stays permanent. (The same file already uses the `<expr> and <issue-url>` form for the `asic_type in ['vs'] and #14449` conditions.) #### How did you verify/test it? - `tests_mark_conditions.yaml` parses cleanly and passes the `check_conditional_mark_sort.py` pre-commit hook. - Simulated the `conditional_mark` evaluation for each `release` value: - issue **open**: master + 202505/202511/202605 all skip; - issue **closed**: master unskips, 202505/202511/202605 remain skipped — matching the intended lift semantics. #### Any platform specific information? None — the skip is keyed on `release` only (all ASICs/topologies), matching the all-vendor nature of the race. #### Supported testbed topology if it's a new test case? N/A — not a new test case; module skip only. ### Documentation N/A Signed-off-by: Deepak Singhal <deepsinghal@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
selldinesh
pushed a commit
to selldinesh/sonic-mgmt
that referenced
this pull request
Jul 16, 2026
sonic-net#26175) (sonic-net#26176) ### Description of PR Summary: Fixes sonic-net#26175 Temporarily skip the whole `bgp/test_bgp_suppress_fib.py` module for the suppress-fib-pending **dynamic-toggle race**. The module toggles `suppress-fib-pending` dynamically at runtime (via the shared `config_bgp_suppress_fib()` helper, no `config reload`). That triggers a race between **orchagent, fpmsyncd and FRR** where routes are intermittently **not marked offloaded in FRR** / **not propagated to the upstream VM** within the wait window, failing essentially every case in the module. The root-cause fix makes `suppress-fib-pending` **static** (takes effect only after a `config reload`), removing the race — [sonic-swss#4333](sonic-net/sonic-swss#4333), [sonic-buildimage#26151](sonic-net/sonic-buildimage#26151), [sonic-utilities#4361](sonic-net/sonic-utilities#4361), [sonic-mgmt#22916](sonic-net#22916), [SONiC#2335](sonic-net/SONiC#2335). > **The product fix is master-only and is not backported.** Because of that, the skip uses **two different lift semantics**, expressed as separate conditions: > > - **`master`** — gated on the tracking issue: `release in ['master'] and https://github.com/sonic-net/sonic-mgmt/issues/26175`. When the fix lands on master and sonic-net#26175 is closed, the skip **auto-lifts** on master and coverage returns — no manual edit needed. > - **`202505` / `202511` / `202605`** — a plain `release in [...]` condition with **no issue gate**. These branches never receive the product fix, so the module is skipped for the life of the branch (same nature as the existing pre-202411 "not supported" condition). > > **Per-branch effect still requires cherry-picking this skip.** Each release branch's nightly runs its own `sonic-mgmt` checkout, so this YAML change must be cherry-picked to 202505/202511/202605 for the skip to take effect there. The identical diff matches on each branch via its own `release` token. > > If a release branch ever does receive the product fix, drop that branch's token from the `release in [...]` list — a deliberate per-branch edit. sonic-net#26175 tracks the lifecycle. ### Type of change - [ ] Bug fix - [x] Testbed and Framework(new/improvement) - [ ] New Test case - [ ] Skipped for non-supported platforms - [ ] Test case improvement ### Back port request - [ ] 202205 - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [x] 202505 - [x] 202511 (also 202605 — not listed in the template checkboxes; cherry-pick required there as well.) ### Approach #### What is the motivation for this PR? The `test_bgp_suppress_fib` module is a persistent nightly-noise source across master and the active release branches. The dynamic runtime toggle of `suppress-fib-pending` races orchagent/fpmsyncd/FRR, so routes are intermittently left un-offloaded / un-propagated and nearly every case in the module fails intermittently. Skipping the module de-noises the nightly signal while the product-layer fix rolls out on master. #### How did you do it? Extended the existing `bgp/test_bgp_suppress_fib.py` skip block with `conditions_logical_operator: or` and split the affected releases by lift semantics: ```yaml conditions: - "release in ['201811', '201911', '202012', '202205', '202211', '202305', '202311', '202405']" - "release in ['202505', '202511', '202605']" - "release in ['master'] and sonic-net#26175" ``` The `conditional_mark` plugin replaces the issue URL with `True`/`False` based on the issue's open/closed state and `eval()`s the condition, so the master line auto-lifts when sonic-net#26175 closes while the release-branch line stays permanent. (The same file already uses the `<expr> and <issue-url>` form for the `asic_type in ['vs'] and sonic-net#14449` conditions.) #### How did you verify/test it? - `tests_mark_conditions.yaml` parses cleanly and passes the `check_conditional_mark_sort.py` pre-commit hook. - Simulated the `conditional_mark` evaluation for each `release` value: - issue **open**: master + 202505/202511/202605 all skip; - issue **closed**: master unskips, 202505/202511/202605 remain skipped — matching the intended lift semantics. #### Any platform specific information? None — the skip is keyed on `release` only (all ASICs/topologies), matching the all-vendor nature of the race. #### Supported testbed topology if it's a new test case? N/A — not a new test case; module skip only. ### Documentation N/A Signed-off-by: Deepak Singhal <deepsinghal@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Signed-off-by: selldinesh <dinesh.sellappan@keysight.com>
selldinesh
pushed a commit
to selldinesh/sonic-mgmt
that referenced
this pull request
Jul 16, 2026
sonic-net#26175) (sonic-net#26176) ### Description of PR Summary: Fixes sonic-net#26175 Temporarily skip the whole `bgp/test_bgp_suppress_fib.py` module for the suppress-fib-pending **dynamic-toggle race**. The module toggles `suppress-fib-pending` dynamically at runtime (via the shared `config_bgp_suppress_fib()` helper, no `config reload`). That triggers a race between **orchagent, fpmsyncd and FRR** where routes are intermittently **not marked offloaded in FRR** / **not propagated to the upstream VM** within the wait window, failing essentially every case in the module. The root-cause fix makes `suppress-fib-pending` **static** (takes effect only after a `config reload`), removing the race — [sonic-swss#4333](sonic-net/sonic-swss#4333), [sonic-buildimage#26151](sonic-net/sonic-buildimage#26151), [sonic-utilities#4361](sonic-net/sonic-utilities#4361), [sonic-mgmt#22916](sonic-net#22916), [SONiC#2335](sonic-net/SONiC#2335). > **The product fix is master-only and is not backported.** Because of that, the skip uses **two different lift semantics**, expressed as separate conditions: > > - **`master`** — gated on the tracking issue: `release in ['master'] and https://github.com/sonic-net/sonic-mgmt/issues/26175`. When the fix lands on master and sonic-net#26175 is closed, the skip **auto-lifts** on master and coverage returns — no manual edit needed. > - **`202505` / `202511` / `202605`** — a plain `release in [...]` condition with **no issue gate**. These branches never receive the product fix, so the module is skipped for the life of the branch (same nature as the existing pre-202411 "not supported" condition). > > **Per-branch effect still requires cherry-picking this skip.** Each release branch's nightly runs its own `sonic-mgmt` checkout, so this YAML change must be cherry-picked to 202505/202511/202605 for the skip to take effect there. The identical diff matches on each branch via its own `release` token. > > If a release branch ever does receive the product fix, drop that branch's token from the `release in [...]` list — a deliberate per-branch edit. sonic-net#26175 tracks the lifecycle. ### Type of change - [ ] Bug fix - [x] Testbed and Framework(new/improvement) - [ ] New Test case - [ ] Skipped for non-supported platforms - [ ] Test case improvement ### Back port request - [ ] 202205 - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [x] 202505 - [x] 202511 (also 202605 — not listed in the template checkboxes; cherry-pick required there as well.) ### Approach #### What is the motivation for this PR? The `test_bgp_suppress_fib` module is a persistent nightly-noise source across master and the active release branches. The dynamic runtime toggle of `suppress-fib-pending` races orchagent/fpmsyncd/FRR, so routes are intermittently left un-offloaded / un-propagated and nearly every case in the module fails intermittently. Skipping the module de-noises the nightly signal while the product-layer fix rolls out on master. #### How did you do it? Extended the existing `bgp/test_bgp_suppress_fib.py` skip block with `conditions_logical_operator: or` and split the affected releases by lift semantics: ```yaml conditions: - "release in ['201811', '201911', '202012', '202205', '202211', '202305', '202311', '202405']" - "release in ['202505', '202511', '202605']" - "release in ['master'] and sonic-net#26175" ``` The `conditional_mark` plugin replaces the issue URL with `True`/`False` based on the issue's open/closed state and `eval()`s the condition, so the master line auto-lifts when sonic-net#26175 closes while the release-branch line stays permanent. (The same file already uses the `<expr> and <issue-url>` form for the `asic_type in ['vs'] and sonic-net#14449` conditions.) #### How did you verify/test it? - `tests_mark_conditions.yaml` parses cleanly and passes the `check_conditional_mark_sort.py` pre-commit hook. - Simulated the `conditional_mark` evaluation for each `release` value: - issue **open**: master + 202505/202511/202605 all skip; - issue **closed**: master unskips, 202505/202511/202605 remain skipped — matching the intended lift semantics. #### Any platform specific information? None — the skip is keyed on `release` only (all ASICs/topologies), matching the all-vendor nature of the race. #### Supported testbed topology if it's a new test case? N/A — not a new test case; module skip only. ### Documentation N/A Signed-off-by: Deepak Singhal <deepsinghal@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Signed-off-by: selldinesh <dinesh.sellappan@keysight.com>
ssithaia-ebay
pushed a commit
to ssithaia-ebay/sflow-yang-sonic-mgmt
that referenced
this pull request
Jul 21, 2026
sonic-net#26175) (sonic-net#26176) ### Description of PR Summary: Fixes sonic-net#26175 Temporarily skip the whole `bgp/test_bgp_suppress_fib.py` module for the suppress-fib-pending **dynamic-toggle race**. The module toggles `suppress-fib-pending` dynamically at runtime (via the shared `config_bgp_suppress_fib()` helper, no `config reload`). That triggers a race between **orchagent, fpmsyncd and FRR** where routes are intermittently **not marked offloaded in FRR** / **not propagated to the upstream VM** within the wait window, failing essentially every case in the module. The root-cause fix makes `suppress-fib-pending` **static** (takes effect only after a `config reload`), removing the race — [sonic-swss#4333](sonic-net/sonic-swss#4333), [sonic-buildimage#26151](sonic-net/sonic-buildimage#26151), [sonic-utilities#4361](sonic-net/sonic-utilities#4361), [sonic-mgmt#22916](sonic-net#22916), [SONiC#2335](sonic-net/SONiC#2335). > **The product fix is master-only and is not backported.** Because of that, the skip uses **two different lift semantics**, expressed as separate conditions: > > - **`master`** — gated on the tracking issue: `release in ['master'] and https://github.com/sonic-net/sonic-mgmt/issues/26175`. When the fix lands on master and sonic-net#26175 is closed, the skip **auto-lifts** on master and coverage returns — no manual edit needed. > - **`202505` / `202511` / `202605`** — a plain `release in [...]` condition with **no issue gate**. These branches never receive the product fix, so the module is skipped for the life of the branch (same nature as the existing pre-202411 "not supported" condition). > > **Per-branch effect still requires cherry-picking this skip.** Each release branch's nightly runs its own `sonic-mgmt` checkout, so this YAML change must be cherry-picked to 202505/202511/202605 for the skip to take effect there. The identical diff matches on each branch via its own `release` token. > > If a release branch ever does receive the product fix, drop that branch's token from the `release in [...]` list — a deliberate per-branch edit. sonic-net#26175 tracks the lifecycle. ### Type of change - [ ] Bug fix - [x] Testbed and Framework(new/improvement) - [ ] New Test case - [ ] Skipped for non-supported platforms - [ ] Test case improvement ### Back port request - [ ] 202205 - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [x] 202505 - [x] 202511 (also 202605 — not listed in the template checkboxes; cherry-pick required there as well.) ### Approach #### What is the motivation for this PR? The `test_bgp_suppress_fib` module is a persistent nightly-noise source across master and the active release branches. The dynamic runtime toggle of `suppress-fib-pending` races orchagent/fpmsyncd/FRR, so routes are intermittently left un-offloaded / un-propagated and nearly every case in the module fails intermittently. Skipping the module de-noises the nightly signal while the product-layer fix rolls out on master. #### How did you do it? Extended the existing `bgp/test_bgp_suppress_fib.py` skip block with `conditions_logical_operator: or` and split the affected releases by lift semantics: ```yaml conditions: - "release in ['201811', '201911', '202012', '202205', '202211', '202305', '202311', '202405']" - "release in ['202505', '202511', '202605']" - "release in ['master'] and sonic-net#26175" ``` The `conditional_mark` plugin replaces the issue URL with `True`/`False` based on the issue's open/closed state and `eval()`s the condition, so the master line auto-lifts when sonic-net#26175 closes while the release-branch line stays permanent. (The same file already uses the `<expr> and <issue-url>` form for the `asic_type in ['vs'] and sonic-net#14449` conditions.) #### How did you verify/test it? - `tests_mark_conditions.yaml` parses cleanly and passes the `check_conditional_mark_sort.py` pre-commit hook. - Simulated the `conditional_mark` evaluation for each `release` value: - issue **open**: master + 202505/202511/202605 all skip; - issue **closed**: master unskips, 202505/202511/202605 remain skipped — matching the intended lift semantics. #### Any platform specific information? None — the skip is keyed on `release` only (all ASICs/topologies), matching the all-vendor nature of the race. #### Supported testbed topology if it's a new test case? N/A — not a new test case; module skip only. ### Documentation N/A Signed-off-by: Deepak Singhal <deepsinghal@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Signed-off-by: ssithaia-ebay <ssithaian@ebay.com>
Contributor
|
@mike-dubrovsky, reminder on Pre_test Static Analysis pre-checker failure. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The suppress-fib-pending configuration change now requires a config save followed by config reload to take effect.
This change needs to go together with
sonic-net/sonic-swss#4333
sonic-net/sonic-buildimage#26151
sonic-net/sonic-utilities#4361
#22916
Description of PR
Summary:
Fixes # (issue)
Type of change
Back port request
Approach
What is the motivation for this PR?
How did you do it?
How did you verify/test it?
Any platform specific information?
Supported testbed topology if it's a new test case?
Documentation