[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
> 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
> 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
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
(option-request DNS DNS-name) (elapsed-time 725) (IA_NA IAID:1687752540
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.
Looks like that bug will see its second birthday in summer.
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0