-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
[fast-reboot] ARP table is not restored after fast-reboot #5580
Comments
Fix merged, issue can be closed. @bingwang-ms |
I think this issue is not fixed by sonic-net/sonic-utilities#1164. Because there is no unicode issue in fast-reboot-dump.py in 201911 branch, and the arp.json has been backed up successfully. I guess the problem is caused by some incorrect logic in restoring ARP. So reopen it. |
This issue is also observed on master branch. |
…s enable. (#1498) This commit is to address the issue that the NEIGH_TABLE loaded by swssconfig after fast-reboot is cleared by neighsyncd. **What I did** Fix sonic-net/sonic-buildimage#5841 and sonic-net/sonic-buildimage#5580 We found that neighbor table loaded by ```swssconfig``` from ```arp.json``` after ```fast-reboot``` is cleared by ```neighsyncd``` mistakenly at the initial stage. This PR adds a check for ```WarmStart``` before cleaning up, and only do that if ```WarmStart``` is enable. **Why I did it** This PR is to fix the issue that arp table is not recovered after fast-reboot. **How I verified it** Verified on Arista-7260, running 201911 image. 1. Run some test to populate ARP entries on DUT, such as ```test_fast_reboot``` 2. Issue a fast-reboot 3. Verify the ```arp.json``` backed up by ```fast-reboot-dump.py``` is loaded and NEIGH_TABLE is restored.
Fixed in sonic-net/sonic-swss#1498 |
…s enable. (#1498) This commit is to address the issue that the NEIGH_TABLE loaded by swssconfig after fast-reboot is cleared by neighsyncd. **What I did** Fix sonic-net/sonic-buildimage#5841 and sonic-net/sonic-buildimage#5580 We found that neighbor table loaded by ```swssconfig``` from ```arp.json``` after ```fast-reboot``` is cleared by ```neighsyncd``` mistakenly at the initial stage. This PR adds a check for ```WarmStart``` before cleaning up, and only do that if ```WarmStart``` is enable. **Why I did it** This PR is to fix the issue that arp table is not recovered after fast-reboot. **How I verified it** Verified on Arista-7260, running 201911 image. 1. Run some test to populate ARP entries on DUT, such as ```test_fast_reboot``` 2. Issue a fast-reboot 3. Verify the ```arp.json``` backed up by ```fast-reboot-dump.py``` is loaded and NEIGH_TABLE is restored.
…s enable. (sonic-net#1498) This commit is to address the issue that the NEIGH_TABLE loaded by swssconfig after fast-reboot is cleared by neighsyncd. **What I did** Fix sonic-net/sonic-buildimage#5841 and sonic-net/sonic-buildimage#5580 We found that neighbor table loaded by ```swssconfig``` from ```arp.json``` after ```fast-reboot``` is cleared by ```neighsyncd``` mistakenly at the initial stage. This PR adds a check for ```WarmStart``` before cleaning up, and only do that if ```WarmStart``` is enable. **Why I did it** This PR is to fix the issue that arp table is not recovered after fast-reboot. **How I verified it** Verified on Arista-7260, running 201911 image. 1. Run some test to populate ARP entries on DUT, such as ```test_fast_reboot``` 2. Issue a fast-reboot 3. Verify the ```arp.json``` backed up by ```fast-reboot-dump.py``` is loaded and NEIGH_TABLE is restored.
Description
I noticed that ARP table is not restored correctly after fast-reboot when debugging test_fast_reboot. I believe the swssconfig has loaded the /arp.json because following logs are found in syslog:
However, there is no restored ARP entry in db and system.
The issue is possible cause by
/usr/bin/restore_neighbors.py
because following logs are found in syslog:Steps to reproduce the issue:
2.Check the ARP table on DUT after fast-reboot with
show arp
, and the ARP table is not restored correctly. As a result, the test case failed because a relatively long period (about 100 seconds) is needed to populate ARP table.Describe the results you received:
The test case
test_fast_reboot
doesn't pass because ARP table is not restored after fast-reboot.Describe the results you expected:
The test case
test_fast_reboot
passed, and ARP table is completely restored after fast-reboot.Additional information you deem important (e.g. issue happens only occasionally):
Attach debug file
sudo generate_dump
:syslog.zip
The text was updated successfully, but these errors were encountered: