Dualtor FRR support with hw NH Protection group by manamand2020 · Pull Request #2251 · sonic-net/SONiC

manamand2020 · 2026-03-02T23:40:21Z

Support for FRR(Fast ReRoute) in DualToR architecture using Hardware based protection nexthop group. This feature allows failover protection of MUX neighbors in hardware without the NOS involvement.

elated PRs and specs:

Repo	PR title	State
sonic-swss	Protection Nexthop Group Support
sonic-buildimage	MUX cable failover_mode Yang Model

mssonicbld · 2026-03-02T23:40:29Z

/azp run

azure-pipelines · 2026-03-02T23:40:36Z

No pipelines are associated with this pull request.

Signed-off-by: Manas Kumar Mandal <manamand@cisco.com>

mssonicbld · 2026-03-03T00:10:04Z

/azp run

azure-pipelines · 2026-03-03T00:10:10Z

No pipelines are associated with this pull request.

Signed-off-by: Manas Kumar Mandal <manamand@cisco.com>

mssonicbld · 2026-03-04T01:06:02Z

/azp run

azure-pipelines · 2026-03-04T01:06:08Z

No pipelines are associated with this pull request.

zjswhhh · 2026-03-11T05:13:07Z

+  * Backward compatible with existing software based switching. When **switching_mode** is set to **hardware** but the ASIC does not support nexthop protection groups, SONiC will fall back to normal software based switching transparently.
+  * Create nexthop protection group for FRR switchover based on the config.
+  * Maintain mapping of mux cable and ICMP echo session object id.
+  * The existing **state** field in App-DB MUX_CABLE_TBL is extended with two new values: **admin_active** and **admin_standby**. LinkMgrd will use these values for admin-initiated switching in both **normal** and **hardware** modes. Existing **active**/**standby** values continue to be used for link-state-driven switching, preserving backward compatibility with older LinkMgrd versions.


In hw switching mode, will linkmgrd initiated toggling take effect if it's not from admin state?

Meaning if linkmgrd writes "active", what will happen?

active and standby states are typically no-op for hardware based protection. Only admin state changes will acted upon by muxorch.

zjswhhh · 2026-03-11T05:21:04Z

+## 10. Future Enhancements
+
+### 10.1 Protection NHG Switchover Counters
+Per-port counters are not applicable for switchover observability because hardware protection switching monitors the ICMP offloaded session, not the physical port state. A new SAI specification will be proposed to define switchover counters scoped to the **SAI_NEXT_HOP_GROUP_TYPE_HW_PROTECTION** object, tracking successful switchover events per NHG. Note that a session state notification from the hardware does not imply a successful switchover; the counter will be incremented only on confirmed switchovers.


Will it be counters only or timestamp as well?

As of now switchover counters alone. We will have platform command to show timestamps. We need to see what we can propose for SAI wrt timestamps.

zjswhhh · 2026-03-11T05:23:56Z

+### 10.1 Protection NHG Switchover Counters
+Per-port counters are not applicable for switchover observability because hardware protection switching monitors the ICMP offloaded session, not the physical port state. A new SAI specification will be proposed to define switchover counters scoped to the **SAI_NEXT_HOP_GROUP_TYPE_HW_PROTECTION** object, tracking successful switchover events per NHG. Note that a session state notification from the hardware does not imply a successful switchover; the counter will be incremented only on confirmed switchovers.
+
+A `show mux switchover status` CLI will present these counters in a per-NHG summary, and a platform CLI will be added to show switchover timestamps for each event.


platform CL - switchover history is a bit important in livesite troubleshooting, we need have some more generic solution.

Understood, we will investigate how we can improve stats for troubleshooting.

zjswhhh · 2026-03-11T05:29:10Z

Is it nexhop group or nh protection group?

It is nexthop protection group.

zjswhhh · 2026-03-11T05:36:44Z

+
+> **Why not a separate ProtNhgOrch?** Protection NHGs for dual-ToR are tightly coupled to the mux neighbor lifecycle and don't need an independent APP_DB table. If a future non-mux use case arises, a ProtNhgOrch can inherit from NhgOrch without changing the protection NHG implementation itself.
+
+#### 7.1.2 MuxOrch


@Ndancejic - please help review 7.1.2 - 7.1.4

zjswhhh · 2026-03-11T05:42:56Z

+#### 7.1.5 IcmpOrch
+IcmpOrch will notify MuxOrch on ICMP session creation and deletion. On session creation, MuxOrch uses the session object id to program **SAI_NEXT_HOP_GROUP_MEMBER_ATTR_MONITORED_OBJECT** on the nexthop protection group member. On session deletion, MuxOrch clears the monitored object attribute so that the protection group member does not reference a stale session.
+
+#### 7.1.6 Debounce Handling


Take it as we don't backoff when there are continuous flaps, which does match today's linkmgrd behavior too. But with linkmgrd (software probing), we got a lot of false alarms and triggers mux flaps, perhaps it won't happen with hw probe that much, but something to think about.

It will currently behave the same way. However we can plan some enhancements to avoid this kind of flaps.

Signed-off-by: Manas Kumar Mandal <manamand@cisco.com>

mssonicbld · 2026-03-13T19:02:20Z

/azp run

azure-pipelines · 2026-03-13T19:02:27Z

No pipelines are associated with this pull request.

mssonicbld · 2026-03-13T19:08:37Z

/azp run

azure-pipelines · 2026-03-13T19:08:43Z

No pipelines are associated with this pull request.

Signed-off-by: Manas Kumar Mandal <manamand@cisco.com>

mssonicbld · 2026-03-13T19:53:08Z

/azp run

azure-pipelines · 2026-03-13T19:53:15Z

No pipelines are associated with this pull request.

Signed-off-by: Manas Kumar Mandal <manamand@cisco.com>

mssonicbld · 2026-03-13T20:08:52Z

/azp run

azure-pipelines · 2026-03-13T20:08:59Z

No pipelines are associated with this pull request.

Signed-off-by: Manas Kumar Mandal <manamand@cisco.com>

mssonicbld · 2026-03-13T23:35:39Z

/azp run

azure-pipelines · 2026-03-13T23:35:46Z

No pipelines are associated with this pull request.

Signed-off-by: Manas Kumar Mandal <manamand@cisco.com>

mssonicbld · 2026-03-16T20:10:01Z

/azp run

azure-pipelines · 2026-03-16T20:10:07Z

No pipelines are associated with this pull request.

prsunny · 2026-04-15T23:34:41Z

+- **Monitored ICMP session deletion:** If the monitored ICMP session is deleted while the nexthop protection group is active, the nexthop protection group member's monitored object attribute will become stale. MuxOrch should handle session deletion notifications from IcmpOrch and update or remove the monitored object attribute accordingly.
+- **Hardware protection switchover failure:** When a hardware-initiated switchover fails for one or more nexthop protection groups, SAI sends a bulk error notification identifying the failed NHGs. ProtNhgOrch processes this bulk notification and forwards the failure information to MuxOrch. MuxOrch then retries the switchover for the failed NHGs by setting **SAI_NEXT_HOP_GROUP_ATTR_ADMIN_ROLE** to force the transition via admin mode. If the admin-mode retry also fails, MuxOrch marks the switchover as failed and the neighbor state as inconsistent. This keeps the failure handling behavior consistent with software-based failover switching mode, where a failed switchover similarly results in an inconsistent neighbor state that requires operator intervention or a subsequent recovery event.
+
+## 13. Testing


Please elaborate on this section for all scenarios

Dualtor FRR support with hw NH Protection group

9e57f3f

Signed-off-by: Manas Kumar Mandal <manamand@cisco.com>

manamand2020 force-pushed the mux_hardware_switching branch from 69dec45 to 9e57f3f Compare March 3, 2026 00:09

Added new admin states

1c00ea5

Signed-off-by: Manas Kumar Mandal <manamand@cisco.com>

zjswhhh reviewed Mar 11, 2026

View reviewed changes

manamand2020 mentioned this pull request Mar 13, 2026

Added MUX cable failover_mode config sonic-net/sonic-buildimage#26172

Open

8 tasks

Added error handling for switching, changed config

ccc3fdc

Signed-off-by: Manas Kumar Mandal <manamand@cisco.com>

Fixed wording on NO_HOST_ROUTE ASIC requirement

86be6f6

Signed-off-by: Manas Kumar Mandal <manamand@cisco.com>

manamand2020 force-pushed the mux_hardware_switching branch from 2d1d3af to 86be6f6 Compare March 13, 2026 19:17

Modified the high level component diagram

4491237

Signed-off-by: Manas Kumar Mandal <manamand@cisco.com>

manamand2020 force-pushed the mux_hardware_switching branch from 90a6e14 to 4491237 Compare March 13, 2026 20:08

Modified link-state to ICMP session state

dbd7b71

Signed-off-by: Manas Kumar Mandal <manamand@cisco.com>

Config keyword modified to failover_mode

1fffd07

Signed-off-by: Manas Kumar Mandal <manamand@cisco.com>

manamand2020 mentioned this pull request Mar 25, 2026

Protection Nexthop group support in nhgorch sonic-net/sonic-swss#4390

Open

prsunny reviewed Apr 15, 2026

View reviewed changes

manamand2020 marked this pull request as ready for review June 2, 2026 18:11


		> Why not a separate ProtNhgOrch? Protection NHGs for dual-ToR are tightly coupled to the mux neighbor lifecycle and don't need an independent APP_DB table. If a future non-mux use case arises, a ProtNhgOrch can inherit from NhgOrch without changing the protection NHG implementation itself.

		#### 7.1.2 MuxOrch

Uh oh!

Conversation

manamand2020 commented Mar 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mssonicbld commented Mar 2, 2026

Uh oh!

azure-pipelines Bot commented Mar 2, 2026

Uh oh!

mssonicbld commented Mar 3, 2026

Uh oh!

azure-pipelines Bot commented Mar 3, 2026

Uh oh!

mssonicbld commented Mar 4, 2026

Uh oh!

azure-pipelines Bot commented Mar 4, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

mssonicbld commented Mar 13, 2026

Uh oh!

azure-pipelines Bot commented Mar 13, 2026

Uh oh!

mssonicbld commented Mar 13, 2026

Uh oh!

azure-pipelines Bot commented Mar 13, 2026

Uh oh!

mssonicbld commented Mar 13, 2026

Uh oh!

azure-pipelines Bot commented Mar 13, 2026

Uh oh!

mssonicbld commented Mar 13, 2026

Uh oh!

azure-pipelines Bot commented Mar 13, 2026

Uh oh!

mssonicbld commented Mar 13, 2026

Uh oh!

azure-pipelines Bot commented Mar 13, 2026

Uh oh!

mssonicbld commented Mar 16, 2026

Uh oh!

azure-pipelines Bot commented Mar 16, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

manamand2020 commented Mar 2, 2026 •

edited

Loading