[orchagent] support single ASIC VOQ Fixed-System#4054
Merged
prsunny merged 15 commits intosonic-net:masterfrom Jan 5, 2026
Merged
[orchagent] support single ASIC VOQ Fixed-System#4054prsunny merged 15 commits intosonic-net:masterfrom
prsunny merged 15 commits intosonic-net:masterfrom
Conversation
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
saravanan-nexthop
force-pushed
the
saravanan.isChassDb
branch
from
bf60c3f to
c1e1e95
Compare
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
saravanan-nexthop
force-pushed
the
saravanan.isChassDb
branch
from
c1e1e95 to
81aff04
Compare
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
saravanan-nexthop
force-pushed
the
saravanan.isChassDb
branch
from
81aff04 to
0f516ca
Compare
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
saravanan-nexthop
force-pushed
the
saravanan.isChassDb
branch
from
0f516ca to
0d4f24e
Compare
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
saravanan-nexthop
force-pushed
the
saravanan.isChassDb
branch
from
0d4f24e to
4ac595a
Compare
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Contributor
Author
|
Original PR3847 reviewers: @mlok-nokia @vganesan-nokia @prsunny @arlakshm |
arlakshm
reviewed
Dec 15, 2025
lakshmi-nexthop
added a commit
to lakshmi-nexthop/sonic-swss
that referenced
this pull request
Dec 16, 2025
Collaborator
|
/azp run |
saravanan-nexthop
force-pushed
the
saravanan.isChassDb
branch
from
fbe0646 to
5f9c91b
Compare
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
use m_intfsOrch->isRemoteSystemPortIntf(nexthop.alias) check inside NeighOrch::getNeighborEntry() instead of `gMySwitchType == voq` as the isRemoteSystemPortIntf is used in similar places for inband ports Signed-off-by: Saravanan Sellappa <[email protected]>
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Signed-off-by: Saravanan Sellappa <[email protected]>
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Contributor
Author
@arlakshm All checks are now passing |
arlakshm
approved these changes
Jan 5, 2026
Collaborator
|
Cherry-pick PR to 202511: #4105 |
mssonicbld
added
Included in 202511 Branch
and removed
Created PR to 202511 Branch
labels
arpit-nexthop
pushed a commit
to nexthop-ai/sonic-swss
that referenced
this pull request
Jan 21, 2026
What I did Orchagent changes needed to support single ASIC VOQ Fixed-System (sonic-net#3847) was reverted via (sonic-net#4035) because vms-kvm-t2 tests were failing. That was because the isChassisAppDbPresent() was using an incorrect path to database_config.json This PR brings back the original sonic-net#3847 and fixes the isChassisAppDbPresent() to use the correct path. Why I did it Single-asic VOQ systems do need sonic-net#3847
ganglyu
pushed a commit
to ganglyu/sonic-swss
that referenced
this pull request
Jan 26, 2026
What I did Orchagent changes needed to support single ASIC VOQ Fixed-System (sonic-net#3847) was reverted via (sonic-net#4035) because vms-kvm-t2 tests were failing. That was because the isChassisAppDbPresent() was using an incorrect path to database_config.json This PR brings back the original sonic-net#3847 and fixes the isChassisAppDbPresent() to use the correct path. Why I did it Single-asic VOQ systems do need sonic-net#3847 Signed-off-by: ganglyu <[email protected]>
prsunny
pushed a commit
that referenced
this pull request
Feb 12, 2026
…s is Inband port (#4157) What I did Fixed the bug reported in sonic-net/sonic-buildimage#25211 Fixed the bug introduced in #4054 which was preventing the ever flow mirror sessions becoming active in remote Asics. When the nexthop is added in remote asics in Voq systems, it is always added against the Inband port and not on the remote system port. So when the nexthop is resolved for the mirror session in the remote asic, the mirror code calls getNeighborEntry to find the nexthop entry by passing the nexthop of the route entry for the mirror destination. Since the nexthop was added on Inband port and getNeighborEntry was checking for RemoteSystemPort, finding nexthop was failing and hence the mirror session never gets activated in remote asics. So modified the code to include the isInbandPort check in addition to isRemoteSystemPortIntf . The isRemoteSystemPortIntf might be needed since the neighbor entries are added against the remote system port. Why I did it Fixed the bug introduced in #4054 which prevents the ever flow mirror sessions becoming active in remote Asics. When the nexthop is added in remote asics in Voq systems, it is always added against the Inband port and not on the remote system port. So when the nexthop is resolved for the mirror session in the remote asic, the mirror code calls getNeighborEntry to find the nexthop entry by passing the nexthop of the route entry for the mirror destination. Since the nexthop was added on Inband port and getNeighborEntry was checking for RemoteSystemPort, finding nexthop was failing and hence the mirror session never gets activated in remote asics. So modified the code to include the isInbandPort check in addition to isRemoteSystemPortIntf . The isRemoteSystemPortIntf might be needed since the neighbor entries are added against the remote system port.
jithenderkondam
pushed a commit
to jithenderkondam/sonic-swss
that referenced
this pull request
Feb 17, 2026
…s is Inband port (sonic-net#4157) What I did Fixed the bug reported in sonic-net/sonic-buildimage#25211 Fixed the bug introduced in sonic-net#4054 which was preventing the ever flow mirror sessions becoming active in remote Asics. When the nexthop is added in remote asics in Voq systems, it is always added against the Inband port and not on the remote system port. So when the nexthop is resolved for the mirror session in the remote asic, the mirror code calls getNeighborEntry to find the nexthop entry by passing the nexthop of the route entry for the mirror destination. Since the nexthop was added on Inband port and getNeighborEntry was checking for RemoteSystemPort, finding nexthop was failing and hence the mirror session never gets activated in remote asics. So modified the code to include the isInbandPort check in addition to isRemoteSystemPortIntf . The isRemoteSystemPortIntf might be needed since the neighbor entries are added against the remote system port. Why I did it Fixed the bug introduced in sonic-net#4054 which prevents the ever flow mirror sessions becoming active in remote Asics. When the nexthop is added in remote asics in Voq systems, it is always added against the Inband port and not on the remote system port. So when the nexthop is resolved for the mirror session in the remote asic, the mirror code calls getNeighborEntry to find the nexthop entry by passing the nexthop of the route entry for the mirror destination. Since the nexthop was added on Inband port and getNeighborEntry was checking for RemoteSystemPort, finding nexthop was failing and hence the mirror session never gets activated in remote asics. So modified the code to include the isInbandPort check in addition to isRemoteSystemPortIntf . The isRemoteSystemPortIntf might be needed since the neighbor entries are added against the remote system port.
ksravani-hcl
pushed a commit
to ksravani-hcl/sonic-swss
that referenced
this pull request
Feb 20, 2026
…s is Inband port (sonic-net#4157) What I did Fixed the bug reported in sonic-net/sonic-buildimage#25211 Fixed the bug introduced in sonic-net#4054 which was preventing the ever flow mirror sessions becoming active in remote Asics. When the nexthop is added in remote asics in Voq systems, it is always added against the Inband port and not on the remote system port. So when the nexthop is resolved for the mirror session in the remote asic, the mirror code calls getNeighborEntry to find the nexthop entry by passing the nexthop of the route entry for the mirror destination. Since the nexthop was added on Inband port and getNeighborEntry was checking for RemoteSystemPort, finding nexthop was failing and hence the mirror session never gets activated in remote asics. So modified the code to include the isInbandPort check in addition to isRemoteSystemPortIntf . The isRemoteSystemPortIntf might be needed since the neighbor entries are added against the remote system port. Why I did it Fixed the bug introduced in sonic-net#4054 which prevents the ever flow mirror sessions becoming active in remote Asics. When the nexthop is added in remote asics in Voq systems, it is always added against the Inband port and not on the remote system port. So when the nexthop is resolved for the mirror session in the remote asic, the mirror code calls getNeighborEntry to find the nexthop entry by passing the nexthop of the route entry for the mirror destination. Since the nexthop was added on Inband port and getNeighborEntry was checking for RemoteSystemPort, finding nexthop was failing and hence the mirror session never gets activated in remote asics. So modified the code to include the isInbandPort check in addition to isRemoteSystemPortIntf . The isRemoteSystemPortIntf might be needed since the neighbor entries are added against the remote system port.
baorliu
pushed a commit
to baorliu/sonic-swss
that referenced
this pull request
Feb 23, 2026
What I did Orchagent changes needed to support single ASIC VOQ Fixed-System (sonic-net#3847) was reverted via (sonic-net#4035) because vms-kvm-t2 tests were failing. That was because the isChassisAppDbPresent() was using an incorrect path to database_config.json This PR brings back the original sonic-net#3847 and fixes the isChassisAppDbPresent() to use the correct path. Why I did it Single-asic VOQ systems do need sonic-net#3847 Signed-off-by: Baorong Liu <[email protected]>
baorliu
pushed a commit
to baorliu/sonic-swss
that referenced
this pull request
Feb 23, 2026
…s is Inband port (sonic-net#4157) What I did Fixed the bug reported in sonic-net/sonic-buildimage#25211 Fixed the bug introduced in sonic-net#4054 which was preventing the ever flow mirror sessions becoming active in remote Asics. When the nexthop is added in remote asics in Voq systems, it is always added against the Inband port and not on the remote system port. So when the nexthop is resolved for the mirror session in the remote asic, the mirror code calls getNeighborEntry to find the nexthop entry by passing the nexthop of the route entry for the mirror destination. Since the nexthop was added on Inband port and getNeighborEntry was checking for RemoteSystemPort, finding nexthop was failing and hence the mirror session never gets activated in remote asics. So modified the code to include the isInbandPort check in addition to isRemoteSystemPortIntf . The isRemoteSystemPortIntf might be needed since the neighbor entries are added against the remote system port. Why I did it Fixed the bug introduced in sonic-net#4054 which prevents the ever flow mirror sessions becoming active in remote Asics. When the nexthop is added in remote asics in Voq systems, it is always added against the Inband port and not on the remote system port. So when the nexthop is resolved for the mirror session in the remote asic, the mirror code calls getNeighborEntry to find the nexthop entry by passing the nexthop of the route entry for the mirror destination. Since the nexthop was added on Inband port and getNeighborEntry was checking for RemoteSystemPort, finding nexthop was failing and hence the mirror session never gets activated in remote asics. So modified the code to include the isInbandPort check in addition to isRemoteSystemPortIntf . The isRemoteSystemPortIntf might be needed since the neighbor entries are added against the remote system port. Signed-off-by: Baorong Liu <[email protected]>
ksravani-hcl
pushed a commit
to ksravani-hcl/sonic-swss
that referenced
this pull request
Feb 24, 2026
…s is Inband port (sonic-net#4157) What I did Fixed the bug reported in sonic-net/sonic-buildimage#25211 Fixed the bug introduced in sonic-net#4054 which was preventing the ever flow mirror sessions becoming active in remote Asics. When the nexthop is added in remote asics in Voq systems, it is always added against the Inband port and not on the remote system port. So when the nexthop is resolved for the mirror session in the remote asic, the mirror code calls getNeighborEntry to find the nexthop entry by passing the nexthop of the route entry for the mirror destination. Since the nexthop was added on Inband port and getNeighborEntry was checking for RemoteSystemPort, finding nexthop was failing and hence the mirror session never gets activated in remote asics. So modified the code to include the isInbandPort check in addition to isRemoteSystemPortIntf . The isRemoteSystemPortIntf might be needed since the neighbor entries are added against the remote system port. Why I did it Fixed the bug introduced in sonic-net#4054 which prevents the ever flow mirror sessions becoming active in remote Asics. When the nexthop is added in remote asics in Voq systems, it is always added against the Inband port and not on the remote system port. So when the nexthop is resolved for the mirror session in the remote asic, the mirror code calls getNeighborEntry to find the nexthop entry by passing the nexthop of the route entry for the mirror destination. Since the nexthop was added on Inband port and getNeighborEntry was checking for RemoteSystemPort, finding nexthop was failing and hence the mirror session never gets activated in remote asics. So modified the code to include the isInbandPort check in addition to isRemoteSystemPortIntf . The isRemoteSystemPortIntf might be needed since the neighbor entries are added against the remote system port.
ksravani-hcl
pushed a commit
to ksravani-hcl/sonic-swss
that referenced
this pull request
Feb 25, 2026
…s is Inband port (sonic-net#4157) What I did Fixed the bug reported in sonic-net/sonic-buildimage#25211 Fixed the bug introduced in sonic-net#4054 which was preventing the ever flow mirror sessions becoming active in remote Asics. When the nexthop is added in remote asics in Voq systems, it is always added against the Inband port and not on the remote system port. So when the nexthop is resolved for the mirror session in the remote asic, the mirror code calls getNeighborEntry to find the nexthop entry by passing the nexthop of the route entry for the mirror destination. Since the nexthop was added on Inband port and getNeighborEntry was checking for RemoteSystemPort, finding nexthop was failing and hence the mirror session never gets activated in remote asics. So modified the code to include the isInbandPort check in addition to isRemoteSystemPortIntf . The isRemoteSystemPortIntf might be needed since the neighbor entries are added against the remote system port. Why I did it Fixed the bug introduced in sonic-net#4054 which prevents the ever flow mirror sessions becoming active in remote Asics. When the nexthop is added in remote asics in Voq systems, it is always added against the Inband port and not on the remote system port. So when the nexthop is resolved for the mirror session in the remote asic, the mirror code calls getNeighborEntry to find the nexthop entry by passing the nexthop of the route entry for the mirror destination. Since the nexthop was added on Inband port and getNeighborEntry was checking for RemoteSystemPort, finding nexthop was failing and hence the mirror session never gets activated in remote asics. So modified the code to include the isInbandPort check in addition to isRemoteSystemPortIntf . The isRemoteSystemPortIntf might be needed since the neighbor entries are added against the remote system port.
ksravani-hcl
pushed a commit
to ksravani-hcl/sonic-swss
that referenced
this pull request
Feb 26, 2026
…s is Inband port (sonic-net#4157) What I did Fixed the bug reported in sonic-net/sonic-buildimage#25211 Fixed the bug introduced in sonic-net#4054 which was preventing the ever flow mirror sessions becoming active in remote Asics. When the nexthop is added in remote asics in Voq systems, it is always added against the Inband port and not on the remote system port. So when the nexthop is resolved for the mirror session in the remote asic, the mirror code calls getNeighborEntry to find the nexthop entry by passing the nexthop of the route entry for the mirror destination. Since the nexthop was added on Inband port and getNeighborEntry was checking for RemoteSystemPort, finding nexthop was failing and hence the mirror session never gets activated in remote asics. So modified the code to include the isInbandPort check in addition to isRemoteSystemPortIntf . The isRemoteSystemPortIntf might be needed since the neighbor entries are added against the remote system port. Why I did it Fixed the bug introduced in sonic-net#4054 which prevents the ever flow mirror sessions becoming active in remote Asics. When the nexthop is added in remote asics in Voq systems, it is always added against the Inband port and not on the remote system port. So when the nexthop is resolved for the mirror session in the remote asic, the mirror code calls getNeighborEntry to find the nexthop entry by passing the nexthop of the route entry for the mirror destination. Since the nexthop was added on Inband port and getNeighborEntry was checking for RemoteSystemPort, finding nexthop was failing and hence the mirror session never gets activated in remote asics. So modified the code to include the isInbandPort check in addition to isRemoteSystemPortIntf . The isRemoteSystemPortIntf might be needed since the neighbor entries are added against the remote system port.
ksravani-hcl
pushed a commit
to ksravani-hcl/sonic-swss
that referenced
this pull request
Feb 27, 2026
…s is Inband port (sonic-net#4157) What I did Fixed the bug reported in sonic-net/sonic-buildimage#25211 Fixed the bug introduced in sonic-net#4054 which was preventing the ever flow mirror sessions becoming active in remote Asics. When the nexthop is added in remote asics in Voq systems, it is always added against the Inband port and not on the remote system port. So when the nexthop is resolved for the mirror session in the remote asic, the mirror code calls getNeighborEntry to find the nexthop entry by passing the nexthop of the route entry for the mirror destination. Since the nexthop was added on Inband port and getNeighborEntry was checking for RemoteSystemPort, finding nexthop was failing and hence the mirror session never gets activated in remote asics. So modified the code to include the isInbandPort check in addition to isRemoteSystemPortIntf . The isRemoteSystemPortIntf might be needed since the neighbor entries are added against the remote system port. Why I did it Fixed the bug introduced in sonic-net#4054 which prevents the ever flow mirror sessions becoming active in remote Asics. When the nexthop is added in remote asics in Voq systems, it is always added against the Inband port and not on the remote system port. So when the nexthop is resolved for the mirror session in the remote asic, the mirror code calls getNeighborEntry to find the nexthop entry by passing the nexthop of the route entry for the mirror destination. Since the nexthop was added on Inband port and getNeighborEntry was checking for RemoteSystemPort, finding nexthop was failing and hence the mirror session never gets activated in remote asics. So modified the code to include the isInbandPort check in addition to isRemoteSystemPortIntf . The isRemoteSystemPortIntf might be needed since the neighbor entries are added against the remote system port.
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
13 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
Orchagent changes needed to support single ASIC VOQ Fixed-System (#3847) was reverted via (#4035) because
vms-kvm-t2 tests were failing.
That was because the
isChassisAppDbPresent()was using an incorrect path todatabase_config.jsonThis PR brings back the original #3847 and fixes the
isChassisAppDbPresent()to use the correct path.Why I did it
Single-asic VOQ systems do need #3847
How I verified it
Tests on vms-kvm-t2 and also single-asic voq systems
Verified on vms-kvm-t2 the test_bgp_fact is passing
Details if related