If commit is not initiated from a 'live' session (for example, on boot), then redirected stdout/err should go to a file.

Yes, radius is used for login.

If that works out wihtout an issue I would like to have it backported into 1.3 just to be more "fancy".

PR https://github.com/vyos/vyos-build/pull/147
Output on the local stand

Welcome to VyOS 1.4 (sagitta)!

I can't reproduce it

PR https://github.com/vyos/vyos-1x/pull/740

@Viacheslav
I guess the logs are from the dhcp-server and not from the client...

@tuxnet Can you describe the steps to reproduce?

also having lots of NAT rules makes the vyos config handling and boot time very slow..

Sorry, I don't have a GitHub account (I try hard to avoid centralized systems). If what you want is a git repo/branch to pull from, I can setup one somewhere and commit the patch there, though.

In T3338#87770, @zsdc wrote:

And it is necessary to leave a bug-report on the Proxmox bug tracker to lead this to the logical end. Could you do this?

Any chance you can send this as GitHub PR?

and indeed the fix works, I'm now able to add more than 215 dnat rules, and still fetch the config over the vyos http api! Thanks a lot everyone.

In T3337#87766, @c-po wrote:

• adding a cli node that passes raw config values from cli to the daemon is bad (we inherited this for dhcp and openvpn and it caused more harm then good in the last 2 years) - is this mandatory?

If I disable Xen PV drivers using "xen_platform_pci=0" from the host/dom0 side, and thus I get emulated e1000 NICs in the Xen HVM guest, then setting address to ethernet interfaces works ok..

PR https://github.com/vyos/vyos-1x/pull/739

It seems it works now

The ISC DHCP relay in VyOS is completely broken for my (non-GRE) use case, I would really like to see it get tossed out for something that works. This might not be the best place to describe my relay problems, but I might as well (skip this paragraph it you're not interested). My setup basically consists of the (ISC) DHCP server host connected to the VyOS router (running on a Dell R320), directly connected to a Cisco ASR920 router. Both VyOS and the ASR are directly connected to user VLANs (VyOS for firewalled/NATed zones and ASR for high-traffic users) and have DHCP relays set up targeting the DHCP server, such that the relayed messages from the ASR passes through the VyOS router towards the DHCP server and should get routed normally (i.e. ignored by the VyOS relay). The VyOS DHCP relay doesn't like this and starts spamming the DHCP messages up to ten or more times, causing wired clients to have to wait maybe ten seconds before getting an IPv4 address and wireless clients to just time out and abort the connection. I can provide the relay logs (mainly screenshots unless i dig up the disk I used) and VyOS config if anyone wants them, but as they have sensitive addresses, I don't intend to post them publicly. EDIT: I should mention that I didn't notice any problems while testing it with only myself, it was when 200 people started connecting the problems started occurring. And the DHCP server VM was not showing any noticable load.

@Viacheslav Looks like it is already fixed with newer release then VyOS 1.4-rolling-202102141111.
I can also add the interface with newer release.

As we use 7.5 in 1.4 now, we can implement that feature.

Start implementing this draft

Hmmm I retract that, apparently not in my configs. But that review indicates that a common pattern is to define the VRF at a global level, then specify an instance at the BGP level...

@c-po not in constrat to other verndors - I know that Juniper ERX allowed for different ASNs if in a VRF. I'll see if I still have some old configs.