Fix for 1.4: https://github.com/vyos/vyos-1x/pull/2109

PR for 1.3: https://github.com/vyos/vyos-1x/pull/2106

To reproduce the problem:

During installation, this happens: https://github.com/vyos/vyatta-cfg-system/blob/bac61854acd40b4eae8b12e47be54306171f5c3c/scripts/install/install-image-existing#L201C3-L201C3

@dutty can you try to build an image again and check now?

PR with the fix: https://github.com/vyos/vyos-build/pull/350

PRs:
1.3 - https://github.com/vyos/vyos-1x/pull/1979
1.4 - https://github.com/vyos/vyos-1x/pull/1978

PR: https://github.com/vyos/vyos-build/pull/343

PR with dependencies: https://github.com/vyos/vyos-build/pull/341

PR (for build): https://github.com/vyos/vyos-build/pull/340

PR: https://github.com/vyos/vyos-build/pull/339

According to nft changelog, this feature is available in 1.0.7 in a much better way:

Just in case someone wants to implement this: debugging must not be enabled by default, only on demand or via config.

PRs:
https://github.com/vyos/libnss-mapuser/pull/7
https://github.com/vyos/libpam-radius-auth/pull/6
https://github.com/vyos/vyos-1x/pull/1851

PRs:
1.3 - https://github.com/vyos/vyos-cloud-init/pull/62
1.4 - https://github.com/vyos/vyos-cloud-init/pull/61

PR with a fix: https://github.com/vyos/vyatta-cfg/pull/61

We also need to increase opened file descriptors (ulimit -n) to listen limit + some margin.
And consider adding a warning about increasing net.core.optmem_max for systems with a limit of more than 100 peers.

PR for 1.3: https://github.com/vyos/vyos-1x/pull/1796

PR for 1.4: https://github.com/vyos/vyos-1x/pull/1795

PR for 1.3: https://github.com/vyos/vyos-build/pull/300

Backport PR https://github.com/vyos/vyos-cloud-init/pull/60

Fixed in the https://github.com/vyos/vyos-cloud-init/pull/58

Fix for 1.4: https://github.com/vyos/vyos-cloud-init/pull/59
It must be backported to 1.3 now.

Draft PR was published: https://github.com/vyos/vyos-1x/pull/1768

Backport PR: https://github.com/vyos/vyos-cloud-init/pull/57

For 1.4 resolved in the https://github.com/vyos/vyos-cloud-init/commit/d385e3655e9eed77397136f5e27325a93719332d
Waiting several days for tests before doing a backport.

I agree that internal logic can be better, but I think that in this specific case the problem is much simpler: https://github.com/vyos/vyos-1x/pull/1708

PR with fix is here: https://github.com/vyos/vyatta-cfg-firewall/pull/35

Sure, it is fully compatible with 1.3. If no problems are found after the changes in 1.4 it must be backported.

Backported in https://github.com/vyos/vyatta-cfg-quagga/pull/97

Fixed in https://github.com/vyos/vyatta-cfg-system/pull/188

Should be fixed in https://github.com/vyos/vyatta-cfg-firewall/pull/34

I am suggesting marking this task as "Resolved" because the driver works by himself and NIC can be used with a proper configuration.

The [email protected] seems to work well after the fix. We should backport this to the equuleus as well.

Not the bug, because it is internally translated to the proper value: https://github.com/vyos/vyos-1x/blob/b01f27b3bb3f4cbc6096011856d83009d0440313/data/templates/ipsec/swanctl/peer.j2#L90

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

I need to reopen this, because after T3781 op-mode CLI references were reverted as well, and now we are in the strange situation when show_nat_translations.py is in the system, but CLI still refers to the old vyatta-nat-translations.pl.
The old script uses too much CPU and RAM, and can even crash on big conntrack tables.
We should backport updates from sagitta to op-mode scripts and replace CLI references to use them.

True, marking packets can help. I would only be very careful because we use marks a lot for PBR, LB, etc. Not sure if they can conflict with each other. Also, the performance is the question - better to check how marking each packet on an interface affects it.

I have no proof now of any obvious negative issues. Moreover, in my personal opinion - if some protocol or interface type requires a default MTU that is not assigned to it by the kernel, this is the problem that should be solved by configuration script for that particular interface.