On Thu, May 20, 2010 at 08:17:48PM +0200, Henning Brauer wrote:
quoted text
> > 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.
> 
> i would never ever run any L3 on switches.
 
Bad wording on my part, the routers run OSPF and the switches are dumb
L2 devices.

Still, without OSPF et al there would be no way to detect a crappy
switch failing in funny ways, which was my point.

As an extra note, if you do get a crappy switch, be very careful with
its management interface. The cheapest ones have unbelievably slow CPUs
that are easily overloaded by broadcasts making the whole thing stop
responding. Even worse, the interrupt load seems to trigger some other
bugs, like LACP mysteriously failing and disabling one port on a trunk
and blackholing half of your traffic (this happened on a ZyXEL GS-4024,
which has otherwise totally Just Worked as a L2 switch for years) or
even the whole switch ASIC "crashing" after a broadcast storm and
requiring a reboot (though the management CPU was still responding
through the out of band ether and serial port after the storm was gone)

Also, it's a very obvious DoS; a malicious person needs to send a rather
small amount of BPDUs to overload the tiny CPU and the cheap switches
obviously have no rate limiting for packets going to the CPU (only on
all broadcasts). So, blocking BPDUs from non-trusted devices should be
enabled (but that should probably be done anyway.)

Even among "trusted" devices STP and LACP involve the shitty code
running on the underpowered management CPU, and that is not the part
that shines in the cheap switches. Static link aggregation works OK.