[prev in list] [next in list] [prev in thread] [next in thread] 

List:       keepalived-devel
Subject:    Re: [Keepalived-devel] keepalived on VMWARE
From:       Todd Fleisher <todd () fleish ! org>
Date:       2009-10-14 16:43:03
Message-ID: 99F9C936-655F-4A12-B39E-48EA99F2791F () fleish ! org
[Download RAW message or body]

John,
Please share your configuration so we can see what you are tracking  
on. If you are tracking on vmnic# and that goes into a true DOWN state  
when you drop the link then in my mind this shouldn't happen. Of  
course, I've not run keepalived on VM's in this fashion so I'm just  
thinking about this theoretically.

To your explicit question about under what state keepalived will send  
out GARP's - it does so when a VRRP changes state to MASTER. It is  
possible under certain configurations to have 2 directors have a split  
brain scenario (e.g. Directors A/B connected to switches A/B  
respectively & switches A/B are trunked together with an ISL. Also A  
has a higher priority than B. If you lose the ISL both directors could  
be in a MASTER state (say A was already MASTER so no state change, but  
say B was BACKUP & when it stops seeing A's advertisements B becomes  
MASTER also & therefore GARP's for the VRRP IP's). Now restore the ISL  
& B would transition to backup when it sees A's advertisements again.  
However, A just stays in a MASTER state the entire time. Since there  
was no transition on A, A doesn't GARP after B moves to BACKUP.  
Therefore, any clients on switch B that saw B's GARP might continue  
trying to send traffic to B instead of A.

-T

On Oct 14, 2009, at 5:30 AM, John Bourke wrote:

> Folks,
>
> Got a tough one !
>
> I am running two Linux instances (LinuxA, LinuxB) on two VMWARE hosts
> (HostA, HostB), one on each.
>
> I have the VMWARE hosts dual connected (vmnic0 and vmnic1) to two  
> switches,
> one link active and one link standby.
>
> Remember, between Linux and Host there is a virtual switch which is  
> always
> on, ie, the port is always up even if the vmnic's are down.
>
> I run keepalived on the servers.
>
> I can switch from active to standby interfaces on a host with no  
> problem, my
> clients still use the VRRP address on the master.  So the network  
> redundancy
> is good, I can loose a switch or an individual interface without  
> affecting
> service.
>
> If I loose both links into the master, the second server takes over  
> the VRRP
> address.  This works fine.
>
> When I run a test sequence like this
>
> Drop HostA vmnic0, network is on HostA vmnic1, VRRP IP on LinuxA
> Drop HostA vmnic1, network is on HostB vmnic0, VRRP IP on LinuxB
> Drop HostB vmnic0, network is on HostB vmnic1, VRRP IP on LinuxB
> Drop HostB vmnic1, network is down,            VRRP IP on LinuxB
> Up HostB vmnic1,   network is on HostB vmnic1, VRRP IP on LinuxB
> Up HostB vmnic0,   network is on HostB vmnic0, VRRP IP on LinuxB
> Up HostA vmnic1,   network is on HostA vmnic1, VRRP IP on LinuxA
> Up HostA vmnic0,   network is on HostA vmnic0, VRRP IP on LinuxA
>
> Looks good !  Except if it run it another way ....
>
> Drop HostA vmnic0, network is on HostA vmnic1, VRRP IP on LinuxA
> Drop HostA vmnic1, network is on HostB vmnic0, VRRP IP on LinuxB
> Drop HostB vmnic0, network is on HostB vmnic1, VRRP IP on LinuxB
> Drop HostB vmnic1, network is down,            VRRP IP on LinuxB
> Up HostA vmnic0,   network is on HostA vmnic0, VRRP IP on LinuxB
>
> So you see the problem.  HostB network is down, LinuxB it has the  
> VRRP IP
> (it was last to send Garp).  LinuxA does not send Garp when HostA  
> network
> comes up.
>
> So keepalived has no way of knowing there is a topology change,  
> there is no
> link state detection because the virtual switches always show up.   
> Also
> keepalived does see LinuxB because HostB network is down.
>
> If there was another VRRP instance somewhere for LinuxA keepalived  
> to see,
> it could then kick off a Garp and pull the traffic to it.
>
> Can anyone tell me under what other conditions that keepalived will  
> send the
> Garp ?
>
> Is there a neat trick I am missing ?
>
> I have one last hack I can do.
>
> LinuxA and LinuxB talk to RouterA and RouterB
>
> I can include the routers in the VRRP group but with priorities  
> which are
> set so that LinuxA and LinuxB are always most likely to have the  
> VRRP IP.
> If both are down, the VRRP IP will move over to the routers which  
> will not
> be of much use to me, both the Linux's are down anyway so there is  
> not a lot
> going on.
>
> But when LinuxA comes back up, it will at least see VRRP on the  
> routers and
> kick back into life.
>
> So a convoluted problem and a convoluted solution.
>
> Is there anything better ?
>
> Thanks
>
> John
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Keepalived-devel mailing list
> Keepalived-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/keepalived-devel
>
> -- 
> This message has been scanned for viruses and
> dangerous content, and is believed to be clean.
>


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Keepalived-devel mailing list
Keepalived-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/keepalived-devel
[prev in list] [next in list] [prev in thread] [next in thread]