[Server-devel] Notes on replacing bridging with bonding

[Alexander Dupuy]

Martin Langhoff escribió:
> This is roughly what I am doing:
>
> # mark the device as a bonding device
> # - for some reason TYPE does not work
>   

I have placed TYPE=Bonding in the ifcfg-bond0 config files, but this is 
not needed for Fedora 7 or later (it doesn't hurt to have it, though)

> # cat /etc/modprobe.d/xs-bonding
> alias bond0 bonding
>   

A modprobe.d/ directory - that's a nice trick!  I wasn't aware of this, 
so just added some lines to the /etc/modprobe.conf file:

alias bond0 bonding
options bond0 miimon=100 mode=3 downdelay=1000 updelay=1000

As far as I know, these options are pretty much the same as the ones 
which can be specified with BONDING_OPTS - I guess it is probably better 
to do that there (this feature was added since Fedora Core 5, when I set 
mine up).  As for the specifics of what might be appropriate for a 
bonded channel with only one interface expected to be enslaved, I would 
suggest something along the lines of:

# use active backup mode, allowing primary slave to be specified
mode=1
# set multicast only on primary
multicast=1
# set primary slave
primary=wlan1
# set status monitoring to 1000msec
miimon=1000

I'm not 100% sure about the last one.  I believe that if there is no 
monitoring, the link status of the bond interface won't reflect the link 
status of the underlying device, but I haven't confirmed this (or, for 
that matter, that the link status of the bond device will reflect the 
underlying device(s) if monitoring is enabled).  There is presumably 
some overhead to this, but at once a second or even tenth of a second, 
it is negligible.  Thinking about this more, since these are wireless 
devices (active antenna via USB) I don't even know if there is a "link 
status" - for those you might want to omit this option.  It could 
theoretically be useful for the wired Ethernet interfaces, though.

Other than these options, which aren't strictly necessary (your setup 
with the defaults should work fine) everything you have looks perfectly 
reasonable.  The only advantage to specifying the active backup mode is 
a little bit of misconfiguration protection, so that if somehow a second 
interface gets enslaved to a bond, it won't be used for transmission 
(packets will still be received on it, however).  Explicitly specifying 
the primary slave in the BONDING_OPTS of the master duplicates some of 
the configuration which introduces the possibility of inconsistency - 
I'm not sure what your feelings on that are.  If the primary slave is 
not explicitly specified, the first enslaved device is the primary.

@alex

-- 
mailto:alex.dupuy at mac.com