Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[action] [PR:16213] [chassis] Chassis DB cleanup when asic comes up #16417

Merged
merged 1 commit into from
Sep 3, 2023

Conversation

mssonicbld
Copy link
Collaborator

Why I did it

In an operational system, after some configuration is changed (that involves line cards generating entries to chassis db), if config reload or system reboot is done without saving the new configuration changes and when system comes up, entries created by the new config are still present in the chassis db and hence the corresponding voq system entries (such as system interface, system neighbor and so on ) in all other line cards. These stale entries may affect the accuracy of the current entries and hence the intended operation of chassis. To fix this, we cleanup the chassis db when the an asic comes up. The chassis db is cleaned up for entries created by the asic that is coming up.

Work item tracking

N/A

How I did it

Cleanup the entries from the following tables in chassis app db in redis_chassis server in the supervisor

(1) SYSTEM_NEIGH
(2) SYSTEM_INTERFACE
(3) SYSTEM_LAG_MEMBER_TABLE
(4) SYSTEM_LAG_TABLE

As part of the clean up only those entries created by the asic that is coming up are deleted. The LAG IDs used by the asics are also de-allocated from SYSTEM_LAG_ID_TABLE and SYSTEM_LAG_ID_SET

How to verify it

  • When chassis is up and running, change configuration that will create entries for the tables mentioned above. Make sure that the entries created are due to changes in the existing configuration.
  • Note that chassis db has entries for new changed configutations.
  • Without saving the changed configuration, do a config reload or reboot the line card or reboot the chassis.
  • Observe that the chassis db does not have the entries created by the changed configuration.

Which release branch to backport (provide reason below if selected)

N/A

Tested branch (Please provide the tested image version)

master

Description for the changelog

  • Changes swss.sh service script. Which is invoked with swss service is started. After cleaning up the critical tables in local redis database, the chassis db entries are cleaned up. The clean up use the hostname and asic name currently detected by the service initialization script. If this hostname and asic name are different than those used to create the entries in the chassis db, the entries will not be cleaned up.

Link to config_db schema for YANG module changes

None

A picture of a cute animal (not mandatory but encouraged)

* [chassis]Chassis DB cleanup when asic comes up

Cleanup the entries from the following tables in chassis app db in
redis_chassis server in the supervisor
(1) SYSTEM_NEIGH
(2) SYSTEM_INTERFACE
(3) SYSTEM_LAG_MEMBER_TABLE
(4) SYSTEM_LAG_TABLE
As part of the clean up only those entries created by the asic that
is coming up are deleted. The LAG IDs used by the asics are also
de-allocated from SYSTEM_LAG_ID_TABLE and SYSTEM_LAG_ID_SET

- Added check to run the chassis db clean up only for voq switches.

Signed-off-by: vedganes <veda.ganesan@nokia.com>
@mssonicbld
Copy link
Collaborator Author

Original PR: #16213

@mssonicbld mssonicbld merged commit ebe24a1 into sonic-net:202305 Sep 3, 2023
16 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants