- User Since
- Sep 10 2018, 3:30 PM (221 w, 19 h)
Nov 2 2022
Sure, it is fully compatible with 1.3. If no problems are found after the changes in 1.4 it must be backported.
Oct 28 2022
Backported in https://github.com/vyos/vyatta-cfg-quagga/pull/97
Oct 27 2022
Oct 21 2022
Oct 20 2022
Oct 18 2022
Oct 7 2022
Oct 6 2022
Sep 16 2022
Sep 12 2022
Should be fixed in https://github.com/vyos/vyatta-cfg-firewall/pull/34
Sep 9 2022
I am suggesting marking this task as "Resolved" because the driver works by himself and NIC can be used with a proper configuration.
Sep 6 2022
The [email protected] seems to work well after the fix. We should backport this to the equuleus as well.
Aug 31 2022
Aug 30 2022
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
Aug 27 2022
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.
Aug 25 2022
Aug 24 2022
Aug 5 2022
Aug 2 2022
Jul 28 2022
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.
Jul 27 2022
Jul 20 2022
Jul 19 2022
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.
Jul 18 2022
Jul 8 2022
Jul 7 2022
Jul 4 2022
Jun 10 2022
Jun 2 2022
@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.
May 31 2022
May 13 2022
May 5 2022
May 3 2022
Resolved in https://github.com/vyos/vyos-cloud-init/pull/54
Apr 30 2022
Apr 25 2022
Apr 14 2022
Theoretically, must be fixed in https://github.com/FRRouting/frr/pull/11004
Apr 11 2022
Apr 1 2022
Hi, @dberlin ! Thanks, you are right about the root cause.
I believe that we need to remove the max-size and action-on-max-size from rsyslog.conf. So, leave everything related to rotating logs to logrotate, and to sending logs to rsyslog - UNIX-way. :)
Mar 31 2022
Mar 26 2022
Updated to 22.1 in 1.4.
The current branch now must be compatible with 1.3, and merged to equuleus if there no new incompatibilities will be found during tests.
Mar 24 2022
Updated: we need to update 20.4 to 22.1 because 20.4 cannot extract SSH keys from the Azure Stack Hub data source.
Mar 15 2022
The same issue with set interfaces bonding bond0 arp-monitor interval 'X' option. Also extra conversion between variable types.
Added the fix to the same PR.
Mar 12 2022
Mar 11 2022
Mar 7 2022
Resolved in https://phabricator.vyos.net/T3774, but it will not be backported to 1.2.
Should be fixed in https://github.com/vyos/vyos-1x/pull/1241
Mar 6 2022
Should be fixed by https://github.com/vyos/vyatta-cfg-firewall/pull/32
Mar 2 2022
Feb 18 2022
Feb 16 2022
Feb 4 2022
Feb 3 2022
Jan 26 2022
We confirmed the problem - some serial consoles continue to work well, some are not initialized properly with the --keep-baud option. For example, this can be reproduced in the SOS console in Equinix Metal.
Originally, the problem comes from a systemd service template.
Since it is not completely clear if the option is necessary in one case or another, it seems that the best solution would be to provide the ability to set/remove it from the CLI, so everyone may configure what works best for his hardware.