Hi Patrick,
The problem is that any broadcast packets across the loop get amplified
pretty quickly and this propagates across the entire broadcast domain
(all related switches that have trunks containing affected vlans for
transit).
of course, I always forget the 3rd party broadcasts when talking about
loops.
For the procurve I think they call the feature "flow control"
so ...
conf t
fault-finder broadcast-storm
interface x flow-control
I'm not sure if flow-control helps here. For my understanding, it only
sends out pause frames and helps to make sure that one server does not
fully utilize the uplink - but probably only if the other side has
flow-control enabled as well.
Should do it. Ideally I'd turn that on all ports. Note that these are
the defaults (or at least should be). The only other way to reduce the
effects of this is to reduce your broadcast domain (read: ports affected
by amplified looping broadcasts) by routing (rather than switching)
closer to the customer.
Yes, that's unfortunately almost impossible in this case because
customer needs to use most of his vlans in multiple rooms in the
datacenter. Maybe we give the customer an own routerport and split him
from the general L2 infrastructure..
Best,
Jeff
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
