[c-nsp] etherchannel between different switches

[Tassos Chatzithomaoglou]

Thanks a lot Aaron for the information.

I had a quick look at the SMLT RFC 
(http://www.ietf.org/internet-drafts/draft-lapuh-network-smlt-05.txt) and it seems troubleshooting 
will be quite difficult if something wrong occurs. I

We're actually trying to combine

1) increased bw between switches A/B and C
2) redundancy between switches A and B

while there is only 1 vlan active in these 3 switches

           router
            | | (hsrp)
    +-------+ +-------+
    |                 | (10 Gbps - 10m link)
    |                 |
switch A --------- switch B
    |                 |
    |                 | (1 Gbps - 3km link)
    +------+  +-------|
           |  |
          switch C
           ||||
          routers

Right now we have achieved No 2, by using the path though switch A as the primary path and the path 
through switch B as backup (configuring spanning-tree & uplink fast).

I guess doubling (2x1 Gbps GEC) all A-B-C connections would solve our No 1 problem too, but i was 
looking for something easier.

Tassos


Aaron Daubman wrote on 12/1/2006 20:20:

> Hi Tassos,
> 
> 
>>I would like to ask if there are any switches (cisco or non-cisco) that support etherchannel
>>functionality between different physical switches.
>>I know that the 3750s can do this through their stack implementation, but i'm looking for bigger
>>ones, like 6500s.
> 
> 
> Nortel is the only vendor I know of that allows this - using SMLT:
> http://en.wikipedia.org/wiki/Split_Multi-link_Trunking_(SMLT)
> 
> I'm not a huge fan (warning: possibly personally skewed bias against
> Nortel) and have heard mutterings that there are "interesting/hidden
> downsides" to this.  (I have no concrete details, however)
> 
> Having operationally implemented SMLT, however, when it works it
> really does seem to 'magically' distribute traffic between access
> switches and multiple cores... you do, however, lose determination
> which makes troubleshooting fun... there were also certain protocol
> limitations imposed when enabling SMLT on a switch, however this may
> have changed...  (I was only involved with the initial roll out, and
> so cannot speak to long-term benefits/issues either)
> 
> YMMV - depending on your network design you may also be able to
> benefit from GLBP (or GLBP + EtherChannel):
> http://en.wikipedia.org/wiki/GLBP
> 
> All-in-all, although not as auto-magical, a "properly" implemented
> network using 802.1w/PVST+ will, in essence, provide the same
> functionality as well as determinism when hunting down problems...
> (this seemed to be Cisco's response to "why no SMLT?" early on at
> least - anybody have better/more current details?  How about concrete
> info on SMLT performance/issues/benefits?)
> 
> Just my $0.02 - please add NaCl,
>      ~Aaron
>