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

ahh.. looking at it now it looks like the new upstream DTB uses lanX for all "lan" switchports..

Enumaration order and names are specified here:
DSA switch ports: https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts#L408-L459
CPU Ethernet ports: https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts#L171-L198

@Apachez no, they are not mapped by hw-id, all mapping of DSA ports are done by the DTB file (Hardware Device Tree) loaded into the kernel. also the enumeration order of cpu ethX interfaces are specified by the DTB file

Does all the interfaces at bananapi represent a hw-id which can be used to map to the ethX syntax of VyOS?

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

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

Re-Opening. this need to be extended to bridge firewall

I would like to contribute with a PR about this. At the same, time I would need some guidance on identifying the conditions requiring the onlink option to be added.

https://github.com/vyos/vyos-1x/pull/2495

I have a similar setup where I have two VyOS VMs used as VPN routers with some firewalling enabled. Since I use OSPF for dynamic routing I am not able to synchronize the sessions between both routers so in case one VPN router fails the other one can't take over flawlessly. Having conntrack-sync configuration separated from VRRP would be a great benefit.

This can be done in other areas such as firewall rules already:

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

vyos@r4# run show interfaces summary 
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface    IP Address         MAC                VRF        MTU  S/L    Description
-----------  -----------------  -----------------  -------  -----  -----  -------------
dum0         203.0.113.1/32     96:44:ad:c5:a1:a5  default   1500  u/u
eth0         192.168.122.14/24  52:54:00:f1:fd:77  default   1500  u/u    WAN
eth1         192.0.2.1/24       52:54:00:04:33:2b  foo       1500  u/u    LAN-eth1
eth1v10v4    10.10.10.10/24     00:00:5e:00:01:0a  foo       1500  u/u
eth2         -                  52:54:00:40:2e:af  default   1504  u/u    LAN-eth2
eth3         -                  52:54:00:09:a4:b4  default   1500  A/D
eth4         -                  52:54:00:2c:51:09  default   1500  A/D
eth5         -                  52:54:00:f3:1d:e8  default   1500  A/D
lo           127.0.0.1/8        00:00:00:00:00:00  default  65536  u/u
             ::1/128

looks great from my perspective (I've just updated our nodes. Tested on Community Edition client on windows and Connect V3 client on windows and Tunnelblick on Mac all working as expected. (I tested with; 1.5-rolling-202311150738).
nice work!