keepalived-devel — Keepalived devel mailing list

Re: [Keepalived-devel] Track file process script priority

[Quentin A. <qu...@ar...>]

On Mon, 2023-11-27 at 13:34 +0100, Lynch maniac wrote:
> 
> Thank you for this beautiful project. I have a question that I couldn't find the answer to
> in the documentation.
> Keepalived offers multiple ways to track who is the master and who is the slave
> (track_file, track_process, track_scripts...). But how does keepalived prioritize these
> trackers ?
> Let me explain. If I have a value with track_file and another with track_script, what is
> the priority between the two values? Do the values add up? How does Keepalived choose the
> master if there are several trackers? Can you confirm that it is possible to have
> track_file and track_script or track_process at the same time ?

If a VRRP instance has multiple trackers, the failure of any of them will put the VRRP
instance into fault state, unless the trackers have a weight, in which case the weight is
added to the VRRP priority of the VRRP instance when the tracker is up. Each tracker
configured against a vrrp instance will add its own weight as appropriate.

So suppose a VRRP instance is configured with priority 100. track_script A has weight 10 and
track_script B weight 15

Script A Script B VRRP effective priority
Down Down 100
Up Down 110
Down Up 115
Up Up 125

The same principle applies for track_process, track_interface, track_file etc.

The current master is determined by the systems whose VRRP instance currently has the
highest effective priority (unless "no_preempt" has been configured). The VRRP master sends
periodic adverts (default every second) which include the instance's current priority. If an
instance on another system has a higher effective priority, unless no_preempt has been
configured, the higher priority system will start sending adverts. Once the lower priority
system sees the higher priority adverts, it will drop back to backup state.

It is possible to have multiple of each of track_script, track_file, track_process,
track_interface and track_bfd at the same time and if they have weights those weights will
all be added to the effective priority as appropriate.

I hope this helps,

Quentin Armitage

[Keepalived-devel] Track file process script priority

[Lynch m. <lyn...@gm...>]

Hi,

Thank you for this beautiful project. I have a question that I couldn't
find the answer to in the documentation.
Keepalived offers multiple ways to track who is the master and who is the
slave (track_file, track_process, track_scripts...). But how does
keepalived prioritize these trackers ?
Let me explain. If I have a value with track_file and another with
track_script, what is the priority between the two values? Do the values
add up? How does Keepalived choose the master if there are several
trackers? Can you confirm that it is possible to have track_file and
track_script or track_process at the same time ?

Thanks in advance!
Vince

Re: [Keepalived-devel] Keepalive holddown timer vs interval?

[Quentin A. <qu...@ar...>]

On Mon, 2021-07-19 at 15:51 +0000, Jeremy Guthrie wrote:
> We are seeing an issue where a single second disconnect or packet loss appears
> to cause keepalived to go into fault and die.  We'd like to actually run with
> an 'advert_int' of 2 seconds with a '10 second hold down timer' meaning we
> have to lose five(5) hellos instead.  Is there a way to do that?   Right now
> it appears that we have only to lose a single hello and VRRP wants to fail
> over which is too fragile.  We are trying to find the configs to allow for
> that.
> 
> Any thoughts?

Jeremy,

This is a very old list that you have sent this message to. The current list
is kee...@gr... .

You don't say which version of keepalived you are using; generally newer
versions are more reliable than older versions. The current version is v2.2.2.

> We are seeing an issue where a single second disconnect or packet loss appears
> to cause keepalived to go into fault and die.  

What is happening here depends on what you are doing. If the network cable is
disconnected from an interface that is being used by keepalived (or indeed if
the interface is downed by command - e.g. ip link set XXX down), then any VRRP
instance tracking that interface will go to fault state until the interface
comes back up again. Once the interface comes back up, the VRRP instance will go
to BACKUP state, and then if it is the highest priority instance and nopreempt
is not set, then after three advert intervals plus a bit (I'll explain later) it
will take over as master.

I am not sure what you mean by "die". Does the VRRP instance remain in fault
state after the interface is restored?

> We'd like to actually run with an 'advert_int' of 2 seconds with a '10 second
> hold down timer' meaning we have to lose five(5) hellos instead.  Is there a
> way to do that?

The simple answer is NO. The VRRP RFCs are specific about how long a backup will
wait before it takes over as master. For VRRPv3 this is 3 * advert_int + (256 -
priority) / 256 * advert_int. For VRRPv2 it is 3 * advert_int + (256 - priority)
/ 256. So the timeout is always somewhere between 3 and 4 advert intervals, and
the higher the priority of the VRRP instance the closer the timeout is to 3
advert intervals.

Since the RFCs are explicit about the calculation of 3 * advert_int plus a bit,
the 3 * is hard coded, and not configurable. Technically the 3 * could be
replaced with a configurable parameter, but then you would not be running VRRP!
 
>    Right now it appears that we have only to lose a single hello and VRRP
> wants to fail over which is too fragile.

This is not the case. An interface going down will cause an immediate transition
to fault state, but the loss of a single advert will NOT cause a backup vrrp to
take over as master.

>   We are trying to find the configs to allow for that.
> 
There are none since keepalived does not support anything other than 3 *
advert_int + a bit, and always immediately transitions to FAULT state if the
interface it is using goes down.

If you could give more details about what is happening in respect of "single
second disconnect or packet loss" and also "go into fault and die" then we might
be able to make some more concrete suggestions.

I hope this helps,

Quentin Armitage

[Keepalived-devel] Keepalive holddown timer vs interval?

[Jeremy G. <Jer...@cd...>]

We are seeing an issue where a single second disconnect or packet loss appears to cause keepalived to go into fault and die.  We'd like to actually run with an 'advert_int' of 2 seconds with a '10 second hold down timer' meaning we have to lose five(5) hellos instead.  Is there a way to do that?   Right now it appears that we have only to lose a single hello and VRRP wants to fail over which is too fragile.  We are trying to find the configs to allow for that.

Any thoughts?

--
Jeremy Guthrie
Technical Architect - Orchestration & DevOps
5520 Research Park | Madison, WI 53711
Phone: 608.298.1061
Fax: 608.288.3007 | ECC: 888.793.2480 or 608.288.4000

[cid:8F1...@co...]

Re: [Keepalived-devel] SNMP problems with more than 1k virtual ips

[Manuel A. <MAl...@an...>]

Seems like an snmpd issue.  Also moved the discussion to kee...@gr... group.
Seems that’s the official one now.

Mit freundlichen Grüßen / Best regards

Manuel Alberer
Senior Systems Engineer / Systems Operation Center

ANEXIA Internetdienstleistungs GmbH

Phone: +43-5-0556-333
Fax: +43-5-0556-500

E-Mail: MAl...@an...
Web: http://www.anexia.at

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
Geschäftsführer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

-----Original Message-----
From: Vincent Bernat <be...@lu...> 
Sent: Mittwoch, 7. Oktober 2020 23:39
To: Manuel Alberer <MAl...@an...>
Cc: kee...@li...
Subject: Re: [Keepalived-devel] SNMP problems with more than 1k virtual ips

 ❦  7 octobre 2020 14:07 GMT, Manuel Alberer:

> ### setup with 1-1k ips
> snmpwalk -v2c -cpublic localhost KEEPALIVED-MIB::vrrpInstanceTable;
> snmpwalk -v2c -c public localhost .1.3.6.1.4.1.9586.100.5.1.1.0
>
> both commands return status within very short time.

Just to get an idea, what's the short time (measure by prefixing with `time`)?
>
> ### setup with 2k+ ips
> snmpwalk -v2c -c public localhost .1.3.6.1.4.1.9586.100.5.1.1.0
>
> snmpwalk runs into a timeout, even when only the keepalived version is 
> requested.

Is there a special value that triggers this problem (between 1k and 2k)?
--
Always do right.  This will gratify some people and astonish the rest.
		-- Mark Twain

Re: [Keepalived-devel] SNMP problems with more than 1k virtual ips

[Vincent B. <be...@lu...>]

 ❦  7 octobre 2020 14:07 GMT, Manuel Alberer:

> ### setup with 1-1k ips
> snmpwalk -v2c -cpublic localhost KEEPALIVED-MIB::vrrpInstanceTable;
> snmpwalk -v2c -c public localhost .1.3.6.1.4.1.9586.100.5.1.1.0
>
> both commands return status within very short time.

Just to get an idea, what's the short time (measure by prefixing with
`time`)?
>
> ### setup with 2k+ ips
> snmpwalk -v2c -c public localhost .1.3.6.1.4.1.9586.100.5.1.1.0
>
> snmpwalk runs into a timeout, even when only the keepalived version is
> requested.

