@zsdc It looks like after boot the DHCP DNS and search does indeed disappear, it just appears to take a minute, so I guess this can be closed (though it seems odd it would get added at all, but I guess that's alright).

@zsdc:

Please reopen T1786 in case of further troubles.

I can't so I've reopened this one; I don't have permissions to do this :(

This is still broken for me on the most recent 1.3 rolling releases:

Hey, the comment I made above (which is now deleted) was incorrect, this works on 1.2 rolling, it is still broken on 1.3. Sorry for the confusion.

It looks like the domain and search are now working (and not showing the DHCP one as expected, so that is fixed too), but the DHCP nameservers are still there:

So just an update, this issue is still present on more recent VyOS 1.3:

It looks like this is indeed fixed now!

Just a note, I updated my docs above cause they were missing the OSPF+OSPFv3 portion of the interface config that enabled BFD :)

I made a test lab at home for this, so let me know if you have any other settings or anything you need documentation for. Unfortunately my Arista device does not support multiple BGP instances at this time, so I've been unable to document BFD for BGP (I need a separate instance than my main one) so far, but I'll be trying other ways soon.

I have a VyOS <-> Arista configuration, which should be similar to Cisco, if that works for y'all?

Yes I'm currently utilizing the rolling releases in service after basic functionality testing, and so far BFD has worked flawlessly for all protocols I've tested.

This feature is currently in the 1.2 rolling release.

Just some feedback here, but this has been working flawlessly in all my environments so far for BGP, OSPF, and OSPFv3 ... you guys are awesome!

@hagbard This now works; I tested with 1.2.0-rolling+201904010337. Thanks!

Added a priority of normal, as this could potentially cause outages (situations where the interface comes up and causes an IP conflict, or causes dynamic routing issues due to the connected route)

This bug is confirmed present on 1.2.0 final release as well.

Just tested the most recent nightly (1.2.0-rolling+201902222123) and it works! Thank you so much y'all.

In T1259#33041, @varesa wrote:

Hopefully a fix: https://github.com/varesa/vyatta-openvpn/commit/a0d7c07f1ff0b5fe7450d3a13c1365b8e3589725
After doing: sudo curl https://raw.githubusercontent.com/varesa/vyatta-openvpn/a0d7c07f1ff0b5fe7450d3a13c1365b8e3589725/lib/Vyatta/OpenVPN/Config.pm -o /opt/vyatta/share/perl5/Vyatta/OpenVPN/Config.pm commit with my above config succeeds.