Fixed in next rolling release.

Also, add some overhead netplug

top - 19:14:34 up 26 min,  1 user,  load average: 10.29, 13.17, 8.57
Tasks: 568 total,   5 running, 228 sleeping,   0 stopped, 335 zombie
%Cpu0  :  5.0 us, 10.6 sy,  0.0 ni, 84.4 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu1  :  9.8 us, 15.2 sy,  0.0 ni, 75.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu2  : 40.7 us,  3.0 sy,  0.0 ni, 56.2 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu3  :  9.6 us, 86.4 sy,  0.0 ni,  4.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :   3870.9 total,   1375.2 free,   1499.9 used,    995.8 buff/cache
MiB Swap:      0.0 total,      0.0 free,      0.0 used.   1716.8 avail Mem

PR for "current" https://github.com/vyos/vyos-1x/pull/764

Expected format @[2001:db8::2]:514

Looks good on 1.4-rolling-202103090218:

I kill the vm 80+ times.
All works fine.
@c-po can we "cherry-pick" it to 1.3.0?

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

Related task https://phabricator.vyos.net/T2362
A maybe better solution in this case to create interfaces like bridge and interfaces with an option which block adding link-local address.

PR https://github.com/vyos/vyatta-wanloadbalance/pull/10

i just tested that solution and it worked too. thanks!

@marcomuskus as a temporary solution try to use CLI sysctl param

configure
set system sysctl custom net.ipv6.conf.default.addr_gen_mode value 0
commit

Looks good on 1.4-rolling-202103080218:

Looks good on 1.4-rolling-202103080218:

vrf detected even it not created
https://github.com/vyos/vyos-1x/blob/dd35eb76153191bc487e3ea23c3e73c753ec1d4b/src/etc/dhcp/dhclient-enter-hooks.d/03-vyos-ipwrapper#L55-L59

root@r-roll01:/home/vyos# basename /sys/class/net/eth1/upper_* | sed -e 's/upper_//'
eth1v1

Wrong behavior

@trystan attach please configuration with sets, how to reproduce it.
For example

set param xxx option xxx..
set param2 xxx .option xxx..

And after commit... tc error..

For VXLAN multicast this is a real bug.

@Cheeze_It that's the new "normal".

For 1.2 this could be evaluated in the tunnels node.def file by something like:

@c-po, using a value of "0" for use inbound packet would actually be the best behavior if we can specify/use that.

I wonder why it is 1 by default now - we actually specify 0 which means "take it from the inbound packet". Nevertheless we need a migrator to mimic existing behavior vor users upgrading from 1.2 -> 1.3, so the migrator should simply insert ttl = 16 into the CLI.

The same with ports.
It will be fixed after rewriting the firewall to python.

Same thing on

vyos@vyos:~$ show vers
Version:          VyOS 1.2.7-epa1
Release Train:    crux

The same behavior happens with VyOS-1.3.0-rc1

vyos@vyos:~$ show vers

Submitted this PR to fix the issue:

I know my opinion is....really not that important but I would *highly* recommend going to maximum TTL of 255 or at minimum 127. TTL is a very hard thing to troubleshoot most of the time and therefore it's almost never worth going lower than maximum for IP TTL.

@c-po , yes now it works. Maybe we need to define ttl=16 as the default value?

FRR doesn't have such a function.

Backport to 1.3 done

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

VyOS 1.2 has this hardcoded: /opt/vyatta/share/vyatta-cfg/templates/interfaces/vxlan/node.def: VXLAN_TTL="ttl 16"

Issue also exists in VyOS 1.2.7-rc1

Unexpected redistribution for isis VyOS 1.4-rolling-202103040218

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

@c-po does not work on 1.4-rolling-202103040218

vyos@vyos# sudo ip -d link show dev vxlan241
7: vxlan241: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master br241 state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether fe:08:e3:3c:d4:ab brd ff:ff:ff:ff:ff:ff promiscuity 1 minmtu 68 maxmtu 65535 
    vxlan id 241 group 239.0.0.241 dev eth0 srcport 0 0 dstport 8472 tos inherit ttl auto ageing 300 udpcsum noudp6zerocsumtx noudp6zerocsumrx

On the middle router in traffic dump I see TTL=1

18:59:29.029090 IP (tos 0x0, ttl 1, id 24806, offset 0, flags [none], proto UDP (17), length 100)
    10.1.2.2.52948 > 239.0.0.241.8472: OTV, flags [I] (0x08), overlay 0, instance 241

There is a bug exactly with client-ip-pool range, config generated with the mistake

[ip-pool]
gw-ip-address=10.1.1.1
10.1.1.100-10.1.1.111

but expected

10.1.1.100-111

@primoz, I have exactly the same issue with "1.4-rolling-202103011828 (sagitta)"

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

I also attempted to fix this bug by writing to grub.cfg.new, calling fsync() on it, renaming it to grub.cfg, and calling fsync() on the directory. Unfortunately, I still encountered an unbootable system.

I attempted to fix this bug by journaling all filesystem data (ext3/4 mount option data=journal). Unfortunately, I still encountered an unbootable system.