Is there a special value that triggers this problem (between 1k and 2k)?
-- 
Always do right.  This will gratify some people and astonish the rest.
		-- Mark Twain

[Keepalived-devel] SNMP problems with more than 1k virtual ips

[Manuel A. <MAl...@an...>]

Keepalived does not react to snmp requests via master x agent if there are more then 1-2k virtual ips.
All ips are setup via virtual_ipaddress_excluded except one.

How to reproduce.

SETUP:
Keepalived running with -x
v2.0.10 on Debian buster with all updates.
Installed via Debian repo.


###Minimal config:
vrrp_instance ANX_MA {
  @anx-ma-cluster01 priority 200
  @anx-ma-cluster02 priority 100
  @anx-ma-cluster03 priority 50

  interface eth0
  virtual_router_id 117
  nopreempt
  virtual_ipaddress {
    192.12.115.223/23
  }
  virtual_ipaddress_excluded {
   10.201.36.14/24
  }
}

###snmp running with config:
agentAddress udp:161
rocommunity public
disk /
disk /boot
dontLogTCPWrappersConnects true
skipNFSInHostResources true
master agentx

### setup with 1-1k ips
snmpwalk -v2c -cpublic localhost KEEPALIVED-MIB::vrrpInstanceTable;
snmpwalk -v2c -c public localhost .1.3.6.1.4.1.9586.100.5.1.1.0

both commands return status within very short time.

### setup with 2k+ ips
snmpwalk -v2c -c public localhost .1.3.6.1.4.1.9586.100.5.1.1.0

snmpwalk runs into a timeout, even when only the keepalived version is requested.

Log shows:
Keepalived_vrrp[122818]: AgentX master disconnected us, reconnecting in 15


Best regards
MA

[Keepalived-devel] VMAC with unicast peers

[Levin D. <dim...@gm...>]

When I use VMAC with unicast peers, master sends ARP requests from VIP,
even when  unicast_src_ip is used. Is it normal? My version is 2.0.11

-- 
Best regards,

 Dima.

[Keepalived-devel] Questions about use_vmac on bond interface...

[Sean <sma...@gm...>]

Hello,

I am building a pair of routers using keepalived-2.0.10-10.el8.x86_64
on CentOS/8.  This router pair is also running frr-7.0-5.el8.x86_64
and advertising our subnet upstream to the internet as an AS with BGP.
Each router has a different ISP interface, as well as a cross-connect
interface for iBGP peering.  I am currently modelling everything in a
Vagrant environment provisioned with ansible, so it's easy to scratch
and restart fresh to try different approaches.

The routers each have a bond interface called "core".  Core has the .2
(router 1) and .3 (router 2) IPs on the subnet, with the keepalived
VIP as the .1.  There is a client VM on this network with .100 as it's
IP.

The keepalived config seems very simple...
vrrp_instance VI_1 {
    interface core
    state MASTER
    use_vmac
    vmac_xmit_base
    virtual_router_id 51
    virtual_ipaddress {
        192.168.192.1
    }
    track_script {
        chk_frr
    }
    unicast_src_ip 192.168.192.2
    unicast_peer {
              192.168.192.3

    }
}

Relevant interface info -
# ip a show core
9: core: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc
noqueue state UP group default qlen 1000
    link/ether 08:00:27:81:27:3b brd ff:ff:ff:ff:ff:ff
    inet 192.168.192.2/22 brd 192.168.195.255 scope global noprefixroute core
       valid_lft forever preferred_lft forever
    inet6 fe80::7d4:ec78:9cd3:c02a/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
4: eth2: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc
fq_codel master core state UP group default qlen 1000
    link/ether 08:00:27:81:27:3b brd ff:ff:ff:ff:ff:ff
# ip a show eth3
5: eth3: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc
fq_codel master core state UP group default qlen 1000
    link/ether 08:00:27:81:27:3b brd ff:ff:ff:ff:ff:ff
