Adapting fib test for T2 topology #3135
Merged
Conversation
This file contains 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
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
@wangxin, would you know how to get this reviewed by "sonic-fundamentals"? |
wangxin
reviewed
Apr 9, 2021
oxygen980
force-pushed
the
fib_new
branch
2 times, most recently
from
1261bd1
to
12e9fee
Compare
saravanansv
reviewed
Apr 12, 2021
tests/fib/test_fib.py
Outdated
| timestamp = datetime.now().strftime('%Y-%m-%d-%H:%M:%S') | ||
| duthost.shell("redis-dump -d 0 -k 'ROUTE*' -y > /tmp/fib.{}.txt".format(timestamp)) | ||
| duthost.fetch(src="/tmp/fib.{}.txt".format(timestamp), dest="/tmp/fib") | ||
| with open("/tmp/fib/{}/tmp/fib.{}.txt".format(duthost.hostname, timestamp)) as fp: |
There was a problem hiding this comment.
should this be /tmp/fib/{}/tmp/fib.{}.txt ? tmp/fib is repeating twice
There was a problem hiding this comment.
The fetch command with take /tmp/fibxxx.txt from DUT and put it under /tmp/fib/<dut.hostname>/tmp/fibxxx.txt. This is the same logic used in get_fib_info for t1/t0 setups.
tests/fib/test_fib.py
Outdated
Comment on lines
82
to
86
| if prefix.startswith('10.0.0') or prefix.startswith('100.1.0'): | ||
| continue | ||
| # Ignore directly connected IPv6 networks | ||
| if prefix.startswith('2064:100') or prefix.startswith("fc00::"): | ||
| continue |
There was a problem hiding this comment.
is there a simpler check like nh being empty and only the intf is valid for directly connected routes ?
There was a problem hiding this comment.
We have pushed a commit to check this based on the nexthop
wangxin
reviewed
Apr 15, 2021
| exp_src_mac = self.router_macs[self.ptf_test_port_map[str(dst_port_list[rcvd_port])]['target_dut']] | ||
| actual_src_mac = Ether(rcvd_pkt).src | ||
| if exp_src_mac != actual_src_mac: | ||
| logging.warn( |
There was a problem hiding this comment.
Similar concern here, why generate warning rather than fail the test?
| exp_src_mac = self.router_macs[self.ptf_test_port_map[str(dst_port_list[rcvd_port])]['target_dut']] | ||
| actual_src_mac = Ether(rcvd_pkt).src | ||
| if exp_src_mac != actual_src_mac: | ||
| logging.warn( |
There was a problem hiding this comment.
Similar concern here, why generate warning rather than fail the test?
|
This pull request introduces 2 alerts when merging 8fa3b64 into 94ffb11 - view on LGTM.com new alerts:
|
wangxin
approved these changes
Apr 16, 2021
|
This is broken with the change to 'config_facts' fixture introduced by PR #3214. Am working on a fix as well support for multi-asic linecards. Please hold off the review. |
added 5 commits
May 3, 2021 14:15
Even though a T2 chassis has multiple DUTs (linecards), we have a single PTF instance that has all the injected ptf ports that connect to all the DUTs frontpanel ports. For the fib test, the src port and the expected rcv ports are from this list of all the injected ptf ports. In a T2 chassis, we have multiple linecards, and routes learnt from a linecard are distributed over the fabric to the other linecards. But, the fib on the other linecards points to the inband recyle port Ethernet-IB0. Therefore, when generating the fib_info_file for the linecards, if the route is learned over the inband recyle port, we have to figure out which other linecard this route was learnt on, and use its frontpanel ports as the outgoing ports for this route. Since a route learnt across the fabric will have an outgoing port on another linecard, and this route could be learnt from multiple linecards (as is the case with routes announced from T1 VMs in a T2 topology), the logic to validate the src_mac of the received packet in fib_test/hash_test has been modified to not check for the src_mac in the expected packet for the verify_packet_any_port call. The src mac is compared to the target_mac defined in ptf_test_port_map.json for the dut that has the rcvd_port.
- Remove t0-52 from supported topology in test_fib as per review comment - raise Exception if src mac of rcvd packet doesn't match the expected src mac, instead of logging an error message
…ed interfaces/peers
added 2 commits
May 3, 2021 14:15
… (multi-dut)
In a T2 chassis, we have multiple linecards, and routes learnt from a linecard are distributed over the fabric to the other linecards.
But, the fib on the other linecards points to the internal inband recyle port. Therefore, when generating the fib_info_file
we follow the following rules while iterating over all the asics in all the linecards.
- If the nexthop interface for a prefix is an 'internal' port (role in cfg facts is 'int'), then we ignore the route. On at-least one of the linecards
this prefix would have the nexthop interface as a frontpanel port, and those are the ports that the packet is going to get forwarded to, regardless
of which linecard the packet ingresses the chassis. This is similar approach to what is done for the multi-asic support where routes learnt over the
backplane interfaces are ignored on a asic.
- Treat the whole chassis as a single DUT, ie. generate a single file for all the linecards instead of one for each linecard. This file would have
all the routes learnt from any of the frontpanel ports on any asic on any linecard, Then, we run the ptf fib test through this file.
- For this added 'single_fib_for_duts' variable to the ptf fib_test. We need this as the existing ptf_test_port_map and router_macs still are being
treated as a multi-dut testbed for a VoQ chassis.
Also, since a route learnt across the fabric will have an outgoing port on another linecard, and this route could be learnt from multiple
linecards (as is the case with routes announced from T1 VMs in a T2 topology), the logic to validate the src_mac of the received
packet in fib_test/hash_test has been modified to not check for the src_mac in the expected packet for the verify_packet_any_port
call. The src mac is compared to the target_mac defined in ptf_test_port_map.json for the dut that has the rcvd_port. If it doesn't
match then we fail.
|
@wangxin, @arlakshm or @rlhui, @saravanansv - we have followed the same logic as being used in the multi-asic pizza box to now make the code much more simpler. Kindly request that you please review the changes once again. |
saravanansv
pushed a commit
to saravanansv/sonic-mgmt
that referenced
this pull request
May 6, 2021
What is the motivation for this PR? Need to make the FIB tests work against a T2 chassis. How did you do it? Even though a T2 chassis has multiple DUTs (linecards), we have a single PTF instance that has all the injected ptf ports that connect to all the DUTs frontpanel ports. For the fib test, the src port and the expected rcv ports are from this list of all the injected ptf ports. In a T2 chassis, we have multiple linecards, and routes learnt from a linecard are distributed over the fabric to the other linecards. But, the fib on the other linecards points to the inband recyle port Ethernet-IB0. Therefore, when generating the fib_info_file for the linecards, if the route is learned over the inband recyle port, we have to figure out which other linecard this route was learnt on, and use its frontpanel ports as the outgoing ports for this route. Since a route learnt across the fabric will have an outgoing port on another linecard, and this route could be learnt from multiple linecards (as is the case with routes announced from T1 VMs in a T2 topology), the logic to validate the src_mac of the received packet in fib_test/hash_test has been modified to not check for the src_mac in the expected packet for the verify_packet_any_port call. The src mac is compared to the target_mac defined in ptf_test_port_map.json for the dut that has the rcvd_port. If it doesn't match then we fail. How did you verify/test it? Tested against a T2 chassis.
bingwang-ms
pushed a commit
to bingwang-ms/sonic-mgmt
that referenced
this pull request
Aug 18, 2021
We are migrating from Jenkins to azure pipeline. This PR added azure pipeline yaml files and dependent template files for nightly tests. Pipeline yaml files only added for 3 testbeds yet. The pipelines were originally added to branch azp-test of repo https://dev.azure.com/mssonic/internal/_git/sonic-mgmt-int. They have been tested on Azure DevOps. Now we formally add these pipelines to the Networking-acs-sonic-mgmt repo. Currently the internal branch of Networking-acs-sonic-mgmt is synched to same internal branch of the sonic-mgmt-int repo. After this PR is merged, we need to update configuration of the created pipelines to formally use these files from the internal branch. If the pipelines work fine with yaml files from internal branch, we will create more pipeline files based on current templates for rest of the nightly testbeds. Related work items: sonic-net#3021, sonic-net#3073, sonic-net#3135, sonic-net#3153, sonic-net#3162, sonic-net#3176, sonic-net#3238, sonic-net#3241, sonic-net#3346, sonic-net#3352, sonic-net#3378, sonic-net#3389, sonic-net#3395, sonic-net#3397, sonic-net#3398, sonic-net#3407, sonic-net#3410, sonic-net#3411, sonic-net#3412, sonic-net#3413, sonic-net#3414, sonic-net#3415, sonic-net#3434, sonic-net#3437, sonic-net#3445, sonic-net#3446, sonic-net#3447, #9740131, #9821349
vmittal-msft
pushed a commit
to vmittal-msft/sonic-mgmt
that referenced
this pull request
Sep 28, 2021
What is the motivation for this PR? Need to make the FIB tests work against a T2 chassis. How did you do it? Even though a T2 chassis has multiple DUTs (linecards), we have a single PTF instance that has all the injected ptf ports that connect to all the DUTs frontpanel ports. For the fib test, the src port and the expected rcv ports are from this list of all the injected ptf ports. In a T2 chassis, we have multiple linecards, and routes learnt from a linecard are distributed over the fabric to the other linecards. But, the fib on the other linecards points to the inband recyle port Ethernet-IB0. Therefore, when generating the fib_info_file for the linecards, if the route is learned over the inband recyle port, we have to figure out which other linecard this route was learnt on, and use its frontpanel ports as the outgoing ports for this route. Since a route learnt across the fabric will have an outgoing port on another linecard, and this route could be learnt from multiple linecards (as is the case with routes announced from T1 VMs in a T2 topology), the logic to validate the src_mac of the received packet in fib_test/hash_test has been modified to not check for the src_mac in the expected packet for the verify_packet_any_port call. The src mac is compared to the target_mac defined in ptf_test_port_map.json for the dut that has the rcvd_port. If it doesn't match then we fail. How did you verify/test it? Tested against a T2 chassis.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Description of PR
Summary:
Fixes # (issue)
Type of change
Approach
What is the motivation for this PR?
Need to make the FIB tests work against a T2 chassis.
How did you do it?
Even though a T2 chassis has multiple DUTs (linecards), we have a single PTF instance that has all the injected ptf ports that connect to all the DUTs frontpanel ports. For the fib test, the src port and the expected rcv ports are from this list of all the
injected ptf ports.
In a T2 chassis, we have multiple linecards, and routes learnt from a linecard are distributed over the fabric to the other linecards. But, the fib on the other linecards points to the inband recyle port Ethernet-IB0. Therefore, when generating the fib_info_file
for the linecards, if the route is learned over the inband recyle port, we have to figure out which other linecard this route was learnt on, and use its frontpanel ports as the outgoing ports for this route.
Since a route learnt across the fabric will have an outgoing port on another linecard, and this route could be learnt from multiple linecards (as is the case with routes announced from T1 VMs in a T2 topology), the logic to validate the src_mac of the received packet in fib_test/hash_test has been modified to not check for the src_mac in the expected packet for the verify_packet_any_port call. The src mac is compared to the target_mac defined in ptf_test_port_map.json for the dut that has the rcvd_port. If it doesn't match then we fail.
How did you verify/test it?
Tested against a T2 chassis.
Any platform specific information?
Supported testbed topology if it's a new test case?
Documentation