RE: IPV6 Multicast Listener storm control?

["Naslund, Steve" <SNaslund () medline com>]

We have seen the same issue with Lenovo devices.  They all seem to have a variety of Intel chipsets.  We have not found 
a good solution other than updating drivers and/or shutting down ipv6 which we really don’t want to do but it is easier 
to automate that than to automate the driver update.  I will be interested in seeing what anyone else has come up with 
to kill these off.  In our case, the biggest issue is wireless clients that show this behavior because they really bury 
the access points CPU.  The switched network seems to absorb the load better.

Steven Naslund
Chicago IL

> > > (originally posted to wispa ipv6 list, and someone there mentioned that folks here might have some suggestions, so 
> > > apologize if you are a member of
> > > both.)

> > > I am seeing issues with IPV6 multicast storms in my network that are fairly low volume (1-2mbit), but that are 
> > > causing service disruptions due to CPU load >>>on the switches and that the network is a Point to MultiPoint 
> > > wireless network.

> > > I have about 500 IPV4 clients on a vlan served by Cisco ME3400, Catalyst
> > > 3750 and 3560 switches.  These are switched back to a routed interface and IP addresses are assigned by DHCP.  We 
> > > are not using IPV6 at all, and I don't >>>have control of the clients.

> > > What I'm seeing is IPV6 Multicast Listener requests from a single client (different clients at different times) 
> > > going out on the network, the switches >>>manage them in software, so CPU goes up (not a lot, but it seems to impact 
> > > performance quite a bit), but the larger problem is that all other IPV6 clients >>>respond to the multicast 
> > > broadcast address generating a 1-2mbit storm of traffic to all ports all the time.  This then transits the bandwidth 
> > > constrained >>>wireless network in a steady state, causing high collisions which causes _significant_ performance 
> > > degradation in the wireless network.