[test_unknown_mac] Fix issue with MAC being present in FDB after fdb flush

[vcheketx]

Description of PR

Summary:
Fixes # (issue)

Type of change

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

Approach

What is the motivation for this PR?

Test uses ping command from PTF to populate ARP on DUT, then clears FDB to emulate unknown_mac behavior.
Partial output of tcpdump during ping:

09:24:16.707355 ARP, Request who-has 192.168.0.1 tell 192.168.0.2, length 28
09:24:16.708029 ARP, Reply 192.168.0.1 is-at fc:bd:67:62:4b:60, length 46
09:24:16.708059 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 1875, seq 1, length 64
09:24:16.708478 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 1875, seq 1, length 64
09:24:17.707817 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 1875, seq 2, length 64
09:24:17.708237 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 1875, seq 2, length 64
09:24:18.731876 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 1875, seq 3, length 64
09:24:18.732507 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 1875, seq 3, length 64
09:24:21.747609 ARP, Request who-has 192.168.0.2 tell 192.168.0.1, length 46
09:24:21.747652 ARP, Reply 192.168.0.2 is-at 40:a6:b7:22:af:18, length 28

There is a secondary unicast ARP request from DUT 5 seconds after start to verify that ARP entry is still valid.
FDB clear command is executed between ping start and this secondary ARP. This causes removed FDB entry to be re-added, resulting in test failing with following error:
Failed: 40:a6:b7:22:af:18 present in FDB

How did you do it?

Added 5 second timeout after ping command.

How did you verify/test it?

Run pfc/test_unknown_mac.py

Any platform specific information?

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

Documentation

[bingwang-ms]

Thanks for the fix. But I'm not very clear why the second ARP request for IP 192.168.0.2 was sent? Why the delay is 5 seconds?

[vcheketx]

Thanks for the fix. But I'm not very clear why the second ARP request for IP 192.168.0.2 was sent? Why the delay is 5 seconds?

@bingwang-ms From what I understand, second ARP request is an ARP probe, sent by DUT to verify that entry for 192.168.0.2 is still valid.
Regarding 5 seconds delay, ARP man page shows that default timeout before sending first probe is 5 seconds. I checked this on DUT:

cat /proc/sys/net/ipv4/neigh/Ethernet4/delay_first_probe_time
5

[bingwang-ms]

Thanks for the fix. But I'm not very clear why the second ARP request for IP 192.168.0.2 was sent? Why the delay is 5 seconds?

@bingwang-ms From what I understand, second ARP request is an ARP probe, sent by DUT to verify that entry for 192.168.0.2 is still valid.
Regarding 5 seconds delay, ARP man page shows that default timeout before sending first probe is 5 seconds. I checked this on DUT:

cat /proc/sys/net/ipv4/neigh/Ethernet4/delay_first_probe_time
5

Make sense to me. Thanks