# ip a show vrrp.51
11: vrrp.51@core: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
noqueue state UP group default qlen 1000
    link/ether 00:00:5e:00:01:33 brd ff:ff:ff:ff:ff:ff
    inet 192.168.192.1/32 scope global vrrp.51
       valid_lft forever preferred_lft forever

Under this config, the .3 is BACKUP, and can ping the .1 when the .1
is on .2 (or .3 obviously).  But the .100 client can not ping the .1
at all, even though it can ping the .2 and .3 just fine.  Running arp
-env on the .100 client shows 192.168.192.1 Incomplete.  TCPDUMP on
either core or vrrp.51 show the arp request received, looks like it's
not sending the arp response though, maybe?  I don't understand why
the .100 can't ping the .1 or what needs to happen to make this work.
  Is it possible that FRR and Keepalived network kernel params or
other networking config conflict with each other?

I'm looking for suggestions and I'm open to alternatives to use_vmac
as long as the real client devices will reconnect quickly when the VIP
flips routers.

Thanks for listening!

--Sean

Re: [Keepalived-devel] Maximum amount of VIPs per VRRP group??

[Quentin A. <qu...@ar...>]

On Thu, 2019-05-30 at 20:24 +0000, Colin Hines wrote:
> Hello,
>  
> We are noticing weird slowness and display behavior with ipvsadm after installing the 26th VIP within a VRRP group, is
> this a documented limit somewhere (I haven’t been able to find anything with my google-fu)?
>  
> Thanks
> Colin
> 
> 
> 
> 
> 
> 
> 
> CONFIDENTIAL NOTICE: This email including any attachments, contains
> 
> confidential information belonging to the sender. It may also be
> 
> privileged or otherwise protected by work product immunity or other
> 
> legal rules. This information is intended only for the use of the
> 
> individual or entity named above. If you are not the intended
> 
> recipient, you are hereby notified that any disclosure, copying,
> 
> distribution or the taking of any action in reliance on the contents
> 
> of this emailed information is strictly prohibited. If you have
> 
> received this email in error, please immediately notify us by
> 
> reply email of the error and then delete this email immediately.
> 
> 
> 
> 
> 
Colin,

I am not aware of any such limit regarding number of VIPs. Can you describe in a bit more detail the symptoms you are
seeing, and also send a copy of your configuration and the output of keepalived -v. I will see if I can observe the same
effects here.

Many thanks,
Quentin

P.S. Please note the new mailing list that I have included in this reply.

[Keepalived-devel] Maximum amount of VIPs per VRRP group??

[Colin H. <ch...@th...>]

Hello,

