> From: "Patrick Okui" <[email protected]>
> 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: [email protected]
alt.advanced.networks.design.configure.operate
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
