Note: Mikrotik's RouterOS can add received IPv6 prefixes to a pool in its DHCPv6 client configuration, then the pool can be configured for DHCPv6 server to hand out addresses or sub-prefixes: https://wiki.mikrotik.com/wiki/Manual:IPv6/DHCP_Client

@Viacheslav This doesn't seem to be related. This PR is merged to 1.5 instead of 1.4.

@Apachez The empty table inet vyos_offload is to ensure the table exists before deleting its content. Regarding hardware offload, I don't have a hardware supporting that. The implementation is totally based on documentation and I don't add any checks before applying the nftables config.

Some extra lines were mistakenly included during rebase:

@fernando This is really nice. Thank you for the testing!

pim6reg is created by FFR's pim6d. It seems to me that it will create such as interface for each VRF. Does this interface have any functional impact on your setup?

@Apachez I am running kernel 6.1.49-amd64-vyos and this works fine with my local setup.
The patch is already in linux kernel since at least 4.3 (you can confirm with https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/include/net/netfilter/nf_conntrack_zones.h?h=linux-4.3.y), but it was added to nft command only since Feb 2017: https://git.netfilter.org/nftables/commit/src/ct.c?id=ed66d9966294a3bab6c8611e369861ba57374743

You can test this approach on a running VyOS router using following commands:

I created a PR to fix this issue by using direction parameter of conntrack zones: https://github.com/vyos/vyos-1x/pull/2236
I have a very basic VRF setup and it works fine. It would be much appreciated if someone could test this with more complex VRF setup.

https://github.com/vyos/vyos-1x/pull/2233 to fix the smoketest.

In T5518#159341, @Apachez wrote:

Something is broken in smoketest test_protocols_pim6.py:

https://github.com/vyos/vyos-rolling-nightly-builds/actions/runs/6133954453/job/16646294279

See "Run smoketests" line 28676 and forward.

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

https://github.com/vyos/vyos-1x/pull/2180 implement a workaround by changing the default values of stdout and stderr from PIPE to None.

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

I opened PR https://github.com/vyos/vyos-1x/pull/2062 for this.

A basic implementation: https://github.com/vyos/vyos-1x/pull/1800

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

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

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

PR https://github.com/vyos/vyatta-cfg-quagga/pull/98

1.3 backport https://github.com/vyos/vyos-1x/pull/1670

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

Created PR to fix this: https://github.com/vyos/vyos-1x/pull/1656
This issue also exists in 1.3 though I didn't backport it.

@aaliddell I am not too concerned about tayga's maintenance. It have been proved to work well for years, and the package is already a part of the official repository of debian. Actually debian's tayga package includes a few patches: https://salsa.debian.org/debian/tayga/-/tree/debian/master/debian/patches

Prototype PR using Tayga: https://github.com/vyos/vyos-1x/pull/1408

I would suggest going with tayga if this feature is planned to be implemented.

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

@c-po I opened https://github.com/vyos/vyos-documentation/pull/805

I already tested the PR before submitting:

@Viacheslav There is already a set interfaces bridge brN igmp node. If the default option is enabled, I think set interfaces bridge brN igmp disable-snooping would sound better.
I prefer to have IGMP snooping disabled as the default option, since improper IGMP snooping causes issues while disabling IGMP snooping doesn't.

PR to add the option: https://github.com/vyos/vyos-1x/pull/1378

I met the same issue. Currently bridge vifs are missing firewall options.

I created a PR to add those options to the config system, but I am not sure if anything else needs to be changed to support them: https://github.com/vyos/vyatta-cfg-quagga/pull/88

I'm also affected by this. My configuration has about 5k ip prefixes in network group for policy based routing.

@Viacheslav Hi, I saw it was fixed in current branch. Is there a plan to backport the fix to 1.3?