Pass FIB suppression flag and to orchagent to control APPL_STATE_DB and pub/sub by mike-dubrovsky · Pull Request #26151 · sonic-net/sonic-buildimage

mike-dubrovsky · 2026-03-12T17:30:12Z

Why I did it

Route download speed degraded after BGP prefix suppression was introduced. RouteOrch::publishRouteState() unconditionally writes to APPL_STATE_DB and sends a pub/sub notification on every route add/remove, even when FIB suppression is disabled and no consumer needs the data.

Work item tracking

Microsoft ADO (number only):

How I did it

This PR is part of a multi-repo change to make this a startup-time flag.

orchagent.sh now:

Reads suppress-fib-pending from CONFIG_DB and passes -F to orchagent when enabled (same pattern as synchronous_mode)

How to verify it

Which release branch to backport (provide reason below if selected)

Tested branch (Please provide the tested image version)

Description for the changelog

Link to config_db schema for YANG module changes

A picture of a cute animal (not mandatory but encouraged)

This change needs to go together with
sonic-net/sonic-swss#4333
sonic-net/sonic-utilities#4361
sonic-net/sonic-mgmt#22916
sonic-net/SONiC#2335

mssonicbld · 2026-03-12T17:30:21Z

/azp run Azure.sonic-buildimage

azure-pipelines · 2026-03-12T17:30:34Z

Azure Pipelines successfully started running 1 pipeline(s).

mssonicbld · 2026-03-16T08:22:43Z

/azp run Azure.sonic-buildimage

azure-pipelines · 2026-03-16T08:22:56Z

Azure Pipelines successfully started running 1 pipeline(s).

mssonicbld · 2026-04-09T03:21:44Z

/azp run Azure.sonic-buildimage

azure-pipelines · 2026-04-09T03:21:55Z

Azure Pipelines successfully started running 1 pipeline(s).

mssonicbld · 2026-05-14T07:15:52Z

/azp run Azure.sonic-buildimage

azure-pipelines · 2026-05-14T07:16:06Z

Azure Pipelines successfully started running 1 pipeline(s).

amitg90

Please explain the expected behavior when this flag changes in CONFIG_DB.

mssonicbld · 2026-07-14T02:36:39Z

/azp run Azure.sonic-buildimage

azure-pipelines · 2026-07-14T02:36:50Z

Azure Pipelines successfully started running 1 pipeline(s).

deepak-singhal0408 · 2026-07-14T05:22:37Z

/azpw run Azure.sonic-buildimage

mssonicbld · 2026-07-14T05:22:40Z

⚠️ Notice: /azpw run only runs failed jobs now. If you want to trigger a whole pipline run, please rebase your branch or close and reopen the PR.
💡 Tip: You can also use /azpw retry to retry failed jobs directly.

Retrying failed(or canceled) jobs...

mssonicbld · 2026-07-14T08:00:02Z

/azp run Azure.sonic-buildimage

azure-pipelines · 2026-07-14T08:00:43Z

Azure Pipelines: Successfully started running 1 pipeline(s).

azure-pipelines · 2026-07-26T23:07:46Z

Azure Pipelines: Successfully started running 1 pipeline(s).

mssonicbld · 2026-07-28T19:00:49Z

/azp run Azure.sonic-buildimage

azure-pipelines · 2026-07-28T19:01:05Z

Azure Pipelines: Successfully started running 1 pipeline(s).

mssonicbld · 2026-07-29T20:29:44Z

/azp run Azure.sonic-buildimage

azure-pipelines · 2026-07-29T20:29:58Z

Azure Pipelines: Successfully started running 1 pipeline(s).

mssonicbld · 2026-07-31T18:15:13Z

/azp run Azure.sonic-buildimage

azure-pipelines · 2026-07-31T18:15:26Z

Azure Pipelines: Successfully started running 1 pipeline(s).

) 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  - [ ] Bug fix - [ ] Testbed and Framework(new/improvement) - [ ] New Test case - [ ] Skipped for non-supported platforms - [ ] Test case improvement ### Back port request - [ ] 202205 - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 ### 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  --------- Signed-off-by: mike-dubrovsky <mdubrovs@cisco.com>

mssonicbld · 2026-08-03T22:40:35Z

/azp run Azure.sonic-buildimage

azure-pipelines · 2026-08-03T22:40:41Z

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.

