@c-po confirmed, works OK in vyos-1.3-beta-202102250443-amd64.iso. Thanks a lot!

Put in a PR for this, https://github.com/vyos/vyos-1x/pull/744

This should have been fixed in the latest 1.3 beta - please try again

It seems the same problem (lack of "ethtool -g" support) happens also with "veth" interfaces.. ref T2516

I'm seeing the same problem with Xen HVM guests, where the paravirtualized nic-driver "xen_netfront" doesn't seem to support "ethtool -g".. ref T3347

I can confirm this bug is still present in the latest 1.3-rolling-202101 snapshot as well as the latest stable release. (1.2.6-S1)

Better not touch crux ;)

ok, I'll do it

@craterman can you check this feature in the latest rolling or beta?

PR for equuleus | extended smoketest
https://github.com/vyos/vyos-1x/pull/743

VyOS is still on the ancient shell-based diagnostic file generator spaghetti inherited from Vyatta. First of all, I'm going to dike out {show,generate} tech-support from vyatta-op and write a rudimentary stub as a replacement in Python/XML. Then we'll need to discuss what exactly needs to go in there.

@c-po , it works properly

Welcome to VyOS 1.4-rolling-202102240218 (sagitta)!

PR https://github.com/vyos/vyatta-cfg-quagga/pull/71
Can be "cherry-picked" to equuleus

PR for equuleus for bgp and ospf https://github.com/vyos/vyatta-cfg-quagga/pull/70
PR for equuleus for rip https://github.com/vyos/vyos-1x/pull/741

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..

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.

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.

On 1.3-beta-202102210443 and 1.4-rolling-202102202002 all work properly and don't require any changes, mark as resolved.

I found a similar issue related to this topic in 1.2.6-S1, script on-dhcp-event.sh can't to determine pdns_recursor PID

vyos@vyos# ps ax | grep pdns
 6626 ?        Ssl    0:00 /usr/sbin/pdns_recursor --daemon=no --write-pid=no --disable-syslog --log-timestamp=no
[edit]
vyos@vyos# pgrep "pdns_recursor"
[edit]
vyos@vyos# pgrep pdns_recursor
[edit]
vyos@vyos#

We need to use pgrep pdns

vyos@vyos# pgrep pdns
6626
[edit]

Which VyOS CLI command enables LRO?

Hi, I have tried these set of configuration and the openvpn connection was up and working fine.