@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.

Please retest using the latest ISO image, fix is in there

It used different scripts in 1.3 and 1.4.
show interfaces => run: ${vyos_op_scripts_dir}/show_interfaces.py --action=show-brief
show interfaces vrrp => run: ${vyatta_bindir}/vyatta-show-interfaces.pl --vrrp --action=show-brief

Giving the nature of the nesting of node.def files and their execution pattern this can not be fixed in 1.2.

Frr doesn't provide such option for ipv4, only for ipv6

It does not work when established / invalid rules are at the top of the access list in any order. This works if the invalid state rule is positioned after the GRE rule, but this is not an expected behavior.

Try to place that rule after established, for example, number 25

Duplicate T3349

Update pr