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.

Expected output, in VyOS 1.3.0-rc1 works fine

showvyos@vyos:~$ show int
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface        IP Address                        S/L  Description
---------        ----------                        ---  -----------
eth0             -                                 u/u  WAN01-pppoe
eth1             10.0.0.1/24                       u/u  LAN
eth2             192.0.2.12/24                     u/u  WAN02-dhcp
eth3             -                                 u/u  
lo               127.0.0.1/8                       u/u  
                 ::1/128                                
pppoe0           10.1.1.101/32                     u/u

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.

You can review the patch here

Also, It can't check that cmd on hypervisor

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

@Viacheslav we already have ip6tnl support.

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

Due to the limited ability to open a pull request on the linux kernel's github repository, I had to submit the patch to netfilter maintainers team by email.

@linuxludo Can you share a link?

It seems to be a BUG in netfilter conntrack module with GRE protocol over IPv6.
I patched the conntrack module and it now works as expected.
I just submit this patch to the netfilter maintainers.
Wait & See...

I've had this bite me a few times now as well, but I wasn't able to pin it down before to being a bug.

Please retest with the latest 1.4 rolling version. TTL can now be set.

It seems it some upstream issue

vyos@r-roll01# sudo ip tunnel add tun22 mode gre local 203.0.113.1 remote any 
[edit]
vyos@r-roll01# sudo ip tunnel change tun22 mode gre local 203.0.113.1 remote 203.0.113.254
add tunnel "tun22" failed: Invalid argument
[edit]
vyos@r-roll01#

For 1.4 the same fail
Config

set interfaces tunnel tun1 address '10.20.30.1/30'
set interfaces tunnel tun1 encapsulation 'gre'
set interfaces tunnel tun1 source-address '192.168.122.11'
set interfaces tunnel tun1 multicast 'disable'
commit
set interfaces tunnel tun1 remote 192.168.122.12
commit

Updated PR
I replace raw dhcpv6 global-parameters with leafNode.

Looks like it is not possible using udev: https://stackoverflow.com/questions/40676914/how-to-set-up-a-udev-rule-for-eth-link-down-link-up

@FileGo will be fixed in the next rolling release.

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

To reproduce, add one tunnel

I think it related T2651

ipsec policys, policy prefix-lists,

Additional info: it seems not to show any tunnel interfaces.

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

Works great, interface remains disabled on boot, as configured.

It seems a bug with your configuration. It is incorrect.

This seems to also happen with setting dhcpv6 as well.

I vote for option 1.

This also happens if you delete ipv6 address autoconf and commit. Where it will drop all IP addresses besides the target interface's.