<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.linux.keepalived.devel">
    <title>gmane.linux.keepalived.devel</title>
    <link>http://blog.gmane.org/gmane.linux.keepalived.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.keepalived.devel/3861"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.keepalived.devel/3853"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.keepalived.devel/3848"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.keepalived.devel/3841"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.keepalived.devel/3831"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.keepalived.devel/3829"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.keepalived.devel/3823"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.keepalived.devel/3822"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.keepalived.devel/3821"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.keepalived.devel/3812"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.keepalived.devel/3806"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.keepalived.devel/3804"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.keepalived.devel/3803"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.keepalived.devel/3799"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.keepalived.devel/3794"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.keepalived.devel/3789"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.keepalived.devel/3787"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.keepalived.devel/3786"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.keepalived.devel/3785"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.keepalived.devel/3783"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.linux.keepalived.devel/3861">
    <title>Backup takeover delay</title>
    <link>http://comments.gmane.org/gmane.linux.keepalived.devel/3861</link>
    <description>&lt;pre&gt;Is there a way to control the number of missed adverts that will cause a
backup to transition to a master? I've looked through the source a bit, and
it looks like it may be hardcoded to 3 * advert plus a skew, but I didn't
study the code enough to be sure.

Is that correct? Is there a way to control the number of missed adverts the
causes a backup to transition to a master?

-Brad
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
Keepalived-devel mailing list
Keepalived-devel&amp;lt; at &amp;gt;lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/keepalived-devel
&lt;/pre&gt;</description>
    <dc:creator>Brad Schick</dc:creator>
    <dc:date>2012-05-24T16:41:30</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.keepalived.devel/3853">
    <title>curiouse state switch</title>
    <link>http://comments.gmane.org/gmane.linux.keepalived.devel/3853</link>
    <description>&lt;pre&gt;Hi,

sry for posting in the developement Mailing List. I hope that its ok. I 
have a realy strange Problem with our 2 Firewalls which runs under 
Debian Squeeze x64 with keepalived and conntrackd.

The Backup Server gos into the Master state for a few seconds without 
any inteface down Reports on Syslog / Snmp or else. On the Master Server 
I can only see some Received lower prio advert, forcing new election 
entrys. The Master server never lost the virtuell IP Adresses. At 
08:13:12 the Backup Server stopps with switching Backup &amp;lt;-&amp;gt; Master and 
was on the correct State "BACKUP".

All internal traffic goes to the correct Gateway IP Adress 192.168.43.1. 
But all the external Traffic was on the Backup Server which had no  
virtuell Adresses! Its also curiouse that the new election was only on 2 
of our 3 VRRP Interfaces as you can see below.

Backup Log(full on attach):

May 24 08:13:10 servername-backup Keepalived_vrrp: 
VRRP_Instance(VI_extern) Transition to MASTER STATE
May 24 08:13:10 servername-backup Kee&lt;/pre&gt;</description>
    <dc:creator>Tobias Dinse</dc:creator>
    <dc:date>2012-05-24T08:06:18</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.keepalived.devel/3848">
    <title>backup keepalived responds to neighbor sollication for vrrp ipv6 address</title>
    <link>http://comments.gmane.org/gmane.linux.keepalived.devel/3848</link>
    <description>&lt;pre&gt;Hey guys,

I'm running Keepalived v1.2.2 (12/23,2011) on 2 ubuntu12.04 servers and 
I'm having ipv6 problems. (ipv4 runs perfectly)
Box2 is answering neighbor sollicitations for the vrrp ipv6 address 
living on box1 although the ip is not configured on box2 and keepalived 
is in backup state there.

box1 keepalived:
vrrp_instance vlan123 {
         state BACKUP
         interface vlan123
         virtual_router_id 40
         priority 250
         preempt_delay 90

         authentication {
                 auth_type PASS
                 auth_pass secretpass
         }

         virtual_ipaddress {
                 1.2.3.49/32
                 2001:1234:ffff::10/124
         }
}

