R: RE: Ethernet bondig

Edoardo Causarano Edoardo.Causarano at laitspa.it
Fri Oct 5 07:03:59 UTC 2007


Hi,

Your trick is nice although I'd like to remain within the second layer of the stack. HP-UX does something similar to your setup by clustering nics and failing over to the spare (keeping the same IP addr though); perhaps RHCS or RH5 could do the same.

As far as I've been told by the network folks, nic teaming can only be done on a single switch (or n-stacked) although the italian wikipedia on spanning tree does seem to imply that the algo would disable the redundant paths keeping them as a hot backups. So, one would think that a switch network should tolerate multiple branches.

Has anyone done bonding on separate switches? Does it work? How long does it take to restore connectivity in case of link failure? (I don't care about bw/port loss, we're on GigE and hw to spare anyway)

Ideally I'd like to work with Nortel DSMLT switches and get rid of spanning tree altogether. (does Cisco do that or not unless over their dead body) 


Ciao,
e

-----Original Message-----
From: redhat-sysadmin-list-bounces at redhat.com <redhat-sysadmin-list-bounces at redhat.com>
To: redhat-sysadmin-list at redhat.com <redhat-sysadmin-list at redhat.com>
Sent: Fri Oct 05 03:10:51 2007
Subject: RE: Ethernet bondig

I understand what you mean and I'd love to know that there is a real solution out there! :)
 
At the moment, I have multiple nics with connections to different switches, and a dodgy perl script that tries to ping a destination via the default route, and if it can't it then drops that interface and points the default route to the next one in the list. It's dodgy but it works...
 
 

________________________________

From: redhat-sysadmin-list-bounces at redhat.com [mailto:redhat-sysadmin-list-bounces at redhat.com] On Behalf Of Edoardo Causarano
Sent: Friday, 5 October 2007 10:20 AM
To: redhat-sysadmin-list at redhat.com
Subject: Ethernet bondig



Hi there,

I have a question for you. I've done some FC SAN configurations and understood the benefits of multipathing so now our critical servers are redundantly connected to minimize storage failure probability.

Can I do the same with network? I'd like to bond a couple eth devs and attach them to redundant switches (not stacked) so in case one link fails, the other one keeps connectivity (throw in some load balancing as a bonus!)

As far as I can understand, and as the network guys put it, it can't be done. In fact, eth bondig replicates the mac address on all the participating interfaces confusing the hell out of the eth routing protocols. Still, I keep wondering about this issue... after all,  having to rush out to the datacentre because a nic, cable or switch gave up the ghost while everything else is duplicated is irritating (and inelegant).

So, would the switches (Cisco, in our case) choke is the same MAC was detected on two different ports of two different units? Would they go in broadcast mode, flooding the VLAN?

All this on Linux servers... Of course ;-)
e



***********************************************************************
The information in this e-mail together with any attachments is
intended only for the person or entity to which it is addressed
and may contain confidential and/or privileged material.
Any form of review, disclosure, modification, distribution
and/or publication of this e-mail message is prohibited. 
If you have received this message in error, you are asked to
inform the sender as quickly as possible and delete this message
and any copies of this message from your computer and/or your
computer system network. 
Any attachments should be checked for viruses by you, before being opened. SunWater accepts no responsibility for an attachment that contains a virus.
***********************************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/redhat-sysadmin-list/attachments/20071005/aee0fc19/attachment.htm>


More information about the redhat-sysadmin-list mailing list