Read suppress-fib-pending from CONFIG_DB in orchagent.sh and pass -F to orchagent when enabled. Config changes take effect after swss restart or config reload. Changes: - orchagent.sh: read suppress-fib-pending from CONFIG_DB and set -F flag - src/sonic-swss: bump to 4f3dda15 (includes sonic-net#4333) - platform/vpp: bump to 77c75ab (includes sonic-net#270) Signed-off-by: mike-dubrovsky <mdubrovs@cisco.com>

mssonicbld · 2026-08-03T22:43:23Z

/azp run Azure.sonic-buildimage

azure-pipelines · 2026-08-03T22:43:35Z

Azure Pipelines: Successfully started running 1 pipeline(s).

…dynamic-toggle race (#1344) …gle race) **202608 backport** of [sonic-mgmt #26176](sonic-net/sonic-mgmt#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](sonic-net/sonic-mgmt#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 ### 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', '202608']" - "release in ['master'] and sonic-net/sonic-mgmt#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

…ub/sub (sonic-net#26151) What: orchagent.sh now reads suppress-fib-pending from CONFIG_DB and passes -F to orchagent when enabled (same pattern as synchronous_mode). Why: Route download speed degraded because RouteOrch::publishRouteState() unconditionally wrote to APPL_STATE_DB and sent pub/sub notifications on every route add/remove, even when FIB suppression was disabled. How: Part of a multi-repo change making this a startup-time flag; the flag is read from CONFIG_DB and passed to orchagent at startup. Testing: Approved by reviewers; Azure CI green (all required checks pass). Signed-off-by: mike-dubrovsky <mdubrovs@cisco.com> Signed-off-by: jackson-micas <jackson@micasnetworks.com>

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: Raghavendran Ramanathan <rraghav@cisco.com>

### Description of PR Summary: Prevent sanity-check recovery from masking unavailable BGP status details with `KeyError('bgp')`. When a BGP check fails without a `bgp` payload, adaptive recovery now selects `config_reload` while preserving the original BGP failure in the test log. Fixes # N/A ### Type of change - [x] Bug fix - [ ] Testbed and Framework(new/improvement) - [ ] New Test case - [ ] Skipped for non-supported platforms - [ ] Test case improvement ### Back port request - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 Tracking issue/work item for backport/cherry-pick request (GitHub issue or Microsoft ADO): N/A Failure type: regression ### Tested branch - [x] master - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 - [ ] N/A ### Test result - master: Python syntax, flake8, and diff checks passed for the updated recovery module. ### Approach #### What is the motivation for this PR? When `bgp_facts` is unavailable, the BGP sanity check marks the result as failed without adding a `bgp` detail payload. Adaptive recovery then indexes `result['bgp']`, raising `KeyError('bgp')` and hiding the original BGP or container failure. Representative Elastictest plans that exposed this failure: - [6a7df975e52f658a6c0dca34](https://elastictest.org/scheduler/testplan/6a7df975e52f658a6c0dca34) - t1-lag-vpp, buildimage PR [sonic-net#27061](sonic-net/sonic-buildimage#27061), 8 affected testbeds - [6a699606b63289adaeeedbe6](https://elastictest.org/scheduler/testplan/6a699606b63289adaeeedbe6) - t1-lag, buildimage PR [sonic-net#26151](sonic-net/sonic-buildimage#26151), 15 affected testbeds - [6a63ce94e05af08a4805ac27](https://elastictest.org/scheduler/testplan/6a63ce94e05af08a4805ac27) - t1-lag, buildimage PR [#28506](sonic-net/sonic-buildimage#28506), 17 affected testbeds Each plan failed in `test_pretest.py::test_recover_admin_up_offline_dpu_modules` with `KeyError('bgp')`, masking the underlying BGP or container failure. #### How did you do it? Extracted BGP recovery selection into `_recover_bgp`. Missing or empty BGP details now fall back to `config_reload`. Existing route re-announcement and neighbor restoration behavior remains unchanged when detailed BGP failure data is available. #### How did you verify/test it? Ran Python syntax, flake8, and diff checks against the updated recovery module. #### Any platform specific information? No. #### Supported testbed topology if it's a new test case? N/A. ### Documentation No documentation changes are required. --------- Signed-off-by: Austin (Ngoc Thang) Pham <austinpham@microsoft.com>

mike-dubrovsky requested a review from lguohan as a code owner March 12, 2026 17:30

mike-dubrovsky force-pushed the fib-supression branch from f4cc8be to a7876bf Compare March 16, 2026 08:22

mike-dubrovsky mentioned this pull request Mar 16, 2026

Inform user that reload is required after suppress-fib-pending change sonic-net/sonic-utilities#4361

Merged

mike-dubrovsky mentioned this pull request Apr 8, 2026

Bug: fib suppression performance improvement #26482

Closed

mike-dubrovsky force-pushed the fib-supression branch from a7876bf to 586edcb Compare April 9, 2026 03:21

mike-dubrovsky mentioned this pull request May 14, 2026

[doc] Update BGP suppress-fib-pending: config reload required to apply sonic-net/SONiC#2335

Merged

mike-dubrovsky force-pushed the fib-supression branch from 586edcb to b93762a Compare May 14, 2026 07:15

mike-dubrovsky changed the title ~~[orchagent] Pass FIB suppression flag and publish state to STATE_DB~~ [orchagent] Pass FIB suppression flag and to orchagent to control APPL_STATE_DB and pub/sub May 14, 2026

mike-dubrovsky changed the title ~~[orchagent] Pass FIB suppression flag and to orchagent to control APPL_STATE_DB and pub/sub~~ Pass FIB suppression flag and to orchagent to control APPL_STATE_DB and pub/sub May 14, 2026

amitg90 reviewed Jul 3, 2026

View reviewed changes

Comment thread dockers/docker-orchagent/orchagent.sh

mike-dubrovsky force-pushed the fib-supression branch from b93762a to ab4bbe7 Compare July 14, 2026 02:36

mike-dubrovsky force-pushed the fib-supression branch from ab4bbe7 to e8b689d Compare July 14, 2026 07:59

deepak-singhal0408 mentioned this pull request Jul 14, 2026

[bgp][test_bgp_suppress_fib] Whole module flaky on master & release branches — suppress-fib dynamic-toggle offload/propagation race sonic-net/sonic-mgmt#26175

Open

mike-dubrovsky force-pushed the fib-supression branch from d8152e9 to f61367a Compare July 28, 2026 19:00

mike-dubrovsky force-pushed the fib-supression branch from f61367a to 48c9a70 Compare July 29, 2026 20:29

mike-dubrovsky force-pushed the fib-supression branch from 48c9a70 to 8672cd7 Compare July 31, 2026 18:15

deepak-singhal0408 mentioned this pull request Aug 3, 2026

[submodule][master] Update submodule sonic-swss to the latest HEAD automatically #28777

Closed

deepak-singhal0408 previously approved these changes Aug 3, 2026

View reviewed changes

mike-dubrovsky dismissed deepak-singhal0408’s stale review via c481077 August 3, 2026 22:40

mike-dubrovsky force-pushed the fib-supression branch from 8672cd7 to c481077 Compare August 3, 2026 22:40

mike-dubrovsky force-pushed the fib-supression branch from c481077 to 5fb87ad Compare August 3, 2026 22:43

sdszhang mentioned this pull request Aug 4, 2026

[202608][PR:26176][bgp]: Skip test_bgp_suppress_fib for suppress-fib dynamic-toggle race Azure/sonic-mgmt.msft#1344

Merged

12 tasks

deepak-singhal0408 approved these changes Aug 4, 2026

View reviewed changes

yxieca merged commit c57e683 into sonic-net:master Aug 4, 2026
29 checks passed

github-project-automation Bot moved this from In Progress to Done in SONiC Routing Dashboard Aug 4, 2026

auspham mentioned this pull request Aug 31, 2026

fix(sanity): handle missing BGP recovery details sonic-net/sonic-mgmt#27224

Merged

21 tasks

Uh oh!

Conversation

mike-dubrovsky commented Mar 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Why I did it

Work item tracking

How I did it

How to verify it

Which release branch to backport (provide reason below if selected)

Tested branch (Please provide the tested image version)

Description for the changelog

Link to config_db schema for YANG module changes

A picture of a cute animal (not mandatory but encouraged)

Uh oh!

mssonicbld commented Mar 12, 2026

Uh oh!

azure-pipelines Bot commented Mar 12, 2026

Uh oh!

mssonicbld commented Mar 16, 2026

Uh oh!

azure-pipelines Bot commented Mar 16, 2026

Uh oh!

mssonicbld commented Apr 9, 2026

Uh oh!

azure-pipelines Bot commented Apr 9, 2026

Uh oh!

mssonicbld commented May 14, 2026

Uh oh!

azure-pipelines Bot commented May 14, 2026

Uh oh!

amitg90 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

mssonicbld commented Jul 14, 2026

Uh oh!

azure-pipelines Bot commented Jul 14, 2026

Uh oh!

deepak-singhal0408 commented Jul 14, 2026

Uh oh!

mssonicbld commented Jul 14, 2026

Uh oh!

mssonicbld commented Jul 14, 2026

Uh oh!

azure-pipelines Bot commented Jul 14, 2026

Uh oh!

azure-pipelines Bot commented Jul 26, 2026

Uh oh!

mssonicbld commented Jul 28, 2026

Uh oh!

azure-pipelines Bot commented Jul 28, 2026

Uh oh!

mssonicbld commented Jul 29, 2026

Uh oh!

azure-pipelines Bot commented Jul 29, 2026

Uh oh!

mssonicbld commented Jul 31, 2026

Uh oh!

azure-pipelines Bot commented Jul 31, 2026

Uh oh!

mssonicbld commented Aug 3, 2026

Uh oh!

azure-pipelines Bot commented Aug 3, 2026

Uh oh!

mssonicbld commented Aug 3, 2026

Uh oh!

azure-pipelines Bot commented Aug 3, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

mike-dubrovsky commented Mar 12, 2026 •

edited

Loading