Hi, on the latest VyOS 1.2.0-rc9 the command:
set protocols bgp 65010 parameters default no-ipv4-unicast

I'm going to verify @dmbaturin patch to set level to info. Additionally we could also use immark, which leave a 'heartbeat' marker in the logfiles, so one can verify logging at least works. It would be visible to remote logging as well.

Sorry, I just overlooked it.

It's not really a bug, the log level is per default set not to log everything, like @EwaldvanGeffen stated above.
'set system syslog global facility all level all' will log everything, embedded users with flash drives will hate us for this if we change it :).
In my opinion, if someone needs to debug anything, he/she can just set the global logging or even to a particular file for debugging.
Otherwise, we can just change the section in the default config to have logging anything enabled per default, which increases the risk for losing information due to disk space limitation for /var/log as well as the quicker rotation (only 5 files are being stored per default).

The functionality is fixed in 1.2-rcX for ARP, I haven't verified other services such as DNS.

@dmbaturin install_routes = 0 not present in rc3

bmon was always there, it's in the dependencies of vyos-1x.

I've made a workaround for it. I've also reported the root cause to FRR: https://github.com/FRRouting/frr/issues/3215

Luckily it never actually made it to 1.1.8 because the commands are badly broken. ;)

FRR appears to include this fix already, so this should be automatically fixed.

This issue appears to no longer be reproducible.

It appears to work now:

Nightly builds are not signed... for better or worse. It wouldn't be too hard to automatically sign them with the development key, but should we?

The root cause is that Quagga and FRR 5.1-dev didn't mind changing settings for non-existent interfaces, but FRR 6.1-dev does. The "ip source-validation" should have always been affected though.

@Merijn I could not reproduce the issue with any of my configs, so I can only suggest two options: either you can make an anonymized version of your config with all AS and network values replaced with those from private ranges (but please make sure the issue is still reproducible with that config); or you can send the actual config to me privately under a promise not to share it with anyone or a formal NDA.

Problem is partly fixed in the latest rolling release. Only this manual step is required in addition at this time:

Hello, we have the same (or similar) problem. After replacing Zebra by FRR, we can't get information from VyOS about BGP Peer status via old SNMP OID.

not sure if it ever worked (without manual manipulations with root user)

Okay - I just see that the allow-root feature wasn't working anyway since the SSH XML rewrite.

Both SNMP and TFTP now print a warning. In a subsequent step we could change this to be an error on commit and introduce a migration script deleting invalid addresses to not kill currently deployed configs!

Remove.
to make root working you need to set a password for it so just this command does not do anything
and most of the automation systems now can elevate privileges

I will implement at least a warning message for the user. Enforcing proper IP addresses could break old comfigurations - or they should be deleted by a migration script and then we can print proper error messages.

oth deletion and alias is ok for me. @syncer?

Remove or not remove?

@hagbardI like that idea
maybe it's time to rewrite show/generate tech-support to python

What about adding the package list of all installed packages to 'generate tech-support archive'?
It adds already:

Wasn't an issue, it's handled properly via frr.