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...

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 Signed-off-by: mike-dubrovsky <mdubrovs@cisco.com>

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).

deepak-singhal0408 · 2026-07-15T22:34:25Z

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

this was discussed in routing-wg and conclusion on behavior is captured here sonic-net/sonic-swss#4333 (comment) and in HLD PR.

#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>

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>

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>

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

Open

mike-dubrovsky mentioned this pull request Apr 8, 2026

Bug: fib suppression performance improvement #26482

Open

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 added this to SONiC Routing Dashboard Jul 15, 2026

github-project-automation Bot moved this to Todo in SONiC Routing Dashboard Jul 15, 2026

deepak-singhal0408 moved this from Todo to In Progress in SONiC Routing Dashboard Jul 15, 2026

deepak-singhal0408 assigned mike-dubrovsky Jul 15, 2026

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!

deepak-singhal0408 commented Jul 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

mike-dubrovsky commented Mar 12, 2026 •

edited

Loading

deepak-singhal0408 commented Jul 15, 2026 •

edited

Loading