Re: VRRP advertisements over multiple interfaces
Robert Groenenberg <[email protected]> Tue, 22 May 2018 15:00:02 +0200
| Newsgroups | gmane.linux.keepalived.devel |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============7354858009641198297==
Content-Type: multipart/alternative;
boundary="------------1977E896DF6FBF1933BC819C"
Content-Language: en-US
This is a multi-part message in MIME format.
--------------1977E896DF6FBF1933BC819C
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Hi Quentin,
I've looked a bit further into you suggestion of using an advert_group
for sending out adverts via multiple interfaces.
It looks like that is indeed a possibility, with the restriction that
only the 'group leader' can have tracking scripts. All VRRP instances in
the group just follow the state and priorities of that group leader. The
group members only have an interface (which should not be tracked) and
optionally VIP(s) on that interface.
I do have a working version (based on the beta branch) and will do some
more testing on it before pushing it for review.
Kind regards,
Robert
On 08-05-18 16:06, Robert Groenenberg wrote:
> Hi Quentin,
>
> On 08-05-18 01:37, Quentin Armitage wrote:
>> 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.
> Don't look to closely at that branch, it's not completely up to date
> with my local version.
>
>> 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.
> Indeed, that's on open item on my list...
>
>> 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.
> Correct.
>> 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?
> Interesting thought. Initially I looked (configuration wise, no code
> changes) at the vrrp_sync_group, but that does not allow weight
> settings for the track_scripts which is something we need. That
> steered me in the direction to use multiple interfaces within a single
> vrrp_instance.
> Defining a vrrp_advert_group would address the multi-interface
> advertisements, but the individual vrrp_instances should also remain
> in sync: not one in Master (sending advertisements) and another in
> Backup (e.g. because its interface is down).
>
> Let's assume this config:
>
> vrrp_advert_group MyAdverts {
> VI_1
> VI_2
> }
>
> vrrp_instance VI_1 {
> ...
> interface eth1
>
> track_script {
> check_app -10
> check_gw_a -5
> }
>
> virtual_ipaddress {
> ...
> }
> }
>
> vrrp_instance VI_2 {
> ...
> interface eth2
> }
>
> We would then need a mechanism that when the 'primary' vrrp_instance
> goes into Backup state, the other instances in the will
> vrrp_advert_group follow. Ideally (in our case) the other instances
> only send advertisements but don't have their own state election. Like
> a 'track_vrrp_instance' option ;)
>
>
> Kind regards,
> Robert
>
>>
>> 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
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
> _______________________________________________
> Keepalived-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/keepalived-devel
--------------1977E896DF6FBF1933BC819C
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<font face="DejaVu Sans">Hi Quentin,<br>
<br>
I've looked a bit further into you suggestion of using an
advert_group for sending out adverts via multiple interfaces.<br>
<br>
It looks like that is indeed a possibility, with the restriction
that only the 'group leader' can have tracking scripts. All VRRP
instances in the group just follow the state and priorities of
that group leader. </font><font face="DejaVu Sans"><font
face="DejaVu Sans">The group members only have an interface
(which should not be tracked) and optionally VIP(s) on that
interface.</font><br>
<br>
I do have a working version (based on the beta branch) and will do
some more testing on it before pushing it for review.<br>
<br>
<br>
Kind regards,<br>
Robert<br>
<br>
</font>
<div class="moz-cite-prefix">On 08-05-18 16:06, Robert Groenenberg
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:[email protected]">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<font face="DejaVu Sans">Hi Quentin,<br>
</font><br>
<div class="moz-cite-prefix">On 08-05-18 01:37, Quentin Armitage
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:[email protected]">
<meta http-equiv="content-type" content="text/html;
charset=utf-8">
<div>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.</div>
</blockquote>
<font face="DejaVu Sans">Don't look to closely at that branch,
it's not completely up to date with my local version.</font><br>
<br>
<blockquote type="cite"
cite="mid:[email protected]">
<div>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.</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>
</blockquote>
<font face="DejaVu Sans">Indeed, that's on open item on my list...<br>
</font><br>
<blockquote type="cite"
cite="mid:[email protected]">
<div>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.<br>
</div>
</blockquote>
<font face="DejaVu Sans">Correct.</font><br>
<blockquote type="cite"
cite="mid:[email protected]">
<div> 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.</div>
<div><br>
</div>
<div>Let me know what you think of this alternative suggestion?</div>
</blockquote>
<font face="DejaVu Sans">Interesting thought. Initially I looked
(configuration wise, no code changes) at the vrrp_sync_group,
but that does not allow weight settings for the track_scripts
which is something we need. That steered me in the direction to
use multiple interfaces within a single vrrp_instance.<br>
Defining a vrrp_advert_group would address the multi-interface
advertisements, but the individual vrrp_instances should also
remain in sync: not one in Master (sending advertisements) and
another in Backup (e.g. because its interface is down).<br>
<br>
Let's assume this config:<br>
<br>
<font face="DejaVu Sans Mono">vrrp_advert_group MyAdverts {<br>
VI_1<br>
VI_2<br>
}<br>
</font></font><font face="DejaVu Sans Mono"><br>
vrrp_instance VI_1 {<br>
...<br>
interface eth1<br>
<br>
track_script {<br>
check_app -10<br>
check_gw_a -5<br>
}<br>
<br>
virtual_ipaddress {<br>
...<br>
}<br>
}<br>
<br>
vrrp_instance VI_2 {<br>
...<br>
interface eth2<br>
}<br>
</font><font face="DejaVu Sans"><br>
We would then need a mechanism that when the 'primary'
vrrp_instance goes into Backup state, the other instances in the
will vrrp_advert_group follow. Ideally (in our case) the other
instances only send advertisements but don't have their own
state election. Like a 'track_vrrp_instance' option ;)<br>
<br>
<br>
Kind regards,<br>
Robert<br>
<br>
</font>
<blockquote type="cite"
cite="mid:[email protected]"><br>
<div>On Mon, 2018-05-07 at 23:30 +0200, Robert Groenenberg
wrote:</div>
<blockquote type="cite" style="margin:0 0 0 .8ex;
border-left:2px #729fcf solid;padding-left:1ex"> <font
face="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> </blockquote>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! <a class="moz-txt-link-freetext" href="http://sdm.link/slashdot">http://sdm.link/slashdot</a></pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Keepalived-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/keepalived-devel">https://lists.sourceforge.net/lists/listinfo/keepalived-devel</a>
</pre>
</blockquote>
<br>
</body>
</html>
--------------1977E896DF6FBF1933BC819C--
--===============7354858009641198297==
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
--===============7354858009641198297==
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
--===============7354858009641198297==--