Mailing List Archive

multi vif with 4 GBEs
has anyone ever configured one multi vif across 4 GBE interfaces? Is there anything to watch out for? I read rumors (can't find the source anymore) that the hashing algorithm to do the load sharing might badly impact performance.

Somehow I have not been able to find anyone that ever had a need for more in 2 GBEs in one multi vif, but the one exception of having one single vif across two switches and having on each switch a multi vif with 2 GBE interface ... clear as mud, right?

thanks - Moritz

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
Re: multi vif with 4 GBEs [ In reply to ]
Moritz.Willers@ubsw.com wrote:
> has anyone ever configured one multi vif across 4 GBE interfaces? Is there anything
> to watch out for? I read rumors (can't find the source anymore) that the hashing
> algorithm to do the load sharing might badly impact performance.
>
> Somehow I have not been able to find anyone that ever had a need for more in 2 GBEs
> in one multi vif, but the one exception of having one single vif across two switches
> and having on each switch a multi vif with 2 GBE interface ... clear as mud, right?

I've got two 960s, each with 4 GBE's in a multi-vif. using IP load balancing,
all four interfaces can get plenty busy. 4 GBE interfaces ane needed on a 960,
btw, because they can sustain 250 - 350 Mbyte/sec of read, at least with my workload.

for splitting the vifs acriss switches, I think you need to make two 2-GBE vifs,
and then a third vif that contains the other two. netapp calls these "second-layer"
vifs.

-skottie


--

Scott Miller | Animation Technology
work: skottie@dreamworks.com | Dreamworks Feature Animation
life: skottie@pobox.com
RE: multi vif with 4 GBEs [ In reply to ]
thanks a lot. Looks like it isn't used too often with GBEs so far bad gets more popular with the FAS900 series as they actually want that much data or otherwise they get bored :)

and just to correct some wrong impression that I might have spread, I heard about the switch's performance being badly impacted by having to do the hashing algorithm, never heard anything bad about the filer. And then it was only with some switch manufacturers, iirc it said Cisco switches scale nicely. If only I could find that URL again.

- Moritz


-----Original Message-----
From: Skottie Miller [mailto:skottie@anim.dreamworks.com]
Sent: Friday, November 15, 2002 7:53 PM
To: Willers, Moritz
Cc: toasters@mathworks.com
Subject: Re: multi vif with 4 GBEs


Moritz.Willers@ubsw.com wrote:
> has anyone ever configured one multi vif across 4 GBE interfaces? Is there anything
> to watch out for? I read rumors (can't find the source anymore) that the hashing
> algorithm to do the load sharing might badly impact performance.
>
> Somehow I have not been able to find anyone that ever had a need for more in 2 GBEs
> in one multi vif, but the one exception of having one single vif across two switches
> and having on each switch a multi vif with 2 GBE interface ... clear as mud, right?

I've got two 960s, each with 4 GBE's in a multi-vif. using IP load balancing,
all four interfaces can get plenty busy. 4 GBE interfaces ane needed on a 960,
btw, because they can sustain 250 - 350 Mbyte/sec of read, at least with my workload.

for splitting the vifs acriss switches, I think you need to make two 2-GBE vifs,
and then a third vif that contains the other two. netapp calls these "second-layer"
vifs.

-skottie


--

Scott Miller | Animation Technology
work: skottie@dreamworks.com | Dreamworks Feature Animation
life: skottie@pobox.com


Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
RE: multi vif with 4 GBEs [ In reply to ]
just to follow up for anyone interested, I found the link:

http://www.nwfusion.com/reviews/2001/0416rev2.html

fortunately we are using a Cisco 6509 in our setup, so the trunking of four links should not be a problem at all.

thanks for all your answers! - Moritz

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.