@drac @maznu called this Intel driver stuff a "tire fire" I have a 5.10.4 Kernel ISO which utilizes the build in Kernel drivers. Could you probably give this a test drive?

Loopback IP addresses are now automatically assigned to every VRF interface

47: bar: <NOARP,MASTER,UP,LOWER_UP> mtu 65536 qdisc noqueue state UP group default qlen 1000
    link/ether 76:7d:c0:53:6d:89 brd ff:ff:ff:ff:ff:ff
    inet 127.0.0.1/8 scope host bar
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever

The system tries to bind itself to the localhost address which is not in the VRF, this is definately a fault, Why did I not see that?

Amending /etc/snmp/snmpd.conf as follows got it working for me (albeit temporarily). Our snmp listen-address is 10.13.0.56 in this instance.

Similar issue for snmpd:

The frequency of this issues seems to have increased, we now seem to be getting panics daily (it was every 4 days previously)

Also, your client should still not end up with 1454 set.
On our system, we have mtu set to 1500, and various clients appear to negotiate both 1500 and 1492 settings successfully via LCP stage of ppp.

The default in code is 1436 - so I really don't understand how the value of 1450 has got there unless there is a problem generating the file at /var/run/accel-pppd/l2tp.conf and it isn't being re-written.

The config you posted has the following which is not correct, it should read 1454.
ppp-max-mtu=1450

I think this may be related to the MAC bound to the device. You can modify the configuration of vyos to adjust the order

Need 'nopmtudisc' option for tunnel interface. This is required for MPLS over gre or Ethernet over gre applications. This option is described in the iproute2 manuals (ip-tunnel).

Alternatively, we've got an i40e VyOS box in production which is stable with:

i40e is a tyre fire.

Seems i40e is a lot of fun. Given thos nasty errors and Intels development cycle, I have a recent 1.3 ISO with Kernel 5.10.4 and build in i40e drivers (mainline).

Frustratingly, 2.13.10 seems to have some other — very nasty — bugs in it. We've had three kernel crashes on the latest VyOS 1.3 releases (from around Christmas) as a result, and I currently believe they are the same as those problems described here:

So we have configured option max-mtu this means

ppp-max-mtu=n
Set the maximum MTU value that can be negotiated for PPP over L2TP sessions.

But I think we need to provide possibility set min-mtu

[ppp]
min-mtu=n

@alainlamar We aren't going to remove web proxy support! I was only talking about the old package specifically—it's been rewritten in the new style.

We can add a new <constraintGroup> element. If you put multiple <constraint> elements inside a <constraintGroup>, they work like logical AND.

Looks like it's not an issue anymore in latest iso.

show mpls table was outputting data.

I've never configured MPLS on anything.
I've loaded the latest release from yesterday, and I'm no longer seeing the issue?
That's v.odd.

As for encrypted DNS, it should cover standard solutions rather than be limited to a certain service provider. The standard solutions are as follows (although in general, there may not be many people using encrypted recursive DNS)

I used dnsdist and dnscrypt-proxy before but currently I settled with:

On server, what is in /var/run/accel-pppd/l2tp.conf ?
The setting should read ppp-max-mtu=1454 under l2tp section

Also I'd expect something is wrong on the client side, can you see the PPP config options the Teltonika is using?

The MTU setting is well described "max-mtu", i.e. a lower one can be negotiated.
Can you capture the LCP stage of PPP negotiation from either the client or server, it sounds like it's negotiating a smaller one for some reason.

I am wondering if these are Zebra errors as they *seem* like Zebra errors.

vyatta-config-migrate removed in branches referenced in:
T3161 Consider removing ConfigLoad.pm
In testing.

Changes in branches here:
https://github.com/vyos/vyatta-cfg/compare/current...jestabro:T3161
https://github.com/vyos/vyatta-cfg-system/compare/current...jestabro:T3161
https://github.com/vyos/vyatta-wanloadbalance/compare/current...jestabro:T3161
This will need reasonable testing before commit, although all pieces had previously been implemented

I've added the two binary defense components oustanding:

Similar task T2045

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

@jack9603301 if you mean option "--clamp-mss-to-pmtu" so it was in wrong chain/hook T2868

Is there a way to support pmtu in interface configuration

Fix typo in script description
PR https://github.com/vyos/vyos-1x/pull/663

Taras confirms that the functionality of

vyatta-cfg-system/etc/init.d/ec2-vyos-init

is replaced by that of cloud-init tools, so this legacy invocation will be removed, allowing for the removal of ConfigLoad.pm, since the other scripts have already been rewritten.