Distributed forwarding in a VOQ architecture HLD #622
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
|
|
NPU to be replaced by ASIC/Multi-ASIC for consistency throughout the document [AI: Kartik/Arista] => document updated to use ASIC instead of NPU Section 1.2: Config & Management Requirements Rephrase second bullet to reflect port configuration is static i.e physical wiring only => Wording clarified as requqested Add context in the document for dynamic port changes [AI: Kartik/Arista] => Section outlining dynamic system port support added in "Future Work" section Section 2.3: State Sharing Update image separate Syncd, swss, DB container per fabric chip [AI: Kartik/Arista] => diagram updated to show multiple syncd, one per fabric chip Section 2.4: Chip Management Update section 2.4.2 to clarify switch ID numbering scheme in the system with reference from SAI specs. [AI: Kartik/Arista] => Section updated to reflect the correct numbering scheme with reference to the VOQ SAI spec. Section 2.5: Port Management Section 2.5.2 update system port table schema [AI: Kartik/Arista] => Updated to reflect proper instance naming as below Section 2.5.3 Update inband port to be explicitly provisioned [AI: Kartik/Arista] => wording around inband port is clarified. Require more clarity what is meant by instance - if LC has two ASICs then what will instance scope mean - swss/CPU instance? Is there is 1:1 mapping between instance to ASIC? [AI: Kartik/Arista] => Added new instance naming section describing naming scheme for both the FSI and an ASIC
daall
reviewed
Jun 24, 2020
Ifname must be unique per FSI. If we decide to create kernel devices for system ports, ifname may have to be globally unique. AI (Kartik/Arista): Amend wording in the document => amended wording in the document Any existing swss test can be run in the virtual chassis mode - except for LAG tests which aren’t compatible . AI (Kartik/Arista) - Clarify the conditions under which existing tests can be run unchanged. => clarified How would dual supervisor scenario work? What considerations do we have for two SSIs? (Danny/Microsoft) AI (Kartik/Arista) - add a summary in Future work section. => added a new dual supervisor section in Future work and summarized some high level approaches
lguohan
pushed a commit
to sonic-net/sonic-buildimage
that referenced
this pull request
Jul 29, 2020
virtual-chassis test uses multiple vs instances to simulate a modular switch and a redis-chassis service is required to run on the vs instance that represents a supervisor card. This change allows vs docker start redis-chassis service according to external config file. **- Why I did it** To support virtual-chassis setup, so that we can test distributed forwarding feature in virtual sonic environment, see `Distributed forwarding in a VOQ architecture HLD` pull request at sonic-net/SONiC#622 **- How I did it** The sonic-vs start.sh is enhanced to start new redis_chassis service if external chassis config file found. The config file doesn't exist in current vs environment, start.sh will behave like before. **- How to verify it** The swss/test still pass. The chassis_db service is verified in virtual-chassis topology and tests which are in following PRs. Signed-off-by: Honggang Xu <hxu@arista.com> (cherry picked from commit c1d45cf81ce3238be2dcbccae98c0780944981ce) Co-authored-by: Honggang Xu <hxu@arista.com>
- Clarifications on DB structure and naming - Cleaning up redundant sections that are expected to be covered in other docs
- Clarification of terminology - Renamed Chassis DB to Global DB - Revised the Global DB configuration structure - Added a failure handling section
BrynXu
reviewed
Aug 13, 2020
per agreement in SONiC community
3 tasks
lguohan
pushed a commit
to sonic-net/sonic-buildimage
that referenced
this pull request
Sep 15, 2020
As per the VOQ HLDs, internal networking between the linecards and supervisor is required within a chassis. Allocating 127.X/16 subnets for private communication within a chassis is a good candidate. It doesn't require any external IP allocation as well as ensure that the traffic will not leave the chassis. References: sonic-net/SONiC#622 sonic-net/SONiC#639 **- How I did it** Changed the `interfaces.j2` file to add `127.0.0.1/16` as the `lo` ip address. Then once the interface is up, the post-up command removes the `127.0.0.1/8` ip address. The order in which the netmask change is made matters for `127.0.0.1` to be reachable at all times. **- How to verify it** ``` root@sonic:~# ip address show dev lo 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/16 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever ``` Co-authored-by: Baptiste Covolato <baptiste@arista.com>
rlhui
reviewed
Sep 27, 2020
lguohan
approved these changes
Oct 10, 2020
rlhui
approved these changes
Oct 10, 2020
santhosh-kt
pushed a commit
to santhosh-kt/sonic-buildimage
that referenced
this pull request
Feb 25, 2021
As per the VOQ HLDs, internal networking between the linecards and supervisor is required within a chassis. Allocating 127.X/16 subnets for private communication within a chassis is a good candidate. It doesn't require any external IP allocation as well as ensure that the traffic will not leave the chassis. References: sonic-net/SONiC#622 sonic-net/SONiC#639 **- How I did it** Changed the `interfaces.j2` file to add `127.0.0.1/16` as the `lo` ip address. Then once the interface is up, the post-up command removes the `127.0.0.1/8` ip address. The order in which the netmask change is made matters for `127.0.0.1` to be reachable at all times. **- How to verify it** ``` root@sonic:~# ip address show dev lo 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/16 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever ``` Co-authored-by: Baptiste Covolato <baptiste@arista.com>
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.
No description provided.