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. ________________________________ This email and any attached files may contain confidential and/or privileged material and is intended solely for the use of the person to whom it is addressed. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender immediately and delete it and all attachments from your computer. Progressive Solutions is not liable for any errors or omissions in the content or transmission of this email.
On Thu, 2011-02-10 at 09:33 +0000, Roberts, Brent wrote:
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. http://dell.to/dJP1ka I've not used one myself, and it's probably not pretty, but it fits your description. Tom
On Thu, Feb 10, 2011 at 09:33:50AM +0000, Roberts, Brent wrote:
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.
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 -- Bill Blackford Network Engineer Logged into reality and abusing my sudo privileges.....
On Thu, Feb 10, 2011 at 10:05:54AM -0500, Chuck Anderson wrote:
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.
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 -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
On Thu, Feb 10, 2011 at 08:33:43PM +0100, Daniel Roesen wrote:
On Thu, Feb 10, 2011 at 10:05:54AM -0500, Chuck Anderson wrote:
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.
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.
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 -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
On Thu, 2011-02-10 at 20:33 +0100, Daniel Roesen wrote:
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.
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. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156
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
participants (6)
-
Bill Blackford -
Chuck Anderson -
Daniel Roesen -
Karl Auer -
Roberts, Brent -
Tom Hill