-
Notifications
You must be signed in to change notification settings - Fork 539
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
Change the log messages in addKernelNeigh/Route from ERROR to INFO. #2416
Conversation
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.
what is test case change about ? Can you add that in PR description.
This pull request introduces 3 alerts when merging 9ddbd65 into dec4570 - view on LGTM.com new alerts:
|
I will update. Basic idea was to add a case where there is a mac address change for neighbor, and get code coverage. The changes here are mainly regrouping the existing code into a function which can be called multiple times to change the mac address of a neighbor. |
This pull request introduces 3 alerts when merging 88ff407 into dec4570 - view on LGTM.com new alerts:
|
This pull request introduces 2 alerts when merging 33f765e into 4aaeec9 - view on LGTM.com new alerts:
|
This pull request introduces 1 alert when merging ee3eef0 into a4b8992 - view on LGTM.com new alerts:
|
/easycla |
53428b6
to
44aae08
Compare
…here we again create a neighbor entry which already exists but with a different ll_address
…ange of a neighbor.
entry in remote linecards.
44aae08
to
32726b0
Compare
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
Closing this PR in favor of PR : #2437. For some reason the PR build/tests get stuck here. |
What I did
Change the Error reporting for API's addKernelRoute, addKernelNeigh from ERR to INFO as the code logic already deletes and retries the creation of Neigh/Route
For the test tests/test_virtual_chassis.py::test_chassis_system_neigh the following change was made
Why I did it
There was sonic-mgmt test failures in multi-asic devices where the Neighbor and routes learnt in in one ASIC is synced with the nearby ASIC, and in case of mac move there is possibility for an existing entry to be updated with a new mac address ( using the command /sbin/ip neigh add lladdr dev ) . This causes error as ip neigh/route add command will fail (error : nbrmgrd RTNETLINK answers: File exists)
How I verified it
With this fix the tests passed
Details if related