Re: VRRP advertisements over multiple interfaces

This is a multi-part message in MIME format.
--===============9208878226082579362==
Content-Type: multipart/alternative;
 boundary="------------76A7B5A312EC38B552970E62"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------76A7B5A312EC38B552970E62
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

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


--------------76A7B5A312EC38B552970E62
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>
    </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>
  </body>
</html>

--------------76A7B5A312EC38B552970E62--


--===============9208878226082579362==
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
--===============9208878226082579362==
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

--===============9208878226082579362==--