Technical data

4. Packages
balance-alb Adaptive load balancing: includes both balance-tlb, and inbound load bal-
ancing (rlb) for IPV4 traffic and needs no special requirements on the Switch. Load
Balancing for incoming traffic is achieved through ARP requests. The bonding
driver catches ARP responses from the server on their way outside and overrides
the source hardware address with the unique hardware address of a slave in the
bond. This way different clients use different hardware addresses for the server.
Incoming traffic from connections created by the server will also be balanced. If the
server sends ARP requests, the bonding driver copies and stores the client IP from
the ARP. At the time the ARP response of the client arrives the bonding driver
determines its hardware address and creates an ARP reply to this client assigning
a client in the bond to it. A problematic effect of ARP arrangements for load
balancing is that every time an ARP request is sent the hardware address of the
bond is used. Clients learn the hardware address of the bond and the incoming
traffic on the current slave collapses. This fact is countered in a way that updates
(ARP Replies) to all clients will be sent to their respective hardware addresses so
that the traffic is divided again. Incoming traffic will be newly allocated even when a
new slave is added to the bonding or an inactive slave is re-activated. The receiving
load is distributed sequentially (round robin) in the group of the slave with the
largest network speed in the bond.
When a connection is restored or a new slave joins the bond incoming traffic will be
distributed anew to all active Slaves in the bond by sending ARP replies with the
selected MAC addresses to each client. The parameter ’updelay’ must be set to a
value greater than or equal to the forwarding delay of the switch in order to avoid
blocking of ARP responses to clients.
Requirements:
• ethtool support in the base device driver to retrieve speed and duplex status
for each device.
• support in the base device driver to set the hardware address even when the de-
vice is open. This is neccessary for granting that at every time at least one slave
in the bond is carrying the hardware address of the bond (curr_active_slave)
although every slave in the bond has its own unique hardware address. If
curr_active_slave fails its hardware address will simply be replaced with a new
one.
BONDING_DEV_x_DEV_N Default: BONDING_DEV_x_DEV_N=’0’
Specifies the number of physical devices the bond consists of. E.g. for a bond between
’eth0’ and ’eth1’ (two eth-devices) ’2’ has to be entered.
BONDING_DEV_x_DEV_x Default: BONDING_DEV_x_DEV_x=”
The name of a physical device which belongs to this bonding device. An example would
be the value ’eth0’. Please note that a physical device that you use for a bond can’t be
used for anything else. So you can’t use it additionally for a DSL modem, a bridge, a
VLAN or inclusion in base.txt.
BONDING_DEV_x_MAC Default: BONDING_DEV_x_MAC=”
80