[j-nsp] Network, trouble after customer created a loop *inside* a VM host
Patrick Okui
pokui at psg.com
Sat Nov 8 17:59:34 EST 2014
On 8-Nov-2014 14:56:27 (+0200), Jeff Meyers wrote:
> alright, but why would the ProCurve and everything above care? Isn't the
> loop only inside the Windows Host since from the perspective of the
> ProCurve, packets come in the same interface where they were sent out?
> Furthermore, what is required for the router to see this "mac move"
> thing? Since there is only one physical port (ae0) towards the L2
> infrastructure, this can only be macs moving between Vlans, right?
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).
Since the storm goes through the same ports and silicon as the other
vlans they are affected as resources to forward all packets are quickly
used up.
> It's currently set to 85% on the EX4200, the ProCurve doesn't even
> support that feature. I guess this will require a value much smaller in
> the 10% region?
For the procurve I think they call the feature "flow control"
so ...
conf t
fault-finder broadcast-storm
interface x flow-control
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.
--
patrick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 244 bytes
Desc: OpenPGP digital signature
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20141109/a62114c4/attachment.sig>
More information about the juniper-nsp
mailing list