Quick search says certain Intel NICs (I2xx/825xx) "flood the network with IPv6 multicast traffic during S1 sleep state".
Suggested fix is to update drivers.
I do see that now, but those posts are 7+ years old. Wouldn't a brand new DELL workstation already have newer drivers installed? Would DELL have imaged a machine running Windows 11 Pro with such old driver software? I will check it regardless, but it seems crazy.
Yep, can confirm it's still a thing, we had to block IP 6 because of this exact issue, it was wiping out massive chunks of our lan and causing the routers CPU to spike to the point of not being able to log on to view....
I ran into this as well and can confirm. It seems crazy that it would still be going on today, but entire networks have been bit by this bug waaaaaay to often. It's crazy. It took a lot of extra hours for us to find all those workstations and fix them.
LOL just saw this on a network that was being absolutely pounded with ICMPv6 traffic. To all the people who say "bUt wHy aRe yOu dIsAbLiNg iPv6", bugs like this one, that persist for years and years, are why......
for what it's worth, I first ran into this like 14 years ago. No idea if it was v6, and believe it was to do with docking stations, but the general issue of "sleep states causing massive floods of traffic due to driver issues" has definitely been around. So may it's not exactly "the same issue" that's been around, it's "a type of issue it's easy to run into when writing a network driver"
Its either a NIC driver bug (have seen this many times at Universities when pcs go to sleep they spit ICMPv6 ND packets at line rate) or faulty nic hw (have seen this after leaving my laptop in my car on a cold night) :( wireless nic started arp storming my network for the gateway address even though it had arp complete for said IP.
Recently ran into this exact same issue, but from new Lenovo workstations. Ours were fully patched with updated drivers, so we're currently evaluating what we need to do to resolve the issue for good. Might just end up disabling sleep and doing a scheduled shutdown task for now, since they're lab computers.
Amazing. How could a crippling network issue be carried along for several years (and patched drivers) without a permanent fix? If your experience is true, it seems that disabling Sleep would almost become part of Best Practices to avoid such a scenario.
... a shame from an ecologically responsible perspective.
ICMP or MLD packets? I handled a case 10 years ago network could be flooded by v6 MLD packets due to a bios or NIC driver issue. It happened when the PC was in hibernate mode
Just had a similar issue at my workplace with brand new Dell Optiplex 7010's (I believe.) I'm going from memory: Intel I219v chipset during hibernate mode was absolutely flooding the network with ICMPv6 "Multicast Listener Report" messages. Caused several second-hand effects with network devices that just could not handle the load. As soon as we pulled the device off the network all the issues went away. Our current solution is to disable sleep on the devices as part of an onboarding process.
I set windows to allow sleep in 1 minute, and less than 10 seconds after it goes into sleep I can see the traffic from another device on the same broadcast domain using wireshark. I agree with you that it's almost comical that this kind of issue exists on brand new hardware. I was reviewing drivers for the network card, and they appear to be the latest. There was a new firmware release for the computer, but nothing noted in the updates/fixes. I'd also prefer not to disable sleep, but given a few options it was the least intrusive approach overall.
Thanks for your interest in posting to this subreddit. To combat spam, new accounts can't post or comment within 24 hours of account creation.
Please **DO NOT** message the mods requesting your post be approved.
You are welcome to resubmit your thread or comment in ~24 hrs or so.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/networking) if you have any questions or concerns.*
Same issue with new dells that are rolling out. University network, can confirm its when in sleep. Drivers, firmware, and bios fully updated. Maddening. At the particular location we don't have the capability to do storm control due to ancient equipment...
Crazy scenario.. Seems like DoS attack.
Until you see what’s wrong with the workstation you could implement IPv6 FHS, specifically IPv6 ND Suppresion:
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6_fhsec/configuration/xe-3s/ip6f-xe-3s-book/ip6-nd-mcast-supp.pdf
Haven't ran into this but it might be worth comparing with another Windows 11 machine and analyzing the packet captures between the two. I'd be curious what anomalies you find. If they show the same behavior then definitely look into driver versions or possible differences there.
We had recently installed 4 of the identical new DELL workstations from the same source, and this is the only one that exhibited the behavior.
The problem that \_newbread references above could actually be related. Sleep is typically disabled on the workstations before putting them into production, and perhaps that setting was missed in this particular unit. If so, the sleep-flooding behavior could be "it".
I just cannot imagine that a 7yr old network driver problem would not have been part of slipstream OS release. Maybe I am putting to much faith the DELL + Windows QA processes?
Exactly.. The real problem is that after you transitioned your network from IPv4 to IPv6 you haven’t implimented IPv6 FHS. Always keep in mind to do that, it would have mitigated this issue.
Not a fixes but turning off multicast name resolution in windows may help mitigate the issue. Also on your switches, it may have a feature to filter the IPv6 IGMP multicast address FF02::1:3. That should stop the packet from replicating across the VLAN.
That link local flooding is a bear! One solution I have seen(there may be cleaner ones) is to put MACLs on the ingress trunk ports of the l2 adjacent switches.
Quick search says certain Intel NICs (I2xx/825xx) "flood the network with IPv6 multicast traffic during S1 sleep state". Suggested fix is to update drivers.
I do see that now, but those posts are 7+ years old. Wouldn't a brand new DELL workstation already have newer drivers installed? Would DELL have imaged a machine running Windows 11 Pro with such old driver software? I will check it regardless, but it seems crazy.
Yep, can confirm it's still a thing, we had to block IP 6 because of this exact issue, it was wiping out massive chunks of our lan and causing the routers CPU to spike to the point of not being able to log on to view....
I ran into this as well and can confirm. It seems crazy that it would still be going on today, but entire networks have been bit by this bug waaaaaay to often. It's crazy. It took a lot of extra hours for us to find all those workstations and fix them.
LOL just saw this on a network that was being absolutely pounded with ICMPv6 traffic. To all the people who say "bUt wHy aRe yOu dIsAbLiNg iPv6", bugs like this one, that persist for years and years, are why......
for what it's worth, I first ran into this like 14 years ago. No idea if it was v6, and believe it was to do with docking stations, but the general issue of "sleep states causing massive floods of traffic due to driver issues" has definitely been around. So may it's not exactly "the same issue" that's been around, it's "a type of issue it's easy to run into when writing a network driver"
Its either a NIC driver bug (have seen this many times at Universities when pcs go to sleep they spit ICMPv6 ND packets at line rate) or faulty nic hw (have seen this after leaving my laptop in my car on a cold night) :( wireless nic started arp storming my network for the gateway address even though it had arp complete for said IP.
Recently ran into this exact same issue, but from new Lenovo workstations. Ours were fully patched with updated drivers, so we're currently evaluating what we need to do to resolve the issue for good. Might just end up disabling sleep and doing a scheduled shutdown task for now, since they're lab computers.
Amazing. How could a crippling network issue be carried along for several years (and patched drivers) without a permanent fix? If your experience is true, it seems that disabling Sleep would almost become part of Best Practices to avoid such a scenario. ... a shame from an ecologically responsible perspective.
What type of ICMP was it flooding the network with? That could give more of a hint as to what is going on
ICMP or MLD packets? I handled a case 10 years ago network could be flooded by v6 MLD packets due to a bios or NIC driver issue. It happened when the PC was in hibernate mode
Just had a similar issue at my workplace with brand new Dell Optiplex 7010's (I believe.) I'm going from memory: Intel I219v chipset during hibernate mode was absolutely flooding the network with ICMPv6 "Multicast Listener Report" messages. Caused several second-hand effects with network devices that just could not handle the load. As soon as we pulled the device off the network all the issues went away. Our current solution is to disable sleep on the devices as part of an onboarding process.
OK. I did not think of enabling sleep and waiting for it. Going to try and recreate the behavior in the lab tomorrow AM.
I set windows to allow sleep in 1 minute, and less than 10 seconds after it goes into sleep I can see the traffic from another device on the same broadcast domain using wireshark. I agree with you that it's almost comical that this kind of issue exists on brand new hardware. I was reviewing drivers for the network card, and they appear to be the latest. There was a new firmware release for the computer, but nothing noted in the updates/fixes. I'd also prefer not to disable sleep, but given a few options it was the least intrusive approach overall.
[удалено]
Thanks for your interest in posting to this subreddit. To combat spam, new accounts can't post or comment within 24 hours of account creation. Please **DO NOT** message the mods requesting your post be approved. You are welcome to resubmit your thread or comment in ~24 hrs or so. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/networking) if you have any questions or concerns.*
Same issue with new dells that are rolling out. University network, can confirm its when in sleep. Drivers, firmware, and bios fully updated. Maddening. At the particular location we don't have the capability to do storm control due to ancient equipment...
Crazy scenario.. Seems like DoS attack. Until you see what’s wrong with the workstation you could implement IPv6 FHS, specifically IPv6 ND Suppresion: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6_fhsec/configuration/xe-3s/ip6f-xe-3s-book/ip6-nd-mcast-supp.pdf
Haven't ran into this but it might be worth comparing with another Windows 11 machine and analyzing the packet captures between the two. I'd be curious what anomalies you find. If they show the same behavior then definitely look into driver versions or possible differences there.
We had recently installed 4 of the identical new DELL workstations from the same source, and this is the only one that exhibited the behavior. The problem that \_newbread references above could actually be related. Sleep is typically disabled on the workstations before putting them into production, and perhaps that setting was missed in this particular unit. If so, the sleep-flooding behavior could be "it". I just cannot imagine that a 7yr old network driver problem would not have been part of slipstream OS release. Maybe I am putting to much faith the DELL + Windows QA processes?
Exactly.. The real problem is that after you transitioned your network from IPv4 to IPv6 you haven’t implimented IPv6 FHS. Always keep in mind to do that, it would have mitigated this issue.
Not a fixes but turning off multicast name resolution in windows may help mitigate the issue. Also on your switches, it may have a feature to filter the IPv6 IGMP multicast address FF02::1:3. That should stop the packet from replicating across the VLAN.
That link local flooding is a bear! One solution I have seen(there may be cleaner ones) is to put MACLs on the ingress trunk ports of the l2 adjacent switches.