We are noticing weird slowness and display behavior with ipvsadm after installing the 26th VIP within a VRRP group, is this a documented limit somewhere (I haven't been able to find anything with my google-fu)?

Thanks
Colin

________________________________

CONFIDENTIAL NOTICE: This email including any attachments, contains
confidential information belonging to the sender. It may also be
privileged or otherwise protected by work product immunity or other
legal rules. This information is intended only for the use of the
individual or entity named above. If you are not the intended
recipient, you are hereby notified that any disclosure, copying,
distribution or the taking of any action in reliance on the contents
of this emailed information is strictly prohibited. If you have
received this email in error, please immediately notify us by
reply email of the error and then delete this email immediately.

[Keepalived-devel] New Keepalived Users Group

[Alexandre C. <ac...@gm...>]

Hello,

This quick email to inform you that we have created a new group to host 
discussions realted to Keepalived. We created a single list. You can 
reach and subscribe to this group at following location :

https://groups.io/g/keepalived-users

I decided to leave sourceforge stuff since we had issues with it and we 
no longer have access to users membership ??!! this stuff is driving me 
crazy. So I am sorry, but I just cant export current membership to new 
Keepalived Users Group, so you need to make it by yourself :/

Have fun,
Alexandre

Re: [Keepalived-devel] send garp to unicast peer when leaving fault state?

[Olivier M. <oli...@6w...>]

Hi,

On Wed, May 22, 2019 at 08:59:14AM +0100, Quentin Armitage wrote:
> On Mon, 2019-05-20 at 08:59 +0200, Olivier Matz wrote:
> > Hi,
> > 
> > I have an issue in the following VRRP scenario:
> > - unicast peering
> > - fast advertisements (100ms)
> > 
> > Machine A
> >     version 3
> >     state BACKUP
> >     interface eth0
> >     garp_master_delay 1
> >     virtual_router_id 1
> >     priority 200
> >     advert_int 100
> >     unicast_peer {
> >       192.168.0.1
> >     }
> >     virtual_ipaddress {
> >       10.200.0.2/24
> >     }
> >     preempt_delay 30
> > 
> > Machine B
> >     version 3
> >     state BACKUP
> >     interface eth0
> >     garp_master_delay 1
> >     virtual_router_id 1
> >     priority 100
> >     advert_int 100
> >     unicast_peer {
> >       192.168.0.2
> >     }
> >     virtual_ipaddress {
> >       10.200.0.1/24
> >     }
> >     preempt_delay 30
> > 
> > 
> > 1/ initial state: A is master
> > 
> > 2/ set eth0 down on machine A
> > 
> >    A switch to fault, B becomes master
> > 
> >    B sends advertisements to A, but after some time, the
> >    ARP cache expires, so B regularly sends ARP requests that
> >    have no answers.
> > 
> > 4/ set eth0 up on machine A
> > 
> >    A changes to backup, and after ~300ms (down timer), it thinks there
> >    is no other master so it changes to master, bypassing the preemt_delay.
> > 
> > I workarounded the issue by using static ARP entries.
> > 
> > Is there a feature in keepalived to solve this issue? Should keepalived
> > send gratuitous ARPs when leaving the fault state when using unicast
> > peers? Or is it something that should be done in a user script?
> > 
> > Thanks,
> > Olivier
> > 
> Olivier,
> 
> This is clearly an issue, and keepalived currently has no direct mechanism to send gratuitous ARPs when leaving fault state.
> I think your suggestion that keepalived when using unicasting should send gratuitous ARP messages when transitioning out of
> fault state is the correct solution.
> 
> Could you please raise an issue at https://github.com/acassen/keepalived/issues including the details above so that we can
> track the progress and anyone else experiencing the issue can add their own input.
> 
> Many thanks,
> Quentin Armitage

Done: https://github.com/acassen/keepalived/issues/1283

Thanks!
Olivier

[Keepalived-devel] [acassen/keepalived] dbdeea: Use -isystem rather than -I for path to kernel hea...

[Quentin A. <no...@gi...>]

  Branch: refs/heads/master
  Home:   https://github.com/acassen/keepalived
  Commit: dbdeeaded297a152f29de62ae161215669bb9118
      https://github.com/acassen/keepalived/commit/dbdeeaded297a152f29de62ae161215669bb9118
  Author: Quentin Armitage <qu...@ar...>
  Date:   2019-05-22 (Wed, 22 May 2019)

  Changed paths:
    M configure.ac

  Log Message:
  -----------
  Use -isystem rather than -I for path to kernel headers

Using -isystem rather than -I allows the dispensation for some warnings
to system headers to apply to the kernel header tree we are specifying.
This stops some warnings that would not occur with kernel headers under
/usr/include but that were being generated when -I was used (it
nevertheless has helped identify two bugs).

Signed-off-by: Quentin Armitage <qu...@ar...>


  Commit: 66e12fe45012f9629e64a6cea981838b40c4b65c
      https://github.com/acassen/keepalived/commit/66e12fe45012f9629e64a6cea981838b40c4b65c
  Author: Quentin Armitage <qu...@ar...>
  Date:   2019-05-22 (Wed, 22 May 2019)

  Changed paths:
    M keepalived/include/vrrp_nftables.h

  Log Message:
  -----------
  Ensure check system headers for definition of NFT_TABLE_MAXNAMELEN

Prior to Linux 4.1 NFT_TABLE_MAXNAMELEN was not defined, but we must
include linux/netfilter/nf_tables.h before checking whether it is
defined or not!

Signed-off-by: Quentin Armitage <qu...@ar...>


  Commit: 7b4d393e75592b84383b0782033da942f34baa6b
      https://github.com/acassen/keepalived/commit/7b4d393e75592b84383b0782033da942f34baa6b
  Author: Quentin Armitage <qu...@ar...>
  Date:   2019-05-22 (Wed, 22 May 2019)

  Changed paths:
    M configure.ac

  Log Message:
  -----------
  Improved configure testing for <linux/netfilter/nf_tables.h>

Signed-off-by: Quentin Armitage <qu...@ar...>


  Commit: a0b87106673d60b113439c9e261088099fb51895
      https://github.com/acassen/keepalived/commit/a0b87106673d60b113439c9e261088099fb51895
  Author: Quentin Armitage <qu...@ar...>
  Date:   2019-05-22 (Wed, 22 May 2019)

  Changed paths:
    M configure.ac
    M genhash/http.c
    M genhash/include/main.h
    M genhash/main.c
    M keepalived/check/check_misc.c
    M keepalived/check/check_parser.c
    M keepalived/check/ipvswrapper.c
    M keepalived/check/ipwrapper.c
    M keepalived/core/keepalived_netlink.c
    M keepalived/vrrp/vrrp.c
    M keepalived/vrrp/vrrp_data.c
    M keepalived/vrrp/vrrp_dbus.c
    M keepalived/vrrp/vrrp_iptables_lib.c
    M keepalived/vrrp/vrrp_json.c
    M keepalived/vrrp/vrrp_nftables.c
    M keepalived/vrrp/vrrp_notify.c
    M keepalived/vrrp/vrrp_scheduler.c
    M keepalived/vrrp/vrrp_snmp.c
    M lib/scheduler.c
    M lib/utils.c

  Log Message:
  -----------
  Add warning -Wwrite-strings and resolve new warnings

Signed-off-by: Quentin Armitage <qu...@ar...>


  Commit: bec382e26af83c89a78cca0d62646adf46cc0139
      https://github.com/acassen/keepalived/commit/bec382e26af83c89a78cca0d62646adf46cc0139
  Author: Quentin Armitage <qu...@ar...>
  Date:   2019-05-22 (Wed, 22 May 2019)

  Changed paths:
    M configure.ac
    M keepalived/core/global_data.c
    M keepalived/vrrp/vrrp.c
    M keepalived/vrrp/vrrp_daemon.c
    M keepalived/vrrp/vrrp_data.c
    M keepalived/vrrp/vrrp_ip_rule_route_parser.c
    M keepalived/vrrp/vrrp_iproute.c
    M keepalived/vrrp/vrrp_json.c
    M lib/timer.h

  Log Message:
  -----------
  Add -Wdouble-promotion and resolve new warnings

Signed-off-by: Quentin Armitage <qu...@ar...>


  Commit: c011e0d87dc52270ee28b4085d857acd9db6747d
      https://github.com/acassen/keepalived/commit/c011e0d87dc52270ee28b4085d857acd9db6747d
  Author: Quentin Armitage <qu...@ar...>
  Date:   2019-05-23 (Thu, 23 May 2019)

  Changed paths:
    M configure.ac
    M keepalived/bfd/bfd.c
    M keepalived/bfd/bfd_daemon.c
    M keepalived/bfd/bfd_data.c
    M keepalived/bfd/bfd_parser.c
    M keepalived/bfd/bfd_scheduler.c
    M keepalived/check/check_api.c
    M keepalived/check/check_bfd.c
    M keepalived/check/check_data.c
    M keepalived/check/check_dns.c
    M keepalived/check/check_http.c
    M keepalived/check/check_misc.c
    M keepalived/check/check_tcp.c
    M keepalived/check/ipwrapper.c
    M keepalived/core/global_data.c
    M keepalived/core/global_parser.c
    M keepalived/core/keepalived_netlink.c
    M keepalived/core/layer4.c
    M keepalived/core/track_process.c
    M keepalived/vrrp/vrrp.c
    M keepalived/vrrp/vrrp_data.c
    M keepalived/vrrp/vrrp_if.c
    M keepalived/vrrp/vrrp_if_config.c
    M keepalived/vrrp/vrrp_iproute.c
    M keepalived/vrrp/vrrp_iprule.c
    M keepalived/vrrp/vrrp_parser.c
    M keepalived/vrrp/vrrp_print.c
    M keepalived/vrrp/vrrp_scheduler.c
    M keepalived/vrrp/vrrp_snmp.c
    M keepalived/vrrp/vrrp_static_track.c
    M lib/assert.c
    M lib/memory.c
    M lib/notify.c
    M lib/parser.c
    M lib/scheduler.c
    M lib/timer.c
    M lib/utils.c

  Log Message:
  -----------
  Add -Wformat-signedness and resolve new warnings

Signed-off-by: Quentin Armitage <qu...@ar...>


  Commit: 63a7b5bc267628d7a6592e1a20bbceec4b9372c7
      https://github.com/acassen/keepalived/commit/63a7b5bc267628d7a6592e1a20bbceec4b9372c7
  Author: Quentin Armitage <qu...@ar...>
  Date:   2019-05-23 (Thu, 23 May 2019)

  Changed paths:
    M keepalived/check/ipwrapper.c

  Log Message:
  -----------
  Fix building on Ubuntu 16.04 with --disable-vrrp

The addition of including <inttypes.h> was needed on Ubuntu 16.04,
whereas it wasn't necessary on Fedora or Debian.

Signed-off-by: Quentin Armitage <qu...@ar...>


  Commit: f60beae6137e2fe3a88d7907d86bf8595f3a3b74
      https://github.com/acassen/keepalived/commit/f60beae6137e2fe3a88d7907d86bf8595f3a3b74
  Author: Quentin Armitage <qu...@ar...>
  Date:   2019-05-23 (Thu, 23 May 2019)

  Changed paths:
    M keepalived/check/check_bfd.c
    M keepalived/core/keepalived_netlink.c
    M keepalived/core/track_process.c
    M keepalived/vrrp/vrrp.c
    M keepalived/vrrp/vrrp_if.c
    M keepalived/vrrp/vrrp_scheduler.c
    M keepalived/vrrp/vrrp_snmp.c

  Log Message:
  -----------
  Explicitly include <inttypes.h> where print format names are used

Signed-off-by: Quentin Armitage <qu...@ar...>


  Commit: 27c22be94898b7bd5fdef6ef680906331ff01e8b
      https://github.com/acassen/keepalived/commit/27c22be94898b7bd5fdef6ef680906331ff01e8b
  Author: Quentin Armitage <qu...@ar...>
  Date:   2019-05-23 (Thu, 23 May 2019)

  Changed paths:
    M configure.ac
    M keepalived/core/smtp.c
    M keepalived/core/track_process.c
    M lib/scheduler.c

  Log Message:
  -----------
  Add more -Wformat-* options and resolve new warnings

Signed-off-by: Quentin Armitage <qu...@ar...>


  Commit: a6cfb0ac483dd9c500a88907f5c2285705fa86b5
      https://github.com/acassen/keepalived/commit/a6cfb0ac483dd9c500a88907f5c2285705fa86b5
  Author: Quentin Armitage <qu...@ar...>
  Date:   2019-05-23 (Thu, 23 May 2019)

  Changed paths:
    M configure.ac

  Log Message:
  -----------
  Add -Wframe-larger-than=5120

The largest frame is just under 4200 bytes (which may be more than we
want anyway), but adding this warning will at least tell us if a stupidly
large frame is created in the future.

Signed-off-by: Quentin Armitage <qu...@ar...>


  Commit: d0acc6529209306dc6c3e10256d812ebb4c0f1cc
      https://github.com/acassen/keepalived/commit/d0acc6529209306dc6c3e10256d812ebb4c0f1cc
  Author: Quentin Armitage <qu...@ar...>
  Date:   2019-05-23 (Thu, 23 May 2019)

  Changed paths:
    M configure.ac

  Log Message:
  -----------
  Fix spelling of -Wmissing-field-initializers

Signed-off-by: Quentin Armitage <qu...@ar...>


  Commit: 0f582a63a243215a40f08c78f6e1f1b149c86e53
      https://github.com/acassen/keepalived/commit/0f582a63a243215a40f08c78f6e1f1b149c86e53
  Author: Quentin Armitage <qu...@ar...>
  Date:   2019-05-23 (Thu, 23 May 2019)

  Changed paths:
    M configure.ac

  Log Message:
  -----------
  Fix definition of PRI_rlim_t generated by configure on 32 bit systems

Signed-off-by: Quentin Armitage <qu...@ar...>


  Commit: ed1ce450aff0bc143878dc6a81d6a376e81fc480
      https://github.com/acassen/keepalived/commit/ed1ce450aff0bc143878dc6a81d6a376e81fc480
  Author: Quentin Armitage <qu...@ar...>
  Date:   2019-05-23 (Thu, 23 May 2019)

  Changed paths:
    M keepalived/bfd/bfd_scheduler.c
    M keepalived/include/bfd.h

  Log Message:
  -----------
  Rseolve warning re >=0 comparison for unsigned value

Signed-off-by: Quentin Armitage <qu...@ar...>


  Commit: 2ac461f11e0361311c4b5676e22c54295c334a62
      https://github.com/acassen/keepalived/commit/2ac461f11e0361311c4b5676e22c54295c334a62
  Author: Quentin Armitage <qu...@ar...>
  Date:   2019-05-23 (Thu, 23 May 2019)

  Changed paths:
    M configure.ac
    M genhash/http.c
    M genhash/include/main.h
    M genhash/main.c
    M keepalived/bfd/bfd.c
    M keepalived/bfd/bfd_daemon.c
    M keepalived/bfd/bfd_data.c
    M keepalived/bfd/bfd_parser.c
    M keepalived/bfd/bfd_scheduler.c
    M keepalived/check/check_api.c
    M keepalived/check/check_bfd.c
    M keepalived/check/check_data.c
    M keepalived/check/check_dns.c
    M keepalived/check/check_http.c
    M keepalived/check/check_misc.c
    M keepalived/check/check_parser.c
    M keepalived/check/check_tcp.c
    M keepalived/check/ipvswrapper.c
    M keepalived/check/ipwrapper.c
    M keepalived/core/global_data.c
    M keepalived/core/global_parser.c
    M keepalived/core/keepalived_netlink.c
    M keepalived/core/layer4.c
    M keepalived/core/smtp.c
    M keepalived/core/track_process.c
    M keepalived/include/bfd.h
    M keepalived/include/vrrp_nftables.h
    M keepalived/vrrp/vrrp.c
    M keepalived/vrrp/vrrp_daemon.c
    M keepalived/vrrp/vrrp_data.c
    M keepalived/vrrp/vrrp_dbus.c
    M keepalived/vrrp/vrrp_if.c
    M keepalived/vrrp/vrrp_if_config.c
    M keepalived/vrrp/vrrp_ip_rule_route_parser.c
    M keepalived/vrrp/vrrp_iproute.c
    M keepalived/vrrp/vrrp_iprule.c
    M keepalived/vrrp/vrrp_iptables_lib.c
    M keepalived/vrrp/vrrp_json.c
    M keepalived/vrrp/vrrp_nftables.c
    M keepalived/vrrp/vrrp_notify.c
    M keepalived/vrrp/vrrp_parser.c
    M keepalived/vrrp/vrrp_print.c
    M keepalived/vrrp/vrrp_scheduler.c
    M keepalived/vrrp/vrrp_snmp.c
    M keepalived/vrrp/vrrp_static_track.c
    M lib/assert.c
    M lib/memory.c
    M lib/notify.c
    M lib/parser.c
    M lib/scheduler.c
    M lib/timer.c
    M lib/timer.h
    M lib/utils.c

  Log Message:
  -----------
  Merge pull request #1282 from pqarmitage/updates

Add further compiler warnings options and resolve new warnings


Compare: https://github.com/acassen/keepalived/compare/2a9d61d8b53f...2ac461f11e03

[Keepalived-devel] VRRP: IGMPv3 packets sent by a BACKUP router leads to traffic loss on the MASTER router

[barak a. <bar...@gm...>]

Hi All,

I am running Keepalived 2.0.13 on our routers for VRRP capabilities.
Linux Kernel is 3.10.

Using the following basic VRRP setup:
==============================


                                                Host 2
                                                   |
                                                   |
           -----------------------------------------------------------------
           |
             |
           |
             |
router A (master) ------- port 1| switch |port 2----- router B (VRRP backup)
                                                    |
                                                    |
                                                Host 1

Router A and Router B are running VRRP, protecting some virtual IPv4
address, let's say VIPx.
Host 1 is using this VIPx address as its default gateway.
Router A is VRRP Master, VIPx is UP and RUNNING associated with VMACx.
VMACx is learned by the switch port 1 connected to Router A.
Traffic sent from Host 1 to Host 2 via Router A - all good, no issues.

Now, rebooting Router B, IGMPv3 Report packets are sent with Group = VRRP
multicast IP. The source MAC of these packet =  VMACx.
This leads to the intermediate switch learning VMACx for a while on port 2
that is connected to Backup Router B. So, traffic sent by Host 1 is going
on the wrong direction (via Router B) and we loose traffic till VMACx is
learned again by the switch on port 1 connected to Router A.

WireShark sniffing packet is attached.

I found this issue already described in issue #882 at:
https://github.com/acassen/keepalived/issues/882

I also found it in Debian bugs report logs:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706198

I tried playing with the "vmac_xmit_base" flag in the past, not for this
issue.
But then I had the real MAC also used for VRRP advertisements and ARP
frames which was somehow problematic.

I am not sure but I think some source code change is needed for sending
IGMP packets with the base interface MAC and not with the VMAC.

I will be thankful for any idea to resolve it.

Thanks
Barak

Re: [Keepalived-devel] send garp to unicast peer when leaving fault state?

[Quentin A. <qu...@ar...>]

On Mon, 2019-05-20 at 08:59 +0200, Olivier Matz wrote:
> Hi,
> 
> I have an issue in the following VRRP scenario:
> - unicast peering
> - fast advertisements (100ms)
> 
> Machine A
>     version 3
>     state BACKUP
>     interface eth0
>     garp_master_delay 1
>     virtual_router_id 1
>     priority 200
>     advert_int 100
>     unicast_peer {
>       192.168.0.1
>     }
>     virtual_ipaddress {
>       10.200.0.2/24
>     }
>     preempt_delay 30
> 
> Machine B
>     version 3
>     state BACKUP
>     interface eth0
>     garp_master_delay 1
>     virtual_router_id 1
>     priority 100
>     advert_int 100
>     unicast_peer {
>       192.168.0.2
>     }
>     virtual_ipaddress {
>       10.200.0.1/24
>     }
>     preempt_delay 30
> 
> 
> 1/ initial state: A is master
> 
> 2/ set eth0 down on machine A
> 
>    A switch to fault, B becomes master
> 
>    B sends advertisements to A, but after some time, the
>    ARP cache expires, so B regularly sends ARP requests that
>    have no answers.
> 
> 4/ set eth0 up on machine A
> 
>    A changes to backup, and after ~300ms (down timer), it thinks there
>    is no other master so it changes to master, bypassing the preemt_delay.
> 
> I workarounded the issue by using static ARP entries.
> 
> Is there a feature in keepalived to solve this issue? Should keepalived
> send gratuitous ARPs when leaving the fault state when using unicast
> peers? Or is it something that should be done in a user script?
> 
> Thanks,
> Olivier
> 
Olivier,

This is clearly an issue, and keepalived currently has no direct mechanism to send gratuitous ARPs when leaving fault state.
I think your suggestion that keepalived when using unicasting should send gratuitous ARP messages when transitioning out of
fault state is the correct solution.

Could you please raise an issue at https://github.com/acassen/keepalived/issues including the details above so that we can
track the progress and anyone else experiencing the issue can add their own input.

Many thanks,
Quentin Armitage

[Keepalived-devel] send garp to unicast peer when leaving fault state?

[Olivier M. <oli...@6w...>]

Hi,

I have an issue in the following VRRP scenario:
- unicast peering
- fast advertisements (100ms)

Machine A
    version 3
    state BACKUP
    interface eth0
    garp_master_delay 1
    virtual_router_id 1
    priority 200
    advert_int 100
    unicast_peer {
      192.168.0.1
    }
    virtual_ipaddress {
      10.200.0.2/24
    }
    preempt_delay 30

Machine B
    version 3
    state BACKUP
    interface eth0
    garp_master_delay 1
    virtual_router_id 1
    priority 100
    advert_int 100
    unicast_peer {
      192.168.0.2
    }
    virtual_ipaddress {
      10.200.0.1/24
    }
    preempt_delay 30


1/ initial state: A is master

2/ set eth0 down on machine A

   A switch to fault, B becomes master

   B sends advertisements to A, but after some time, the
   ARP cache expires, so B regularly sends ARP requests that
   have no answers.

4/ set eth0 up on machine A

   A changes to backup, and after ~300ms (down timer), it thinks there
   is no other master so it changes to master, bypassing the preemt_delay.

I workarounded the issue by using static ARP entries.

Is there a feature in keepalived to solve this issue? Should keepalived
send gratuitous ARPs when leaving the fault state when using unicast
peers? Or is it something that should be done in a user script?

Thanks,
Olivier

Re: [Keepalived-devel] Binding to the VIP

[Vincent B. <be...@lu...>]

 ❦ 17 mai 2019 10:13 +01, 700 grm <70...@gm...>:

> I have 2 SNMPD services that are configured to bind to VIP:
>
> snmpd configuration:
> agentAddress  udp:10.12.4.51:161
> agentAddress  udp:10.12.4.52:161
>
> However "notify"  option is starting SNMP agents before VIPs are moved, and
> because of it it cannot start services as there are still no VIPs

Set net.ipv4.ip_nonlocal_bind to 1. Some daemons are able to do
something similar by themselves ("freebind"), but NetSNMP doesn't.
-- 
Use variable names that mean something.
            - The Elements of Programming Style (Kernighan & Plauger)

[Keepalived-devel] Binding to the VIP

[700 g. <70...@gm...>]

Hi,

I have 2 SNMPD services that are configured to bind to VIP:

snmpd configuration:
agentAddress  udp:10.12.4.51:161
agentAddress  udp:10.12.4.52:161

However "notify"  option is starting SNMP agents before VIPs are moved, and
because of it it cannot start services as there are still no VIPs

How to configure keepalived  to move VIPs initially even when vrrp_script
is failing  at first, I've tried global_defs and vrrp_script


######## CONFIGURATION ###############
! Configuration File for keepalived

global_defs {
        router_id snmpservers
        vrrp_mcast_group4 224.0.0.18
        script_user root root
        enable_script_security

}


vrrp_script chk_snmpd {
        script   '/usr/bin/pkill -0 snmpd'
        interval 1
        fall 1
        rise 1
}



vrrp_instance VI_1 {
        state MASTER
        interface ens160
        virtual_router_id 1
        priority 150
        advert_int 1
        authentication {
                auth_type PASS
                auth_pass 12345678
        }

   notify /etc/keepalived/start-snmpd-agents.sh

        virtual_ipaddress {
                10.12.4.51/24
                10.12.4.52/24
       }

        track_script {
                chk_snmpd
        }
}
########## END ######################

Re: [Keepalived-devel] Keepalived erroneously deleting virtual route

[Quentin A. <qu...@ar...>]

On Wed, 2019-05-15 at 15:08 -0500, Murat Deligonul wrote:
> Hi,
> In my Keepalived setup, I have multiple "vrrp_instance" sections in the same configuration file. Each VRRP instance record
> also lists "virtual_routes" to be added when it's in the master state. In this particular case, the same virtual route is
> defined for two of the VRRP instances (call them A and B).
> 
> I noticed a problem with how Keepalived manages these virtual routes during state transitions. If the daemon is in Master
> state for both VRRP Instances A and B, and goes to Backup for only one of the VRRP instances, it then deletes the virtual
> route, even though the other VRRP instance still needs it.
> 
> Is this known? I observed this problem with the latest Keepalived release (2.0.16).
> 
> Let me know if you need additional details.
> 
> Thanks,
> Murat

Keepalived does not attempt to detect the same route configured in multiple vrrp instances. When a vrrp instance transitions
from backup to master it will attempt to add all the virtual routes, rules and addresses that are configured for that
instance; if they are already configured due to other vrrp instances having the same routes/rules/addresses, an error should
be logged since keepalived won't be able to add the route. Similarly, when an instance transitions from master to backup, it
will attempt to delete its virtual routes/rules/addresses.

Think of it this way: vrrp instances A and B both have route W.X.Y.Z. If instance A is down, it means it doesn't want the
route installed, if instance B is up, is does want the route installed. What should happen if A is down and B is up?

Fortunately there is a solution. You can specify different priorities for the routes, which means that both routes can be
installed at the same time, and they can be added and deleted individually.

I hope that helps,

Quentin Armitage

[Keepalived-devel] Keepalived erroneously deleting virtual route

[Murat D. <del...@gm...>]

Hi,

In my Keepalived setup, I have multiple "vrrp_instance" sections in the
same configuration file. Each VRRP instance record also lists
"virtual_routes" to be added when it's in the master state. In this
particular case, the same virtual route is defined for two of the VRRP
instances (call them A and B).

I noticed a problem with how Keepalived manages these virtual routes during
state transitions. If the daemon is in Master state for both VRRP Instances
A and B, and goes to Backup for only one of the VRRP instances, it then
deletes the virtual route, even though the other VRRP instance still needs
it.

Is this known? I observed this problem with the latest Keepalived release
(2.0.16).

Let me know if you need additional details.

Thanks,
Murat

Re: [Keepalived-devel] Keepalived v2.0.11 sometimes route to VIP isn't being deleted

[Quentin A. <qu...@ar...>]

Responses inline below:

On Tue, 2019-05-14 at 14:56 +0300, Yossi Boaron wrote:
> Hi all,
> 
> Sometimes after keepalived set & move a VIP in the system the route for the VIP IP isn't being deleted.
> The VIP (192.168.111.5) should be set to 'eth1' by keepalived as secondary IP address.
> 
> This is the relevant part of both 'ip a' and 'ip route' before keepalived starts to run:
> $ip a:
> -----
> eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
>     inet 192.168.111.21/24 brd 192.168.111.255 scope global dynamic noprefixroute eth1
>        valid_lft 2889sec preferred_lft 2889sec
> 
> $ ip r 
> default via 192.168.111.1 dev eth1 proto dhcp metric 101 
> 10.128.0.0/14 dev tun0 scope link 
> 172.22.0.0/24 dev eth0 proto kernel scope link src 172.22.0.75 metric 100 
> 172.30.0.0/16 dev tun0 
> 192.168.111.0/24 dev eth1 proto kernel scope link src 192.168.111.21 metric 101 
> 
> The Keepalived.conf file :
> -----------------------------------
> vrrp_instance ostest_API {
>     state BACKUP
>     interface eth1
>     virtual_router_id 169
>     priority 40
>     advert_int 1
>     authentication {
>         auth_type PASS
>         auth_pass ostest_api_vip
>     }
>     virtual_ipaddress {
>         192.168.123.5
>     }
>     track_script {
>         some_chk_script
>     }
> }

Should the virtual_ipaddress be 192.168.111.5?

> Sometimes after keepalived set&move the VIP (192.168.111.5) from this node, I can still see the route to the VIP.

When you say "set&move" the VIP, do you mean that the vrrp_instance becomes master, and then becomes backup again. If not,
could you please explain what is happening.
> ip r:-----$ ip r 
> default via 192.168.111.1 dev eth1 proto dhcp metric 101 
> 10.128.0.0/14 dev tun0 scope link 
> 172.22.0.0/24 dev eth0 proto kernel scope link src 172.22.0.75 metric 100 
> 172.30.0.0/16 dev tun0 
> 192.168.111.0/24 dev eth1 proto kernel scope link src 192.168.111.21 metric 101 
> 192.168.111.5 dev eth1 proto kernel scope link src 192.168.111.5 metric 101 
> $ 
With the keepalived configuration above (assuming the VIP is 192.168.111.5) keepalived doesn't do anything with routes (it
will only add or delete routes if there are static_routes or virtual_routes statements). Note also that the highlighted
route states 'proto kernel' which implies that the kernel added the route.

