-
Notifications
You must be signed in to change notification settings - Fork 746
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
Fix an issue of all lldp entries take some time to be in DB after reboot in scaling setup. #15731
Conversation
…oot in scaling setup.
The pre-commit check detected issues in the files touched by this pull request. Detailed pre-commit check results: To run the pre-commit checks locally, you can follow below steps:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for updating
@yejianquan for 202405 branch. |
…oot in scaling setup. (sonic-net#15731) Fix an issue of all lldp entries take some time to be in DB after reboot in scaling setup
Cherry-pick PR to 202405: #16014 |
…oot in scaling setup. (#15731) Fix an issue of all lldp entries take some time to be in DB after reboot in scaling setup
Description of PR
It's found in scaling setup (34K BGP routes) test_lldp_entry_table_after_reboot test may fail as lldp table entries in DB and from show are not in sync. Further analysis shows that after reboot, full lldp entries takes longer time to come back into DB. Entries are coming to DB one by one and takes few seconds to have full data there.
Current test is calling reboot and check all critical services are up and all admin up ports are back to line then will begin lldp entries check. This could be too early as lldp packets are coming in one by one and lldp entries are written to DB one by one. The following few lldp queries could be out of sync in this scenario.
Solution is to take a query of how many lldp entries are in DB before reboot. After reboot will wait to check till all the lldp entries are in DB before further queries.
With this check the test passed on scaling setup.
Summary:
Fixes # (issue)
Type of change
Back port request
Approach
What is the motivation for this PR?
Fix test failure
How did you verify/test it?
Run lldp syncd OC tests with the fix. Did not see the issue.