Jun 10 2018
Jun 3 2018
We not going to implement it in 1.1.x
May 28 2018
Apr 9 2018
I'm sorry to bother with this issue again, but as I need to upgrade some VyOS 1.2.x routers in the near future, I would be grateful for any information on how to do this the best way regarding the changes stated above. As I have already mentioned, older nightlies don't set "native_ipv6" in the keepalived.conf. So if I upgrade one device at a time, VRRP will be broken until I have also upgraded the other devices. Do you have any advice how I should deal with this problem? Upgrading all devices at the same time is not really an option with my setup, but maybe there is some kind of reasonable workaround which you would recommend?
Feb 23 2018
Feb 19 2018
While that is true, older nightly versions don't set "native_ipv6" in the keepalived.conf, so any back-to-back updates will result in broken VRRP configurations. In addition, it is my understanding that you can't use both IPv4 and IPv6 in one VRRP group in newer versions of keepalived or rather you should not do it. Therefore simply adding "native_ipv6" may not be the best way to implement IPv6 support.
Feb 13 2018
1.2.x nighlies have support for ipv6
This can also be a problem for people using 1.2.x, as the "native_ipv6" line has also made it's way into vyatta-keepalived.pl in those nightly versions at some point in the past. So trying to upgrade from some early 2017 nightly to a current version will break VRRP in 1.2.x too.
Feb 7 2018
Jan 26 2018
What's the probability of seeing a 1.1.9 release sometime soon with this fix in it? I have a bunch of machines I'd like to upgrade to 1.1.8+, but it seems irritating to have to manually install an updated .deb on each of them.
Jan 6 2018
Dec 27 2017
Dec 22 2017
Please wait for todays build and test again. Thanks for your support!
IPv6 address in scp://<user>:<passwd>@[IPv6-address]/<dir> looks like not properly escaped. Should be \[IPv6-address\].
Dec 21 2017
@c-po can you look into this please
Dec 18 2017
@dmbaturin can you confirm an issue?
i move that to 1.1.9 backlog
Dec 11 2017
Since that wasn't included in 1.1.8 for some reason
Dec 6 2017
After some discussion surrounding similar issue in IRC recently, I believe FORWARD is the correct place for this, and 'set-mss' should be configurable in a rule which can specify one or both of input *and* output interface to allow proper expression of explicit MSS for inbound and outbound connections.
Dec 5 2017
Nov 22 2017
Nov 16 2017
Another workaround is the following: