SixXS::Sunset 2017-06-06

Multicast flood "listener reportmax resp delay"
[ca] Shadow Hawkins on Wednesday, 14 May 2014 19:18:50
On our non-v6-enabled network (no official routers), I'm seeing floods of IP6 multicast traffic from two machines, e.g. IP6 fe80::223:24ff:fe65:4302 > ff02::2: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::fb, length 24 IP6 fe80::223:24ff:fe63:1ecf > ff02::2: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::fb, length 24 IP6 fe80::223:24ff:fe63:1ecf > ff02::1:ff55:2a53: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::1:ff55:2 a53, length 24 IP6 fe80::223:24ff:fe65:4302 > ff02::1:ff55:2a53: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::1:ff55:2 a53, length 24 The packets do not come all the time, but hundreds a second for hours then stop for a bit, then start again. Has anyone else seen this ? Are the two machines somehow triggering each other ? Is it likely a glitch that will go away if the machines are rebooted, or is it a configuration problem ?
Multicast flood "listener reportmax resp delay"
[ca] Shadow Hawkins on Wednesday, 14 May 2014 22:58:03
Andrew Daviel wrote:
Has anyone else seen this ?
I just found this Intel page and this technet page Apparently a bug in the Intel I217-V Windows driver
Multicast flood "listener reportmax resp delay"
[it] Shadow Hawkins on Thursday, 15 May 2014 08:40:22
Andrew Daviel wrote:
Andrew Daviel wrote:
Has anyone else seen this ?
I just found this Intel page and this technet page Apparently a bug in the Intel I217-V Windows driver
The same here on our LAN: it was driving me mad! I added a firewall rule to drop it on the LAN interface since it was going to generate several MB/sec of unuseful traffic. Thank you very much for the above information.
Multicast flood "listener reportmax resp delay"
[ch] Jeroen Massar SixXS Staff on Thursday, 15 May 2014 09:25:24
fe80::223:24ff:fe65:4302
OUI is: G-PRO COMPUTER Thus those are actually rebadged Intel cards? :) At least one advantage: you know which computers are sending the packets.
Multicast flood "listener reportmax resp delay"
[ca] Shadow Hawkins on Wednesday, 21 May 2014 23:26:14
We have updated affected machines to the Intel driver version 12.11.96 (from Intel's site), which appears to have stopped the floods. But I still don't understand how a bad driver could cause an application-layer flood. Unless maybe it was re-sending one packet over and over, and not flushing it from a queue. But then, it seemed to require two or more vulnerable machines entering sleep mode to trigger a flood.

Please note Posting is only allowed when you are logged in.

Static Sunset Edition of SixXS
©2001-2017 SixXS - IPv6 Deployment & Tunnel Broker