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

[Derek_Brown]

The issue is not a BROADCAST store. IPv6 does not use Broadcast, only multicast. Since we are not using IPv6 on the network yet I can't be of any more help than to eliminate what the vendor said so you aren't going down a wasted path. The first thing I ALWAY do when there is a problem like this is mirror the port and capture the data with Sniffer or Wireshark. Only then can you see what the traffic is and what it is really doing.

[EtherMAN]

wonder if this is related to mcast listening floods we had back in 2014 when intel had bad drivers and if IPV6 were enabled and the nic card went to sleep.... ??

[Patrick_Voss]

Hi Rod,

I took a second look at you post and misunderstood your question. High CPU will only appear if there is a lot learning going on. This traffic is automatically sent to the CPU for processing. If the traffic is being switched normally then you wouldn't see an issue unless the port is being over utilized. Without knowing what kind of traffic this is it would be very difficult to understand why this is only affecting the printers. Maybe you can mirror one of the printer ports and do a packet capture.

[Mike_D]

Hello Rod,

fwiw, I agree with your doubt about the diagnosis. Also agree with your reasoning - a traffic flood problem would leave tracks you would be able to follow.

On the flip side - no help understanding what's really going on.

Regards,

Mike

[Patrick_Voss]

Hi Rod,

How high is BCMRX getting in the "top" output? Is the issue still happening or is there a workaround to resolve it? If the issue is resolvable how long before it comes back?

There is a way to look at the packets hitting the CPU but this requires a case with GTAC and debug-mode to be enabled. Pending valid entitlement on the switch this may be the best route moving forward.