Introduce basic T2 topology #2638
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
More details about the topology in the img/png file
3 line card topology with all ports connected to VM
Adding T2 topology file for a SONiC Chassis that has 4 DUT's: - 3 linecards - dut_index 0, 1, and 2 - 1 supervisor card - dut_index 3 Each linecard has 32 VM's. BGP info: DUT ASN: 65100 Linecard 1 (dut_index 0) has 32 eBGP peers, each with the same ASN 65200 Linecard 2 (dut_index 1) has 32 eBGP peers, each with a different ASN (65001-65132) Linecard 3 (dut_index 2) has 32 eBGP peers, each with a different ASN (65033-65064)
Adding a T2 topology file
|
|
yxieca
approved these changes
Dec 11, 2020
|
retest vsimage please |
2 tasks
wangxin
reviewed
Dec 15, 2020
Incorporated comments by Ying and added lag+regular ports on each DUT
T2 topology now has LAGs and regular ports. hence # of VMs reduce
3 tasks
wangxin
reviewed
Dec 22, 2020
…work with gen-mg - Changed addresses from 20.0.0.x on interfaces to 10.0.0.x to be inline with other topologies - Added loopback interfaces for the line card DUTs - Added dut_index to ports on the VMs. - changed vm_offset to not jump by 2 for the LAG VMs - increment it only by 1.
3 tasks
wangxin
approved these changes
Dec 25, 2020
saravanansv
reviewed
Feb 2, 2021
| @@ -23,6 +23,13 @@ | |||
|
|
|||
| ## Current topologies | |||
|
|
|||
| ### t2 | |||
There was a problem hiding this comment.
Looks like t2 is assumed to be 1 supe, 3max LCs accommodating chassis and can't support any more LCs right other than 3 right ?
Might be worth mentioning it here.
There was a problem hiding this comment.
Actually, that's the base topology. We wanted to give an example of 1 upstream and 2 downstream line cards. Just as we can extend current t0.yml to make t0-52.yml, t0-112.yml, etc, we can extend this to add a fully populated sonic chassis too. Many infra PRs mentioned in the chassis subgroup tracker were put in place precisely to support this flexibility and line card additions.
wangxin
pushed a commit
that referenced
this pull request
Feb 8, 2021
…ect to only a single host and supervisor card (#2700) What is the motivation for this PR? For SONiC Chassis support gen-mg has the following limitations: * for multi-dut it assumes each VM is connected to all the DUT's (similar to the dualtor topology) * assumes that all interfaces connected to a PortChannel are sequential. It also needs the following enhancements: * In a SONiC Chassis we have a 'supervisor' card which has no ports and thus no BGP/loopback/IpInterfaces/ACL's etc. The minigraph should not include info about these. * We need to introduce 'T3' router type as 'CoreRouter' How did you do it? For VMs to connect to a single DUT: * In vm_topo_config, the fields like interface_indexes, intfs, ip_intf etc would be either empty or null. Add checks for these where they are being used in gen-mg (config_sonic_basedon_testbed.yml and the minigraph templates). For not all PortChannel ports being sequential: * In config_sonic_based_on_testbed.yml, changed interface_to_vms structure to be compatable to allow using ansible's 'with_subelements' loop to get the intf_names For SONiC Chassis support: * For 'supervisor' card, there are no BGP peers, interfaces etc. required. * A 'supervisor' card is identified by having 'type' field in the inventory with value 'supervisor'. * Add this check to skip generation of portions not valid for supervisor card * Added 'CoreRouter' as the DUT type for T3 VM's that connect to 'T2' DUT. How did you verify/test it? * Ran gen-mg against all the testbeds defined in vtestbed.csv with latest github master code, and then with our code changes. Verified that there are no differences in the generated minigraph files. * Ran against topo_t2.yml proposed in PR #2638 where we have 3 linecards with 24 VM's each (8 on 2 port LAG and 16 on single port) and 1 supervisor card. * Validated generated minigraph files for the linecards are the same as those generated by running gen-mg against individual linecard testbed (with only 1 DUT). * Validate the generated minigraph file for supervisor card is acceptable to sonic-cfggen and the generated config_db.json is valid for the supervisor card.
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 a basic topology against which T2 test cases can be standardized and executed.
How did you do it?
The new T2 topology, as pictured in the README.testbed.Topology.md file, has:
3 line cards - dut_index 0, 1, and 2
1 supervisor card - dut_index 3
Each line card has 32 VMs.
BGP info:
DUT ASN: 65100
Linecard 1 (dut_index 0) has 32 eBGP peers, each with the same ASN 65200
Linecard 2 (dut_index 1) has 32 eBGP peers, each with a different ASN (65001-65132)
Linecard 3 (dut_index 2) has 32 eBGP peers, each with a different ASN (65033-65064)
How did you verify/test it?
Tests are not yet deployed. Hence, not applicable.
Any platform specific information?
Supported testbed topology if it's a new test case?
Documentation