Hi. Is anyone using conntrack-tools to implement gateway failover on a network with windows clients? I set it up with ucarp and keepalived, and found that gratuitous ARP doesn''t always seem to update the cache on Windows machines. It works the first time, but if a second failover happens, the client continues to send stuff to the wrong MAC address. Linux machines work fine. I''ve noticed similar reports from other people, but nothing that seemed like a solution. Has anyone experimented with doing MAC address takeover too? That seems like it ought to work, but I haven''t tried it out because neither ucarp nor keepalived seem to implement it; and I wondered if I was missing something. What do other people do? -- ams
On 10/10/07 05:35, Abhijit Menon-Sen wrote:> Is anyone using conntrack-tools to implement gateway failover on a > network with windows clients?No, not as of yet. Sorry.> I set it up with ucarp and keepalived, and found that gratuitous ARP > doesn''t always seem to update the cache on Windows machines. It works > the first time, but if a second failover happens, the client > continues to send stuff to the wrong MAC address. Linux machines work > fine.Um, why are you not using the same MAC address for the gateway and having the systems decide who is actively using the MAC at any given time?> I''ve noticed similar reports from other people, but nothing that > seemed like a solution.*nod*> Has anyone experimented with doing MAC address takeover too? That > seems like it ought to work, but I haven''t tried it out because > neither ucarp nor keepalived seem to implement it; and I wondered if > I was missing something. What do other people do?Virtual Router Redundancy Protocol (VRRP) comes to mind. There is a very simple VRRP daemon (vrrpd) for Linux / Unix that will achieve this. To my knowledge it works by creating a new MAC address that is used for the VRRP router. The VRRP router is a virtual router that is traded back and forth between two or more possible real routers. Technically VRRP creates a new virtual MAC address 00:00:5E:00:01:XX that the IP is associated with. The "XX" is the virtual redundant router ID, usually 1 unless you have multiple virtual redundant routers in your network. The active virtual router will claim the 00:00:5E:00:01:XX MAC address and send out GARPs to update switch / bridge tables for the new location of the same MAC address. The two or more VRRP routers will heart beat each other (I think by multicast (?)) and if the active does not heartbeat with in a timeout the next router in the chain takes over, GARPs to updates switch / bridge tables and clients continue using the same MAC address. I''ve set up VRRP on a couple of test systems just long enough to say "Yep, that works." but did not do any thing further. I used vrrpd which was ridiculesly easy to set up. Be aware that VRRP is only meant for routers and not for hosts that have things bound to the virtual interface / IP, you want some sort of load balancing / failover scenario in that case. Grant. . . .
(Sorry for the delayed response. I''ve been on vacation. I''m quoting extensively to provide context.) At 2007-10-10 09:55:57 -0500, gtaylor@riverviewtech.net wrote:> > > Is anyone using conntrack-tools to implement gateway failover on a > > network with windows clients? [...]To recap: I have two gateway machines that share two virtual addresses (one on eth0, connected to the internal network and the other on eth1, connected to the outside world).> Um, why are you not using the same MAC address for the gateway and > having the systems decide who is actively using the MAC at any given > time?Mostly because neither ucarp nor keepalived seem to support changing the MAC address... and besides, everything I read seems to suggest that just gratuitous ARP should be sufficient.> There is a very simple VRRP daemon (vrrpd) for Linux / Unix that will > achieve this. To my knowledge it works by creating a new MAC address > that is used for the VRRP router.I did not realise that vrrpd supports it. My problem with ucarp (which, like vrrpd, also uses a single daemon per interface/shared IP) is that the pair of daemons on eth0 were not always perfectly synchronised with the pair on eth1. As a result, failover time was unpredictable. That''s why I switched to keepalived, so as to manage both interfaces with a single process. But I''ll try vrrpd anyway, thanks.> The two or more VRRP routers will heart beat each other (I think by > multicast (?))Yes, through multicast; and if the primary goes down, the remaining nodes elect a new primary. I''ll try it and report. -- ams
At 2007-10-23 11:38:00 +0530, ams@toroid.org wrote:> > But I''ll try vrrpd anyway, thanks.Ah, no. vrrpd is a non-starter, because it provides no notification when a machine switches between primary and secondary mode. Unfortunately, I can''t use any of the three failover programs I''ve tried so far. 1. keepalived - Provides notifications. - Uses a single process for multiple interfaces, so no synchronisation problems. - Doesn''t support MAC address takeover. 2. vrrpd - Supports MAC address takeover. - Uses one process per interface, but supports synchronisation through signalling the other process when state the changes. - Doesn''t provide notifications (although Jerome Etienne''s OLS presentation suggests that he meant to implement this). - Not very nice code; authentication partly implemented, but with bugs and without sufficient testing. 3. ucarp - Provides notifications. - Reasonably nice code. - Uses one process per interface, and provides no synchronisation support at all. - Does not support MAC address takeover. I''m going to modify ucarp to change the MAC address with the state, and to switch state on signal, so that two processes can be synchronised. This is a lot more painful than I thought it would be. -- ams