Fast Etherchannel Q's

Fast Etherchannel Q's

Post by Jim Mac » Wed, 09 Jul 2003 07:59:12



Hi -
  We own one NAS box, and are evaluating another, that offer dual GigE
NICs operating as a 'bonded pair'.  These connect to an HP switch that
supports port trunking.  There is some confusion about just how this
bonding occurs, but one of the mfr's seems to think it's FEC.

  Each of these boxes (running RH Linux) creates a logical interface
named 'bond0', which has as its elements 'eth1' and 'eth2', the physical
NICs.  In each case the two NICs are assigned the same IP address.

  But in one of these boxes, the individual NICs also have the same MAC
address, where the other one has sequential MAC addresses for the two
NICs.

  So the question is, which is preferable, assuming that this is really
FEC?  Both mfr's claim that they just hook these up to a switch and
there are "no problems".  Well, wrong.  The box with the different MAC
addresses seems only to use one interface, while the other one idles.
The box with the identical MACs balances its load between the NICs, but
is clearly not performing at its best... pulling one cable actually
speeds up access.

  Any thoughts?

--
        Jim

 
 
 

Fast Etherchannel Q's

Post by Fritz » Wed, 09 Jul 2003 08:39:32



>   But in one of these boxes, the individual NICs also have the same MAC
> address, where the other one has sequential MAC addresses for the two
> NICs.

The MAC addresses must be the same on both adapters if you're using GEC
(Gig EtherChannel) or 802.3ad link aggregation.  (ISTR Intel had a
"teaming" feature where the MAC addresses could be different).

There's also setup required at the switch side, so you'll want to check
that.

RFM
--
To reply, translate domain from l33+ 2p33|< to alpha.
                4=a  0=o  3=e  +=t

 
 
 

Fast Etherchannel Q's

Post by Geo » Wed, 09 Jul 2003 09:35:30


Hi,
       Please review the document at HP's networking site
http://www.hp.com/rnd/library/pdf/techlib_hi_perf.pdf  (relevance at page 9
of PDF).   I might also suggest calling HP for configuration assistance at
970-635-1000 in the US.
       There are some derivations to each of the trunking methods.  Port
trunking is suppported with the most recent IEEE LACP trunking protocol ,
FEC (cisco proprietary), and pre-standard basic plain-olde "port trunking".
Some of these methods can be made to operate SA only, or SA/DA.  Some of the
methods balance on the outbound only, with all incoming traffic coming in
over one link.
       If you come back to this group, it may be preferrable to state the
actual hardware, it's versions, with as much configuration detail as
possible.
Good luck!

George Johnston
Logical Solutions for Integration
Clarity in an Unclear World

Quote:> Hi -
>   We own one NAS box, and are evaluating another, that offer dual GigE
> NICs operating as a 'bonded pair'.  These connect to an HP switch that
> supports port trunking.  There is some confusion about just how this
> bonding occurs, but one of the mfr's seems to think it's FEC.

>   Each of these boxes (running RH Linux) creates a logical interface
> named 'bond0', which has as its elements 'eth1' and 'eth2', the physical
> NICs.  In each case the two NICs are assigned the same IP address.

>   But in one of these boxes, the individual NICs also have the same MAC
> address, where the other one has sequential MAC addresses for the two
> NICs.

>   So the question is, which is preferable, assuming that this is really
> FEC?  Both mfr's claim that they just hook these up to a switch and
> there are "no problems".  Well, wrong.  The box with the different MAC
> addresses seems only to use one interface, while the other one idles.
> The box with the identical MACs balances its load between the NICs, but
> is clearly not performing at its best... pulling one cable actually
> speeds up access.

>   Any thoughts?

> --
>         Jim

 
 
 

Fast Etherchannel Q's

Post by Hansang Ba » Wed, 09 Jul 2003 09:54:59



says...
[snip: FEC or 802.3ad question]

Quote:>   So the question is, which is preferable, assuming that this is really
> FEC?  Both mfr's claim that they just hook these up to a switch and
> there are "no problems".  Well, wrong.  The box with the different MAC
> addresses seems only to use one interface, while the other one idles.
> The box with the identical MACs balances its load between the NICs, but
> is clearly not performing at its best... pulling one cable actually
> speeds up access.

Keep in mind that if you have the same source/destination pair, you
won't use more than one link.   FEC works by XOR'ing the MAC (and
sometimes IP addresses) of the source and destination.  If you only have
two links, it uses the last bit to determine which link it will use.  So
if XOR of the src/dest MAC comes up 0, it will use the first link.  If
the XOR of the src/dest MAC comes up 1, it will use the second link.  If
you have more than two links available for FEC, it just XORs the last
two bits (00, 01, 10, 11)

--

hsb

"Somehow I imagined this experience would be more rewarding"  Calvin
***************  USE ROT13 TO SEE MY EMAIL ADDRESS  ****************
********************************************************************
Due to the volume of email that I receive, I may not not be able to
reply to emails sent to my account.  Please post a followup instead.
********************************************************************

 
 
 

