Update SmartSwitch HA HLD by BYGX-wcr · Pull Request #2180 · sonic-net/SONiC

BYGX-wcr · 2026-01-12T18:55:01Z

Update HA HLD with a new state transition graph.

Related Code PRs:
sonic-net/sonic-dash-ha#145
sonic-net/sonic-dash-ha#155
sonic-net/sonic-dash-ha#156
sonic-net/sonic-dash-ha#157
sonic-net/sonic-dash-ha#159
sonic-net/sonic-dash-ha#160

Signed-off-by: BYGX-wcr <wcr@live.cn>

mssonicbld · 2026-01-12T18:55:10Z

/azp run

azure-pipelines · 2026-01-12T18:55:16Z

No pipelines are associated with this pull request.

zjswhhh · 2026-01-13T20:03:08Z

+Although the state machine is driven by HAmgrd running on the NPU, the health signals that triggers the unplanned state machine transition are still expected to be driven by the DPU.
+Specifically, we expect the DPU to perform the following two health monitoring mechanisms:
+1. DPU-to-DPU liveness probing: The data path and packet format of the DPU-to-DPU probe will be the same as the one defined in the main HA design doc. Please refer to the [DPU-to-DPU data plane channel design](./smart-switch-ha-hld.md#4352-dpu-to-dpu-data-plane-channel). Upon detecting remote DPU failure events, the local DPU should notify the local HAmgrd via [DASH SAI event notification API](https://github.com/opencomputeproject/SAI/blob/master/experimental/saiswitchextensions.h).
+2. DPU self health check: The DPU should monitor the health of itself and try to report failures via pmon if it can.


Can we add details about these health checkers? I.e. what exact DB entries are we checking?

The self-health check is meant to be implemented by the vendors. Yet, we certainly should define a uniform PMON messaging format.

zjswhhh · 2026-01-13T20:06:07Z

+
+The state transition graph for DPU-scope-NPU-driven HA is shown as below:
+
+<p align="center"><img alt="HA state transition" src="./images/dpu-scope-npu-driven-ha-state-transition.svg"></p>


Instead of wording like "problem detected", can we put in more details, i.e. PeerLost SAI notification?

Can we have a full picture of what exact events will trigger what transition?

Signed-off-by: BYGX-wcr <wcr@live.cn>

mssonicbld · 2026-01-13T22:42:51Z

/azp run

azure-pipelines · 2026-01-13T22:42:57Z

No pipelines are associated with this pull request.

Signed-off-by: BYGX-wcr <wcr@live.cn>

mssonicbld · 2026-01-14T22:07:24Z

/azp run

azure-pipelines · 2026-01-14T22:07:30Z

No pipelines are associated with this pull request.

Signed-off-by: BYGX-wcr <wcr@live.cn>

mssonicbld · 2026-01-14T22:26:20Z

/azp run

azure-pipelines · 2026-01-14T22:26:27Z

No pipelines are associated with this pull request.

…ents Signed-off-by: BYGX-wcr <wcr@live.cn>

mssonicbld · 2026-01-15T23:13:04Z

/azp run

azure-pipelines · 2026-01-15T23:13:10Z

No pipelines are associated with this pull request.

Signed-off-by: BYGX-wcr <wcr@live.cn>

mssonicbld · 2026-01-16T20:24:32Z

/azp run

azure-pipelines · 2026-01-16T20:24:39Z

No pipelines are associated with this pull request.

Signed-off-by: BYGX-wcr <wcr@live.cn>

mssonicbld · 2026-01-16T21:10:04Z

/azp run

azure-pipelines · 2026-01-16T21:10:10Z

No pipelines are associated with this pull request.

r12f · 2026-01-24T02:01:53Z


 Hence, to summarize, we are skipping designing ENI-level pipeline probe here.

+#### 6.3.3. Failure Notication


TOC is not updated.

r12f · 2026-01-24T02:03:38Z

+
+#### 7.2.2 State: Connecting
+
+- Iniate connections to the peer DPU


r12f · 2026-01-24T02:13:10Z

+
+- Iniate connections to the peer DPU
+- On successful connection to the peer DPU, transition to *Connected*
+- On connection failures, follow the standard procedure to transition to *Standalone*


we need to do retry here on connection failure.

r12f · 2026-01-24T02:42:17Z

+- On acquiring the voting result, perform the following state changes:
+	* transition to *InitializingToActive* if won the vote
+	* transition to *InitializingToStandby* if lost the vote
+- If failed to get the voting result, follow the standard procedure to transition to *Standalone*


replace standard procedure to transition to *Standalone* with [Entering standalone setup](#1014-entering-standalone-setup)

Standalone is a state. This will be misleading, as it could end up with state that is not standalone.

r12f · 2026-01-24T02:45:54Z

+- Listening for `PlannedSwitchover` and `PlannedShutdown`
+	* On receiving `PlannedSwitchover`, transition to *SwitchingToActive*
+	* On receiving `PlannedShutdown`, transition to *Destroying*
+- Listening for health signals


maybe we should just refer to unplanned events handling.

there can be many ways to fail unplanned.

if that is the case, there is no need to list this in every single item.

r12f · 2026-01-24T02:48:10Z

+- Request the approval to be active DPU from SDN controller
+- Wait until received the approval, transition to *Active*
+
+#### 7.2.7 State: PendingStandbyRoleActivation


also need to update the switch over and launch process below.

updated launch process. Not seen any changes needed in switchover.

zjswhhh · 2026-01-26T05:27:46Z


+#### 6.3.3. Failure Notication
+
+Although we let the vendors to design their own probing mechanism, we specify a uniform failure event notification interface: [DASH SAI event notification API](https://github.com/opencomputeproject/SAI/blob/master/experimental/saiswitchextensions.h). The health signal will be reflected in `dp_channel_is_alive` field in `DASH_HA_SET_STATE` table of `STATE_DB` (per-DPU).


It should be DPU_STATE_DB, instead of DPU's STATE_DB.

zjswhhh · 2026-01-26T05:42:18Z

 | Standalone | Heartbeat to pair is lost. Acting like a standalone setup. | Yes | Yes | Yes | Yes | No | No | Acting like the peer doesn’t exist, hence skip all data syncs. <br/><br/>However, the peer can be still connected, because in certain failure cases, we have to drive the DPU to standalone mode for mitigation. |
 | SwitchingToActive | Connected and preparing to switch over to active. | No | Yes | Yes | Yes | Yes | No | SwitchingToActive state is a transient state to help old active moving to standby, hence it accepts flow sync from old active, as well as making decision and sync flow back, when old active moved to standby.<br/><br/>Bulk sync is not used in SwitchOver at all. |
 | SwitchingToStandby | Connected, leaving active state and preparing to become standby. | Yes | Tunneled to pair | Tunneled to pair | Yes | No | No | SwitchingToStandby is a transient state to help new active moving from SwitchingToActive state to active state. It is identical to standby except responding NPU probe to tunneling traffic. This is needed to make sure we always only have 1 decider at any moment during the transition.<br/><br/>Bulk sync is not used in SwitchOver at all. |
+| PendingActiveRoleActivation | Connected, waiting for approval to become active. | No | Drop | Drop | No | No | No | PendingActiveRoleActivation is an intermediate state where we allow the SDN controller to block the DPU until the flow programming has been completed. |


Why InitializingToActive can init flow sync but PendingActiveRoleActivation can't?

According to the state transition, we enter PendingActiveRoleActivation from InitializingToActive when standby is ready. So it seems to be an even more advanced/ready state?

InitializingToActive can only initiate bulk sync. Initiating flow sync is only allowed in Active state.

mssonicbld · 2026-01-26T22:21:30Z

/azp run

azure-pipelines · 2026-01-26T22:21:37Z

No pipelines are associated with this pull request.

Signed-off-by: BYGX-wcr <wcr@live.cn>

mssonicbld · 2026-01-26T22:25:02Z

/azp run

azure-pipelines · 2026-01-26T22:25:08Z

No pipelines are associated with this pull request.

Signed-off-by: BYGX-wcr <wcr@live.cn>

mssonicbld · 2026-01-30T00:49:40Z

/azp run

azure-pipelines · 2026-01-30T00:49:47Z

No pipelines are associated with this pull request.

Signed-off-by: BYGX-wcr <wcr@live.cn>

mssonicbld · 2026-02-03T18:24:28Z

/azp run

azure-pipelines · 2026-02-03T18:24:35Z

No pipelines are associated with this pull request.

Signed-off-by: BYGX-wcr <wcr@live.cn>

mssonicbld · 2026-02-03T21:51:37Z

/azp run

azure-pipelines · 2026-02-03T21:51:43Z

No pipelines are associated with this pull request.

Signed-off-by: BYGX-wcr <wcr@live.cn>

mssonicbld · 2026-02-11T21:22:00Z

/azp run

azure-pipelines · 2026-02-11T21:22:06Z

No pipelines are associated with this pull request.

Signed-off-by: BYGX-wcr <wcr@live.cn>

mssonicbld · 2026-03-10T00:50:30Z

/azp run

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

No pipelines are associated with this pull request.

Signed-off-by: BYGX-wcr <wcr@live.cn>

mssonicbld · 2026-04-13T23:35:12Z

/azp run

azure-pipelines · 2026-04-13T23:35:19Z

No pipelines are associated with this pull request.

add dpu-scope npu-driven ha hld

1e6d0e3

Signed-off-by: BYGX-wcr <wcr@live.cn>

zjswhhh reviewed Jan 13, 2026

View reviewed changes

add the specification for health signals from DPUs

0cfc4c2

Signed-off-by: BYGX-wcr <wcr@live.cn>

add detailed state transition specifications

fc5db41

Signed-off-by: BYGX-wcr <wcr@live.cn>

add missing paths for planned shutdown

5048102

Signed-off-by: BYGX-wcr <wcr@live.cn>

Revise state transition graph and add more details about unplanned ev…

9cfe962

…ents Signed-off-by: BYGX-wcr <wcr@live.cn>

Merging the docs

0dff5b0

Signed-off-by: BYGX-wcr <wcr@live.cn>

fix incorrect content

38000cd

Signed-off-by: BYGX-wcr <wcr@live.cn>

BYGX-wcr changed the title ~~Add dpu-scope npu-driven HA HLD~~ Update SmartSwitch HA HLD Jan 16, 2026

r12f requested changes Jan 24, 2026

View reviewed changes

zjswhhh reviewed Jan 26, 2026

View reviewed changes

address comments and update launch process

9a9c81e

Signed-off-by: BYGX-wcr <wcr@live.cn>

BYGX-wcr force-pushed the NPU-driven-hamgrd branch from 61a83db to 9a9c81e Compare January 26, 2026 22:24

fix the launch process

6f24d09

Signed-off-by: BYGX-wcr <wcr@live.cn>

enrich content

c06412b

Signed-off-by: BYGX-wcr <wcr@live.cn>

BYGX-wcr added 2 commits February 3, 2026 13:49

fix 8.1.1 and 8.1.2

71750f9

Signed-off-by: BYGX-wcr <wcr@live.cn>

add missing field in HA detailed design HLD

2c4a4a6

Signed-off-by: BYGX-wcr <wcr@live.cn>

add ha_term in DASH_HA_SCOPE_TABLE

1b431bc

Signed-off-by: BYGX-wcr <wcr@live.cn>

Update the Standalone workflow

74407b0

Signed-off-by: BYGX-wcr <wcr@live.cn>

BYGX-wcr added 2 commits April 13, 2026 16:24

update usage for dp_channel_dst_port

8cece1a

Signed-off-by: BYGX-wcr <wcr@live.cn>

add Force Shutdown workflow description

899f60c

Signed-off-by: BYGX-wcr <wcr@live.cn>

zjswhhh approved these changes Apr 14, 2026

View reviewed changes

r12f approved these changes Apr 17, 2026

View reviewed changes

BYGX-wcr merged commit 5da3879 into sonic-net:master Apr 17, 2026
2 checks passed

BYGX-wcr deleted the NPU-driven-hamgrd branch April 17, 2026 20:36


		The state transition graph for DPU-scope-NPU-driven HA is shown as below:

		<p align="center"><img alt="HA state transition" src="./images/dpu-scope-npu-driven-ha-state-transition.svg"></p>


		Hence, to summarize, we are skipping designing ENI-level pipeline probe here.

		#### 6.3.3. Failure Notication


		#### 7.2.2 State: Connecting

		- Iniate connections to the peer DPU


		#### 6.3.3. Failure Notication

		Although we let the vendors to design their own probing mechanism, we specify a uniform failure event notification interface: [DASH SAI event notification API](https://github.com/opencomputeproject/SAI/blob/master/experimental/saiswitchextensions.h). The health signal will be reflected in `dp_channel_is_alive` field in `DASH_HA_SET_STATE` table of `STATE_DB` (per-DPU).

Conversation

BYGX-wcr commented Jan 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mssonicbld commented Jan 12, 2026

Uh oh!

azure-pipelines Bot commented Jan 12, 2026

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!

mssonicbld commented Jan 13, 2026

Uh oh!

azure-pipelines Bot commented Jan 13, 2026

Uh oh!

mssonicbld commented Jan 14, 2026

Uh oh!

azure-pipelines Bot commented Jan 14, 2026

Uh oh!

mssonicbld commented Jan 14, 2026

Uh oh!

azure-pipelines Bot commented Jan 14, 2026

Uh oh!

mssonicbld commented Jan 15, 2026

Uh oh!

azure-pipelines Bot commented Jan 15, 2026

Uh oh!

mssonicbld commented Jan 16, 2026

Uh oh!

azure-pipelines Bot commented Jan 16, 2026

Uh oh!

mssonicbld commented Jan 16, 2026

Uh oh!

azure-pipelines Bot commented Jan 16, 2026

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!

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zjswhhh Jan 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

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!

mssonicbld commented Jan 26, 2026

Uh oh!

BYGX-wcr commented Jan 12, 2026 •

edited

Loading

zjswhhh Jan 26, 2026 •

edited

Loading