[149042] in North American Network Operators' Group
RE: 10G switchrecommendaton
daemon@ATHENA.MIT.EDU (George Bonser)
Fri Jan 27 14:49:18 2012
From: George Bonser <gbonser@seven.com>
To: Fabien Delmotte <fdelmotte1@mac.com>
Date: Fri, 27 Jan 2012 19:48:47 +0000
In-Reply-To: <8FC22B9F-D792-483E-AB3F-2BF9F1DC6304@mac.com>
Cc: nanog list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
> -----Original Message-----
> From: Fabien Delmotte=20
> Sent: Friday, January 27, 2012 2:20 AM
> To: Grant Ridder
> Cc: nanog list
> Subject: Re: 10G switchrecommendaton
>=20
> I worked for Extreme, and I deployed a lot of X650 (24 10G ports) for
> DataCenter environment. The box is really good.
> In fact if you use the box at a layer 2 it is perfect, BUT DON'T use
> their BGP code, they never understood what is BGP :)
>=20
> Regards
>=20
> Fabien
A place I worked around 2000-ish was an Extreme shop. My perception at the=
time was that they were probably the best switch in the world at layer 2. =
I used BGP on the 1i and 5i products. The problem we had with them was wh=
en I asked when they were going to support multiple path BGP (as in the max=
imum-paths command for Cisco / Brocade). They told me at the time that the=
y had no plans to support that option, it wasn't on the road map, and frank=
ly, BGP was not a priority for them as they were concentrating on layer2 me=
tro and data center features at the time.
That meeting resulted in a call to Foundry and the eventual purchase of sev=
eral BigIron switches. As the application was just plain IP routing, they =
worked great. I haven't used Extreme since so can't attest to their BGP fe=
ature set but my gut feeling seems to be the same ... great gear at layer 2=
but layer 3 seems to be a back burner priority for them. I would have no =
problem using their gear in an office or data center but would have to take=
a good long look at it for internet peering/transit.
Arista is really good gear and I use them for 10G aggregation from top of r=
ack switches in an application where pods of connectivity are scattered abo=
ut in various leased cages in a commercial data center. The TOR switches l=
ink to the Aristas in an MLAG configuration which might look like an "end o=
f row" configuration. Those uplink to the core in another bit of space in =
the data center to keep the number of cross-connects down. Performance has=
so far been perfect, not so much as a glitch from those units. I've also =
recently deployed them as TOR switches for a 10G cluster of machines and wo=
uld have chosen TurboIrons if they would stack or had MCT features. The be=
nefit of the TurboIron, if they will work for you, is the lifetime warranty=
. No annual support cost is a huge deal. Arista is also lagging in layer =
3 and ipv6 features, or were the last time I looked at them at layer 3. Th=
at might have changed recently. They had only recently come out with OSPF =
support on their chassis units.
One question I would have re: deep buffers. It wouldn't seem to me to make=
much difference if you are buffering on the TOR switch or buffering on the=
host. If flow control is giving you problems, maybe you just need more bu=
ffering on the host or maybe you should just let tcp back off a bit and mit=
igate the congestion using the protocol. More buffering can sometimes caus=
e more performance problems than it solves but depends on the application. =
If I have a lot of "fan in" such as several front end hosts taking to a fe=
w back end hosts, I generally try to ease that congestion by giving that ba=
ck end host considerably more BW. Such as GigE from the front end hosts an=
d 2x10G to the back end servers. For example, an Intel X520-T2 card with 2=
x10G RJ-45 ports to a pair of Aristas in an MLAG configuration works pretty=
well provided you use the latest Intel driver for the cards.
