ctrl + shift + ? for shortcuts
© 2024 Groups.io

Using an IPv6 VRRP group *without* an LLA


 

Hi,

We are using keepalived with IPv6 groups and while investigating a
related problem (https://github.com/reubenhwk/radvd/issues/131)
discovered that keepalived (at least version v2.0.12 which we are
currently using) does not require a link-local address in a VRRP router.

The RFC states:
The first address [of an IPv6 group] must be the Link-Local address associated with the virtual router.
I know this did *not* used to work in earlier keepalived versions, so my
questions are:

* is this now explicitly supported by keepalived?
* when did this change (if known)?
* will I subtly break anything by doing so?

Thanks!

--
Michael Brown
Civilized Discourse Construction Kit, Inc.
https://www.discourse.org/


 

On Fri, 2020-11-20 at 15:13 -0500, Michael Brown via groups.io wrote:
Hi,

We are using keepalived with IPv6 groups and while investigating a
related problem (
)
discovered that keepalived (at least version v2.0.12 which we are
currently using) does not require a link-local address in a VRRP router.

The RFC states:
The first address [of an IPv6 group] must be the Link-Local address associated with the virtual router.

I know this did *not* used to work in earlier keepalived versions, so my
questions are:

* is this now explicitly supported by keepalived?
* when did this change (if known)?
* will I subtly break anything by doing so?

Thanks!

As is usual with keepalived, we aim to allow as much flexibility as possible, while logging if things aren't right but keepalived can continue to operate. In this case, for example, if a user explicitly wants not to have a link local address in the list of VIPs, we will allow that configuration since there is nothing stopping it working, but we also log a message "the first IPv6 VIP address must be link local", to warn the user that it is not quite right.

keepalived was logging it as a hard error, but then continuing running, although a reload would have failed if global_defs reload_config_check were set.

I have today changed the code so that if vrrp_strict is set, it will treat the first IPv6 VIP not being link local as an error, and keepalived will fail to load/reload if reload_config_check is set. If vrrp_strict is not set, then it will log the first VIP not being link local as a warning.

* is this now explicitly supported by keepalived?
You can have the first IPv6 as not link-local if vrrp_strict is not set.

* when did this change (if known)?
My recollection is that keepalived used not to check at all, and then I added a check that just logged that the first such VIP should be link local. I don't recollect keepalived ever not working if the first VIP was not link local.

* will I subtly break anything by doing so?
keepalived will not have a problem if the first VIP is not link local, although if keepalived is interworking with a different VRRP implementation there could be problems.

I hope this helps,

Quentin Armitage


 

On 2020-11-22 12:38 p.m., Quentin Armitage wrote:
* is this now explicitly supported by keepalived?
You can have the first IPv6 as not link-local if vrrp_strict is not set.
Excellent!

keepalived will not have a problem if the first VIP is not link local, although if keepalived is interworking with a different VRRP implementation there could be problems.

Naturally, but as long as we keep things within keepalived we'll be fine.

That's great news - it does help!

Thanks,

M.

-- 
Michael Brown
Civilized Discourse Construction Kit, Inc.
https://www.discourse.org/