When the ip -r output shows the above, what does ip -a show? This looks like the route the kernel installs when an address
with a subnet mask of /32 is added, and so suggests that the address is still configured.

It would be helpful if you could include what the keepalived logs show, and also the output of keepalived -v.
> OS details$ uname -mrs
> Linux 4.18.0-80.el8.x86_64 x86_64
> $
It looks like you are running on RHEL 8, but the version of keepalived on RHEL 8 is 2.0.10. Have you built your own version
of keepalived; if so is there a reason why you haven't used 2.0.15 or 2.0.16?
> As a result of that, it's impossible to to communicate with the VIP from this node (e.g: ping 192.168.111.5) I'm getting
> 'connect: Invalid argument' error (due to 'src 192.168.111.5').
> 
> 
> I tried to search for similar bug in keepalived bug list - but no luck, is it a known issue in V2.0.11?
> 
> 
Quentin Armitage

[Keepalived-devel] Keepalived v2.0.11 sometimes route to VIP isn't being deleted

[Yossi B. <yos...@gm...>]

Hi all,

Sometimes after keepalived set & move a VIP in the system the route for the
VIP IP isn't being deleted.
The VIP (192.168.111.5) should be set to 'eth1' by keepalived as secondary
IP address.

This is the relevant part of both 'ip a' and 'ip route' before keepalived
starts to run:
$ip a:
-----
eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP
group default qlen 1000
    inet 192.168.111.21/24 brd 192.168.111.255 scope global dynamic
