[acassen/keepalived] 4610c4: Fix compilation with RFC SNMP without Keepalived S...

Alexandre Cassen <[email protected]>
Newsgroups gmane.linux.keepalived.devel
Message-ID <57566c75e0088_623d3fd38102b2c01853d@hookshot-fe3-cp1-prd.iad.github.net.mail>
  Branch: refs/heads/master
  Home:   https://github.com/acassen/keepalived
  Commit: 4610c4981401980d933258048d13c4b0e3017e71
      https://github.com/acassen/keepalived/commit/4610c4981401980d933258048d13c4b0e3017e71
  Author: Quentin Armitage <[email protected]>
  Date:   2016-06-03 (Fri, 03 Jun 2016)

  Changed paths:
    M keepalived/vrrp/vrrp.c

  Log Message:
  -----------
  Fix compilation with RFC SNMP without Keepalived SNMP

Signed-off-by: Quentin Armitage <[email protected]>


  Commit: 34ef8a531160804a665967b026395143dad12263
      https://github.com/acassen/keepalived/commit/34ef8a531160804a665967b026395143dad12263
  Author: Quentin Armitage <[email protected]>
  Date:   2016-06-03 (Fri, 03 Jun 2016)

  Changed paths:
    M keepalived/vrrp/vrrp.c

  Log Message:
  -----------
  Update master_adver_int when receive higher priority advert when master

If VRRPv3 is being used, and a higher priority advert is received when
in master mode, the master_adver_int needs to be updated when transitioning
backup mode. If this isn't done, and our advert interval is less than a third
of the new masters, we will time out and re-enter master mode, send an advert
to which the other master will resond with a higher priority advert, causing
us to go back into backup mode, until our timer expires again, and this will
continue indefinitely.

Signed-off-by: Quentin Armitage <[email protected]>


  Commit: 1f2bbb90c370d7c880bed18112a8de950c7130fb
      https://github.com/acassen/keepalived/commit/1f2bbb90c370d7c880bed18112a8de950c7130fb
  Author: Quentin Armitage <[email protected]>
  Date:   2016-06-03 (Fri, 03 Jun 2016)

  Changed paths:
    M keepalived/vrrp/vrrp.c

  Log Message:
  -----------
  Don't send advert after receiving higher priority advert

If a master receives a higher priority advert, there is no need
to send another advert, since the sender of the higher priority
advert is already a master. Further, any other instance in backup
mode will process our subsequent advert, and then consider the
wrong system to be master, until it receives another advert from
the real master.

With VRRPv3, if the other master has an advert interval more than
three times our advert interval, backup routers will be using our
advert interval after we've sent our subsequent advert, and will
then timeout before the new master sends another advert, prompting
(one of) the backup routers to become a master, which will prompt
the higher priority master to send an advert, the ex-backup router
will then send another advert and we could end up in an endless cycle.

Signed-off-by: Quentin Armitage <[email protected]>


  Commit: 3cd66b25b73621025bd12687913858fdadcc4345
      https://github.com/acassen/keepalived/commit/3cd66b25b73621025bd12687913858fdadcc4345
  Author: Quentin Armitage <[email protected]>
  Date:   2016-06-03 (Fri, 03 Jun 2016)

  Changed paths:
    M keepalived/vrrp/vrrp.c

  Log Message:
  -----------
  Fix receiving advert from address owner when in fault state

