I will close this task as a duplicate of https://vyos.dev/T4502 where work is in progress.

Using VyOS 1.5-rolling-202309170024.

So what remains is how to solve point 1.

It looks like point 3 can be taken care of:

Ok, I was thinking if that then waited for some password or such.

How does a simple "sudo bash" work?

Testing point 2 above with VyOS 1.5-rolling-202309170024.

This is the one I was thinking of:

This seems to have been resolved since a few days (1.5-rolling nightly).

Output of ps auxww | grep -i frr after proposed v3 is applied:

Update of proposed changes (Ill call them proposed v3).

Update of proposed changes (Ill call them proposed v2).

I can create a PR if everyone agrees upon the proposed changes above however I have limited capability to test each and everyone of these changes.

Proposed data/templates/frr/daemons.frr.tmpl:

PR created: https://github.com/vyos/vyos-build/pull/414

PR created: https://github.com/vyos/vyos-build/pull/413

1. Using hardware flowtable (flags offload;) on an interface which doesnt support it returns an error:

Tried to enable both software and hardware flowtable with VyOS 1.5-rolling-202309151051:

How does FRR/vrrpd work regarding SNMP compatability?

Note that PR2062 is broken.

Regarding testing of arm-builds, hopefully this article might come handy (how to use qemu-system-aarch64 (on x86) part of the qemu-system-arm package):

The excludes-file in PR406 had incorrectly a '/' as first character (for the directory to be excluded from the squashfs-file).

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

Should probably add "-M rpki" permanently to FRR/bgp.

Could the error from latest nightly be due to that rpki module isnt loaded for FRR/bgp?

Could https://vyos.dev/T2044 be related to the failed nightly build from last night?

This is still the case in VyOS 1.5-rolling-202309130022:

Suggestion of "hidden" ruleset (visible when doing show firewall and show firewall statistics):

PR created: https://github.com/vyos/vyos-build/pull/406

Found out that mksquashfs supports -ef EXCLUDE_FILE as a file that (line by line) defines which files and directories to be excluded during creation of filesystem.squashfs. Adding -wildcard will make it possible to use wildcards within the EXCLUDE_FILE.

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

Something like this console command but more handy in op-mode?

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

Turns out that the values who override the vyos-config values are set in /etc/sysctl.d/30-vyos-router.conf:

I can confirm that setting these values AFTER boot (and doing commit) they will be properly set.

Turns out to exist an RFC for this regarding IPv6 along with a naming:

Note that command = command.lstrip() for def cmd in python/vyos/utils/process.py was reverted yesterday.

I have created a PR upstream which hopefully resolves why the logging didnt work as expected in VyOS (since the binary_rootfs in vyos-live-build isnt used by the nightly build who uses vyos-build and the deb-package of live-build from Debian 12.x (bookworm)):

Checked with #netfilter irc-channel.

I was thinking about N/D and personally I would prefer "None" to be listed for the various "show firewall" commands instead of N/D.

Resolved by: https://vyos.dev/T5564

This can be put to resolved when the backports are confirmed aswell.

Confirmed working with VyOS 1.5-rolling-202309110651

Im a bit allergic to have stuff automatically created which clearly is not enabled by the config.

I dont know if its related to this task but I noticed recently that even if I have no IPv6 configured on any interface and have IPv6 disabled for forwarding:

set system ipv6 disable-forwarding

I can in VyOS 1.5-rolling-202309080021 see an additional pim6reg interface!?

vyos@vyos:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
...
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq master MGMT state UP group default qlen 1000
...
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq master INTERNET state UP group default qlen 1000
...
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq master INTERNET state UP group default qlen 1000
...
5: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq master INTERNET state UP group default qlen 1000
...
6: pim6reg@NONE: <NOARP,UP,LOWER_UP> mtu 1452 qdisc noqueue state UNKNOWN group default qlen 1000
    link/pimreg 
7: INTERNET: <NOARP,MASTER,UP,LOWER_UP> mtu 65575 qdisc noqueue state UP group default qlen 1000
...
8: MGMT: <NOARP,MASTER,UP,LOWER_UP> mtu 65575 qdisc noqueue state UP group default qlen 1000
...

Its also visible when running:

monitor bandwidth interface *

Latest run https://github.com/vyos/vyos-rolling-nightly-builds/actions/runs/6138721359/job/16655876943

Oh sorry, I missed that this commit was for LTS 1.3.x series.

Fix by @sever regarding those failing conntrack smoketest: https://github.com/vyos/vyos-1x/pull/2234

@vfreex the referenced netfilter patch is from 2015, is that really valid for current version thats included in the Linux 6.1 LTS kernel?

The failed smoketest test_interfaces_ethernet.py can be seen at:

The failed smoketest test_protocols_pim6.py seems to have been taken care of by:

Regarding the failing smoketest test_system_conntrack.py (test_conntrack_ignore):

Something is broken in smoketest test_protocols_pim6.py:

Still errors in:

Related: https://vyos.dev/T5513

Related: https://vyos.dev/T5311

PR created (fixes https://github.com/vyos/vyos-build/commit/a863fe0): https://github.com/vyos/vyos-build/pull/395

For the tests above, which configs are actually being used?

Some observations:

Using VyOS 1.4-rolling-202309070021.

Related to https://vyos.dev/T5514 ?

Could please the vyos_debconfig files be updated aswell?

PR392 was merged in VyOS 1.4-rolling-202309070021.

In case there are other just like me who didnt know about "action continue":

Something else to consider is to increase the readcache of squashfs by changing this:

Looking at the kernel configs from both arm and x86 arch:

So what needs to be done is to copy that block and make a separate question regarding:

According to https://github.com/vyos/vyos-1x/blob/current/src/init/vyos-router it should be named:

There is a similar case going on at the forum with different workarounds which might help?

I think that would be a bad idea comparing to other vendors where you can select if you want to do IPv4 routing and/or IPv6 routing. If both are disabled the device will only do switching/bridging.

Ehm, are you sure you operate on the correct config?

Well in that case it boils down to if the FRR/vrrpd supports namespaces, various tracking (interface etc) aswell as multicast vs unicast which keepalived seems to support them all.

One can enable snmp module through:

I will put this as resolved under protest :-)

I dont know if something would break to run migrate from within another VyOS version but you could test something like this, preferly from last version that worked without errors ("5: 1.4-rolling-202306030305"?):

What VyOS version did you have there?

Note that regarding qdisc it seems that qdisc=fq_codel is nowadays supported according to:

If the FRR/vrrpd is good enough then the main benefit is that the FRR/vrrpd is already included so no need to also include and use keepalived (unnecessary files and binaries and dependencies).

Using the config you provided in Slack I managed to trace the error (or I think so):

I dont agree this is resolved.

Memtest86+ can easily be included in the iso by altering the lb_config_tmpl variable in https://github.com/vyos/vyos-build/blob/current/scripts/build-vyos-image

I think VyOS might need to accept as default traffic to/from localhost towards itself for both IPv4 and IPv6.

Might be related: