<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE>R: RE: Ethernet bondig</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><TT><FONT SIZE=2>Hi,<BR>
<BR>
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.<BR>
<BR>
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.<BR>
<BR>
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)<BR>
<BR>
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)<BR>
<BR>
<BR>
Ciao,<BR>
e<BR>
<BR>
-----Original Message-----<BR>
From: redhat-sysadmin-list-bounces@redhat.com <redhat-sysadmin-list-bounces@redhat.com><BR>
To: redhat-sysadmin-list@redhat.com <redhat-sysadmin-list@redhat.com><BR>
Sent: Fri Oct 05 03:10:51 2007<BR>
Subject: RE: Ethernet bondig<BR>
<BR>
I understand what you mean and I'd love to know that there is a real solution out there! :)<BR>
<BR>
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...<BR>
<BR>
<BR>
<BR>
________________________________<BR>
<BR>
From: redhat-sysadmin-list-bounces@redhat.com [<A HREF="mailto:redhat-sysadmin-list-bounces@redhat.com">mailto:redhat-sysadmin-list-bounces@redhat.com</A>] On Behalf Of Edoardo Causarano<BR>
Sent: Friday, 5 October 2007 10:20 AM<BR>
To: redhat-sysadmin-list@redhat.com<BR>
Subject: Ethernet bondig<BR>
<BR>
<BR>
<BR>
Hi there,<BR>
<BR>
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.<BR>
<BR>
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!)<BR>
<BR>
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).<BR>
<BR>
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?<BR>
<BR>
All this on Linux servers... Of course ;-)<BR>
e<BR>
<BR>
<BR>
<BR>
***********************************************************************<BR>
The information in this e-mail together with any attachments is<BR>
intended only for the person or entity to which it is addressed<BR>
and may contain confidential and/or privileged material.<BR>
Any form of review, disclosure, modification, distribution<BR>
and/or publication of this e-mail message is prohibited.<BR>
If you have received this message in error, you are asked to<BR>
inform the sender as quickly as possible and delete this message<BR>
and any copies of this message from your computer and/or your<BR>
computer system network.<BR>
Any attachments should be checked for viruses by you, before being opened. SunWater accepts no responsibility for an attachment that contains a virus.<BR>
***********************************************************************<BR>
<BR>
</FONT></TT>
</P>

</BODY>
</HTML>