If a vrrp instance was in fault state, and it then receives an
advert from the address owner (advert priority == 255), the
instance would transition to master mode. The check was:
      } else if (vrrp->effective_priority > hd->priority ||
            hd->priority == VRRP_PRIO_OWNER) {

Clearly, if the advert is FROM the address owner, then this
instance should be transitioning to backup state, and not master
state.

A reasonable check would have been:
      } else if (vrrp->effective_priority > hd->priority ||
            vrrp->effective_priority == VRRP_PRIO_OWNER) {

but the second part of the test is superfluous since if
vrrp->effective_priority == VRRP_PRIO_OWNER, then hd->priority
should not be VRRP_PRIO_OWNER, and hence we will have
vrrp->effective_priority > hd->priority

Signed-off-by: Quentin Armitage <[email protected]>


  Commit: 5c27936b476243de74ace0e6c14363dbb02665bf
      https://github.com/acassen/keepalived/commit/5c27936b476243de74ace0e6c14363dbb02665bf
  Author: Quentin Armitage <[email protected]>
  Date:   2016-06-03 (Fri, 03 Jun 2016)

  Changed paths:
    M keepalived/vrrp/vrrp_scheduler.c

  Log Message:
  -----------
  When transitioning from fault state, log state change

Signed-off-by: Quentin Armitage <[email protected]>


  Commit: a27c61f52678b92585316bf7046c17500fe10677
      https://github.com/acassen/keepalived/commit/a27c61f52678b92585316bf7046c17500fe10677
  Author: Quentin Armitage <[email protected]>
  Date:   2016-06-03 (Fri, 03 Jun 2016)

  Changed paths:
    M keepalived/vrrp/vrrp.c

  Log Message:
  -----------
  Add further configuration sanity checks re preempt

Signed-off-by: Quentin Armitage <[email protected]>


  Commit: e9234b654e1332de2df20959082e50c7740e3ef6
      https://github.com/acassen/keepalived/commit/e9234b654e1332de2df20959082e50c7740e3ef6
  Author: Quentin Armitage <[email protected]>
  Date:   2016-06-03 (Fri, 03 Jun 2016)

  Changed paths:
    M doc/KEEPALIVED-MIB
    M doc/keepalived.conf.SYNOPSIS
    M doc/man/man5/keepalived.conf.5
    M keepalived/include/vrrp.h
    M keepalived/vrrp/vrrp.c
    M keepalived/vrrp/vrrp_scheduler.c

  Log Message:
  -----------
  Fix preempt delay when transitioning from fault state

Issue #296 identified that preempt_delay wasn't working when transitioning
out of fault state.

There were two ways of leaving fault state, either by receiving a packet
on the instance, or by a netlink message indication that the interface is
up again. In neither case was preempt_delay considered in the code.

This commit changes the way vrrp->preempt_time is used. preempt_time is now
only used once a higher priority advert is received, rather than being updated
every time a lower priority advert is received. vrrp->preempt_time is now also
set when transitioning out of fault state. vrrp->preempt_time.tv_sec == 0 now
indicates the timer is not running.

This commit should resolve issue #296.

Signed-off-by: Quentin Armitage <[email protected]>


  Commit: 63b3ce3db98ad1d13fd34e624a4ad2d9762d34e1
      https://github.com/acassen/keepalived/commit/63b3ce3db98ad1d13fd34e624a4ad2d9762d34e1
  Author: Quentin Armitage <[email protected]>
  Date:   2016-06-04 (Sat, 04 Jun 2016)

  Changed paths:
    M keepalived/vrrp/vrrp.c

  Log Message:
  -----------
  Detect and report duplicate address owners

If more than one system is configured as an address owner (priority
== 255), this would be a configuration error, and could cause
unexpected behaviour. This commit ensures that the problem is
reported, and sets the local instance not to be the addess owner,
as a temporary workaround for the problem.

Signed-off-by: Quentin Armitage <[email protected]>


  Commit: 7cba5a163c841eeb851b32c7657c65836008a282
      https://github.com/acassen/keepalived/commit/7cba5a163c841eeb851b32c7657c65836008a282
  Author: Alexandre Cassen <[email protected]>
  Date:   2016-06-07 (Tue, 07 Jun 2016)

  Changed paths:
    M doc/KEEPALIVED-MIB
    M doc/keepalived.conf.SYNOPSIS
    M doc/man/man5/keepalived.conf.5
    M keepalived/include/vrrp.h
    M keepalived/vrrp/vrrp.c
    M keepalived/vrrp/vrrp_scheduler.c

  Log Message:
  -----------
  Merge pull request #346 from pqarmitage/preempt

Fix preempt issue from fault state


Compare: https://github.com/acassen/keepalived/compare/bdd357a826c8...7cba5a163c84

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e

_______________________________________________
Keepalived-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/keepalived-devel
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.