Looking for feedback/recommendations on higher density Switch’s in the 10GBASE-T arena.
Preferably TOR switches if possible.
Minimum 16 ports usable for Rack Server connectivity + Uplinks to Collapsed Twin Distro/Core setup.
Found the Arista 7X00 family to have the density I am looking for but others of similar spec would be appreciated.
Any Thoughts and/or suggestions would be greatly appreciated.
Dell sell (I doubt they make it) their '8024' 24-port 10GBASE-T switch.
I've not used one myself, and it's probably not pretty, but it fits your
description.
Tom
Juniper EX4500 has 40 fixed SFP/SFP+ ports plus 2 uplink modules that
can contain 4 SFP/SFP+ ports each for a total of 48 10GBASE-X ports.
Need to buy SFP+ modules or use direct-attach SFP+ cables though.
Juniper EX4500 has 40 fixed SFP/SFP+ ports plus 2 uplink modules that
can contain 4 SFP/SFP+ ports each for a total of 48 10GBASE-X ports.
Need to buy SFP+ modules or use direct-attach SFP+ cables though.
And is now shipping with a model that can stack and/or join a EX4200 VC stack.
It's either EX4500-40F-VC1-BF or EX4500-40F-VC1-FB depending on whether you
want Front-to-Back or Back-to-Front airflow.
-b
Be aware, that IGMP snooping breaks some(!) IPv6 multicast (e.g.
DHCPv6). Affects whole EX-series and current plan is to fix it sometime
end of year (Q4 release). If you use IPv4 multicast and need IGMP
snooping to prevent flooding and plan to use e.g. stateful DHCPv6, that
might be a showstopper for now and the VLANs where IGMP snooping is
enabled.
Best regards,
Daniel
I should add that we're quite happy with the EX4500 on the features it
has (want QinQ yesterday, prettypretty please). No datacenter usage though.
Best regards,
Daniel
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? If so, IGMP snooping and MLD
snooping should be able to coexist, I'd have thought. In fact, it will
be a major blow for the future of dual-stacking if they can't.
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?
Regards, K.
Hi,
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 somethingAlso. 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