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:[EMAIL PROTECTED] _______________________________________________ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel