[master][sonic-mgmt]Fix decap/test_subnet_decap.py::test_vlan_subnet_…#19061
Merged
StormLiangMS merged 1 commit intosonic-net:masterfrom Jul 2, 2025
Merged
Conversation
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
11 tasks
vvolam
pushed a commit
to vvolam/sonic-mgmt
that referenced
this pull request
Jul 3, 2025
…decap (sonic-net#19061) What is the motivation for this PR? Fixes failures for decap/test_subnet_decap::test_vlan_subnet_decap[negative-IPv4/6] for active-standby dualtor topos The test selects the DUT randomly, irrespective of it being the standby ToR In the positive case, this will not be a problem - the encapsulated packet is sent with an outer SIP that matches the config on the DUT, the packet gets decapped and gets routed towards the upstream T1s In the negative case, the outer SIP does not match the config on the DUT and hence will not be decapsulated, but forwarded to the outer DIP, which is set to IP 192.168.0.200/fc02:1000::200 This will require forwarding over one of the downstream ports where the ARP responder is also set up - if the DUT is a standby; this forwarding will not happen How did you do it? This fix calls the fixture to ensure the selected DUT will be the active ToR, and the non-decapsulated packet can be forwarded along the downstream port How did you verify/test it? Ran decap/test_subnet_decap.py on DCS-7050CX3
Collaborator
|
@pragnya-arista PR conflicts with 202505 branch |
Contributor
Author
I'll open a separate PR for 202505 |
11 tasks
Contributor
Author
Opened PR 19061 for 202505 |
yejianquan
added
Included in 202505 branch
and removed
Cherry Pick Conflict_202505
labels
nissampa
pushed a commit
to nissampa/sonic-mgmt_dpu_test
that referenced
this pull request
Aug 7, 2025
…decap (sonic-net#19061) What is the motivation for this PR? Fixes failures for decap/test_subnet_decap::test_vlan_subnet_decap[negative-IPv4/6] for active-standby dualtor topos The test selects the DUT randomly, irrespective of it being the standby ToR In the positive case, this will not be a problem - the encapsulated packet is sent with an outer SIP that matches the config on the DUT, the packet gets decapped and gets routed towards the upstream T1s In the negative case, the outer SIP does not match the config on the DUT and hence will not be decapsulated, but forwarded to the outer DIP, which is set to IP 192.168.0.200/fc02:1000::200 This will require forwarding over one of the downstream ports where the ARP responder is also set up - if the DUT is a standby; this forwarding will not happen How did you do it? This fix calls the fixture to ensure the selected DUT will be the active ToR, and the non-decapsulated packet can be forwarded along the downstream port How did you verify/test it? Ran decap/test_subnet_decap.py on DCS-7050CX3
ashutosh-agrawal
pushed a commit
to ashutosh-agrawal/sonic-mgmt
that referenced
this pull request
Aug 14, 2025
…decap (sonic-net#19061) What is the motivation for this PR? Fixes failures for decap/test_subnet_decap::test_vlan_subnet_decap[negative-IPv4/6] for active-standby dualtor topos The test selects the DUT randomly, irrespective of it being the standby ToR In the positive case, this will not be a problem - the encapsulated packet is sent with an outer SIP that matches the config on the DUT, the packet gets decapped and gets routed towards the upstream T1s In the negative case, the outer SIP does not match the config on the DUT and hence will not be decapsulated, but forwarded to the outer DIP, which is set to IP 192.168.0.200/fc02:1000::200 This will require forwarding over one of the downstream ports where the ARP responder is also set up - if the DUT is a standby; this forwarding will not happen How did you do it? This fix calls the fixture to ensure the selected DUT will be the active ToR, and the non-decapsulated packet can be forwarded along the downstream port How did you verify/test it? Ran decap/test_subnet_decap.py on DCS-7050CX3
vidyac86
pushed a commit
to vidyac86/sonic-mgmt
that referenced
this pull request
Oct 23, 2025
…decap (sonic-net#19061) What is the motivation for this PR? Fixes failures for decap/test_subnet_decap::test_vlan_subnet_decap[negative-IPv4/6] for active-standby dualtor topos The test selects the DUT randomly, irrespective of it being the standby ToR In the positive case, this will not be a problem - the encapsulated packet is sent with an outer SIP that matches the config on the DUT, the packet gets decapped and gets routed towards the upstream T1s In the negative case, the outer SIP does not match the config on the DUT and hence will not be decapsulated, but forwarded to the outer DIP, which is set to IP 192.168.0.200/fc02:1000::200 This will require forwarding over one of the downstream ports where the ARP responder is also set up - if the DUT is a standby; this forwarding will not happen How did you do it? This fix calls the fixture to ensure the selected DUT will be the active ToR, and the non-decapsulated packet can be forwarded along the downstream port How did you verify/test it? Ran decap/test_subnet_decap.py on DCS-7050CX3
opcoder0
pushed a commit
to opcoder0/sonic-mgmt
that referenced
this pull request
Dec 8, 2025
…decap (sonic-net#19061) What is the motivation for this PR? Fixes failures for decap/test_subnet_decap::test_vlan_subnet_decap[negative-IPv4/6] for active-standby dualtor topos The test selects the DUT randomly, irrespective of it being the standby ToR In the positive case, this will not be a problem - the encapsulated packet is sent with an outer SIP that matches the config on the DUT, the packet gets decapped and gets routed towards the upstream T1s In the negative case, the outer SIP does not match the config on the DUT and hence will not be decapsulated, but forwarded to the outer DIP, which is set to IP 192.168.0.200/fc02:1000::200 This will require forwarding over one of the downstream ports where the ARP responder is also set up - if the DUT is a standby; this forwarding will not happen How did you do it? This fix calls the fixture to ensure the selected DUT will be the active ToR, and the non-decapsulated packet can be forwarded along the downstream port How did you verify/test it? Ran decap/test_subnet_decap.py on DCS-7050CX3 Signed-off-by: opcoder0 <110003254+opcoder0@users.noreply.github.com>
gshemesh2
pushed a commit
to gshemesh2/sonic-mgmt
that referenced
this pull request
Dec 16, 2025
…decap (sonic-net#19061) What is the motivation for this PR? Fixes failures for decap/test_subnet_decap::test_vlan_subnet_decap[negative-IPv4/6] for active-standby dualtor topos The test selects the DUT randomly, irrespective of it being the standby ToR In the positive case, this will not be a problem - the encapsulated packet is sent with an outer SIP that matches the config on the DUT, the packet gets decapped and gets routed towards the upstream T1s In the negative case, the outer SIP does not match the config on the DUT and hence will not be decapsulated, but forwarded to the outer DIP, which is set to IP 192.168.0.200/fc02:1000::200 This will require forwarding over one of the downstream ports where the ARP responder is also set up - if the DUT is a standby; this forwarding will not happen How did you do it? This fix calls the fixture to ensure the selected DUT will be the active ToR, and the non-decapsulated packet can be forwarded along the downstream port How did you verify/test it? Ran decap/test_subnet_decap.py on DCS-7050CX3 Signed-off-by: Guy Shemesh <gshemesh@nvidia.com>
AharonMalkin
pushed a commit
to AharonMalkin/sonic-mgmt
that referenced
this pull request
Dec 16, 2025
…decap (sonic-net#19061) What is the motivation for this PR? Fixes failures for decap/test_subnet_decap::test_vlan_subnet_decap[negative-IPv4/6] for active-standby dualtor topos The test selects the DUT randomly, irrespective of it being the standby ToR In the positive case, this will not be a problem - the encapsulated packet is sent with an outer SIP that matches the config on the DUT, the packet gets decapped and gets routed towards the upstream T1s In the negative case, the outer SIP does not match the config on the DUT and hence will not be decapsulated, but forwarded to the outer DIP, which is set to IP 192.168.0.200/fc02:1000::200 This will require forwarding over one of the downstream ports where the ARP responder is also set up - if the DUT is a standby; this forwarding will not happen How did you do it? This fix calls the fixture to ensure the selected DUT will be the active ToR, and the non-decapsulated packet can be forwarded along the downstream port How did you verify/test it? Ran decap/test_subnet_decap.py on DCS-7050CX3 Signed-off-by: Aharon Malkin <amalkin@nvidia.com>
gshemesh2
pushed a commit
to gshemesh2/sonic-mgmt
that referenced
this pull request
Dec 21, 2025
…decap (sonic-net#19061) What is the motivation for this PR? Fixes failures for decap/test_subnet_decap::test_vlan_subnet_decap[negative-IPv4/6] for active-standby dualtor topos The test selects the DUT randomly, irrespective of it being the standby ToR In the positive case, this will not be a problem - the encapsulated packet is sent with an outer SIP that matches the config on the DUT, the packet gets decapped and gets routed towards the upstream T1s In the negative case, the outer SIP does not match the config on the DUT and hence will not be decapsulated, but forwarded to the outer DIP, which is set to IP 192.168.0.200/fc02:1000::200 This will require forwarding over one of the downstream ports where the ARP responder is also set up - if the DUT is a standby; this forwarding will not happen How did you do it? This fix calls the fixture to ensure the selected DUT will be the active ToR, and the non-decapsulated packet can be forwarded along the downstream port How did you verify/test it? Ran decap/test_subnet_decap.py on DCS-7050CX3 Signed-off-by: Guy Shemesh <gshemesh@nvidia.com>
venu-nexthop
pushed a commit
to venu-nexthop/sonic-mgmt
that referenced
this pull request
Jan 13, 2026
…decap (sonic-net#19061) What is the motivation for this PR? Fixes failures for decap/test_subnet_decap::test_vlan_subnet_decap[negative-IPv4/6] for active-standby dualtor topos The test selects the DUT randomly, irrespective of it being the standby ToR In the positive case, this will not be a problem - the encapsulated packet is sent with an outer SIP that matches the config on the DUT, the packet gets decapped and gets routed towards the upstream T1s In the negative case, the outer SIP does not match the config on the DUT and hence will not be decapsulated, but forwarded to the outer DIP, which is set to IP 192.168.0.200/fc02:1000::200 This will require forwarding over one of the downstream ports where the ARP responder is also set up - if the DUT is a standby; this forwarding will not happen How did you do it? This fix calls the fixture to ensure the selected DUT will be the active ToR, and the non-decapsulated packet can be forwarded along the downstream port How did you verify/test it? Ran decap/test_subnet_decap.py on DCS-7050CX3
gshemesh2
pushed a commit
to gshemesh2/sonic-mgmt
that referenced
this pull request
Jan 26, 2026
…decap (sonic-net#19061) What is the motivation for this PR? Fixes failures for decap/test_subnet_decap::test_vlan_subnet_decap[negative-IPv4/6] for active-standby dualtor topos The test selects the DUT randomly, irrespective of it being the standby ToR In the positive case, this will not be a problem - the encapsulated packet is sent with an outer SIP that matches the config on the DUT, the packet gets decapped and gets routed towards the upstream T1s In the negative case, the outer SIP does not match the config on the DUT and hence will not be decapsulated, but forwarded to the outer DIP, which is set to IP 192.168.0.200/fc02:1000::200 This will require forwarding over one of the downstream ports where the ARP responder is also set up - if the DUT is a standby; this forwarding will not happen How did you do it? This fix calls the fixture to ensure the selected DUT will be the active ToR, and the non-decapsulated packet can be forwarded along the downstream port How did you verify/test it? Ran decap/test_subnet_decap.py on DCS-7050CX3 Signed-off-by: Guy Shemesh <gshemesh@nvidia.com>
ytzur1
pushed a commit
to ytzur1/sonic-mgmt
that referenced
this pull request
Feb 2, 2026
…decap (sonic-net#19061) What is the motivation for this PR? Fixes failures for decap/test_subnet_decap::test_vlan_subnet_decap[negative-IPv4/6] for active-standby dualtor topos The test selects the DUT randomly, irrespective of it being the standby ToR In the positive case, this will not be a problem - the encapsulated packet is sent with an outer SIP that matches the config on the DUT, the packet gets decapped and gets routed towards the upstream T1s In the negative case, the outer SIP does not match the config on the DUT and hence will not be decapsulated, but forwarded to the outer DIP, which is set to IP 192.168.0.200/fc02:1000::200 This will require forwarding over one of the downstream ports where the ARP responder is also set up - if the DUT is a standby; this forwarding will not happen How did you do it? This fix calls the fixture to ensure the selected DUT will be the active ToR, and the non-decapsulated packet can be forwarded along the downstream port How did you verify/test it? Ran decap/test_subnet_decap.py on DCS-7050CX3 Signed-off-by: Yael Tzur <ytzur@nvidia.com>
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
5 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.
…decap
Description of PR
Summary:
Fixes # (591)
Type of change
Back port request
Approach
What is the motivation for this PR?
config on the DUT, the packet gets decapped and gets routed towards the upstream T1s
forwarded to the outer DIP, which is set to IP 192.168.0.200/fc02:1000::200
DUT is a standby; this forwarding will not happen
How did you do it?
This fix calls the fixture to ensure the selected DUT will be the active ToR, and the non-decapsulated packet can be
forwarded along the downstream port
How did you verify/test it?
Ran decap/test_subnet_decap.py on DCS-7050CX3
Any platform specific information?
Supported testbed topology if it's a new test case?
Documentation