Tested as working in: VyOS 1.5-rolling-202404230019

In T6258#184716, @Viacheslav wrote:

Most likely needs to change priority to 319 for the sysctl

vyos@r4:~$ /usr/libexec/vyos/priority.py | match "ethernet|sysctl"
       300  interfaces_virtual-ethernet.py      ['interfaces', 'virtual-ethernet']
       318  interfaces_ethernet.py              ['interfaces', 'ethernet']
       318  system_sysctl.py                    ['system', 'sysctl']
       321  interfaces_pseudo-ethernet.py       ['interfaces', 'pseudo-ethernet']
vyos@r4:~$

What happens if another interface/value occupies the index 101?
For example, PPPoE-server and PPP interface can generate thousands of interfaces

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

It was filtered in https://vyos.dev/T2086 to avoid pam_unix mess

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

Can't reproduce it, close the task

Most likely needs to change priority to 319 for the sysctl

vyos@r4:~$ /usr/libexec/vyos/priority.py | match "ethernet|sysctl"
       300  interfaces_virtual-ethernet.py      ['interfaces', 'virtual-ethernet']
       318  interfaces_ethernet.py              ['interfaces', 'ethernet']
       318  system_sysctl.py                    ['system', 'sysctl']
       321  interfaces_pseudo-ethernet.py       ['interfaces', 'pseudo-ethernet']
vyos@r4:~$

I have asked the OP @canoziia to provide such in the forum.

Extend to <1-65535>
PR https://github.com/vyos/vyos-1x/pull/3353

What do I need to do to get these values?

root@r1-right:/home/vyos# sysctl net.ipv6.neigh.eth3/2.base_reachable_time_ms
sysctl: cannot stat /proc/sys/net/ipv6/neigh/eth3.2/base_reachable_time_ms: No such file or directory

I can only refer to whats unfolded on the forum at https://forum.vyos.io/t/how-to-set-net-ipv6-neigh-etha-b-base-reachable-time-in-vyos/14304

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

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

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

@Viacheslav or another of the Maintainers:

Could you provide the full set of commands to reproduce?

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 ?