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: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0