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.

Unfortunately I can not connect the dots between "still the same process" and set protocols bgp <asn> vs. set protocols vrf <vrf> bgp <asn> (I explicitly left the "move bgp tagNode to node with local-as" topic out of the discussion as this is something different and is addressed via a different task)

Ahh.. yea, i see that now.. i've never done this, so cant say how it work.. but as i can se this is still the same process, so my answer is still the same.... Actually this migth be a good reason for migrating set protocols bgp <asn> to its own local-as <asn> subnode, so the AS is not hardcoded in the configpath

FRR actually supports configuring a different ASN per VRF in contrast to other vendors

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]