Distributed VOQ HLD #639
Merged
Distributed VOQ HLD #639
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
|
|
Updated text reflects discussion on the 07/23/2020 call on Option-2. Additional discussion still pending
Updated for changes in database object names and example configurations
This image is not used anymore
3 tasks
This was referenced Sep 10, 2020
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 <[email protected]>
Name changes from global_app_db to chassis_app_db
global_app_db name change to chassis_app_db
global_app_db name change to chassis_app_db
global_app_db name change to chassis_app_db
rlhui
reviewed
Sep 27, 2020
|
Are all action items discussed in chassis subgroup for this HLD closed/updated in doc if needed? E.g. "AI: Update Switch_ID can be computed using the SKU information. If the config_db is automatically created using the chassis map, Switch_ID can be auto-generated as well"? |
The switch_id is provided as part of minigraph of the linecards under the DEVICE_METADATA section. I don't think our current proposal is to auto-generate switch_ID as part of Sonic. |
Reversed the order of section 2.2 and 2.3 compared to the previous version.
lguohan
pushed a commit
to sonic-net/sonic-sairedis
that referenced
this pull request
Oct 12, 2020
This PR includes implementation of System ports initialization & orchestration, Interface & Neighbor Synchronization using GLOBAL_APP_DB, Inband Interface Configuration. HLD: sonic-net/SONiC#639 Dependency PR(sonic-swss-common): sonic-net/sonic-swss-common#380 Co-authored-by: vedganes <[email protected]>
rlhui
approved these changes
Oct 19, 2020
lguohan
pushed a commit
to sonic-net/sonic-swss-common
that referenced
this pull request
Oct 28, 2020
…ynchronization... (#380) This PR includes implementation of System ports initialization & orchestration, Interface & Neighbor Synchronization using GLOBAL_APP_DB, Inband Interface Configuration. HLD: sonic-net/SONiC#639 Signed-off-by: vedganes <[email protected]>
rlhui
pushed a commit
to sonic-net/sonic-swss
that referenced
this pull request
Jan 17, 2021
…ynchronization... (#1431) This PR includes implementation of System ports initialization & orchestration, Interface & Neighbor Synchronization using GLOBAL_APP_DB, Inband Interface Configuration. HLD: sonic-net/SONiC#639 Dependency PR's (sonic-swss-common): sonic-net/sonic-swss-common#380 (sonic-sairedis): sonic-net/sonic-sairedis#657 * [voq] Redis instance for global app db * [voq] System port init and orchestration * [voq] Router interface for system ports, global app db sync * [voq] Inband interface config * [voq] System port neighbors Kernel programming of static neigh and full mask static route for system neighbors is moved to nbrmgr since orchagent should not own kernel objects to avoid complication in warmboot reconciliation The orchagent programs only SAI object for the system neighbors and signals the completion of SAI programming by setting mac address in SYSTE_NEIGH table of STATE_DB. Nbrmgr subscribes to these state entries to program kernel entries corresponding to the system neighs * [swss]VS tests for VOQ system ports The following tests are added as part of virtual chassis tests - VOQ switch objects verification - System port object syncing with chassis app db by checking presence of system port RIFs in chassis app db in supervisor card - Creation of system port RIF record creation in ASIC_DB Following changes are done for the above tests: - SYSTEM_PORT table is added in default_config.json of line cards. These are loaded as part of config_db loading - Core and Port index mapping file is added in line card directories. - use dvs_database.py lib to connect to redis databases instead of using raw connection via swsscommon DBConnectors. - call dvs apis to get access to databases for the local redis instances. - Default handling for speed of the system port is removed in addSystemPorts() - Comment added to clarify types of rif-s synced to chassis app db - vs tests: connection to chassis app dp uses chassis app db id defined in dvs lib instead of using the id from swsscommon Using the chassis app db id from swsscommon instead of chassis app db id from dvd lib . This is to avoid python lgtm alert and test failure. Co-authored-by: vedganes <[email protected]> Co-authored-by: vganesan-nokia <[email protected]>
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 <[email protected]>
DavidZagury
pushed a commit
to DavidZagury/sonic-swss
that referenced
this pull request
Mar 4, 2021
…ynchronization... (sonic-net#1431) This PR includes implementation of System ports initialization & orchestration, Interface & Neighbor Synchronization using GLOBAL_APP_DB, Inband Interface Configuration. HLD: sonic-net/SONiC#639 Dependency PR's (sonic-swss-common): sonic-net/sonic-swss-common#380 (sonic-sairedis): sonic-net/sonic-sairedis#657 * [voq] Redis instance for global app db * [voq] System port init and orchestration * [voq] Router interface for system ports, global app db sync * [voq] Inband interface config * [voq] System port neighbors Kernel programming of static neigh and full mask static route for system neighbors is moved to nbrmgr since orchagent should not own kernel objects to avoid complication in warmboot reconciliation The orchagent programs only SAI object for the system neighbors and signals the completion of SAI programming by setting mac address in SYSTE_NEIGH table of STATE_DB. Nbrmgr subscribes to these state entries to program kernel entries corresponding to the system neighs * [swss]VS tests for VOQ system ports The following tests are added as part of virtual chassis tests - VOQ switch objects verification - System port object syncing with chassis app db by checking presence of system port RIFs in chassis app db in supervisor card - Creation of system port RIF record creation in ASIC_DB Following changes are done for the above tests: - SYSTEM_PORT table is added in default_config.json of line cards. These are loaded as part of config_db loading - Core and Port index mapping file is added in line card directories. - use dvs_database.py lib to connect to redis databases instead of using raw connection via swsscommon DBConnectors. - call dvs apis to get access to databases for the local redis instances. - Default handling for speed of the system port is removed in addSystemPorts() - Comment added to clarify types of rif-s synced to chassis app db - vs tests: connection to chassis app dp uses chassis app db id defined in dvs lib instead of using the id from swsscommon Using the chassis app db id from swsscommon instead of chassis app db id from dvd lib . This is to avoid python lgtm alert and test failure. Co-authored-by: vedganes <[email protected]> Co-authored-by: vganesan-nokia <[email protected]>
raphaelt-nvidia
pushed a commit
to raphaelt-nvidia/sonic-swss
that referenced
this pull request
Oct 5, 2021
…ynchronization... (sonic-net#1431) This PR includes implementation of System ports initialization & orchestration, Interface & Neighbor Synchronization using GLOBAL_APP_DB, Inband Interface Configuration. HLD: sonic-net/SONiC#639 Dependency PR's (sonic-swss-common): sonic-net/sonic-swss-common#380 (sonic-sairedis): sonic-net/sonic-sairedis#657 * [voq] Redis instance for global app db * [voq] System port init and orchestration * [voq] Router interface for system ports, global app db sync * [voq] Inband interface config * [voq] System port neighbors Kernel programming of static neigh and full mask static route for system neighbors is moved to nbrmgr since orchagent should not own kernel objects to avoid complication in warmboot reconciliation The orchagent programs only SAI object for the system neighbors and signals the completion of SAI programming by setting mac address in SYSTE_NEIGH table of STATE_DB. Nbrmgr subscribes to these state entries to program kernel entries corresponding to the system neighs * [swss]VS tests for VOQ system ports The following tests are added as part of virtual chassis tests - VOQ switch objects verification - System port object syncing with chassis app db by checking presence of system port RIFs in chassis app db in supervisor card - Creation of system port RIF record creation in ASIC_DB Following changes are done for the above tests: - SYSTEM_PORT table is added in default_config.json of line cards. These are loaded as part of config_db loading - Core and Port index mapping file is added in line card directories. - use dvs_database.py lib to connect to redis databases instead of using raw connection via swsscommon DBConnectors. - call dvs apis to get access to databases for the local redis instances. - Default handling for speed of the system port is removed in addSystemPorts() - Comment added to clarify types of rif-s synced to chassis app db - vs tests: connection to chassis app dp uses chassis app db id defined in dvs lib instead of using the id from swsscommon Using the chassis app db id from swsscommon instead of chassis app db id from dvd lib . This is to avoid python lgtm alert and test failure. Co-authored-by: vedganes <[email protected]> Co-authored-by: vganesan-nokia <[email protected]>
pettershao-ragilenetworks
pushed a commit
to pettershao-ragilenetworks/sonic-sairedis
that referenced
this pull request
Nov 18, 2022
This PR includes implementation of System ports initialization & orchestration, Interface & Neighbor Synchronization using GLOBAL_APP_DB, Inband Interface Configuration. HLD: sonic-net/SONiC#639 Dependency PR(sonic-swss-common): sonic-net/sonic-swss-common#380 Co-authored-by: vedganes <[email protected]>
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.
This is a design document proposal for Distributed VOQ from the Nokia-SONiC team