IPV6 broadcast storm, on an IPV4 network

[Rod_Robertson2]

We have a number of printers that by default have IPV6 configured though not used. ( not supported by me )
These printers are also connected to an IPV4 vlan where the IP address is allocated via DHCP and routed at a distribution switch X460.

Recently we had a issue with only the printers on the network , other devices on the same network , were able to operate and use the dhcp service and access the internet.

Only these printers would not work , if we connected a laptop to the switch port or disconnected the printer and used that port , the laptop would operate as expected.

We are being informed by the printer manufacturer that the issue we are seeing is that the Printer is creating an IPV6 broadcast storm , which I could understand , though my question is :

Would this not present itself the same as an IPV4 broadcast storm , CPU BCMrx high , vlan unresponsive etc?

This might be a IPV6 multicast issue as well ..

I.E the IPV4 network would also be effected .. which it was not.

I look forward to any comments and or suggestions .

Regards

[Rod_Robertson2]

Hi

Thanks for the updates ..

We have a wireshark trace and have identified a number of "IPV6 top senders as previously suggested.

We are also going to control the IPv6 multicast by ACL.

As suggested in the posts , I think the Printer issues are only an " indicator" that there is an IPV6 multicast issue on the network, and we have seen no immediate effect on network performance.

Again thansk for all your comments and suggestions.,

[Stephen_Elliot1]

we've had exactly the same issue.

as mentioned above it's not a broadcast storm (often caused when there's a loop in the network) but a lot of spurious IPV6 multicast packets being sent from one or two machines with a particular NIC (intel i217's from memory).

I think the switches and other non-v6 devices can cope perfectly well with the amount of traffic being forwarded, but the printers themselves get overloaded and stop functioning correctly, perhaps because they are the only devices listening to IPv6 multicasts?

if an actual broadcast/multicast storm was happening then I believe the switches would also start to suffer.

[Jarek]

Hi, maybe you have arp storm or other traffic that is hitting the cpu? Wireshark is your friend as Derek suggested. You can also block ipv6 traffiic via vlan acl if you want. -- Jarek

[Patrick_Voss]

Hi Rod,

How are we confirming that they are indeed hitting the CPU? It seems very odd to me that only the printers that are producing the traffic are experiencing issues even though there are multiple VLANs traversing the same physical interfaces. I do not think there is enough information to provide an explanation for what is happening on this network.

[Rod_Robertson2]

Hi many thanks for your comments , the engineers on site did take a trace and found that this is as suggested an IPV6 Multicast Listener Report ( STORM) .. so it would seem that the following scenario exists.

As we can have multiple networks on a single "piece of wire " ( old school ) we have the standard IPV4 behaving as expected and we also have the IPV6 ( Printer Default configuration ) sharing the same physical wire , though on a separate network , because all the printers are on the IPV6 network as well as the IPV4 , when one of them starts this IPV6 Query the others response and this seems to start a cyclic process that is "self destruction".

It has been suggested on other forums that Storm control , and other edge configurations could help , the main one being disabling IPV6 on the printers.

So I seem to have a fix ,Though I still do not understand how the IPV6 packets , hitting the Switch CPU , would not register as high BCMrx and then be dropped or were theses IPV6 packets hitting another process , and therefore we missed this .

Any advise on how IPV6 hits the cpu and the process used would be appreciated ..

Many Thanks again