We have a new kernel

It is mostly impossible to use tags as each tag requires the same packages/binaries which were relevant for each tag

@Rhongomiant Is it still relevant?

It does not make sense to use it only in one VRF

Wontfix due to the old backend.

Merged

Please add and example of what you do.

@a.apostoliuk Could you check if it is implemented and close it

Cluster is deprecated and was dropped
for 1.4/1.5

Still relevant for 1.3.5

vyos@r1# commit
[ vpn ipsec site-to-site peer TST2 tunnel 0 ]
VPN configuration error: Can not use local-subnet or remote-subnet when using transport mode

We have moved to KEA-DHCP
Needs to check if it works for 1.5

XDP was a test feature and removed
The task is not actual

Needs to revisit
Close it for now, as the parent task is closed.

Fixed in 1.3.5

vyos@r1# set interfaces ethernet eth1 address '203.0.113.1/24'
[edit]
vyos@r1# 
[edit]
vyos@r1# set interfaces tunnel tun0 address '100.64.0.1/30'
[edit]
vyos@r1# set interfaces tunnel tun0 encapsulation gretap
[edit]
vyos@r1# set interfaces tunnel tun0 source-address '203.0.113.1'
[edit]
vyos@r1# set interfaces tunnel tun0 mtu '1500'
[edit]
vyos@r1# set interfaces tunnel tun0 multicast 'enable'
[edit]
vyos@r1# set interfaces tunnel tun0 parameters ip ttl '64'
[edit]
vyos@r1# set interfaces tunnel tun0 remote '203.0.113.2'
[edit]
vyos@r1# set system sysctl custom net.ipv4.conf.tun0.accept_local value '1'
[edit]
vyos@r1# commit
[edit]
vyos@r1# sudo sysctl net.ipv4.conf.tun0.accept_local
net.ipv4.conf.tun0.accept_local = 1
[edit]
vyos@r1#

Close it as wontfix for 1.3.
We use KEA-DHCP-server for 1.5
Reopen it for KEA task if it is necessary.

Fixed and not actual bug for 1.5:

vyos@r4# set interfaces bridge br0 member interface eth1.10
[edit]
vyos@r4# set interfaces ethernet eth1 vif 10 address 100.64.0.1/24
[edit]
vyos@r4# commit
[ interfaces ethernet eth1 ]
Cannot assign address to interface "eth1.10" as it is a member of bridge
"br0"!

Again, notifing upstream (or downstream) is not only about VRRP.

Wontfix due to the old backend implementation.

As to me there arping -q -b -c 1 -I eth0 -U -s 192.168.0.4 192.168.0.4 should to be in the transition script master of VRRP, isn't it?
What else we can do there?

Is not developed ~3 years
I don't think that it can maintain someone else except @thomas-mangin
Close as wontfix. Feel free to reopen if it is necessary.

Probably we can use this util https://github.com/azlux/log2ram/

GARP is needed for VRRP but the GARP setting is also needed when doing NAT.

Does this mean that only you can maintain it?
Did you try to add some of those changes to the upstream?

Logrotate just renames the logs so that doesnt bring many writes.

@dmbaturin Can we close it?

@chenxiaolong Thanks for confirming!

Could it be solved via hooks? https://github.com/vyos/vyos-1x/tree/current/src/etc/dhcp

Tested https://github.com/vyos/vyos-1x/pull/2857 and confirmed that it works properly now. Thanks for the quick fix!

After thinking a bit I suppose there is 3 possible solutions.

The minimal options were increased

There are no other reports
close it

Implemented

vyos@r4# set container name c1 
Possible completions:
   allow-host-networks  Allow host networks in container
   arguments            The command's arguments for this container
+  cap-add              Container capabilities/permissions
   command              Override the default CMD from the image

PR was rejected

Should work with route leaking

T5757

We need some examples of implementation or configs for it.

Mark as wont fix as we do not maintain the MIBs, should be fixed by upstream

Stil reproduced

vyos@r1# run show ver

@trae32566 Is it still the bug?