IPV6 Multicast Listener storm control?

Mon Sep 22 23:44:17 UTC 2014

(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.

It would appear that this is _generally_ caused by Dell or HP workstations
with buggy network interface cards in hibernate mode.

http://blog.bimajority.org/2014/09/05/the-network-nightmare-that-ate-my-week/

http://packetpushers.net/good-nics-bad-things-blast-ipv6-multicast-listener-discovery-queries/

Now it looks like from my reading that CISCO MLD snooping would _help_ with
this, though it would not stop the offender from generating the multicast
requests, it might keep if from reaching _all_ ports, but it would still
affect any ports that had _subscribed_ IPV6 clients, and it would require
changing the SDM template and a reload on all the switches.  So not a real
answer and very painful.

Right now, I'm just tracking the source down and shutting it off.  Do not
really want to get into an argument about switched vs routed, and am
working on reducing the size of the broadcast domain now, but this is a new
issue, and I need to come up with some kind of plan to resolve with my
current equipment/network.

Any thoughts?? Ideas?  I suspect this will become more of an issue for more
folks in the near future.

/thanks

-- 
Richard Holbo
Southern Oregon Network Support Services
richard.holbo at sonss.net - 541.890.8067
http://www.sonss.net