* Matthew Dempsky  [2008-04-11 02:37]:

quoted text
> On Thu, Apr 10, 2008 at 2:33 PM, Stuart Henderson  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, hb@bsws.de, henning@openbsd.org

BS Web Services, http://bsws.de

Full-Service ISP - Secure Hosting, Mail and DNS Services

Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam