Comment 12 for bug 1463831

(con'td). As it has been stated above in thise defect report, it is actually very dificult to reproduce because the sistuation has to be artificially created so the router does not create any traffic at all.
The question is not really weather or not this can happen. It is how easy is the trigger to reproduce. ip traffic is always simplex. It goes from ip a to ip b. There is no gurantee anywhere that the traffic will take the same path back in the case of a tcp flow. Which means I can actually reproduce this behavior in a regualr vanilla network. For example, with a pc connected to two routers, one is the outgoing gateway, and the other is the incoming gateway. In that case there could be a situation where you can make the physical switch behave in the exact manner that br-int is doing here.
But those situations usually don't arise because there is a plethora of other traffic type (not necessarily ip but other type of ehternet traffic) which causes the mac address to be populated in the mac-table of the switch.

The same applies here, the router might not be talking to the vm, but it might be talking to something else.

But your point is valid. if this situation is quite common, and the trigger occurs quite often, then perhaps it is a good idea to try to mitigate this behavior.
But even in this case, the vm itself usually will send an arp request because its arp table has a time limite as well.
So you see, I am not saying this is not possible, I am just questioning if how oftent it happens, and if there is already not a solution built into the protocols being used (tcp, icmp, ethernet, etc..) which might alivitate this problem already.