Any news about this issue @SrividyaA and @c-po ?

The fix mentioned above has been backported to 1.4: T5996.

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"
+     }
+ }

Just as another data-point - I have found that leaving the DHCP lease to auto-renew itself (not me doing it manually) that it doesn't then add it to the routing table.
i.e. at the moment my DHCP client is still connected, but there's no default via the DHCP session at the moment.

The flowtable has to be set on ethernet interfaces only!
It does not need to set it to PPP/BOND/VLAN/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?

This is the result of buster-backports being removed from the main repository server: https://backports.debian.org/news/Removal_of_buster-backports_from_the_debian_archive/

In T5153#184332, @n.fort wrote:

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

Hi,
I was playing around with VyOS and thought i'd build myself an iso and hit this issue. Not sure if its the correct way to solve it, but this is what I did:

This will be resolved after backport of T5996.

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