Fix arp/test_unknown_mac by disabling arp_update#13410
Fix arp/test_unknown_mac by disabling arp_update#13410StormLiangMS merged 3 commits intosonic-net:masterfrom
Conversation
|
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:
|
lolyu
left a comment
There was a problem hiding this comment.
Can we simply ignore the fdb entries from the IPv6 echo replies?
I don't believe there is a simple way to just ignore it. Even if there is a way to differentiate ipv6 echo replied fdb entries, I don't believe it will be a good idea to filter or add logic to check, as the goal of the test is to test the behaviour when the mac address is unknown. The test will be the most accurate and functionally correct if the DUT indeed does not know the mac at all. |
Actually, will change it so that we disable IPv6 on the DUT side instead of disabling it on the PTF container. Disabling on PTF may cause some previously populated items to be lost. |
|
@lolyu could you help to review? |
|
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:
|
|
Changed to disable IPv6 from DUT instead of PTF. This method of disabling PTF is same as the method used here: |
This comment was marked as outdated.
This comment was marked as outdated.
lolyu
left a comment
There was a problem hiding this comment.
Maybe we can disable the arp refresh by disabling the arp_update:
# docker exec -it swss supervisorctl stop arp_update
arp_update: stopped
# docker exec -it swss supervisorctl start arp_update
arp_update: started
Will use this method instead, thanks. |
The DUT will occasionally (~5 mins) send a echo request through IPV6 to the ptf container (from `arp_update`), and this is casuing the fdb table to be populated - which is bad because the test expects the fdb table to be empty. Temporarily disabling arp_update during the test will eliminate the problem.
|
Changed the fix method to use the |
|
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:
|
1 similar comment
|
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:
|
|
@lolyu could you please review it again? |
tests/arp/test_unknown_mac.py
Outdated
| rand_selected_dut(AnsibleHost) : dut instance | ||
| """ | ||
| duthost = rand_selected_dut | ||
| assert duthost.shell("docker exec -t swss supervisorctl stop arp_update")['stdout_lines'][0] \ |
There was a problem hiding this comment.
If the arp_update stop fails here, LINE#59 will not be executed, we'd better to restart arp_update in this case.
There was a problem hiding this comment.
That is the intention - fail fast if any other test somehow disabled arp_update, or if it is disabled unintentionally.
Though if you prefer to continue the test, I am open to change it so re-enable it. Please let me know your decision, thanks.
There was a problem hiding this comment.
Changed so it will allow arp_update to remain off and it will restart when the test is done.
What is the motivation for this PR? Test was flaky. Monitoring tcpdump on the PTF container and the DUT's fdb table shows IPv6 echo is causing mac addresses to be learned on the DUT even though it was previously flushed. How did you do it? Disable IPv6. How did you verify/test it? Disabling IPv6 will allow the test to consistently past. If IPv6 is re-enabled during the test and packets are sent, it immediately fails. Any platform specific information?
|
Cherry-pick PR to 202405: #14121 |
What is the motivation for this PR? Test was flaky. Monitoring tcpdump on the PTF container and the DUT's fdb table shows IPv6 echo is causing mac addresses to be learned on the DUT even though it was previously flushed. How did you do it? Disable IPv6. How did you verify/test it? Disabling IPv6 will allow the test to consistently past. If IPv6 is re-enabled during the test and packets are sent, it immediately fails. Any platform specific information?
What is the motivation for this PR? Test was flaky. Monitoring tcpdump on the PTF container and the DUT's fdb table shows IPv6 echo is causing mac addresses to be learned on the DUT even though it was previously flushed. How did you do it? Disable IPv6. How did you verify/test it? Disabling IPv6 will allow the test to consistently past. If IPv6 is re-enabled during the test and packets are sent, it immediately fails. Any platform specific information?
|
Cherry-pick PR to 202311: #14213 |
What is the motivation for this PR? Test was flaky. Monitoring tcpdump on the PTF container and the DUT's fdb table shows IPv6 echo is causing mac addresses to be learned on the DUT even though it was previously flushed. How did you do it? Disable IPv6. How did you verify/test it? Disabling IPv6 will allow the test to consistently past. If IPv6 is re-enabled during the test and packets are sent, it immediately fails. Any platform specific information?
What is the motivation for this PR? Test was flaky. Monitoring tcpdump on the PTF container and the DUT's fdb table shows IPv6 echo is causing mac addresses to be learned on the DUT even though it was previously flushed. How did you do it? Disable IPv6. How did you verify/test it? Disabling IPv6 will allow the test to consistently past. If IPv6 is re-enabled during the test and packets are sent, it immediately fails. Any platform specific information?
What is the motivation for this PR? Test was flaky. Monitoring tcpdump on the PTF container and the DUT's fdb table shows IPv6 echo is causing mac addresses to be learned on the DUT even though it was previously flushed. How did you do it? Disable IPv6. How did you verify/test it? Disabling IPv6 will allow the test to consistently past. If IPv6 is re-enabled during the test and packets are sent, it immediately fails. Any platform specific information?
Description of PR
The DUT will occasionally (~5 mins) send a echo request through IPv6 to the PTF container. When the PTF container replies, it populates the fdb table. This is bad because the test expects the fdb table to be empty.
Temporarily disabling IPv6 on the PTF container during the test will eliminate the problem.Temporarily disabling
arp_updateon the DUT during the test will eliminate the problem.Summary:
Fixes #
Type of change
Back port request
Approach
What is the motivation for this PR?
Test was flaky. Monitoring tcpdump on the PTF container and the DUT's fdb table shows IPv6 echo is causing mac addresses to be learned on the DUT even though it was previously flushed.
How did you do it?
Disable IPv6.
How did you verify/test it?
Disabling IPv6 will allow the test to consistently past. If IPv6 is re-enabled during the test and packets are sent, it immediately fails.
Any platform specific information?
Supported testbed topology if it's a new test case?
Documentation