Fast Etherchannel Q's

Post by Jim Mac » Wed, 09 Jul 2003 11:01:12



> Hi,
>        Please review the document at HP's networking site
> http://www.hp.com/rnd/library/pdf/techlib_hi_perf.pdf  (relevance at
> page 9 of PDF).   I might also suggest calling HP for configuration
> assistance at 970-635-1000 in the US.
>        There are some derivations to each of the trunking methods.
> Port trunking is suppported with the most recent IEEE LACP trunking
> protocol , FEC (cisco proprietary), and pre-standard basic plain-olde
> "port trunking". Some of these methods can be made to operate SA
> only, or SA/DA.  Some of the methods balance on the outbound only,
> with all incoming traffic coming in over one link.
>        If you come back to this group, it may be preferrable to state
> the actual hardware, it's versions, with as much configuration detail
> as possible.
> Good luck!

Thanks to all who responded.

Before asking here, I did consult with all the vendors, including HP,
and was left with more questions.  HP support was not helpful... the
tech was sure that there was no such thing as "port aggregation
protocol".  As you know, HP switches are Cisco-clones in many ways.
This is a 4108gl with the latest firmware, and FEC is fully supported,
including PAgP.

Because I don't have complete, or reliable, information from the
vendors, my question was necessarily nonspecific.  I asked what I
thought was a generic question about whether the MAC addresses should be
identical when using FEC, which FritzM answered.

The document you cited, which I had read, doesn't speak to the MAC
address question in any way that I could understand.  I just read it
again, and I still don't see it.  But I'm still learning, and now I know
more than I did this morning. :-)

--
        Jim

 
 
 

Fast Etherchannel Q's

Post by AnyBody » Wed, 09 Jul 2003 23:50:03



> Hi -
>   We own one NAS box, and are evaluating another, that offer dual GigE
> NICs operating as a 'bonded pair'.  These connect to an HP switch that
> supports port trunking.  There is some confusion about just how this
> bonding occurs, but one of the mfr's seems to think it's FEC.

>   Each of these boxes (running RH Linux) creates a logical interface
> named 'bond0', which has as its elements 'eth1' and 'eth2', the physical
> NICs.  In each case the two NICs are assigned the same IP address.

>   But in one of these boxes, the individual NICs also have the same MAC
> address, where the other one has sequential MAC addresses for the two
> NICs.

>   So the question is, which is preferable, assuming that this is really
> FEC?  Both mfr's claim that they just hook these up to a switch and
> there are "no problems".  Well, wrong.  The box with the different MAC
> addresses seems only to use one interface, while the other one idles.
> The box with the identical MACs balances its load between the NICs, but
> is clearly not performing at its best... pulling one cable actually
> speeds up access.

>   Any thoughts?

Hi,

I have some detailed(ish) knowledge of Cisco stuff.

Over the years cisco have supported various methods of selecting a
wire for
the transmission of a particular frame.

These have included the, XOR of the last [log2 of n bits] of one of
the
MAC addresses, method originally used.

As I recall a more sophisticated hash of the addresses is now done on
at least some platforms - I don't know if the method has been made
public.

source    MAC or IP
dest      MAC or IP
src + dst MAC or IP with a more sophisticated hash than above.

Cat 6000 on CatOS software apparently does:-
EtherChannel load balancing can use either MAC addresses or IP
addresses,
and either source or destination or both source and destination
addresses.
The selected mode applies to all EtherChannels configured on the
switch

http://www.cisco.com/en/US/tech/tk389/tk213/technologies_tech_note091...

All of these schemes guarantee that a particular half conversation
uses a particular path. This maintains packet order in each stream.

While out of order packet would not necessarily cause applications to
fail, I suspect that it may result in an increase in processing
overhead
for the data stream.

The point of all of the discussion is that various schemes are
possible.

I am not surprised by the difficulty in obtaining a reliable statement
of the principles of operation of this sort of equipment. This has
been my own
experience in the past with various vendors. Just sign here sir:-)

Getting your sniffer out has often been the only reliable way of
resolving sort of this issue.

 
 
 

Fast Etherchannel Q's

Post by Jim Mac » Thu, 10 Jul 2003 12:19:11



> "Jim Mack" wrote...
>> Hi -
>>   We own one NAS box, and are evaluating another, that offer dual
>> GigE NICs operating as a 'bonded pair'.  These connect to an HP
>> switch that supports port trunking.  There is some confusion about
>> just how this bonding occurs, but one of the mfr's seems to think
>> it's FEC.

>>   Each of these boxes (running RH Linux) creates a logical interface
>> named 'bond0', which has as its elements 'eth1' and 'eth2', the
>> physical NICs.  In each case the two NICs are assigned the same IP
>> address.

>>   But in one of these boxes, the individual NICs also have the same
>> MAC address, where the other one has sequential MAC addresses for
>> the two NICs.

>>   So the question is, which is preferable, assuming that this is
>> really FEC?  Both mfr's claim that they just hook these up to a
>> switch and there are "no problems".  Well, wrong.  The box with the
>> different MAC addresses seems only to use one interface, while the
>> other one idles. The box with the identical MACs balances its load
>> between the NICs, but is clearly not performing at its best...
>> pulling one cable actually speeds up access.

