10GBASE-T Switches

Thu Feb 10 20:28:22 UTC 2011

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