keepalived

Sven Hartge <sven@...> wrote:

> I am using v1.1.20 on Debian Lenny with 2.6.32 from backports to
> implement a redundant router with 4 interfaces in each of the two
> servers. So I am just using the VRRP component from keepalived.

> Everything works fine so far, one server is Master (prio 150), one is
> Backup (prio 50), if I stop keepalived on the master, the backup becomes
> active, starts its notify-script, conntrackd imports the connection
> state cache, IP failover happens, etc.

Additional info: I know, that with my config, the whole Group will FAULT
if only one interface is down and that both Master and Backup will be
offline, if both have a faulty link. This is, as of now, intentional.

Grüße,
Sven.

-- 
Sig lost. Core dumped.

Sven Hartge <sven@...> wrote:

> But while testing with link failures, something weird happend. 

This seems to be related to

http://article.gmane.org/gmane.linux.keepalived.devel/3183

and

http://article.gmane.org/gmane.linux.keepalived.devel/3166

Am I right?

Grüße,
Sven.

-- 
Sig lost. Core dumped.

Sven Hartge <sven@...> wrote:
> Sven Hartge <sven@...> wrote:

>> But while testing with link failures, something weird happend. 

> This seems to be related to

> http://article.gmane.org/gmane.linux.keepalived.devel/3183

> and

> http://article.gmane.org/gmane.linux.keepalived.devel/3166

> Am I right?

Seems, I am not, as I am not seeing the "forcing a new MASTER election"
messages on my BACKUP system, after the link has been restored.

Grüße,
Sven.

-- 
Sig lost. Core dumped.

Sven Hartge <sven@...> wrote:
> Sven Hartge <sven@...> wrote:
>> Sven Hartge <sven@...> wrote:

>>> But while testing with link failures, something weird happend. 

>> This seems to be related to

>> http://article.gmane.org/gmane.linux.keepalived.devel/3183

>> and

>> http://article.gmane.org/gmane.linux.keepalived.devel/3166

>> Am I right?

> Seems, I am not, as I am not seeing the "forcing a new MASTER election"
> messages on my BACKUP system, after the link has been restored.

I compiled and deployed Vincentes latest fixes-tree and retested my
scenario, and as I suspected: the fix from above does not fix my problem.

Grüße,
Sven.

-- 
Sig lost. Core dumped.

OoO En ce  début d'après-midi nuageux du vendredi  22 octobre 2010, vers
14:00, Sven Hartge <sven@...> disait :

> vrrp_sync_group GRP_FW02 {
>         group {
>                 eth0
>                 eth1
>                 eth2
>                 eth3
>         }
>         notify "/usr/local/sbin/failover.sh"
> }

Just to be sure. The storm only happens if you use a sync group? Does it
happen without the notify script?
-- 
I WILL NOT BURY THE NEW KID
I WILL NOT BURY THE NEW KID
I WILL NOT BURY THE NEW KID
-+- Bart Simpson on chalkboard in episode 9F03

Vincent Bernat <bernat@...> wrote:
> OoO En ce  début d'après-midi nuageux du vendredi  22 octobre 2010, vers
> 14:00, Sven Hartge <sven@...> disait :

>> vrrp_sync_group GRP_FW02 {
>>         group {
>>                 eth0
>>                 eth1
>>                 eth2
>>                 eth3
>>         }
>>         notify "/usr/local/sbin/failover.sh"
>> }

> Just to be sure. The storm only happens if you use a sync group? Does
> it happen without the notify script?

Yes, only with the sync group.

If I don't use any sync group, the vrrp_instance whose interface has
been replugged transitions to MASTER state alone, even if there is
another MASTER (with higher prio) already active on that interface.

If I use the sync group, this vrrp_instance "pulls" all other instances
into MASTER state, as you can see from the logs.

I don't know (yet) if this also happens without notify script and sync
group, I will test this on Monday, when I am back at work.

But in the case without sync group there also was no notify script and
the replugged vrrp_instance (eth3 in this case) transitioned to MASTER
state.

S°

-- 
Sig lost. Core dumped.

Vincent Bernat <bernat@...> wrote:
> OoO En ce  début d'après-midi nuageux du vendredi  22 octobre 2010, vers
> 14:00, Sven Hartge <sven@...> disait :

>> vrrp_sync_group GRP_FW02 {
>>         group {
>>                 eth0
>>                 eth1
>>                 eth2
>>                 eth3
>>         }
>>         notify "/usr/local/sbin/failover.sh"
>> }

> Just to be sure. The storm only happens if you use a sync group? Does it
> happen without the notify script?

Yes, the same behavior happens without the notify script.

Grüße,
Sven.

-- 
Sig lost. Core dumped.

Vincent Bernat <bernat@...> wrote:
> OoO En ce  début d'après-midi nuageux du vendredi  22 octobre 2010, vers
> 14:00, Sven Hartge <sven@...> disait :

>> vrrp_sync_group GRP_FW02 {
>>         group {
>>                 eth0
>>                 eth1
>>                 eth2
>>                 eth3
>>         }
>>         notify "/usr/local/sbin/failover.sh"
>> }

> Just to be sure. The storm only happens if you use a sync group? Does it
> happen without the notify script?

Any news on this one? I will get some spare hardware this or the
following week, which allows me to test different scenarios and patches
without disrupting my production network.

If you have any ideas, I am more than eager to test them.

Grüße,
Sven.

-- 
Sig lost. Core dumped.

OoO La nuit ayant déjà recouvert d'encre ce jour du dimanche 14 novembre
2010, vers 23:45, Sven Hartge <sven@...> disait :

>>> vrrp_sync_group GRP_FW02 {
>>> group {
>>> eth0
>>> eth1
>>> eth2
>>> eth3
>>> }
>>> notify "/usr/local/sbin/failover.sh"
>>> }

>> Just to be sure. The storm only happens if you use a sync group? Does it
>> happen without the notify script?

> Any news on this one? I will get some spare hardware this or the
> following week, which allows me to test different scenarios and patches
> without disrupting my production network.

Unfortunately, I am  not very aware of sync groups. I  need to find some
time to look at it.
-- 
BOFH excuse #139:
UBNC (user brain not connected)