Hi, On Fri, Feb 11, 2011 at 06:52:07AM +1100, Karl Auer wrote: > Not disagreeing, I've never met this device, just curious about the > problem and wondering if it is a generic class of problem. > > Is this device supposed to be IPv6-capable?
We're using EX switches currently only in L2-only roles, cannot comment on L3. > If so, IGMP snooping and MLD snooping should be able to coexist, I'd > have thought. MLD snooping wasn't enabled (EX4500 doesn't even support it yet) so that's no factor. Expected behaviour would be to flood any IPv6 multicast frames to all ports in a VLAN. We've found the bug on EX3200-24T btw. but JTAC confirms it affects all EX series. > So is the problem of which you speak just a bug, or is it an artifact of > the switch not being IPv6 capable and so limiting broadcasts at the > ethernet level to IGMP-discovered listeners only, ignoring IPv6 > multicast listeners? Or something :-) > > Also. why does it only affect DHCPv6? Or was that just an example of a > service that would be affected by the problem? Example of a frame (DHCPv6 SOLICIT) which is not being passed with IGMP snooping enabled: 00:1a:64:99:0f:5c > 33:33:00:01:00:02, ethertype 802.1Q (0x8100), length 118: vlan 633, p 0, ethertype IPv6, (hlim 1, next-header UDP (17) payload length: 60) fe80::21a:64ff:fe99:f5c.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=be0a2d (client-ID hwaddr/time type 1 time 345579243 001a64990f5c) (option-request DNS DNS-name) (elapsed-time 725) (IA_NA IAID:1687752540 T1:3600 T2:5400)) L3/L2 destination address is all-dhcpv6-agents. IPv6 RA (destination "all nodes") are being passed just fine, e.g.: 20:24:35.480395 00:26:cb:d5:8b:d9 > 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 86: (class 0xe0, hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::226:cbff:fed5:8bd9 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 32 My guess is that L2 filters aren't being properly handled by the IGMP snooping feature - not permitting 33:33:*, but e.g. only 33:33:00:00:00:* or so. We didn't poke around to find out exactly which multicast destination MACs do work and which don't. What surprises me, that this hasn't come up in "enterprise LAN" type of testing IGMP+MLDv2 snooping I'd consider a "must" there, and DHCPv6 a basic requirement in enterprise IPv6 deployments. PR/456700 Looks like that bug will see its second birthday in summer. Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0