[j-nsp] Network, trouble after customer created a loop *inside* a VM host

Michele Bergonzoni bergonz at labs.it
Sun Nov 9 05:04:27 EST 2014


> From: "Patrick Okui" <pokui at psg.com>
> The problem is that any broadcast packets across the loop get amplified
> pretty quickly and this propagates across the entire broadcast domain

Yes, that's probably what Jeff saw: his switches were not part of the loop, but were nonetheless in the same broadcast domain(s).

> > Jeff Meyers wrote:
> > 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 customer was so creative that the loop could indeed involve bridging across multiple VLANs. Another possibility is that the moving MAC was the one of the MX, the router of the VLANs (I suppose), routers do send broadcast sometimes, and when those broadcast enter the VM loop they get reflected back as any other broadcast.

I think you should really implement some form of control plane protection, which is something global to the device and so should be carefully planned and tested (you can end up dropping all OSPF hellos during a broadcast storm, which is not a great result), and also set a very low broadcast threshold for that particular ports. If you have a 1 Gbit/s port, 1% is still 10 Mbit/s of broadcast frames, which is quite a lot and probably still enough to hog your CPUs.

You should also investigate what your switches really limit: Broadcast? Non-unicast (broadcast + multicast)? Flooded frames (broadcast + multicast + unknown unicast)? All this gets reflected during a L2 loop.

Regards,
                       Bergonz

-- 
Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a.
Phone:+39-051-6781926 e-mail: bergonz at labs.it
alt.advanced.networks.design.configure.operate


More information about the juniper-nsp mailing list