[crm] Fix issues in static_route test case #3740
Conversation
What is the motivation for this PR? There are two issues in the current static route test case： 1. As all the ECMP entries are in the same subnet on the PTF, the PTF's route table will have three same route entries for this subnet. While sending a packet, the output interface is inexplicit within this subnet. Especially for ARP request, the interface will reply with their own MAC even the request is for other interfaces. 2. While the config_reload_test option is True, the FDB will be flushed after reload. The packet will flood to all the interfaces in the Vlan1000. This may cause failures as other ports could receive the expected packet. How did you do it? 1. Add static neigh on the DUT for each PTF's interfaces, to avoid ARP request from DUT. 2. Send ICMP packet from each PTF's interfaces to update FDB table on the DUT, to avoid flooding. How did you verify/test it? Run test_static_route.py, all the test cases should pass.
| ip_ttl=64 | ||
| ) | ||
| # Send pkt to update DUT's FDB table to avoid flooding | ||
| testutils.send(ptfadapter, nexthop_devs[idx], pkt) |
There was a problem hiding this comment.
Does this part does the neighbor resolution? If so, we probably need to avoid it since the automatic neighbor resolution is part of the static route feature, we need to check that. I think the current failures of the test come from two aspects: 1. the arp_update script has a period of 300 seconds, whereas the config reload waiting time is shorter than that; 2. according to sonic-net/sonic-buildimage#4930 the arp_update some times fails.
There was a problem hiding this comment.
No, it is to fill the FDB entry for all interfaces on the DUT to avoid flooding unknown unicast packets. I think we may not need this changes anymore if we can wait until arp_update script is finished.
|
I created another PR #3749 to make sure that the arp_update script does the neighbor resolution. That should fix the failure for |
What is the motivation for this PR?
There are two issues in the current static route test case：
How did you do it?
How did you verify/test it?
Run test_static_route.py, all the test cases should pass.
Description of PR
Summary:
Fixes # (issue)
Type of change
Back port request
Approach
What is the motivation for this PR?
How did you do it?
How did you verify/test it?
Any platform specific information?
Supported testbed topology if it's a new test case?
Documentation