noprefixroute eth1
       valid_lft 2889sec preferred_lft 2889sec

$ ip r
default via 192.168.111.1 dev eth1 proto dhcp metric 101
10.128.0.0/14 dev tun0 scope link
172.22.0.0/24 dev eth0 proto kernel scope link src 172.22.0.75 metric 100
172.30.0.0/16 dev tun0
192.168.111.0/24 dev eth1 proto kernel scope link src 192.168.111.21 metric
101

The Keepalived.conf file :
-----------------------------------
vrrp_instance ostest_API {
    state BACKUP
    interface eth1
    virtual_router_id 169
    priority 40
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass ostest_api_vip
    }
    virtual_ipaddress {
        192.168.123.5
    }
    track_script {
        some_chk_script
    }
}


Sometimes after keepalived set&move the VIP (192.168.111.5) from this node,
I can still see the route to the VIP.
ip r:
-----

$ ip r
default via 192.168.111.1 dev eth1 proto dhcp metric 101 10.128.0.0/14
dev tun0 scope link 172.22.0.0/24 dev eth0 proto kernel scope link src
172.22.0.75 metric 100 172.30.0.0/16 dev tun0 192.168.111.0/24 dev
eth1 proto kernel scope link src 192.168.111.21 metric 101
*192.168.111.5 dev eth1 proto kernel scope link src 192.168.111.5
metric 101*
$

