Re: VRRP advertisements over multiple interfaces
Quentin Armitage <[email protected]> Tue, 08 May 2018 00:37:31 +0100
| Newsgroups | gmane.linux.keepalived.devel |
|---|---|
| Organization | The Armitage family |
| Message-ID | <[email protected]> |
--===============7320224093825992424==
Content-Type: multipart/alternative; boundary="=-7RW8FAguUlRjJFD4vMJU"
--=-7RW8FAguUlRjJFD4vMJU
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Robert,
I had noticed your multi_interface branch, but haven't looked at it
yet. It's helpful to have an explanation of what it's about.
I don't think we need to worry about whether this goes beyond the RFC
so long as keepalived can still be configured to work in conformance
with the RFC. As long as we ensure that if vrrp_strict or strict_mode
is set then keepalived is operating in compliance with the RFC, then we
should be fine. After all, unicast peers don't comply with the RFC.
One area where there will be problems is with the SNMP RFC MIBs, which
won't support multiple interfaces per VRRP instance.
I'm wondering if there might be a simpler way to do this. My
understanding is that what you want to achieve is that an advert can be
received via a number of different routes/interfaces and any one of
them will maintain the state of the vrrp instance. I think what we
could do is define a vrrp_advert_group block, whose members are
vrrp_instances. If an advert is received on any member of the
vrrp_advert_group, then it is propagated to the other members of the
vrrp_advert_group. This approach has the advantage that the basic
configuration maintains compatibility the RFCs, different VRIDs can be
used on different interfaces, and that the only change is the
propagating of received adverts across different vrrp instances. There
might be some sanity checks needed such as advert_int should be the
same across all members of an advert group, but I think that is
relatively straight forward.
Let me know what you think of this alternative suggestion?
Quentin Armitage
On Mon, 2018-05-07 at 23:30 +0200, Robert Groenenberg wrote:
> Hi Quentin, Alexandre, others,
>
>
>
> In order to have more reliable communication between two (or
> more)
> nodes and reducing the risk of a split-brain situation, I have
> been looking into the option of sending the advertisements over
> multiple interfaces. It involves each VRRP instance to have a
> list
> of 'vrrp interfaces' with the ifp, source address, etc. instead
> of
> a single ifp, etc., which requires some substantial amount
> changes
> in the code. I do have a first version working, both for
> multicast
> and unicast. All configurable per VRRP instance in the config
> file.
>
>
>
> Although I think it kind of conflicts with the RFC to tie a
> single
> virtual router to multiple interfaces, I have seen questions
> from
> others for such behaviour for the same reason.
>
> Would there be interest to take this functionality on board?
>
>
>
> Kind regards,
>
> Robert
>
>
>
>
>
--=-7RW8FAguUlRjJFD4vMJU
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
<html><head>
<meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8=
">
</head>
<body text=3D"#2e3436" bgcolor=3D"#ffffff" link=3D"#2a76c6" vlink=3D"#2e3=
436"><div>Robert,</div><div><br></div><div>I had noticed your multi_interfa=
ce branch, but haven't looked at it yet. It's helpful to have an explanatio=
n of what it's about.</div><div><br></div><div>I don't think we need to wor=
ry about whether this goes beyond the RFC so long as keepalived can still b=
e configured to work in conformance with the RFC. As long as we ensure that=
if vrrp_strict or strict_mode is set then keepalived is operating in compl=
iance with the RFC, then we should be fine. After all, unicast peers don't =
comply with the RFC.</div><div><br></div><div>One area where there will be =
problems is with the SNMP RFC MIBs, which won't support multiple interfaces=
per VRRP instance.</div><div><br></div><div>I'm wondering if there might b=
e a simpler way to do this. My understanding is that what you want to achie=
ve is that an advert can be received via a number of different routes/inter=
faces and any one of them will maintain the state of the vrrp instance. I t=
hink what we could do is define a vrrp_advert_group block, whose members ar=
e vrrp_instances. If an advert is received on any member of the vrrp_advert=
_group, then it is propagated to the other members of the vrrp_advert_group=
. This approach has the advantage that the basic configuration maintains co=
mpatibility the RFCs, different VRIDs can be used on different interfaces, =
and that the only change is the propagating of received adverts across diff=
erent vrrp instances. There might be some sanity checks needed such as adve=
rt_int should be the same across all members of an advert group, but I thin=
k that is relatively straight forward.</div><div><br></div><div>Let me know=
what you think of this alternative suggestion?</div><div><br></div><div>Qu=
entin Armitage</div><div><br></div><div>On Mon, 2018-05-07 at 23:30 +0200, =
Robert Groenenberg wrote:</div><blockquote type=3D"cite" style=3D"margin:0 =
0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex">
<font face=3D"DejaVu Sans">Hi Quentin, Alexandre, others,<br>
<br>
In order to have more reliable communication between two (or more)
nodes and reducing the risk of a split-brain situation, I have
been looking into the option of sending the advertisements over
multiple interfaces. It involves each VRRP instance to have a list
of 'vrrp interfaces' with the ifp, source address, etc. instead of
a single ifp, etc., which requires some substantial amount changes
in the code. I do have a first version working, both for multicast
and unicast. All configurable per VRRP instance in the config
file.<br>
<br>
Although I think it kind of conflicts with the RFC to tie a single
virtual router to multiple interfaces, I have seen questions from
others for such behaviour for the same reason.<br>
Would there be interest to take this functionality on board?<br>
<br>
Kind regards,<br>
Robert<br>
</font>
=20
<pre></pre><pre>
</pre></blockquote></body></html>
--=-7RW8FAguUlRjJFD4vMJU--
--===============7320224093825992424==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
--===============7320224093825992424==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Keepalived-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/keepalived-devel
--===============7320224093825992424==--