[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ifupdown-bonding package

[ I suggest me move the discussion off-list, as it's now quite OT :) ]

On Tue, Oct 18, 2005, Jerome Martin wrote:
> >That's useful indeed.  That would be another round of fixes for the
> >bonding if-up scripts.
> Mmmhh ... are there already any bonding if-up scripts ? If so, I don't 
> know in which package ...

 I think only the one I cited, from ifenslave-2.6.

> When not using miimon, you can configure bonding to send arp requests to 
> specified IPs in order to check link connectivity. One of the problem I 
> have with that mode is that whenever you change the IP of those 
> reference machines or those individual hosts go down, your link is 
> declared as down. If the ifup scripts for bonding could automatically 
> select reasonable IPs to send ARPs to (after checking ARP requests are 
> honored), it could allow sysadmins to transparently use arp monitoring 
> without worrying too much about whether the bonding configuration is 
> up-to-date. Good candidates for such reference hosts could be the 
> declared default gateway for the interface and DNS servers (specified in 
> network/interfaces through resolvconf package hooks). This is very 
> specific to bonding, so I can't see how it can be usefull to other 
> inteface type.

 Ok, thanks for the clarification.

> A common problem with bonding + SNMP is that when you get the interface 
> list of an SNMP-enabled host, the SNMP agent only returns the first 
> interface to which a specific IP/mac address is attached (and this is 
> normal behavior, not a bug). Say you have eth1 and eth2 slaves of bond0. 
> If eth1 is brought up before bond0, its physicall interface definition 
> will appear first in the SNMP interface table, thus it will be used 
> instead of bond0 as "primary" interface for the corresponding IP 
> address. This is wrong because it works only when eth1 is primary in a 
> primary-backup scheme, but reports wrong stats in any other case (stats 
> like traffic, dropped packets, etc.).

 Ok, thanks for the explanation.

> The only way to make sure the SNMP agent will report the correct 
> interfaces indexes is to load the bonding module first, then load each 
> slave driver (of course this works only with modules, not with 
> monolithically compiled-in drivers).

 I think that the solution is wrong in this case, but I prefer we
 continue this discussion privately, as it's getting OT for this list.

 I suppose the final discussion and decision will be taken by the
 package maintainer of the files you want to change.  :)

> Is it clearer now ?

 Yes, thanks.

> Well, for one, there is a major flaw when reconfiguring interfaces : in 
> order for the if state to be properly handled, you are supposed to 
> ifdown the interface before any change to the config. Otherwise, you 
> loose the ability to properly ifdown it at a later time.

 Ok, that's a general problem with ifupdown IMO, non-vlan or bonding

> Good, I was not sure that bash was in base and allowed for such scripts 
> by policy. #!/bin/sh is bash anyway on a default installation :-).

 You need to use #!/bin/bash, not sh, even if sh points to bash by
 default.  bash is "Essential", meaning it's always there.

> I hope this clears up why I think specific precautions should be taken 
> when playing with VLANs + bonding.


> I agree this is ugly, but I disagree with your suggestion, witch is even 
> more error-prone IMHO. The problem in your example is redundancy of 
> information, without automatic cross-checking. I do prefer the 
> vlan_raw_device stanza style, where all VLAN definition is grouped into 
> the VLAN interface (a la RedHat) :
> iface eth0 inet manual
> iface eth0.16 inet static
> vlan_raw_device eth0
> vlan_id 16
> # this could be host / interface
> bind-type PER_KERNEL
> address x.x.x.x

 It has its defaults too, since one can do inconsistent things such as
 having eth0.16 using vlan_raw_device eth1, or iface eth0.16 with
 vlan_raw_device eth0 and iface eth0 with an address, etc.

> One simple reason I prefer the latest is because a VLAN may have 
> multiple specific options besides it VLAN number

 One doesn't forbid the other IMO.  I don't frankly care that the VLANs
 are declared in the resulting interfaces or in the physical interface
 carying them, but I do care about the information encoded in the name.

 Concerning your point about checking for names, well you know that when
 you boot your machine you start with eth0, eth1 etc.  So you also know
 that when you add VLANs to eth0, you end up with eth0.16 etc., it's

 This is way off-topic, but I would happily continue discussing this
 stuff either privately, or via IRC/IRL.

Loïc Minier <lool@dooz.org>

Reply to: