Ethernet bondig

[Holder, Bill]

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/479be066/attachment.htm>