I'd personally recommend "pmtu-discovery-disable", but either would be fine.

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

Proposed CLI

set interfaces tunnel tun0 parameters ip disable-pmtu-discovery

@Dmitry Thank you for correcting. I may have got it wrong

@victorhooi try to build a stable version for yourself, on the stable version is defined by udev rules https://github.com/vyos/vyos-build/blob/crux/tools/vendors_udev/64-vyos-SAF51015I-net.rules
Or you can use way with binding hw-id as noticed @jack9603301 (but not mac)

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

@c-po https://github.com/vyos/vyos-1x/pull/668

@c-po has also tested an iso from the above branches, notably testing a vyatta-wanloadbalance configuration. It had been presumed that the listed dependency of vyatta-wanloadbalance on vyatta-config-migrate was a legacy error, as there were no explicit dependencies, but it required a sanity check. I will merge via PR's, in order to better track the changes over the 3 required packages.

Put PR for segment routing addition:

Thanks for that. However, encapsulation ip6gre is nowhere to be found in a documentation search on readthedocs.
As to why it got tased VyOS Manager, the tag was automatically inserted when I created the issue and no alternatives were offered by the UI at my userlevel.
Apologies for my ignorance, I am relatively new to VyOS though quite experienced with IPv6 and with routing in general.
Respectfully, I suggest reopening this ticket and recategorizing it to documentation appropriately so as to get the documents brought up to speed with the implementation.

@maznu I've also been looking at switch to Mellanox cards after my experience with Intel. It's not as if this is a mass consumer product with end-users that don't really know what they're doing. It's a product that's most likely supported by IT/network staff that get to influence purchasing decisions for equipment like this.

@drac, while yes that is an option I am unsure which VyOS should as a software package should use.

Or you could implement import and export policies for BGP, which is what I did.
We already had export policies but it is good practice to have both.

So, this option can be disabled here per the FRR manual:

Just tried this with 7.4 yeah, issue persists. Using 7.3 which is also in the LTS version for so long...

This is due to RFC 8212, which was added on FRR 7.4. Please see here...

Reverting back to 7.4 series until those are resolved.

This infact hit me, too which is super annoying and could kill your entire AS.

Here are my conclusions about the last week's shenanigans.

IPv6 GRE is already supported as tunnel encapsulation ip6gre. It is the IPv6 equivalent of GRE, which allows us to encapsulate any Layer 3 protocol over IPv6.

Why should this task be created in vyos manager

And a slightly longer-term traffic graph, showing CPU usage vs traffic levels across VyOS 1.2.5 to 1.3-rolling on the same XL710 box:

@drac we're a typical ISP/NSP, with a fair amount of eyeball traffic behind us, so expecting to see a fairly high amount of UDP for QUIC (but it's not the bulk of our traffic on our VyOS boxes which are BGP peering/transit edge). Each of our six VyOS boxes is pushing around 300-500Mbit/sec, of which two have XL710 NICs (the rest are a mix of ixgbe and qlcnic).

I've switched the image overnight.
Everything seems to work ok apart from I've noticed the following items being logged (104) entries so far - and it's only been up 20 mins
an 3 01:40:26 vyos kernel: [ 968.052496] l2tp_core: tunl 18294: recv short packet (len=12)
Jan 3 01:40:34 vyos kernel: [ 975.367315] l2tp_core: tunl 19358: recv short packet (len=12)
Jan 3 01:40:34 vyos kernel: [ 975.431273] l2tp_core: tunl 56700: recv short packet (len=12)

I've just realised, if you look in /var/log/messages you should see the LCP negotiation of MRU (i.e. the agreed MTU)

Just to add to the knowledge surrounding this issue...

Allowing utf-8 in general may be problematical:
(1) utf-8 within, say, a description name (see parent T2941) should be manageable; any restrictions in the legacy backend (I have not confirmed) could be addressed relatively easily
(2) allowing alternative quote characters (this task) is a can of worms for the lexer, and likely a very bad idea

If you look at vif 17, the description contains matched single quotes: notably, unicode character U+2018 'Left Single Quotation Mark'. Converting to utf-8 following the prescription in 'man utf-8' gives:
0xE2 0x80 0x98
hence the 0xE2 error message. One can reference this at
https://www.compart.com/en/unicode/U+2018, but this value was checked for completeness.

@drac enabling such debug features is not easily possible as we can not install two kernels in parallel.

Resolved in https://github.com/vyos/vyos-1x/commit/faabb3e0f5dd80fcce381f35be9064f52cceb5e3

The odd thing about this is that I don't seem to have this issue consistently across systems.
I have two identical systems (hardware) one of them acting as a PPPoE concentrator with OSPF, the other is an L2TP session concentrator with OSPF and BGP.
I only see this issue on the L2TP system. It's currently only doing around 50Mbps of UDP on average.
The PPPoE system does at least twice that on average.

It feels like a bug which we received from upgrading to FRR 7.5 series.

I took the opportunity to update the supported protocols list of the dynamic DNS client. Thanks for the hint!

@drac are you seeing Slab in /proc/meminfo gradually increasing before the panic? If so, the sourceforge post at the top recommends disabling TUPLE "acceleration". It seems that the more traffic you have, the quicker the crash. We were getting them every ~6 hours.