VXLAN test: Test DUT against reference implementation (FRR) instead of against itself

[jbemmel]

This allows for the introduction of an OSPF check, clarifying delays a bit. It also guards against a theoretical possibility of devices that only interop with themselves

Proposal in the context of #2254

[ipspace]

Makes perfect sense. Will merge once the integration tests I'm running finish.

The once change you should make is to increase the STP timer to 30+ seconds (35 should do the trick). It takes 30 seconds for STP to go from "learning" to "forwarding" and sometimes OSPF starts surprisingly fast.

Also, it would be nice to add the STP time to the wait_times (for example, as stp_forwarding)

[ipspace]

OK, I'm back ;) and would like to discuss the bigger picture before merging a variant of this (adding @ssasso to the discussion):

A) The same change (one DUT, one or more FRR nodes) should be applied to all VXLAN tests (no worries, I'll do that)
B) That changes the meaning of "VXLAN works" (as in: between identical devices) to "VXLAN works with FRR". I think our FRR VXLAN implementation is solid enough to be a reference implementation (and of course I'll run the full set of integration tests before merging whatever we agree upon).
C) The "multivendor" test becomes obsolete.

Anything else I've missed?

[jbemmel]

B) That changes the meaning of "VXLAN works"

Since the EVPN tests are already structured like this (for the most part), the above is limited to "static VXLAN works" (and shouldn't be a big issue given that the EVPN tests pass)

Some EVPN tests (like 20-vxlan-irb-ospf.yml) could be converted too