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.

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

This is a behavior "by design". The prefix-len option cannot be used for BGP routes. We should add this notice to the CLI.
Check: http://docs.frrouting.org/en/latest/routemap.html#clicmd-match-ip-address-prefix-len-0-32

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

@m.korobeinikov I believe that I already posted this some time ago, but just in case...
Not all combinations of DPD and close-action are safe. Actually, most of them sooner or later will lead to issues with IPSec. So, I created the next scheme. It is from 2020, so I will not say that nothing was changed from that time, however, it shows well how careful you should be while configuring IPSec. On the scheme, you can see the only safe configuration of the close-action option, depending on how the peer is configured, but the same logic can be applied to DPD.

PR for 1.3: https://github.com/vyos/vyos-build/pull/231
PR for 1.4: https://github.com/vyos/vyos-build/pull/230

Resolved in https://github.com/vyos/vyos-cloud-init/pull/54

Theoretically, must be fixed in https://github.com/FRRouting/frr/pull/11004