We exchanged the EX4200 now with EX4300. Software is 14.1X53-D35.3. Although this SW has some other difficulties with VSTP at least this issue is handled differently:
On EX4300 (or with Release 14.1X53D35, I cannot verify that) the ARP entry is magically refreshed on expiry.
schoberw@sw1s> show arp no-resolve vpn oam expiration-time MAC Address Address Interface Flags TTE 80:ac:ac:1e:a6:81 10.55.255.15 irb.5 [ae0.0] none 318 00:01:2e:6e:b5:66 10.55.255.100 irb.5 [ae0.0] none 108 08:00:27:98:3f:a9 192.168.44.100 irb.20 [ae0.0] none 157 Total entries: 3
If that entry to e.g. 00:01:2e:6e:b5:66 -> 10.55.255.100 is timing out, we see a single ARP request for the IP address on wireshark on the target host. I do not see any traffic to the IP address.
If I clear the arp entries (`clear arp vpn oam`) it is gone forever. Even after coffee break the ARP entry will not show up. So there is no traffic to 10.55.255.100!
This leads to the conclusion, that the EX4300 is keeping it's ARP entries alive somehow. I havent found a document yet describing this issue.
And by the ARP request the MAC forwarding table is kept alive as well:
schoberw@sw1s> show ethernet-switching table brief | match 00:01:2e:6e:b5:66
v0005 00:01:2e:6e:b5:66 D - ae0.0
v0990 00:01:2e:6e:b5:66 D - ae0.0
These entries are also not timed out on both stacks. This will prevent flooding traffic as well on asymmetric routing.
Although this is not perfect for the first packet it is sufficient for continues operation.