* Matthew Dempsky <[EMAIL PROTECTED]> [2008-04-11 02:37]: > On Thu, Apr 10, 2008 at 2:33 PM, Stuart Henderson <[EMAIL PROTECTED]> wrote: > > Problem is, a carp interface is not interested in the state of the > > syncdev, it is interested in the state of its own carpdev (since > > multiple carp interfaces on a machine are independent). And carpdev > > usually faces a switch, so it stays up. > > I didn't mean it would monitor the state of its own carpdev, but that > you'd be able to set an extra watchdev (or whatever) that it would > watch.
for what? aside from the fact that carp failover IS blazingly fast already (i do switchovers during business hours sometimes, and nobody ever noticed anything), let's look at the typical fwA + fwB secanrio, 3 interfaces: ext, int, and syndev. now the carps on ext and int have "watchdev" syncdev. case A: fwA is master, fwB is slave, fwA fails, syncdev going down tells the carp interface which are backup to become master? hoe about case B: fwA is master, fwB is slave, I visit you and cut the syndev cable, because I like fun. fwB's slave carp interfaces notice the "watchdev" going down and go to master. great, now we have two masters. as I have had such a split brain config in the fast (due to a switch misconfiguration) I can tell you - that is not fun. really. But, you'll say, after a short while fwB will switch to BACKUP again, since it sees fwAs announcements. Yeah, right. But now the switch is confuzzled on which port the carp mac address actually sits and will, with a >75% chance, CONTINUE to send traffic to fwB, since that's where it learned the mac address last. carp interfaces send out gratious arp when they become master. There is no "i don't have this mac anymore" type message. Doesn't exist. You lose. now to the more interesting cases... case C: fwA carp: ext1: master, int1: master, ext2: slave, int2: slave fwB carp: ext1: slave, int1: slave, ext2: master, int2: master now teh syncdev goes dowm. oooommmgggg.... it gets more complicated :) So, what do you gain? -marginal faster failover, maybe. I have my doubts you actually gain much. Just one point, the time the switch needs to "move" the mac entry to the other port is greater than 0 too. Downsides: -more code, potentially more bugs -more complex, more bugs -really really really bad behaviour when the sync connection is cut -weird behaviour with multiple carp groups (and probably more if I spend more time thinking about it) not worth it. q. e. d. :) -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
