[static route] Extend config reload wait time for static route tests

[shi-su]

Description of PR

Summary: Extend config reload wait time for static route tests
Fixes sonic-net/sonic-buildimage#7968

Type of change

• Bug fix
• Testbed and Framework(new/improvement)
• Test case(new/improvement)

Back port request

• 201911

Approach

What is the motivation for this PR?

The arp_update script updates unresolved neighbors every 300 seconds. As the default config reload wait time is 120 seconds, the arp_update script may not finish the neighbor resolution before the config reload wait time and cause the static route test to fail. This PR aims to fix the timing issue for static route tests.

The test case test_static_route_ecmp_ipv6 may be affected by sonic-net/sonic-buildimage#4930, so the test case may still fail in some scenarios

Note:

How did you do it?

Extend config reload wait time for static route tests to 350 seconds.

How did you verify/test it?

Confirm that test_static_route_ecmp test case could pass with neighbors not resolved right after config reload.

Any platform specific information?

Supported testbed topology if it's a new test case?

Documentation

[kevinskwang]

I think there is still a issue need to be addressed. If you check the accuracy ARP/NDP that the DUT learned, you can see all three IP neighbors will have the same MAC address. So it will always send to the port which has this MAC, the other two ports can't even receive any packets. It should not the ECMP's purpose.

[shi-su]

I think there is still a issue need to be addressed. If you check the accuracy ARP/NDP that the DUT learned, you can see all three IP neighbors will have the same MAC address. So it will always send to the port which has this MAC, the other two ports can't even receive any packets. It should not the ECMP's purpose.

Thanks for this comment. Will look into this behavior and circle back.

[shi-su]

I think there is still a issue need to be addressed. If you check the accuracy ARP/NDP that the DUT learned, you can see all three IP neighbors will have the same MAC address. So it will always send to the port which has this MAC, the other two ports can't even receive any packets. It should not the ECMP's purpose.

The changes in this PR #3791 should address the issue for APR learned in ipv4 tests. For ipv6 tests, the neighbors seem to be right.