On Thu, May 20, 2010 at 11:31:22PM +0300, Jussi Peltola wrote: > I do this too. In addition to the previously mentioned problems with > cheap switches losing their configs (and vlans) you should make sure the > active interfaces are all on one switch so that the link between them > isn't uselessly used; this will also avoid an unpleasant split brain > event if that link ever happens to fail. But in this case you will also > have to very carefully check the other switch stays properly configured so > the backup interfaces will actually pass the traffic you want. >
don't mix up cheap switches with crap switches. actually, some very expensive switches are really crappy indeed. but i don't see your "problems", you just have to take care a little bit and don't try to run your highly redundant high-performance firewall cluster with a bunch of SOHO linksys switches (oh wait, they're cisco now). but there is no real problem, trunk failover with carp + pfsync and redundant switches works very well and i have installed it in many different highly available production sites. it is hard to make it not work unless you configure your switches wrong - eg. by cascading the redundant switches to other uplink switches and creating some weird loops. > Linux's bonding module has an arp monitor which solves some of these > problems, but the implementation is so hackish (as usual there...) that > I'd rather not use it in production. arping and ifstated might do the > same on openbsd, but I'm not sure if that will work when the interfaces > are trunk ports. I'll need to check this when I have time. > why not? trunk is just a "normal" ethernet interface. the linux bondage trick sounds hackish, but link detection protocols like udld or bfd should help here on the ethernet level. many managed switches support one of these protocols and i'd like to do this on the openbsd side at some point to alter the link state based on optional uni-/bidirectional link detection. reyk
