Avoid nhgroup update when mux state changes#3822
Merged
prsunny merged 4 commits intosonic-net:masterfrom Nov 18, 2025
Merged
Conversation
Signed-off-by: Manas Kumar Mandal <[email protected]>
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
yxieca
pushed a commit
to Azure/sonic-swss.msft
that referenced
this pull request
Aug 13, 2025
Port PR sonic-net/sonic-swss#3822 NHGroup update is not required during mux state updates. When a mux neighbor in a ECMP NexthopGroup changes state to standby we point the prefix route originally pointing to the ECMP nexthop group to any available active neighbor NH or tunnel NH and the original ECMP nexthopgroup remains unused, so this update is useless and uncessarily takes extra SAI calls. This fix also avoid creation of nexthop group with a mix of different types of NextHops which will allow platform that do not support such nexthop groups. Signed-off-by: Manas Kumar Mandal <[email protected]>
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
zjswhhh
approved these changes
Nov 2, 2025
Contributor
|
@manamand2020 - please add proper labels for this PR. |
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Contributor
|
Hi @prsunny - can you help review and merge this please? |
prsunny
approved these changes
Nov 18, 2025
YairRaviv
pushed a commit
to YairRaviv/sonic-swss
that referenced
this pull request
Nov 22, 2025
What I did Avoided updating the NHGroup with mux neighbor nexthops during mux state updates. Why I did it When a mux neighbor in a ECMP NexthopGroup changes state to standby we point the prefix route originally pointing to the ECMP nexthop group to any available active neighbor NH or tunnel NH and the original ECMP nexthopgroup remains unused, so this update is useless and uncessarily takes extra SAI calls. This fix also avoid creation of nexthop group with a mix of different types of NextHops which will allow platform that do not support such nexthop groups.
Contributor
|
@manamand2020 I believe that this PR is causing dualtor tests on KVM single tor T0 to fail. See this run for an example. Can you take a look? |
yijingyan2
added a commit
to yijingyan2/sonic-swss
that referenced
this pull request
Dec 2, 2025
This reverts commit a4ed959.
Contributor
Author
Did not get a chance to run the management tests to see the exact reason here for the failure. But I think this seems to be happening because the neighbor remains in use inside the ECMP group due to this change while we try to remove the entry from disableneighbors() which throws this error. We should have some DVS test to cover this. |
prsunny
pushed a commit
that referenced
this pull request
Dec 4, 2025
kalash-nexthop
pushed a commit
to kalash-nexthop/sonic-swss
that referenced
this pull request
Dec 16, 2025
…sonic-net#4030) Reverts sonic-net#3822 This change is blocking sonic-swss submodule advance for 2 weeks. Signed-off-by: Kalash Nainwal <[email protected]>
Pterosaur
pushed a commit
to Janetxxx/sonic-swss
that referenced
this pull request
Jan 6, 2026
What I did Avoided updating the NHGroup with mux neighbor nexthops during mux state updates. Why I did it When a mux neighbor in a ECMP NexthopGroup changes state to standby we point the prefix route originally pointing to the ECMP nexthop group to any available active neighbor NH or tunnel NH and the original ECMP nexthopgroup remains unused, so this update is useless and uncessarily takes extra SAI calls. This fix also avoid creation of nexthop group with a mix of different types of NextHops which will allow platform that do not support such nexthop groups.
Pterosaur
pushed a commit
to Janetxxx/sonic-swss
that referenced
this pull request
Jan 6, 2026
…sonic-net#4030) Reverts sonic-net#3822 This change is blocking sonic-swss submodule advance for 2 weeks.
Pterosaur
pushed a commit
to Janetxxx/sonic-swss
that referenced
this pull request
Jan 6, 2026
What I did Avoided updating the NHGroup with mux neighbor nexthops during mux state updates. Why I did it When a mux neighbor in a ECMP NexthopGroup changes state to standby we point the prefix route originally pointing to the ECMP nexthop group to any available active neighbor NH or tunnel NH and the original ECMP nexthopgroup remains unused, so this update is useless and uncessarily takes extra SAI calls. This fix also avoid creation of nexthop group with a mix of different types of NextHops which will allow platform that do not support such nexthop groups.
Pterosaur
pushed a commit
to Janetxxx/sonic-swss
that referenced
this pull request
Jan 6, 2026
…sonic-net#4030) Reverts sonic-net#3822 This change is blocking sonic-swss submodule advance for 2 weeks.
yehjunying
pushed a commit
to yehjunying/sonic-swss
that referenced
this pull request
Jan 16, 2026
What I did Avoided updating the NHGroup with mux neighbor nexthops during mux state updates. Why I did it When a mux neighbor in a ECMP NexthopGroup changes state to standby we point the prefix route originally pointing to the ECMP nexthop group to any available active neighbor NH or tunnel NH and the original ECMP nexthopgroup remains unused, so this update is useless and uncessarily takes extra SAI calls. This fix also avoid creation of nexthop group with a mix of different types of NextHops which will allow platform that do not support such nexthop groups.
theasianpianist
pushed a commit
to theasianpianist/sonic-swss
that referenced
this pull request
Feb 4, 2026
What I did Avoided updating the NHGroup with mux neighbor nexthops during mux state updates. Why I did it When a mux neighbor in a ECMP NexthopGroup changes state to standby we point the prefix route originally pointing to the ECMP nexthop group to any available active neighbor NH or tunnel NH and the original ECMP nexthopgroup remains unused, so this update is useless and uncessarily takes extra SAI calls. This fix also avoid creation of nexthop group with a mix of different types of NextHops which will allow platform that do not support such nexthop groups. Signed-off-by: Lawrence Lee <[email protected]>
baorliu
pushed a commit
to baorliu/sonic-swss
that referenced
this pull request
Feb 23, 2026
What I did Avoided updating the NHGroup with mux neighbor nexthops during mux state updates. Why I did it When a mux neighbor in a ECMP NexthopGroup changes state to standby we point the prefix route originally pointing to the ECMP nexthop group to any available active neighbor NH or tunnel NH and the original ECMP nexthopgroup remains unused, so this update is useless and uncessarily takes extra SAI calls. This fix also avoid creation of nexthop group with a mix of different types of NextHops which will allow platform that do not support such nexthop groups. Signed-off-by: Baorong Liu <[email protected]>
baorliu
pushed a commit
to baorliu/sonic-swss
that referenced
this pull request
Feb 23, 2026
…sonic-net#4030) Reverts sonic-net#3822 This change is blocking sonic-swss submodule advance for 2 weeks. Signed-off-by: Baorong Liu <[email protected]>
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
6 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.
What I did
Avoided updating the NHGroup with mux neighbor nexthops during mux state updates.
Why I did it
When a mux neighbor in a ECMP NexthopGroup changes state to standby we point the prefix route originally pointing to the ECMP nexthop group to any available active neighbor NH or tunnel NH and the original ECMP nexthopgroup remains unused, so this update is useless and uncessarily takes extra SAI calls. This fix also avoid creation of nexthop group with a mix of different types of NextHops which will allow platform that do not support such nexthop groups.
How I verified it
Verified DVS tests and on hardware setup.
Details if related