Pretty sure some preceding backports are pending. Please give me a couple of days. I plan to sync up 1.4 with 1.5 and update the docs.

We'll discuss this internally, but for sure a fix should be applied.
Thanks for such a detailed bug-report.

PR https://github.com/vyos/vyos-build/pull/459

Agree with @Viacheslav and @GurliGebis comments above.

I agree, without it, you end up repeating yourself alot, with the established, related and invalid rules.
As long as they are applied before the zone specific rules (which is how I guess it used to work), it makes sense.

Should we return global state policy?
It was useful.

Backport to 1.4 has conflicts https://github.com/vyos/vyos-1x/pull/2533

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

@Viacheslav
I missed running git pull on my ansible execution node. Works as it should. Thank you!

A fix that changes the behavior back to it was https://github.com/vyos/vyos-1x/pull/2527

PR for bridge: https://github.com/vyos/vyos-1x/pull/2528

Works fine

$ curl -k --location --request POST 'https://192.168.122.11/reboot'   --form data='{"op": "reboot", "path": ["now"]}'   --form key='foo'
{"success": true, "data": "Warning: there are unsaved configuration changes!\nRun 'save' command if you do not want to lose those changes after reboot/shutdown.\n\n", "error": null}

@a.apostoliuk will be available in the next rolling release.

I had the below set on the pppoe interface to allow for DHCPv6-PD. That part was working fine it was just the pppoe interface that wasn't picking up an address:

This is related to Kernel addr_gen_mode beeing globally disabled. It's actually on my "to refactor list" and with this bug it gainer priority!

PR2518 submitted

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

I need to requst subnet-mask, routers, rfc3442-classless-static-routes

Did you try it?

set interfaces pppoe pppoe1 ipv6

If someone will implement it, there was a discussion https://github.com/vyos/vyos-1x/pull/2488

Draft PR for 1.5 https://github.com/vyos/vyos-1x/pull/2508

This PR LGTM as it addresses my main need, although I think it'd be better to add support for the rest of options from RFC 2132 (eventually).
When talking about request as an option I'm talking about adding a way to add a request (or also request) statement to dhclient.conf. I need to requst subnet-mask, routers, rfc3442-classless-static-routes from my ISP, and the current implementation doesn't allow me to do that.

dhcp-server's raw parameters, which would pass options to dhclient as-is

oh okay. I don't know what else to do. this is difficult to replicate and it's scary if this happens when i am not at home and primary wan is also unavailable.

kea-dhcp will only be the server, not the DHCP client that you use here, I am unaware of a Kea based DHCP client.

This has happened 2-3 times since my last comment. I'll keep this open until kea-dhcp is merged and then check if this bug remains.

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

I agree, even if its "odd" at first sight I like that all interfaces are named ethX within VyOS and then its a matter to map each to physical interface by hw-id (which is done automagically during first install but can be remapped if wanted).

I am against this change, why not use eth0 everywhere? If it's a WAN or LAN port should be user decidable. Please use udev rules to rename those interfaces to eth0...ethXX