>>   Any thoughts?

> Hi,

> I have some detailed(ish) knowledge of Cisco stuff.

> Over the years cisco have supported various methods of selecting a
> wire for
> the transmission of a particular frame.

> These have included the, XOR of the last [log2 of n bits] of one of
> the
> MAC addresses, method originally used.

> As I recall a more sophisticated hash of the addresses is now done on
> at least some platforms - I don't know if the method has been made
> public.

> source    MAC or IP
> dest      MAC or IP
> src + dst MAC or IP with a more sophisticated hash than above.

> Cat 6000 on CatOS software apparently does:-
> EtherChannel load balancing can use either MAC addresses or IP
> addresses,
> and either source or destination or both source and destination
> addresses.
> The selected mode applies to all EtherChannels configured on the
> switch

http://www.cisco.com/en/US/tech/tk389/tk213/technologies_tech_note091...

- Show quoted text -

Quote:

> All of these schemes guarantee that a particular half conversation
> uses a particular path. This maintains packet order in each stream.

> While out of order packet would not necessarily cause applications to
> fail, I suspect that it may result in an increase in processing
> overhead
> for the data stream.

> The point of all of the discussion is that various schemes are
> possible.

> I am not surprised by the difficulty in obtaining a reliable statement
> of the principles of operation of this sort of equipment. This has
> been my own
> experience in the past with various vendors. Just sign here sir:-)

> Getting your sniffer out has often been the only reliable way of
> resolving sort of this issue.

Thanks for the additional info.  I hope we can resolve this with the
vendors soon, but it seems to be a popular week for vacations :)

--
        Jim

 
 
 

Fast Etherchannel Q's

Post by shop » Fri, 11 Jul 2003 04:02:57



Quote:> Hi -
>   We own one NAS box, and are evaluating another, that offer dual GigE
> NICs operating as a 'bonded pair'.  These connect to an HP switch that
> supports port trunking.  There is some confusion about just how this
> bonding occurs, but one of the mfr's seems to think it's FEC.

>   Each of these boxes (running RH Linux) creates a logical interface
> named 'bond0', which has as its elements 'eth1' and 'eth2', the physical
> NICs.  In each case the two NICs are assigned the same IP address.

>   But in one of these boxes, the individual NICs also have the same MAC
> address, where the other one has sequential MAC addresses for the two
> NICs.

>   So the question is, which is preferable, assuming that this is really
> FEC?  Both mfr's claim that they just hook these up to a switch and
> there are "no problems".  Well, wrong.  The box with the different MAC
> addresses seems only to use one interface, while the other one idles.
> The box with the identical MACs balances its load between the NICs, but
> is clearly not performing at its best... pulling one cable actually
> speeds up access.

Jim

it sounds like there is a processor load for load balancing that is hitting
performance

do you care? - this kind of load balancing started on 10M ports to improve
throughput.

Is the performance with 1 link limited by the box or the Gig port?

If its the Gig port then alter it to do failover and ignore the channel
aggregation

Quote:

>   Any thoughts?

> --
>         Jim

--
Regards

Stephen Hope - remove xx from email to reply

 
 
 

1. Is it 'RG6' or 'RG6 QS' ???

NoArchive wrote :

It depends on what kind of connectors you will use.
The outside diameters of RG6, even just the foil-
shielded kind, can vary with type.  The smallest
foil-shielded RG6 that I see in my old Belden catalog
(no. 9146) is .275 inches (6.99mm), and it's described
as "Duofoil + 17% aluminum braid".  A higher grade of
RG6 (no. 9114), frequently used by cable companies
16 years ago, is .290 inches (7.37mm), and it's
described as "Duobond II + 37% aluminum braid".
Belden's real "Quadra-Shield" RG6, e.g. no. 1189A,
is .295 inches (7.49mm) and it's described as
"Duobond II + 58% aluminum braid + Duofoil tape +
40% aluminum braid" - a real belt-and-suspenders
arrangement.  My experience has been that the hex
crimp type of F-connectors aren't too fussy, and any
RG6 cable will work with an RG6 connector.  But if
you plan to use the compression type of connector
(a better quality), you need to select from 2 sizes of
RG6 connector available.  The only sure way in that
case is to try both.

Al_Hennesy

2. Quest: How to hang up proxy w/ dial-up?

3. QS: Clock too fast on our Meridian 61C

4. BSR 6800MX

5. Fast EtherChannel Failover on 6509?

6. Bill Gates Is A Baby-Eater

7. Redundancy with Cisco 7200 FE and Catalyst 3524XL with Fast Etherchannel and Port Groups

8. 24bit sonic solutions format

9. Question of Fast Etherchannel

10. Fast Etherchannel

11. Fast Etherchannel between switch and server

12. Which IEEE 802.3 Document is Cisco Fast EtherChannel based on?

13. Fast Etherchannel with 7206VXR