OS details

$ uname -mrs
Linux 4.18.0-80.el8.x86_64 x86_64
$

As a result of that, it's impossible to to communicate with the VIP from
this node (e.g: ping 192.168.111.5) I'm getting 'connect: Invalid argument'
error (due to 'src 192.168.111.5').



I tried to search for similar bug in keepalived bug list - but no luck, is
it a known issue in V2.0.11?

Thanks in advance

Re: [Keepalived-devel] /bin/ld: vrrp/libvrrp.a(vrrp_ip_rule_route_parser.o): undefined reference to symbol '__fpclassify@@GLIBC_2.2.5'

[Thomas J. <tho...@gm...>]

FYI this has been fixed by Quentin for an upcoming 2.0.15.


On Tue, Apr 2, 2019 at 9:33 AM Thomas Janssens <tho...@gm...>
wrote:

> Hi,
>
> When I execute *./configure* followed by *make *command, I have the
> following error:
> /bin/ld: vrrp/libvrrp.a(vrrp_ip_rule_route_parser.o): undefined reference
> to symbol '__fpclassify@@GLIBC_2.2.5'
>
> Keepalived version is 2.0.14
>
> Is it a bug?
>
> Thomas
>
>

[Keepalived-devel] /bin/ld: vrrp/libvrrp.a(vrrp_ip_rule_route_parser.o): undefined reference to symbol '__fpclassify@@GLIBC_2.2.5'

[Thomas J. <tho...@gm...>]

Hi,

When I execute *./configure* followed by *make *command, I have the
following error:
/bin/ld: vrrp/libvrrp.a(vrrp_ip_rule_route_parser.o): undefined reference
to symbol '__fpclassify@@GLIBC_2.2.5'

Keepalived version is 2.0.14

Is it a bug?

Thomas