Yes! Turns out the following is what fixed it:
https://phabricator.vyos.net/T2980

All of ours do as far as I know, which includes 10,40, and 100g. I'm pretty sure 2.5g and 5g will as well.

Works for me!

trae@cr01b-vyos:~$ show protocols bfd peers
Session count: 11
SessionId  LocalAddress                             PeerAddress                             Status         
=========  ============                             ===========                             ======         
3776760774 192.168.253.3                            192.168.253.7                           up             
1851352402 fd52:d62e:8011:fffe:192:168:253:3        fd52:d62e:8011:fffe:192:168:253:6       up             
3344115206 192.168.253.3                            192.168.253.2                           down           
1252680903 fd52:d62e:8011:fffe:192:168:253:3        fd52:d62e:8011:fffe:192:168:253:2       down           
3664188082 192.168.253.3                            192.168.253.6                           up             
2809207409 fd52:d62e:8011:fffe:192:168:253:3        fd52:d62e:8011:fffe:192:168:253:1       up             
2086113021 192.168.253.3                            192.168.253.12                          up             
1362288442 unknown                                  fd52:d62e:8011:fffe:192:168:253:12      down           
3846665654 fd52:d62e:8011:fffe:192:168:253:3        fd52:d62e:8011:fffe:192:168:253:7       up             
276439511  fd52:d62e:8011:fffe:192:168:253:3        fd52:d62e:8011:fffe:192:168:253:12      down           
1342044518 192.168.253.3                            192.168.253.1                           up

That sounds great to me! I actually like that more.

awesome, thanks!

Try a show ipv6 route ospfand look at the routes; they're probably being rejected:

trae@cr01b-vyos# run show ipv ro ospf
Codes: K - kernel route, C - connected, S - static, R - RIPng,
       O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table,
       v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR,
       f - OpenFabric,
       > - selected route, * - FIB route, q - queued route, r - rejected route

Can regression testing of some sort be added for this? I've seen this issue crop up before now, so I would guess this is a good candidate for that if possible.

Closed - this is available as set system ip layer4-hashing

Oh, neat. Thanks, I'll close this then!

This appears to be caused by the setting of service ssh listen-address; it appears the script generating the config is omitting the actual address. Removing a specific listening address is a temporary workaround.

Actually I think this is a result of T2434 since the source interface is bond1, so I'm closing this again. My apologies.

@jjakob This doesn't appear to have been fixed in VyOS 1.3-rolling-202005130117

That build was given to me to test in #lobby by Thomas Mangin, so he may be able to tell you more about it if needed.

Yup that did it. Thanks!

That fixed it for me. Thanks!

Just tested this using 1.3-rolling-202004201924 and it still happens, so that doesn't appear to have worked.

show dhcp server leases now works, but I've found show dhcp server statistics is broken as well:

vyos@cr01b-vyos:~$ show dhcp server statistics
Traceback (most recent call last):
  File "/usr/libexec/vyos/op_mode/show_dhcp.py", line 243, in <module>
    leases = len(get_leases(lease_file, state='active', pool=p))
TypeError: get_leases() missing 1 required positional argument: 'leases'

I'd also recommend not using a variable named stdout later on since it's very confusing (easily confused with sys.stdout, which took me a minute to figure out).

I've found that on the most recent releases of VyOS, Netflow flow-accounting is also broken. I've managed to fix the first 2 errors I encountered and verify uacctd is indeed running; however, if IPv6 is used, another error is encountered which I did not fix. I also probably did not fix Sflow entirely with these changes.
Initial error:

vyos@cr01a-vyos# commit
[ system flow-accounting buffer-size 2048 ]

Any reason in particular you're not using crypt.crypt() here?

Shouldn't it be fixed at some point though? I mean is there a reason this should stay something that has to be worked around?

Confirmed here as well, I had a working config back on 1.2.3 and it broke when I upgraded to 1.3. This is what happens when I try to commit:

@kroy I tried just now with vyos-1.3-rolling-202001160217 in UEFI mode (even forced UEFI boot only in the BIOS to make sure) and am still having the same problem.

In T1869#49212, @hagbard wrote:

Looks like an issue with the raid metadata and grub, problem confirmed with virtual box. Tested, latest rolling, 1.2.3 and 1.2.4-epa1.

@Dmitry yes, I tried 1.2 rolling as well. I have not been able to try 1.2.3 stable due to a lack of access.

Have a screen recording 😄

@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 deleted comment I made above 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.

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.