Use the Inband Port's alias in getNeighborEntry to make Everflow mirror session active in remote Asics#4157
Merged
prsunny merged 9 commits intosonic-net:masterfrom Feb 12, 2026
Conversation
…s is Inband port Signed-off-by: saksarav <[email protected]>
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Contributor
Author
|
@arlakshm @saravanan-nexthop please review |
saksarav-nokia
changed the title
saksarav-nokia
changed the title
saravanan-nexthop
approved these changes
Jan 28, 2026
Contributor
saravanan-nexthop
left a comment
saravanan-nexthop
left a comment
There was a problem hiding this comment.
It will be good to have a swss test coverage for this use case
Contributor
Author
Yes. I will add a test and create a different PR. I want this PR to be merged since the entire everflow sonic-mgmt suite is broken for multi-asic VOQ without this fix. |
Contributor
Author
|
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Contributor
Author
|
@arlakshm , could you please review this PR |
arlakshm
approved these changes
Feb 2, 2026
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Contributor
Author
|
The PR checker failures are not due to my changes and i see the same failures in all other PR's. |
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Contributor
|
@prsunny please could you review/merge once build passes |
Contributor
Author
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
…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.
Contributor
|
@arlakshm it looks like we need this PR in 202511. |
Contributor
|
@vmittal-msft could you please check and approve this PR for 202511 ? |
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
8 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
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.
How I verified it
Ran the everflow sonic-mgmt tests and verified that they are passing with the fix
Details if related