So the root cause here is that vrf.py runs prior to vrf_vni.py where the first one eliminates all vni configuration within FRR.
The main reason for this weird logic is T5492.

I just did a quick search - it doesn't seem like dnsmasq supports option 82 when acting like a relay.

I tried to extend the range, and seems it also relies on nftables conntrack zones

vyos@r4# compare 
+ vrf {
+     name blue {
+         table "4294967295"
+     }
+     name red {
+         table "1"
+     }
+ }

The flowtable has to be set on ethernet interfaces only!
It does not need to set it to PPP/BOND/VLAN/WG?etc, as it will work anyway.
We need to hardcode it only for ethX interfaces, because people use it incorrect.

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

Precreate the interfaces used in the bond and the bond itself. I used the hw-id to create my interface because it seemed like the best minimal config option, not sure if it's required or not.

I have the same issue, running a locally built 1.4-rolling-202403240547.

Perhaps Im missing something here but where is Option82 information included (injected into the DCHP-request reaching the DHCP-server)?

They switched to the OpenBSD fork of dhcrelay (I still have a router running OPNsense to test some stuff) 🙂

Here is a post from an OPNsense forum administrator in august 2023 (dunno if the below is still valid for OPNsense):

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

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

While I do somewhat agree on that, having more than one to choose from, for everything, is going to be a maintenance nightmare.
If you have just 5 things with 2 packages to choose from, you already have 32 different combinations to support.
Having something else than everyone else sounds great, but again, people are not going to switch due to a vuln being found - they are going to push for a fix for it instead.

When evaluating proper replacement (other than choosing the best one for the task) another thing to consider is, if possible, to select something that not everybody else uses in terms of if/when a vuln is found in that softrware then not ALL vendors are affected at once.

Depending on how BSD dependent the OpenBSD one is, that might be the easiest drop-in replacement.
Otherwise I would suggest going for dnsmasq, since it is quiet small and well maintained. (not saying the other projects aren't being maintained, but I don't know about them)

I just built and tested with the latest sagitta commits, and it is preventing it now as expected.
So I would say it can be closed as fixed, since it has been fixed some time between November and now.

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

Tested as working in: VyOS 1.5-rolling-202404190019

And do you have similar setup and situation in newer version?

In T5153#184332, @n.fort wrote:

Output seems to be for VyOS 1.3, rather than 1.5
Can you show VyOS version @PeppyH ?

Output seems to be for VyOS 1.3, rather than 1.5
Can you show VyOS version @PeppyH ?

Test addresses have to be different

Provide the set of the commands to reproduce

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

Not reproduced on VyOS 1.5-rolling-202404141045

vyos@r-left# set pki ca "my test ca name" certificate 'MIIDnTCCAoWgAwIBAgIUFvyB2rY0V1V6AaIpPWHCftGRwN8wDQYJKoZIhvcNAQELBQAwVzELMAkGA0IxEzARBgNVBAgMClNvbWUtU3RhdGUxEjAQBgNVBAcMCVNvbWUtQ2l0eTENMAsGA1UECgwEVnlPUzEQMA4GA1UEAwwHdnlvcy5pbzAeFw0yNDA0MTgxMTM3MzZaFw0yOTA0MzZaMFcxCzAJBgNVBAYTAkdCMRMwEQYDVQQIDApTb21lLVN0YXRlMRIwEAYDVQQHDAlTb21lLUNpdHkxDTALBgNVBAoMBFZ5T1MxEDAOBgNVBAMMB3Z5b3MuaW8wggEiMA0GCQEBAQUAA4IBDwAwggEKAoIBAQCKEVxs7gdzmnN4iMinvXN1vdGaT+v3TOnHSXbBkWHnt9YdWmo8UoqFpVqyVM3E8xmoT+3HOXJeWkKArEpMkGo93kWaGo0f25KGEFWbS2ttgNA9cqH9PGa42XTKyTY+5ZoIWaQQzNNiUSaIoslRrMSV4V2yQs90ECxR37ezlV2RAIHEhZ6mizUkMkuSmdjqRolh2tpF1MoisyhspFPXBC6lJ8d0jFZEi1tP3tlQjqVEWPjTvtddy34iOLFeUjBF5cOwfmpVLzWBVLbIxJr5ZHamGeQIabn36Jg1u0+/6p7hb8avqBW4dT0K8UykWVqgjQ4W4rM7AgMBAAGjYTBfMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAgGGMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDATAdBgNVHQ4EFgQUxEx+IVaoLb7M/SW9AkCVRaXCNTUwDQYJKoZIhvcNAQELBQADggEBAGjV6WiH4Z+hfdANG8oWgY0xsHmUZg8dCjwqO5GMwjBVIuu8GuoZu0JobtLa097behWcgCkwjvKBffuwCu542WbFkxdXzBLZjSAc+K3itegZIuy4jqRO5z6Q0IbPSaFUhR4HhfwejwlyXgjNCFzEMzwoDL2/3PXjWyilkqthYyFcx092tgwiXtnfO9z9Xm/YQHQmRG2VWzLEwucOhV698xnqFgRJk3uKqcDN9KjF+5v32OQ0eis7GHn1aJim5aUee1nnCRFdQO0llNJRwF6fIaICzKLwa7zzMjF7HhRehh5kpwY8omcQX7xYz7GJag4='

@dotAndy Is it still relevant?
Can you create a PR?

It would be handy if the GARP announcement wouldnt be a separate list but rather picked up from any DNAT or SNAT rules.

From initial PR these two feedback points are now implemented. PR has been amended see https://github.com/vyos/vyos-1x/pull/3307

I think I might've found the cause of this issue: the vni is unset from all VRFs when making changes. I posted a message about this on Slack (and about another, fairly similar, issue) on Slack about this.

Just checked with the current rolling release 1.5-rolling-202404141045. After committing set high-availability disable, keepalived is successfully stopped and the logs show that the transition script seems to be executed: