On Thu, May 20, 2010 at 07:28:55PM +0200, Henning Brauer wrote:
How about the warnings about packet reordering and interactions with
TCP? I'd guess it's not really such a big issue if you have two
identical switches and routers. But shouldn't the hash based trunk modes
work just fine, too (with the caveat that some flows will stop working
completely if the other switch fails in some ways while roundrobin will
cause half of the packets to be blackholed, keeping badly degraded
connectivity)
Also, the switches need to be separate; connecting them directly may
cause learned MACs to flap between the real host port and the cable
between the switches and make the trunk receive its own traffic on the
other port.
Fail-over trunk should work just fine, too. But see the following
paragraphs...
If you want reliability, do not use cheap switches. Switch power
supplies are not the failure mode you want to avoid. I don't remember
seeing very many at all, however I've seen lots of crappy ones lose
their config or stop forwarding completely while keeping the link up.
I have two identical "core" switches in one (not really so critical at
all) place running OSPF, with a bunch of routers connecting to both
switches for redundancy. Works pretty well and there has even been a
config reset incident, which didn't break anything - because OSPF can
detect link failures. Trying to do the same all the way to the end hosts
(i.e. without a routing protocol) is pretty difficult.
One pseudo solution is to run a bridge instead of trunk on the 2
interfaces and use STP for fail-over; I find that too yucky to solve a
problem that doesn't really exist (just buy a reliable switch with a
redundant power supply or connect the single one to a good UPS)
However, if you need to ask if you can run a trunk on top of a carp, do
yourself a favor and use a single switch. There will be less downtime.
Jussi Peltola