box2 keepalived:
vrrp_instance vlan123 {
         state BACKUP
         interface vlan123
         virtual_router_id 40
         priority 200
         preempt_delay 90

         authentication {
                 auth_type PASS
                 auth_pass secretpass
         }

         virtual_ipaddress {
                 1.2.3.49/3&lt;/pre&gt;</description>
    <dc:creator>Tom van Leeuwen</dc:creator>
    <dc:date>2012-05-07T06:10:37</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.keepalived.devel/3841">
    <title>Getting around an ARP cache with a very longrefresh</title>
    <link>http://comments.gmane.org/gmane.linux.keepalived.devel/3841</link>
    <description>&lt;pre&gt;Hi,
I have a very basic setup where I just move IPs and a few routes
between two machines. I though I could get away with just keepalived -
it works beautifully, or at least it did in my test environment... One
of our link providers has some insane ARP cache refresh (several
hours) and so my lovely keepalived system moves the IPs in seconds
only for the IPs to remain unavailable for hours :-(. Of course they
aren't updating with gratuitous ARPs (which keepalived does also,
right? Anyway, even manual arping doesn't change things) I didn't want
to introduce any other pieces into the system but if I am going to
have a virtual MAC that gets transferred then I'll need something more
right? Is that the best way to go?
Any ideas?
Thanks
Anton

&lt;/pre&gt;</description>
    <dc:creator>Anton Melser</dc:creator>
    <dc:date>2012-05-02T13:41:03</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.keepalived.devel/3831">
    <title>Failover takes 3-5 seconds</title>
    <link>http://comments.gmane.org/gmane.linux.keepalived.devel/3831</link>
    <description>&lt;pre&gt;Hi,

I've setup keepalived in a MASTER/BACKUP configuration on 2 servers. I'll
paste the configuration of both at the end of the message.

Everything is working perfectly - When the check fails on MASTER, the
virtual IP is swapped and the failover happens. When I kill keepalived on
the MASTER, it happens too. When I bring keepalived or the check passes on
the lower priority server, the failover happens.

However, This failover takes 3-5 seconds, during which I can see 3-4
packets lost on a regular 'ping VIRTUAL_IP' (1-sec interval ICMP). Is this
normal? Can this be lower? in 5 seconds I can lose quite a bit of HTTP
requests from users, since we have a pretty high-volume website.

Note: I'm using keepalived 1.1.20 with Willy Tarreau (haproxy author)
unicast patch: http://1wt.eu/keepalived/keepalived-1.1.19-unicast.patch .
It works great.

Here are the configurations:

MASTER:
global_defs {
notification_email {
email&amp;lt; at &amp;gt;example.com
}
notification_email_from "Keepalived &amp;lt;keepalived&amp;lt; at &amp;gt;lb-01.example.com&amp;gt;"
smtp_server &lt;/pre&gt;</description>
    <dc:creator>Bar Ziony</dc:creator>
    <dc:date>2012-04-29T10:53:07</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.keepalived.devel/3829">
    <title>Keepalived 1.2.2, IPV6 &amp; fwmarks</title>
    <link>http://comments.gmane.org/gmane.linux.keepalived.devel/3829</link>
    <description>&lt;pre&gt; 

It's been awhile since I've posted to this list, which reflects my
dive into Keepalived with IPv6. Does anyone have a solution for a
Keepalived config using fwmarks with both IPv4/IPv6 and UDP/TCP
services? I've already tried the following patch


https://github.com/vincentbernat/keepalived/commit/479bb39cb94e602e8e8891d84538b2f67de14f04


with limited success. It fixes my IPv6 issues, but breaks my IPv4 UDP
regardless of my use of fwmarks. I'm using DNS as the initial test
service. Using ipvsadm all services appear up and ready on dual stack
servers, but I get response timeouts with IPv6 without patch, and IPv4
with patch. Without patch, IPv6 works great using the traditional
IP:port config - but in my environment that's a hell of a high
maintenance config. Fwmarks makes everything simple. I'd like to keep it
that way if at all possible. I'm using CentOS 6.2 (i386), LVS-DR,
IPv6/IPv4 port 53 (TCP/UDP), and the latest Keepalived 1.2.2-3 from EPEL
rebuilt using the source RPM. 

Any ideas? 

Thanks in adva&lt;/pre&gt;</description>
    <dc:creator>Ken Price</dc:creator>
    <dc:date>2012-04-23T16:51:09</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.keepalived.devel/3823">
    <title>A few collected patches</title>
    <link>http://comments.gmane.org/gmane.linux.keepalived.devel/3823</link>
    <description>&lt;pre&gt;I'd best begin with an apology - I originally wrote these several years 
ago (1.1.15).  I've forward ported them to 1.2.2, but not tested them. 
Most of them came from trying to figure out why KA wasn't working 
(missing values for example when I expected a default value to be present)

keepalived.check_ports.diff - error if the ports aren't valid
keepalived.check_smtp_log.diff - log alert
keepalived.check_ssl_log.diff - log alert
keepalived.missing_syslogs.diff - log group changes
keepalived.nohostport.diff - use "Host: foo" rather than "Host: foo:80" 
in requests
keepalived.received.diff - fix spelling errors
keepalived.syslog_facility.diff - for some reason we don't respect 
LOG_DAEMON - I'm not sure _why_  (main.c doesn't do this)
keepalived.validvalues.diff - report when values are not valid

Sometimes the SMTP and logging seems inconsistent - perhaps there should 
just be a generic logging function for anything "important".

Adrian

----------------------------------------------------------------------&lt;/pre&gt;</description>
    <dc:creator>Adrian Bridgett</dc:creator>
    <dc:date>2012-03-31T12:02:29</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.keepalived.devel/3822">
    <title>Upgrade from 1.1.15 to 1.1.20</title>
    <link>http://comments.gmane.org/gmane.linux.keepalived.devel/3822</link>
    <description>&lt;pre&gt;Hello everybody,

Actually I got 2 firewalls where Debian Lenny is running (yeah I know ...
outdated).
Therefore, I'm going to upgrade them to Debian Squeeze but in the
meantime, 
I'm interessed in your feedback/experiences regarding those versions of
Keepalived.

You'll find my configuration (anonymized) in attachement, basicly a bit of
VRRP and of LVS.
I'm most interessed :
    1. to check if any behavior has changed from 1.1.15 to .20 ?
    2. to know if it's possible to have .15 and .20 talk together; 
       Is this possible or is this something I absolutely have to avoid by
disconnecting the upgrading server ?

Thanks for your help :)

Henry-Nicolas Tourneur.
vrrp_script chk_ping {
        script "ping -c 2 -i 0.1 17.4.40.51 -W 1"
        interval 5
        weight -100
}

vrrp_script chk_vpn {
        script "/usr/local/bin/check_openvpn -t localhost -p 11940 -n openvpn"
        interval 30
        weight -100
}

vrrp_instance VI_1 {
        interface eth2
        dont_track_primary
    &lt;/pre&gt;</description>
    <dc:creator>Henry-Nicolas Tourneur</dc:creator>
    <dc:date>2012-03-30T13:45:40</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.keepalived.devel/3821">
    <title>Healthcheckers and delay_before_retry defaultvalue causing 100% cpu</title>
    <link>http://comments.gmane.org/gmane.linux.keepalived.devel/3821</link>
    <description>&lt;pre&gt;Hello,

I cant find a suitable existing topic that covers this so..

Were running keepalived (Keepalived v1.2.2 (11/07,2011)) on RHEL6 (2.6.32-220.4.2.el6.i686) (and x86_64) which the configuration has migrated from RHEL4 so it was missing afew values.

After the OS and keepalived upgrade the cpu started to hit the roof, during investigation i removed the checkers one by one and found the issuing checker was checking a service which was down.
Adding (it was missing) delay_before_retry to the config caused cpu to hit normal values again.

Briefly checking the code i notice you divide and multiply with TIMER_HZ, could it be that without the delay_before_retry set the check is issued at an alarming rate, ie 100 or 1000 times per second?

Sincerely,
Joachim

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure_______________________________________________
Keepalived-devel ma&lt;/pre&gt;</description>
    <dc:creator>Joachim Larsson</dc:creator>
    <dc:date>2012-03-27T14:42:44</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.keepalived.devel/3812">
    <title>keepalived continuously forcing new election</title>
    <link>http://comments.gmane.org/gmane.linux.keepalived.devel/3812</link>
    <description>&lt;pre&gt;I have a very simple keepalived configuration with two VRRP instances 
(VRRP_1 and VRRP_2) using two nodes (call then A and B) for failover:

Node A is default MASTER for VRRP_1 with priority 100 and BACKUP for 
VRRP_2 with priority 50.

Node B is default MASTER for VRRP_2 with priority 100 and BACKUP for 
VRRP_1 with priority 50.

This seems simple enough to me. When both nodes are up, each will manage 
a single VIP. If one fails, the other will serve as backup. My config 
file is attached. The file is identical on both nodes except that state 
and priority are changed as expected.

With keepalived running on node A, it will be master for both VRRP 
instances. The problem occurs when I start keepalived on node B. I would 
expect that node B would become master for VRRP_2 and node A would 
remain master for VRRP_1. That does not seem to be the case. On node B I 
see:

Mar 21 08:31:44 node-02 Keepalived_vrrp: VRRP_Instance(VRRP_2) Received 
lower prio advert, forcing new election
Mar 21 08:31:44 node-02 Keepa&lt;/pre&gt;</description>
    <dc:creator>Ryan O'Hara</dc:creator>
    <dc:date>2012-03-21T16:02:25</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.keepalived.devel/3806">
    <title>Question</title>
    <link>http://comments.gmane.org/gmane.linux.keepalived.devel/3806</link>
    <description>&lt;pre&gt;If you set the weights in keepalived to 10000 and the other server 1.

Will that now only send 1 connection for every 10000 that hit the other?

I dont want to traffic to go to my other server unless my primary drops
out. Since keepalived doesnt have this function i was wondering if the
weights are limited to a specified number?

Cheers

Nick Tailor
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d_______________________________________________
Keepalived-devel mailing list
Keepalived-devel&amp;lt; at &amp;gt;lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/keepalived-devel
&lt;/pre&gt;</description>
    <dc:creator>nick tailor</dc:creator>
    <dc:date>2012-03-06T19:13:04</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.keepalived.devel/3804">
    <title>use_vmac</title>
    <link>http://comments.gmane.org/gmane.linux.keepalived.devel/3804</link>
    <description>&lt;pre&gt;Hi

Is this implemented in keepalived-1.2.2-2.el6.i686? Have people found it useful?

Thanks,
&lt;/pre&gt;</description>
    <dc:creator>Steve Clark</dc:creator>
    <dc:date>2012-03-06T14:29:41</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.keepalived.devel/3803">
    <title>[bug?] keepalived-1.2.2：sockaddr_storage compare</title>
    <link>http://comments.gmane.org/gmane.linux.keepalived.devel/3803</link>
    <description>&lt;pre&gt;Hi all,
     I find there is bug in sockstorage_equal().
     First, sockstorage_equal() always return true when comparing IPv4 
address.
     Second, if vs has vfwmark or vsgname, it will be clear on reload. 
Because, sockaddr_storage is initialized to zero.Then, two virtual 
servers are never equal by VS_ISEQ(). It is similar to virtual server 
group entry.
     The patch is as follows.
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d_______________________________________________
Keepalived-devel mailing list
Keepalived-devel&amp;lt; at &amp;gt;lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/keepalived-devel
&lt;/pre&gt;</description>
    <dc:creator>Jiajun Chen</dc:creator>
    <dc:date>2012-02-28T12:41:09</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.keepalived.devel/3799">
    <title>Keepalived and ipv6</title>
    <link>http://comments.gmane.org/gmane.linux.keepalived.devel/3799</link>
    <description>&lt;pre&gt;Hi, 

  I'm trying to configure an IPv6 virtual server using keepalived. But, as a
result I'm getting an IPv4 one with wrong ip addresses. I'm using ipvsadm 1.25.9
and keepalived 1.2.2-2 (both from RH6 and compiled with libnl 1.1.14).
  When I configure a VS manually it works fine:

#ipvsadm -A -f 201 -6 -s wrr
#ipvsadm -a -f 201 -6 -r 2a00:81c0:4000:1f41::300:0 -w 5
#ipvsadm -a -f 201 -6 -r 2a00:81c0:4000:1f41::300:100 -w 5

# ipvsadm
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -&amp;gt; RemoteAddress:Port           Forward Weight ActiveConn InActConn
FWM  201 IPv6 wrr
  -&amp;gt; [2a00:81c0:4000:1f41::300:0]:0 Route   5      0          0
  -&amp;gt; [2a00:81c0:4000:1f41::300:100]:0 Route   5      0          0

  If I use keepalived with a config file like this (I removed all MISC_CHECK
stuff as not-related):

virtual_server fwmark 201 {
  lb_algo wrr
  lb_kind DR
  protocol TCP
  real_server 2a00:81c0:4000:1f41::300:0 0 {
    weight 1
    inhibit_on_failure
  }
  real_server 2a00:81c0:4&lt;/pre&gt;</description>
    <dc:creator>Anton Antonov</dc:creator>
    <dc:date>2012-02-27T12:11:46</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.keepalived.devel/3794">
    <title>Weight vs. Priority - what's the relationship?</title>
    <link>http://comments.gmane.org/gmane.linux.keepalived.devel/3794</link>
    <description>&lt;pre&gt;Hi all,

Most of the example configurations I find do not specify a "weight"
for vrrp_script or track_script, and it sounds like the default weight
is "2".

At the same time, the same example configurations specify a priority
of "150" for the MASTER, and "100" for the BACKUP.

My question is:  if the track_script fails, and the weight is "2", how
does the BACKUP take over the VIPs?  The priorities differ by 50, but
the weight is only 2.


The reason I ask is that I'm facing a problem with failover, in which
the MASTER retains the VIPs, but traffic is being directed toward the
BACKUP (which should now be the MASTER) -- sort of a split-brain
problem.

My configuration files are below.  I'm running Debian w/ keepalived 1:1.1.20-1.

Thanks!

---------------------- lb1 ----------------------

vrrp_script check_nginx {
    script "/usr/bin/killall -0 nginx"
    interval 2
    #weight 2
}

vrrp_instance VI_1 {
    interface eth1
    state MASTER
    virtual_router_id 51
    priority 150

    authentication {
      &lt;/pre&gt;</description>
    <dc:creator>Kian Mohageri</dc:creator>
    <dc:date>2012-02-24T19:55:01</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.keepalived.devel/3789">
    <title>here is my CENTISECOND advertize interval patch</title>
    <link>http://comments.gmane.org/gmane.linux.keepalived.devel/3789</link>
    <description>&lt;pre&gt;Hello every one
I'm new to the list and thought i would introduce my self with a bang
attached is my patch to implement centisecond vrrp advertize intervals
I've been able to confirm with tcpdumd it actually does send
advertizements as fast as every 0.01 seconds

The catch is the  advert_int  option in the configuration is now in
centiseconds and as such I've altered the default to be 100 ( 1
second)

Also I suspect there are other bottlenecks in the code but I was able
to get my iptables firewall to failover and resuming the sessions
(with contrackd) at full speed again in under 4 seconds from the time
the link on the network cable disappeared.

with the following settings in my conf

garp_master_delay 0 # yes this means no delay it actually works
advert_int 1 # 1/100th of a second

vrrp over the crossover link between the firewalls
with several vips on various interfaces

contrackd with "DisableExternalCache On" set in the config

disconnecting the cable on one of the tracked interfaces "not with
vrrp dire&lt;/pre&gt;</description>
    <dc:creator>Paul Robert Marino</dc:creator>
    <dc:date>2012-02-24T18:04:04</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.keepalived.devel/3787">
    <title>keepalived-1.2.2 unicast patch</title>
    <link>http://comments.gmane.org/gmane.linux.keepalived.devel/3787</link>
    <description>&lt;pre&gt;Hello,

I want to share keepalived unicast patch for version 1.2.2 based on 
Willy Tarreau patch for earlier version 
http://1wt.eu/keepalived/keepalived-1.1.19-unicast.patch.
I'm not C programmer, so please review the following code and consider 
including it in main version. Of course this patch is not RFC compliant 
but critical for large networks and environments where multicast is 
unavailable.

Two additional parameter added:
vrrp_unicast_bind
vrrp_unicast_peer

Currently only two ipv4 peers supported.

Best regards,
Aleksey



diff --git a/keepalived/include/vrrp.h b/keepalived/include/vrrp.h
index 03c94f9..8c3cb15 100644
--- a/keepalived/include/vrrp.h
+++ b/keepalived/include/vrrp.h
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -94,6 +94,8 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; typedef struct _vrrp_rt {
         list track_ifp;         /* Interface state we monitor */
         list track_script;      /* Script state we monitor */
         uint32_t mcast_saddr;   /* Src IP address to use in VRRP IP 
header */
+       uint32_t unicast_bind;  /* listen to this IP if mcast is not &lt;/pre&gt;</description>
    <dc:creator>Aleksey Chudov</dc:creator>
    <dc:date>2012-02-09T15:59:11</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.keepalived.devel/3786">
    <title>[PATCH] Add excluded VIPs to loopback instead tothe IF the VRRP</title>
    <link>http://comments.gmane.org/gmane.linux.keepalived.devel/3786</link>
    <description>&lt;pre&gt;Hi,

we've been investigating a few minor issues with LVS and keepalived; a
freelance developer at my team also prepared a couple of smaller patches
to resolve those issues we'd like to contribute to the general
LVS/keepalived public.

The patches are based upon commit 91c61a85dccffd00dd6e887d24302443e412433d
from http://master.formilux.org/git/people/alex/keepalived.git, but
of course do apply to newer releases as well.

=== Add excluded VIPs to loopback instead to the IF the VRRP

Services at our site are running in a georedundant setup;
to enable the balancer pair at site B to take over the VIP adresses
usually routed to site A, we're running the Border Gateway Protocol
from balancers to advertise the VIPs to our network core.

As a result, there isn't any need to run ARP (IPv4) or neighbor 
advertisements (IPv6) for our balancer's VIPs. In fact, we'd like
to avoid their ARP/ND traffic at all.

Some balancers may host very many VIPs, so a local failover may result in 
a temporary flooding of gratious ARP &lt;/pre&gt;</description>
    <dc:creator>Anders Henke</dc:creator>
    <dc:date>2012-02-09T15:28:50</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.keepalived.devel/3785">
    <title>[PATCH] Make http(s) healthchecker check forregular expression</title>
    <link>http://comments.gmane.org/gmane.linux.keepalived.devel/3785</link>
    <description>&lt;pre&gt;Hi,

we've been investigating a few minor issues with LVS and keepalived; a
freelance developer at my team also prepared a couple of smaller patches
to resolve those issues we'd like to contribute to the general
LVS/keepalived public.

The patches are based upon commit
91c61a85dccffd00dd6e887d24302443e412433d
from http://master.formilux.org/git/people/alex/keepalived.git, but
of course to apply to newer releases as well.

=== Regex content check for http(s) healthcheckers

Usually, checking for the digest of a static (testing-only) website is
fine to check wether some service is available; in some setups, we do
need some way to also check more "dynamic" content and not only the
testing code by checking the content of a http(s) website.

Over the last few years, we did so using a check_misc command, but chose 
to implement an option to the keepalived-internal healtchecker as well.

The attached patch uses the regex functions of ICU/libicuuc to check 
for a regular expression within the first 4000 byte of retu&lt;/pre&gt;</description>
    <dc:creator>Anders Henke</dc:creator>
    <dc:date>2012-02-09T15:04:25</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.keepalived.devel/3783">
    <title>[PATCH] Add notify_failed and notify_ok forchecks</title>
    <link>http://comments.gmane.org/gmane.linux.keepalived.devel/3783</link>
    <description>&lt;pre&gt;Hi,

we've been investigating a few minor issues with LVS and keepalived; a
freelance developer at my team also prepared a couple of smaller patches
to resolve those issues we'd like to contribute to the general
LVS/keepalived public.

The patches are based upon commit 91c61a85dccffd00dd6e887d24302443e412433d 
from http://master.formilux.org/git/people/alex/keepalived.git, but
of course to apply to newer releases as well.

=== Add notify_failed and notify_ok for checks

In our setups, we're setting up at least three healthchecker commands:
-check the realserver's service - for an obvious reason
-check for a tcp service at the realserver for the general
 service availability. When a realserver's admin or devops 
 requires some time for maintenance, they shut down that special
 tcp service and wait for a few minutes until any persisted connections 
 have also left.
-check for a local file on the balancer, wether some realservers
 should be excluded from balancing. This way the admin of a keepalived
 balancer m&lt;/pre&gt;</description>
    <dc:creator>Anders Henke</dc:creator>
    <dc:date>2012-02-09T14:52:35</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.keepalived.devel/3782">
    <title>[PATCH] libipvs: Fix initialization of netlink(needed for IPv6)</title>
    <link>http://comments.gmane.org/gmane.linux.keepalived.devel/3782</link>
    <description>&lt;pre&gt;Hi,

we've been investigating a few minor issues with LVS and keepalived; a
freelance developer at my team also prepared a couple of smaller patches
to resolve those issues we'd like to contribute to the general
LVS/keepalived public.

=== Fix Netlink Init

When the kernel module for ip_vs hasn't been loaded yet and an
application (say, keepalived) tries to call ipvs, IPVS assumes
netlink not to be present and triggers another load attempt
of the kernel module, but without re-testing for netlink.
In the end, netlink isn't being used. However, netlink is essential
for running IPVS with IPv6.

Attached is a oneline-patch for libipvs to adress this issue; it is
based upon commit 91c61a85dccffd00dd6e887d24302443e412433d from
http://master.formilux.org/git/people/alex/keepalived.git,
but is simple enough to be applied to almost any other
release of libipvs as well.

I've posted this patch also to lvs-devel, but as the repository
for keepalived seems to maintain its own version of libipvs,
I'm also posting the pat&lt;/pre&gt;</description>
    <dc:creator>Anders Henke</dc:creator>
    <dc:date>2012-02-09T14:03:06</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.linux.keepalived.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.linux.keepalived.devel</link>
  </textinput>
</rdf:RDF>

