 
		Linux Ethernet Bonding Driver HOWTO

%		Latest update: 12 November 2007
%
		ǽ2007ǯ1112

%Initial release : Thomas Davis <tadavis at lbl.gov>
%
꡼Thomas Davis <tadavis at lbl.gov>

%Corrections, HA extensions : 2000/10/03-15 :
%
ĥ2000/10/03-15 :
  - Willy Tarreau <willy at meta-x.org>
  - Constantine Gavrilov <const-g at xpert.com>
  - Chad N. Tindel <ctindel at ieee dot org>
  - Janice Girouard <girouard at us dot ibm dot com>
  - Jay Vosburgh <fubar at us dot ibm dot com>

%Reorganized and updated Feb 2005 by Jay Vosburgh
%Added Sysfs information: 2006/04/24
%
ƹȹ2005ǯ 2 Jay Vosburgh
sysfs ɲá2006ǯ 424
  - Mitch Williams <mitch.a.williams at intel.com>

ܸȻ <yosshy@debian.or.jp>

%Introduction
%============
%
Ϥ
========

%	The Linux bonding driver provides a method for aggregating
%multiple network interfaces into a single logical "bonded" interface.
%The behavior of the bonded interfaces depends upon the mode; generally
%speaking, modes provide either hot standby or load balancing services.
%Additionally, link integrity monitoring may be performed.
%
Linux bonding ɥ饤ФʣΥͥåȥ󥿡եñŪʡַ
줿ץ󥿡ե礹ʤ󶡤ޤ礵줿󥿡ե
ưϥ⡼ɤ˰¸ޤ̤˸Ǥ⡼ɤϥۥåȥХޤ
ʬӥ󶡤ޤäơ󥯤ƻ뤬¸ޤ
	
%	The bonding driver originally came from Donald Becker's
%beowulf patches for kernel 2.0. It has changed quite a bit since, and
%the original tools from extreme-linux and beowulf sites will not work
%with this version of the driver.
%
bonding ɥ饤Фϸ Donald Becker Υͥ 2.0  Beowulf ѥåޤ
Ϥθ徯ѹ졢Extreme-Linux  Beowulf ΥȤˤ륪ꥸʥ
ΥġϡΥСΥɥ饤ФǤưʤǤ礦

%	For new versions of the driver, updated userspace tools, and
%who to ask for help, please follow the links at the end of this file.
%
СΥɥ饤С줿桼֤Υġ롢䤤碌ϡΥե
ˤ򻲾ȤƲ

桼 (userspace) ϥͥ (kernelspace) ȤǡԤ
  䥳ޥɤʤɤΥ桼̥ץԤǥХɥ
  Ф䥹塼ʤɤΥ桼̥ץǤʤͥ
  ̣ޤ


%Table of Contents
%=================
%
ܼ
====

%1. Bonding Driver Installation
1. bonding ɥ饤ФΥ󥹥ȡ

%2. Bonding Driver Options
2. bonding ɥ饤ФΥץ

%3. Configuring Bonding Devices
3. bonding ǥХ

%3.1	Configuration with Sysconfig Support
3.1     sysconfig ݡȤˤ

%3.1.1		Using DHCP with Sysconfig
3.1.1           sysconfig ˤ DHCP λ

%3.1.2		Configuring Multiple Bonds with Sysconfig
3.1.2           sysconfig ˤʣ bond 

%3.2	Configuration with Initscripts Support
3.2     initscripts ݡȤˤ

%3.2.1		Using DHCP with Initscripts
3.2.1           initscripts ˤ DHCP λ

%3.2.2		Configuring Multiple Bonds with Initscripts
3.2.2           initscripts ˤʣ bond 

%3.3	Configuring Bonding Manually with Ifenslave
3.3     ifenslave ˤ bonding μư

%3.3.1		Configuring Multiple Bonds Manually
3.3.1           ưǤʣ bond 

%3.4	Configuring Bonding Manually via Sysfs
3.4     sysfs ͳμưǤ bonding 

%4. Querying Bonding Configuration
4. bonding γǧ

%4.1	Bonding Configuration
4.1     bonding 

%4.2	Network Configuration
4.2     ͥåȥ

%5. Switch Configuration
5. å

%6. 802.1q VLAN Support
6. 802.1q VLAN ݡ

%7. Link Monitoring
7. 󥯴ƻ

%7.1	ARP Monitor Operation
7.1     ARP ƻ

%7.2	Configuring Multiple ARP Targets
7.2     ʣ ARP åȤ

%7.3	MII Monitor Operation
7.3     MII ƻ

%8. Potential Trouble Sources
8. Ū긻

%8.1	Adventures in Routing
8.1     롼ƥ󥰤Ǥ

%8.2	Ethernet Device Renaming
8.2     ͥåȥǥХ̾ѹ

%8.3	Painfully Slow Or No Failed Link Detection By Miimon
8.3     miimon ˤỴ٤ 뤤 󥯼ԸΤ

%9. SNMP agents
9. SNMP 

%10. Promiscuous mode
10. Promiscuous ⡼

%11. Configuring Bonding for High Availability
11. Ѥ bonding 

%11.1	High Availability in a Single Switch Topology
11.1    ñ쥹åȥݥˤ

%11.2	High Availability in a Multiple Switch Topology
11.2    ʣåȥݥˤ

%11.2.1		HA Bonding Mode Selection for Multiple Switch Topology
11.2.1          ʣΥåȥݥˤ bonding ⡼ɤ

%11.2.2		HA Link Monitoring for Multiple Switch Topology
11.2.2          ʣΥåȥݥˤ󥯴ƻ

%12. Configuring Bonding for Maximum Throughput
12. 祹롼ץåȤΰ٤ bonding 

%12.1	Maximum Throughput in a Single Switch Topology
12.1    ñ쥹åȥݥˤ祹롼ץå

%12.1.1		MT Bonding Mode Selection for Single Switch Topology
12.1.1            ñ쥹åȥݥˤ祹롼ץåȤ bonding ⡼ɤ

%12.1.2		MT Link Monitoring for Single Switch Topology
12.1.2          ñ쥹åȥݥˤ祹롼ץåȤΥ󥯴ƻ

%12.2	Maximum Throughput in a Multiple Switch Topology
12.2    ʣΥåȥݥˤ祹롼ץå

%12.2.1		MT Bonding Mode Selection for Multiple Switch Topology
12.2.1          ʣΥåȥݥˤ祹롼ץåȤ bonding ⡼ɤ

%12.2.2		MT Link Monitoring for Multiple Switch Topology
12.2.2          ʣΥåȥݥˤ祹롼ץåȤΥ󥯴ƻ

%13. Switch Behavior Issues
13. åεư

%13.1	Link Establishment and Failover Delays
13.1    󥯳Ωȥե륪Сٱ

%13.2	Duplicated Incoming Packets
13.2    ʣѥå

%14. Hardware Specific Considerations
14. ϡɥ̤ιͻ

14.1	IBM BladeCenter

%15. Frequently Asked Questions
15. 褯

%16. Resources and Links
16. ȥ


%1. Bonding Driver Installation
%==============================
%
1. bonding ɥ饤ФΥ󥹥ȡ
============================

%	Most popular distro kernels ship with the bonding driver
%already available as a module and the ifenslave user level control
%program installed and ready for use. If your distro does not, or you
%have need to compile bonding from source (e.g., configuring and
%installing a mainline kernel from kernel.org), you'll need to perform
%the following steps:
%
ۤȤɤμפʥǥȥӥ塼Υͥ bonding ɥ饤Ф⥸塼
ȤƴѲǽˤ󶡤Ƥޤifenslave 桼٥ץ
ѤǤ褦󥹥ȡ뤵ƽƤޤ⤷ʤΥǥȥӥ塼
󤬾嵭ΤȤǤʤʤ顢⤷bonding ɥ饤Ф򥽡饳ѥ
(Ĥޤꡢkernel.org ꤷᥤ饤󥫡ͥꤷƥ󥹥ȡ)
ɬפΤʤ顢̤˹ԤʤʤФʤʤǤ礦

%1.1 Configure and build the kernel with bonding
%-----------------------------------------------
%
1.1 bonding ɥ饤դͥȹ
--------------------------------------------

%	The current version of the bonding driver is available in the
%drivers/net/bonding subdirectory of the most recent kernel source
%(which is available on http://kernel.org).  Most users "rolling their
%own" will want to use the most recent kernel from kernel.org.
%
ߤΥС bonding ɥ饤ФϺǿΥͥ륽(http://kernel.org 
ǽ) drivers/net/bonding ֥ǥ쥯ȥˤޤּʬãǤä㤦
ۤȤɤΥ桼 kernel.org κǿΥͥȤǤ礦

%	Configure kernel with "make menuconfig" (or "make xconfig" or
%"make config"), then select "Bonding driver support" in the "Network
%device support" section.  It is recommended that you configure the
%driver as module since it is currently the only way to pass parameters
%to the driver or configure more than one bonding device.
%
make menuconfig(ޤϡmake xconfigסmake config)ǥͥꤷ
Network device supportץΡBonding driver supportפ򤷤Ʋ
bonding ɥ饤Фϥ⥸塼ˤᤷޤʤʤ顢bonding ɥ饤Ф
ѥ᡼Ϥꡢʣ bonding ǥХꤹ뺣ΤȤͣμʤ
Ǥ

%	Build and install the new kernel and modules, then continue
%below to install ifenslave.
%
ͥȥ⥸塼ۡ󥹥ȡ뤷³μ ifenslave 
ޥɤ򥤥󥹥ȡ뤷ޤ

%1.2 Install ifenslave Control Utility
%-------------------------------------
%
1.2 ifenslave 桼ƥƥΥ󥹥ȡ
----------------------------------------------

%	The ifenslave user level control program is included in the
%kernel source tree, in the file Documentation/networking/ifenslave.c.
%It is generally recommended that you use the ifenslave that
%corresponds to the kernel that you are using (either from the same
%source tree or supplied with the distro), however, ifenslave
%executables from older kernels should function (but features newer
%than the ifenslave release are not supported).  Running an ifenslave
%that is newer than the kernel is not supported, and may or may not
%work.
%
ifenslave 桼٥ץϥͥ륽ĥ꡼
(Documentation/networking/ifenslave.c ե)˴ޤޤƤޤ̤ˡ
ͥŬ(Ʊͥ륽ĥ꡼ʪ䡢ǥȥӥ塼
Ƥ) ifenslave λѤᤷޤǤ⡢Ťͥ뤫 
ifenslave μ¹ԥեⵡǽǤ礦(â ifenslave С꿷
ǽϥݡȤޤ)ͥ꿷 ifenslave μ¹ԤϥݡȤ
Ƥޤ󤷡ưưʤ꤫ǤϤޤ

%	To install ifenslave, do the following:
%
inenslave 򥤥󥹥ȡ뤹٤ˡΥޥɤ¹ԤƲ:

# gcc -Wall -O -I/usr/src/linux/include ifenslave.c -o ifenslave
# cp ifenslave /sbin/ifenslave

%	If your kernel source is not in "/usr/src/linux," then replace
%"/usr/src/linux/include" in the above with the location of your kernel
%source include directory.
%
ͥ륽/usr/src/linuxפˤʤϡ嵭Ρ/usr/src/linux/include
򥫡ͥ륽 include ǥ쥯ȥΥեѥ֤Ʋ

%	You may wish to back up any existing /sbin/ifenslave, or, for
%testing or informal use, tag the ifenslave to the kernel version
%(e.g., name the ifenslave executable /sbin/ifenslave-2.6.10).
%
¸ /sbin/ifenslave Хååפ뤫(ƥȤѤΰ٤)
ifenslave ˥դ(㤨Сifenslave ޥɤ /sbin/ifenslave-2.6.10 
Ȥ̾դ)ȻפΤޤ

%IMPORTANT NOTE:
%
פա

%	If you omit the "-I" or specify an incorrect directory, you
%may end up with an ifenslave that is incompatible with the kernel
%you're trying to build it for.  Some distros (e.g., Red Hat from 7.1
%onwards) do not have /usr/include/linux symbolically linked to the
%default kernel source include directory.
%
-Iפάꡢְäǥ쥯ȥꤷ硢ŪΥͥȸߴ
ʤ ifenslave ƤޤΤޤ󡣤ĤΥǥȥӥ塼(㡧
Red Hat Linux 7.1 ʹ)ϥͥ륽 include ǥ쥯ȥؤΥܥå
 /usr/include/linux ʤʤޤ

%SECOND IMPORTANT NOTE:
%
Ĥνפա

%	If you plan to configure bonding using sysfs, you do not need
%to use ifenslave.
%
sysfs Ѥ bonding Ԥ硢ifenslave ޥɤϻȤɬפ


%2. Bonding Driver Options
%=========================
%
2. bonding ɥ饤ФΥץ
===============================

%	Options for the bonding driver are supplied as parameters to the
%bonding module at load time, or are specified via sysfs.
%
bonding ɥ饤ФΥץ bonding ⥸塼Υɻ˥ѥ᡼Ȥ
롢ޤ sysfs 𤷤ƻꤵޤ
%
%	Module options may be given as command line arguments to the
%insmod or modprobe command, but are usually specified in either the
%/etc/modules.conf or /etc/modprobe.conf configuration file, or in a
%distro-specific configuration file (some of which are detailed in the next
%section).
%
⥸塼륪ץ insmod ޤ modprobe ޥɤΥޥɥ饤Ȥ
ͿƤɤǤ̾ /etc/modules.conf ޤ /etc/modprobe.conf ե
Τɤ餫뤤ϥǥȥӥ塼ͭե(δĤ
ϼΥޤ)ǻꤵޤ
%
%	Details on bonding support for sysfs is provided in the
%"Configuring Bonding Manually via Sysfs" section, below.
%
sysfs  bonding ݡȤξܺ٤ϡҤΡsysfs ͳμưǤ bonding 
󶡤ޤ

%	The available bonding driver parameters are listed below. If a
%parameter is not specified the default value is used.  When initially
%configuring a bond, it is recommended "tail -f /var/log/messages" be
%run in a separate window to watch for bonding driver error messages.
%
Ѳǽ bonding ɥ饤ФΥѥ᡼ʲ˼ޤѥ᡼ꤵ
äϡǥեͤѤޤǽ bond ꤹݤϡbonding 
饤ФΥ顼å򸫤뤿ˡ̤Υɥǡtail -f
/var/log/messagesפ¹Ԥᤷޤ

%	It is critical that either the miimon or arp_interval and
%arp_ip_target parameters be specified, otherwise serious network
%degradation will occur during link failures.  Very few devices do not
%support at least miimon, so there is really no reason not to use it.
%
miimon ѥ᡼ޤ arp_interval  arp_ip_target ѥ᡼λɬܤǤ
ꤷʤС󥯼Ԣδ֤˿ʥͥåȥǽ㲼ȯޤۤ
ɤΥǥХϾʤȤ miimon 򥵥ݡȤƤΤǡѤʤͳ
ˤޤ

ͥåȥ󥿡ե֡뤤ϥͥåȥ󥿡ե HUB 
      ̿䤷Ƥ

%	Options with textual values will accept either the text name
%or, for backwards compatibility, the option value.  E.g.,
%"mode=802.3ad" and "mode=4" set the same mode.
%
ƥͤˤ륪ץϥƥ̾(ߴΰ)ץͤΤɤ餫
դޤ㤨Сmode=802.3adפȡmode=4פƱ⡼ɤ򥻥åȤޤ

%	The parameters are as follows:
%
ѥ᡼ϰʲ̤ꡧ

arp_interval

%	Specifies the ARP link monitoring frequency in milliseconds.
%
	ARP 󥯴ƻ٤ߥñ̤ǻꤷޤ

%	The ARP monitor works by periodically checking the slave
%	devices to determine whether they have sent or received
%	traffic recently (the precise criteria depends upon the
%	bonding mode, and the state of the slave).  Regular traffic is
%	generated via ARP probes issued for the addresses specified by
%	the arp_ip_target option.
%
	ARP ƻϥ졼֥ǥХǶ̿ɤ򸡽Ф٤ˡ
	졼֥ǥХŪ˥åˤ굡ǽޤ(̩ʴ 
	bonding ⡼ɡ졼֥ǥХξ֤˰¸ޤ)arp_ip_target 
	ˤäƻꤵ줿ɥ쥹ؤ ARP ץ֤ˤäŪ̿
	ȯޤ

%	This behavior can be modified by the arp_validate option,
%	below.

	ưϸҤ arp_validate ץѹǽǤ

%	If ARP monitoring is used in an etherchannel compatible mode
%	(modes 0 and 2), the switch should be configured in a mode
%	that evenly distributes packets across all links. If the
%	switch is configured to distribute the packets in an XOR
%	fashion, all replies from the ARP targets will be received on
%	the same link which could cause the other team members to
%	fail.  ARP monitoring should not be used in conjunction with
%	miimon.  A value of 0 disables ARP monitoring.  The default
%	value is 0.
%
	ARP ƻ򥤡ͥߴ⡼(⡼ 0  2)ǻѤ硢
	 HUB 󥯤Ϥäƶ˥ѥåȤʬ⡼ɤꤵ
	Фʤޤ󡣥å XOR ǥѥåȤۿ褦ꤵ줿
	硢ARP åȤαƱ󥯷ͳǼ졢¾Υ
	ФǤʤˤʤޤARP ƻ miimon Ȱ˻Ѥ٤
	ǤϤޤ0 ͤ ARP ƻ̵ޤͤ 0 Ǥ

arp_ip_target

%	Specifies the IP addresses to use as ARP monitoring peers when
%	arp_interval is > 0.  These are the targets of the ARP request
%	sent to determine the health of the link to the targets.
%	Specify these values in ddd.ddd.ddd.ddd format.  Multiple IP
%	addresses must be separated by a comma.  At least one IP
%	address must be given for ARP monitoring to function.  The
%	maximum number of targets that can be specified is 16.  The
%	default value is no IP addresses.
%
	arp_interval  0 礭硢ARP ƻоݤȤƻѤ IP ɥ쥹
	ꤷޤ 󥯤³֤ȽǤ٤ ARP ꥯ
	ȤΥåȤǤͤ ddd.ddd.ddd.ddd եޥåȤǻꤷ
	ޤʣ IP ɥ쥹򥳥ޤǶڤʤꤹ٤ǤARP ƻ뤬
	ǽ뤿ˤϡʤƤ 1 Ĥ IP ɥ쥹ͿʤФʤ
	󡣻ǽʥåȤκ 16 ǤͤǤ IP ɥ쥹
	ꤵƤޤ

arp_validate

%	Specifies whether or not ARP probes and replies should be
%	validated in the active-backup mode.  This causes the ARP
%	monitor to examine the incoming ARP requests and replies, and
%	only consider a slave to be up if it is receiving the
%	appropriate ARP traffic.
%
	active-backup ⡼ɤ ARP 䤤碌ȱڤ뤫ɤꤷ
	ޤ ARP ƻФäƤ ARP ׵ȱ򸡾ڤŬڤ 
	ARP ȥեå줿졼֥ǥХΤߤ󥯥åפƤ
	ȽǤ褦ꤷޤ

%	Possible values are:
%
	ǽͤϡ

%	none or 0
%
	none ޤ 0

%		No validation is performed.  This is the default.
%
		ڤޤ󡣤줬ͤǤ
	

%	active or 1
%
	active ޤ 1

%		Validation is performed only for the active slave.
%
		ƥ֤ʥ졼֤Τ߸ڤ¹Ԥޤ

%	backup or 2
%
	backup ޤ 2

%		Validation is performed only for backup slaves.
%
		ХååפΥ졼֤Τ߸ڤ¹Ԥޤ

%	all or 3
%
	all ޤ 3

%		Validation is performed for all slaves.
%
		ƤΥ졼֤ФƸڤ¹Ԥޤ

%	For the active slave, the validation checks ARP replies to
%	confirm that they were generated by an arp_ip_target.  Since
%	backup slaves do not typically receive these replies, the
%	validation performed for backup slaves is on the ARP request
%	sent out via the active slave.  It is possible that some
%	switch or network configurations may result in situations
%	wherein the backup slaves do not receive the ARP requests; in
%	such a situation, validation of backup slaves must be
%	disabled.
%
	active-slave ˤơθڤǤ arp_ip_target ΣĤ줿
	Ǥ뤫ǧ٤ ARP åޤŵŪ˥Хååפ
	졼֤ϤαʤΤǡХååפΥ졼֤ΰ٤˼¹
	븡ڤ ARP ׵򥢥ƥ֤ʥ졼֤ޤХåå
	졼֤ ARP ׵ʤǡĤΥåޤϥͥå
	꤬̤ФǽǤΤ褦ʾǤϡХåå
	졼֤θڤ̵٤Ǥ

%	This option is useful in network configurations in which
%	multiple bonding hosts are concurrently issuing ARPs to one or
%	more targets beyond a common switch.  Should the link between
%	the switch and target fail (but not the switch itself), the
%	probe traffic generated by the multiple bonding instances will
%	fool the standard ARP monitor into considering the links as
%	still up.  Use of the arp_validate option can resolve this, as
%	the ARP monitor will only consider ARP requests and replies
%	associated with its own instance of bonding.
%
	Υץ϶̤Υåۤʣ bonding ۥȤ 1 Ĥޤ
	ʣΥåȤƱ ARP ФƤͥåȥǤ
	 (åΤξ㳲ǤϤʤ) åȥåȴ֤Υ󥯤㳲ˤ
	Сʣ bonding 󥹥󥹤ˤץ֥ȥեåˤ
	ץ̿ˤäơ󥯤ޤåפƤ褦ɸ ARP 
	ƻ뤬ǧޤarp_validate ץλѤϡARP ƻ뤬Ȥ 
	bonding 󥹥󥹤ȴϢդ줿 ARP ׵ᤪӱθ
	Ǥ褷ޤ

%	This option was added in bonding version 3.1.0.
%
	Υץ bonding С 3.1.0 ɲäޤ

	Red Hat Enterprise Linux 5.1  bonding ɥ饤ФΥС 
	3.1.2 Ǥ

downdelay

%	Specifies the time, in milliseconds, to wait before disabling
%	a slave after a link failure has been detected.  This option
%	is only valid for the miimon link monitor.  The downdelay
%	value should be a multiple of the miimon value; if not, it
%	will be rounded down to the nearest multiple.  The default
%	value is 0.
%
	󥯼ԤФ줿塢졼̵֤ˤԤĻ֤ꤹ(
	ñ)Υץ miimon 󥯴ƻǤΤͭǤ downdelay 
	ͤ miimon ͤܿͤǤ٤ܿͤǤʤ硢Ǥᤤܿͤ
	ڤΤƤޤǥեͤ 0 Ǥ

fail_over_mac

%	Specifies whether active-backup mode should set all slaves to
%	the same MAC address (the traditional behavior), or, when
%	enabled, change the bond's MAC address when changing the
%	active interface (i.e., fail over the MAC address itself).
%
	active-backup ⡼ɤ졼֤Ʊ MAC ɥ쥹ꤹ٤(
	ư)(ͭ)ƥ֤ʥ󥿡եѹ bond  MAC 
	쥹ѹ(ĤޤꡢMAC ɥ쥹Τե륪)٤Τɤ餫
	ꤷޤ
%
%	Fail over MAC is useful for devices that cannot ever alter
%	their MAC address, or for devices that refuse incoming
%	broadcasts with their own source MAC (which interferes with
%	the ARP monitor).
%
	MAC ե륪Фϡ̤ MAC ɥ쥹ѹǤʤǥХ뤤
	(ARP ƻΥ󥿡ե)Ȥ MAC ɥ쥹ļ֥
	ɥ㥹ȤݤǥХǤ
%
%	The down side of fail over MAC is that every device on the
%	network must be updated via gratuitous ARP, vs. just updating
%	a switch or set of switches (which often takes place for any
%	traffic, not just ARP traffic, if the switch snoops incoming
%	traffic to update its tables) for the traditional method.  If
%	the gratuitous ARP is lost, communication may be disrupted.
%
	ե륪 MAC ηϡŪˡˤ룱åޤϥå
	ι(åȤΥơ֥򹹿٤˼ȥեå˵
	Ƥ硢ARP ̿ǤϤʤǤդ̿ǤФȯ)Фơ
	ͥåȥǥХ gratuitous ARP 𤷤ƹʤФʤ
	Ǥ(åȤΥơ֥򹹿٤˼ȥեå˵
	Ƥ硢ARP ̿ǤϤʤǤդ̿ǤФȯ)
	gratuitous ARP 줿硢̿ʬǤ뤫Τޤ
%
%	When fail over MAC is used in conjuction with the mii monitor,
%	devices which assert link up prior to being able to actually
%	transmit and receive are particularly susecptible to loss of
%	the gratuitous ARP, and an appropriate updelay setting may be
%	required.
%
	ե륪 MAC  MII ƻѤ³ǻѤݡºݤ
	ǽˤʤ˥󥯥åפǸǥХϡä gratuitous ARP 
	μԤ¬졢Ŭڤ updelay ꤬ɬפˤʤޤ
%
%	A value of 0 disables fail over MAC, and is the default.  A
%	value of 1 enables fail over MAC.  This option is enabled
%	automatically if the first slave added cannot change its MAC
%	address.  This option may be modified via sysfs only when no
%	slaves are present in the bond.
%
	0 ͤϥե륪 MAC ̵ˤ줬ǥեȤǤ1 ͤϥե
	륪 MAC ͭˤޤǽ˲ä줿졼֤ MAC ɥ쥹
	Ǥʤä硢ΥץϼưŪͭˤʤޤbond ˥
	졼֤ĤʤΥץ sysfs ͳǤΤ߽
	ޤ
%
%	This option was added in bonding version 3.2.0.
%
	Υץ bonding С 3.2.0 ɲäޤ

lacp_rate

%	Option specifying the rate in which we'll ask our link partner
%	to transmit LACPDU packets in 802.3ad mode.  Possible values
%	are:
%
	802.3ad ⡼ɤˤ LACPDU ѥåȤФ뤿˲桹Υ
	䤤碌٤ꤹ륪ץǽͤ:

%	slow or 0
%
	slow ޤ 0

%		Request partner to transmit LACPDUs every 30 seconds
%
		30  LACPDU Фѡȥʡ׵᤹롣

%	fast or 1
%
	fast ޤ 1

%		Request partner to transmit LACPDUs every 1 second
%
		1  LACPDU Фѡȥʡ׵᤹롣

%	The default is slow.
%
	ǥեȤ slow Ǥ

max_bonds

%	Specifies the number of bonding devices to create for this
%	instance of the bonding driver.  E.g., if max_bonds is 3, and
%	the bonding driver is not already loaded, then bond0, bond1
%	and bond2 will be created.  The default value is 1.
%
	bonding ɥ饤ФΥ󥹥Ѥ˺ bonding ǥХοꤷ
	ޤ㤨Сmax_bonds  3 ǡbonding ɥ饤ФޤɤƤ
	ϡbond0bond1bond2 ޤǥեͤ 1 Ǥ

miimon

%	Specifies the MII link monitoring frequency in milliseconds.
%	This determines how often the link state of each slave is
%	inspected for link failures.  A value of zero disables MII
%	link monitoring.  A value of 100 is a good starting point.
%	The use_carrier option, below, affects how the link state is
%	determined.  See the High Availability section for additional
%	information.  The default value is 0.
%	
	MII 󥯤δƻ٤ߥñ̤ǻꤷޤϥ󥯾㳲ΰ٤ˤɤ
	̤٤ǳƥ졼֤Υ󥯾֤뤫ꤷޤ0  MII 
	ƻ̵ˤޤ100 ϺǽꤹΤɤͤǤҤ 
	use_carrier ץϡ󥯾֤ɤΤ褦ȽǤ뤫˱ƶޤ
	¾ξˤĤƤϹξϤ򸫤Ʋǥեͤ 0 Ǥ

mode

%	Specifies one of the bonding policies. The default is
%	balance-rr (round robin).  Possible values are:
%
	bonding ݥꥷΣĤꤷޤǥեȤ balance-rr (饦ɥ
	ӥ)Ǥǽͤϡ

%	balance-rr or 0
%
	balance-rr ޤ 0

%		Round-robin policy: Transmit packets in sequential
%		order from the first available slave through the
%		last.  This mode provides load balancing and fault
%		tolerance.
%
		饦ɥӥݥꥷѲǽʥ졼ַκǽ餫ǸޤǤ
		Ϣν֤ǥѥåȤФޤΥ⡼ɤʬѾ㳲
		󶡤ޤ

%	active-backup or 1
%
	active-backup ޤ 1

%		Active-backup policy: Only one slave in the bond is
%		active.  A different slave becomes active if, and only
%		if, the active slave fails.  The bond's MAC address is
%		externally visible on only one port (network adapter)
%		to avoid confusing the switch.
%
		ƥ֥Хååץݥꥷbond Σ졼֤Τߥƥ
		֤Ǥ̤Υ졼֤ϥƥ֤ʥ졼֤㳲ˤʤäΤ
		ƥ֤ˤʤޤͥåȥåκ򤱤١bond 
		 MAC ɥ쥹ϳñΥݡ(ͥåȥץ)
		ޤ

%		In bonding version 2.6.2 or later, when a failover
%		occurs in active-backup mode, bonding will issue one
%		or more gratuitous ARPs on the newly active slave.
%		One gratuitous ARP is issued for the bonding master
%		interface and each VLAN interfaces configured above
%		it, provided that the interface has at least one IP
%		address configured.  Gratuitous ARPs issued for VLAN
%		interfaces are tagged with the appropriate VLAN id.
%
		bonding С 2.6.2 ʹߡactive-backup ⡼ɤǥե
		Фȯ硢bonding Ͽƥ֤ˤʤä졼
		ǣĤޤϤʾ gratuitous (̵̣) ARP ȯԤޤ
		bonding ޥ󥿡եȤξꤵ줿 VLAN 󥿡
		եΰ٤ 1 Ĥ gratuitous ARP ȯԤ졢Υ󥿡ե
		ʤƤ 1 ĤѤ IP ɥ쥹Ĥ褦ˤʤޤ
		VLAN 󥿡եʣ gratuitous ARP Ŭڤ VLAN ID 
		ǥդƤޤ

		Red Hat Enterprise Linux 4 Update 4CentOS 4.4 ʹߤϥС
		 2.6.3 ʹߤ bonding ɥ饤ФѤƤޤ

%		This mode provides fault tolerance.  The primary
%		option, documented below, affects the behavior of this
%		mode.
%
		Υ⡼ɤѾ㳲󶡤ޤprimary ץ()Ϥ
		⡼ɤεư˱ƶޤ

%	balance-xor or 2
%
	balance-xor ޤ 2

%		XOR policy: Transmit based on the selected transmit
%		hash policy.  The default policy is a simple [(source
%		MAC address XOR'd with destination MAC address) modulo
%		slave count].  Alternate transmit policies may be
%		selected via the xmit_hash_policy option, described
%		below.
%
		XOR(¾)ݥꥷ򤵤줿žϥåݥꥷ˴Ť
		žޤǥեȤΥݥꥷñǤ [( MAC 
		쥹 MAC ɥ쥹¾)򥹥졼֥Ȥǳ
		;]̤žݥꥷ xmit_hash_policy ץ()
		ͳǤޤ

%		This mode provides load balancing and fault tolerance.
%
		Υ⡼ɤʬѾ㳲󶡤ޤ

%	broadcast or 3
%
	broadcast ޤ 3

%		Broadcast policy: transmits everything on all slave
%		interfaces.  This mode provides fault tolerance.
%
		֥ɥ㥹ȥݥꥷ졼֥󥿡եƤΥ
		åȤФޤΥ⡼ɤѾ㳲󶡤ޤ

%	802.3ad or 4
%
	802.3ad ޤ 4

%		IEEE 802.3ad Dynamic link aggregation.  Creates
%		aggregation groups that share the same speed and
%		duplex settings.  Utilizes all slaves in the active
%		aggregator according to the 802.3ad specification.
%
		IEEE 802.3ad ưŪ󥯽ǤƱ®٤Ʊͭ
		뽸祰롼פޤ802.3ad ͤ˽ƥ֤ʽ
		졼֤Ѥޤ

%		Slave selection for outgoing traffic is done according
%		to the transmit hash policy, which may be changed from
%		the default simple XOR policy via the xmit_hash_policy
%		option, documented below.  Note that not all transmit
%		policies may be 802.3ad compliant, particularly in
%		regards to the packet mis-ordering requirements of
%		section 43.2.4 of the 802.3ad standard.  Differing
%		peer implementations will have varying tolerances for
%		noncompliance.
%	
		ؤ̿Υ졼ϥåݥꥷˤäƹԤ
		ޤΥݥꥷϥǥեȤñ XOR ݥꥷҤ 
		xmit_hash_policy ץˤäѹǤޤƤݥ
		 802.3ad (ä 802.3ad ɸΥ 43.2.4 ׵
		줿ѥåȤν֥ߥ˴ؤ)ǤǤϤʤդƲ
		ۤʤԥƵޤ

%		Prerequisites:
%
		

%		1. Ethtool support in the base drivers for retrieving
%		the speed and duplex of each slave.
%
		1. ƥ졼֤®٤ȾŤ뤿Υ١ɥ饤Ф
		 Ethtool ݡ

%		2. A switch that supports IEEE 802.3ad Dynamic link
%		aggregation.
%
		2. IEEE 802.3ad ưŪ󥯥ꥲ򥵥ݡȤ륹å

%		Most switches will require some type of configuration
%		to enable 802.3ad mode.
%
		ۤȤɤΥå 802.3ad ⡼ɤͭˤ٤β餫
		ɬפˤʤޤ

%	balance-tlb or 5
%
	balance-tlb ޤ 5

%		Adaptive transmit load balancing: channel bonding that
%		does not require any special switch support.  The
%		outgoing traffic is distributed according to the
%		current load (computed relative to the speed) on each
%		slave.  Incoming traffic is received by the current
%		slave.  If the receiving slave fails, another slave
%		takes over the MAC address of the failed receiving
%		slave.
%
		Ŭžʬ: ̤ʥåݡȤɬפȤʤͥ
		Ǥϳƥ졼֤θߤ(®٤˴ϢƷ׻ޤ) 
		˽äʬޤϸߤΥ졼֤ˤäƹԤޤ
		Ƥ륹졼֤㳲򵯤硢̤Υ졼֤㳲
		졼֤ MAC ɥ쥹Ѥޤ

%		Prerequisite:
%
		:

%		Ethtool support in the base drivers for retrieving the
%		speed of each slave.
%
		ƥ졼֤̿®٤٤Υ١ɥ饤Ф ethtool ݡ

%	balance-alb or 6
%
	balance-alb ޤ 6

%		Adaptive load balancing: includes balance-tlb plus
%		receive load balancing (rlb) for IPV4 traffic, and
%		does not require any special switch support.  The
%		receive load balancing is achieved by ARP negotiation.
%		The bonding driver intercepts the ARP Replies sent by
%		the local system on their way out and overwrites the
%		source hardware address with the unique hardware
%		address of one of the slaves in the bond such that
%		different peers use different hardware addresses for
%		the server.
%
		Ŭʬ: IPV4 ̿ΰ٤ balance-tlb ȼʬ (rlb) 
		ޤߡ̤ʥåΥݡȤ׵ᤷޤ󡣼ʬ 
		ARP ͥˤ¸ޤbonding ɥ饤Фϥ
		륷ƥˤä줿 ARP иǼפꡢbond 
		Υ졼֤ΣĤñȤΥϡɥɥ쥹 (ARP Ρ
		ϡɥɥ쥹񤭤ޤˤꡢΥФؤ
		ۤʤ꤬̿ۤʤϡɥɥ쥹Ȥ褦ˤʤޤ

%		Receive traffic from connections created by the server
%		is also balanced.  When the local system sends an ARP
%		Request the bonding driver copies and saves the peer's
%		IP information from the ARP packet.  When the ARP
%		Reply arrives from the peer, its hardware address is
%		retrieved and the bonding driver initiates an ARP
%		reply to this peer assigning it to one of the slaves
%		in the bond.  A problematic outcome of using ARP
%		negotiation for balancing is that each time that an
%		ARP request is broadcast it uses the hardware address
%		of the bond.  Hence, peers learn the hardware address
%		of the bond and the balancing of receive traffic
%		collapses to the current slave.  This is handled by
%		sending updates (ARP Replies) to all the peers with
%		their individually assigned hardware address such that
%		the traffic is redistributed.  Receive traffic is also
%		redistributed when a new slave is added to the bond
%		and when an inactive slave is re-activated.  The
%		receive load is distributed sequentially (round robin)
%		among the group of highest speed slaves in the bond.
%
		Фˤäƺ줿³μȥեåʬ
		ޤ ƥब ARP׵硢bonding ɥ饤
		Ф ARP ѥåȤ IP 򥳥ԡ¸ޤ꤫̿
		 ARP 夹硢Υϡɥɥ쥹졢
		bonding ɥ饤Ф bond Υ졼֤ΣĤƤơ̿
		 ARP ޤХ󥹲ΰ٤ ARP ͥ
		Ѥη̤ ARP ׵᤬֥ɥ㥹Ȥݤ 
		ARP ׵᤬ bond Υϡɥɥ쥹ѤȤǤ
		椨̿ bond Υϡɥɥ쥹ؽ
		ʬϸߤΥ졼֤ԤƤޤޤϡ̿ʬ
		褦ʥϡɥɥ쥹򤽤ơ˳Ƥ줿
		(ARP )Ƥ̿ǰޤ졼
		֤ bond ˲ää󥢥ƥ֤ʥ졼֤٥ƥ
		줿ˤ⡢ȥեåʬޤ٤ 
		bond κǹ®Υ졼֤Υ롼״֤༡Ū(饦ɥӥ)
		ʬޤ

%		When a link is reconnected or a new slave joins the
%		bond the receive traffic is redistributed among all
%		active slaves in the bond by initiating ARP Replies
%		with the selected MAC address to each of the
%		clients. The updelay parameter (detailed below) must
%		be set to a value equal or greater than the switch's
%		forwarding delay so that the ARP Replies sent to the
%		peers will not be blocked by the switch.
%
		󥯤³뤫졼֤ bond ˲ä硢ƥ
		Ȥ˸򤵤줿 MAC ɥ쥹դ ARP ȯ
		ǡbond ƥ֥졼ִ֤Ǽȥեåʬ
		ޤupdelay ѥ᡼(˾ܺ)򥹥åžٱ
		ƱʾꤷʤФʤޤ󡣤ˤꡢ̿
		줿 ARP å˥֥åʤʤޤ

%		Prerequisites:
%
		:

%		1. Ethtool support in the base drivers for retrieving
%		the speed of each slave.
%
		1. ƥ졼֤®٤뤿Ρ١ɥ饤Фˤ Ethtool
		ݡ

%		2. Base driver support for setting the hardware
%		address of a device while it is open.  This is
%		required so that there will always be one slave in the
%		team using the bond hardware address (the
%		curr_active_slave) while having a unique hardware
%		address for each slave in the bond.  If the
%		curr_active_slave fails its hardware address is
%		swapped with the new curr_active_slave that was
%		chosen.
%
		2. ץ桢ǥХΥϡɥɥ쥹ꤵ٤Υ١
		ɥ饤Хݡȡϡbond γƥ졼֤ñΥϡɥ
		ɥ쥹Ĵ֡ΣĤΥ졼֤ bond Υϡ
		ɥ쥹(curr_active_slave)ˤʤ褦ˤ٤ɬפǤ
		curr_active_slave Ԥ硢Υϡɥɥ쥹Ͽ
		򤵤줿 curr_active_slave ֤ޤ

primary

%	A string (eth0, eth2, etc) specifying which slave is the
%	primary device.  The specified device will always be the
%	active slave while it is available.  Only when the primary is
%	off-line will alternate devices be used.  This is useful when
%	one slave is preferred over another, e.g., when one slave has
%	higher throughput than another.
%
	ɤΥ졼֤ǽΥǥХꤹʸ(eth0eth2¾)ꤵ
	ǥХϡ줬ѲǽʾϾ˥ƥ֤ʥ졼֤ˤʤޤ
	ǽΥǥХե饤ˤʤäΤߡ̤ΥǥХ򤵤ޤ
	ΥץϡĤΥ졼֤̤ΤΤͥ褵硢㤨С
	졼֤̥졼֤®٤®Ǥ

%	The primary option is only valid for active-backup mode.
%
	primary ץ active-backup ⡼ɤǤΤͭǤ

updelay

%	Specifies the time, in milliseconds, to wait before enabling a
%	slave after a link recovery has been detected.  This option is
%	only valid for the miimon link monitor.  The updelay value
%	should be a multiple of the miimon value; if not, it will be
%	rounded down to the nearest multiple.  The default value is 0.
%
	줬Τ줿塢졼֤ͭˤʤԤĻ֤ߥꥻ
	ǻꤷޤΥץ miimon 󥯴ƻǤΤͭǤupdelay 
	ͤ miimon ͤܿǤ٤ǤܿǤʤ硢Ǥᤤܿ˴ݤ
	ޤǥեͤ 0 Ǥ

use_carrier

%	Specifies whether or not miimon should use MII or ETHTOOL
%	ioctls vs. netif_carrier_ok() to determine the link
%	status. The MII or ETHTOOL ioctls are less efficient and
%	utilize a deprecated calling sequence within the kernel.  The
%	netif_carrier_ok() relies on the device driver to maintain its
%	state with netif_carrier_on/off; at this writing, most, but
%	not all, device drivers support this facility.
%
	󥯾֤Τ٤ˡmiimon  MII ޤ ETHTOOL  ioctl Ȥ
	ޤ netif_carrier_ok() ȤɤꤷޤMII ޤ ETHTOOL
	ioctl ϸΨͥǤϿ侩ƤʤƽХ󥹤Ѥ
	ޤnetif_carrier_ok() Ͼ֤ netif_carrier_on/off Ǵ٤ˡ
	ǥХɥ饤ФäƤޤ񤤤ƤǤϡۤȤ(
	ƤǤϤʤ)ΥǥХɥ饤Фεǽ򥵥ݡȤƤޤ

%	If bonding insists that the link is up when it should not be,
%	it may be that your network device driver does not support
%	netif_carrier_on/off.  The default state for netif_carrier is
%	"carrier on," so if a driver does not support netif_carrier,
%	it will appear as if the link is always up.  In this case,
%	setting use_carrier to 0 will cause bonding to revert to the
%	MII / ETHTOOL ioctl method to determine the link state.
%
	󥯤󤷤Ƥ٤˥󥯥åפƤ bonding ĥ
	硢ͥåȥǥХɥ饤Ф netif_carrier_on/off 򥵥ݡȤ
	ʤΤޤnetif_carrier ΥǥեȾ֤ "carrier on" Ǥ
	Τǡɥ饤Ф netif_carrier 򥵥ݡȤƤʤ硢˥󥯥
	פƤ褦˥ɥ饤Фޤξ硢use_carrier  0 ꤹ
	ǡbonding Υ󥯾֤θˡ MII/ETHTOOL ioctl ᤻ޤ

%	A value of 1 enables the use of netif_carrier_ok(), a value of
%	0 will use the deprecated MII / ETHTOOL ioctls.  The default
%	value is 1.
%
	 1  netif_carrier_ok() λѤͭˤ 0 侩 
	MII/ETHTOOL ioctl Ѥޤǥեͤ 1 Ǥ

xmit_hash_policy

%	Selects the transmit hash policy to use for slave selection in
%	balance-xor and 802.3ad modes.  Possible values are:
%
	balance-xor ޤ 802.3ad ⡼ɤǤΥ졼˻Ѥžϥå
	ݥꥷ򤷤ޤѲǽͤ:

	layer2

%		Uses XOR of hardware MAC addresses to generate the
%		hash.  The formula is
%
		ϥå˥ϡɥ MAC ɥ쥹¾¤Ѥ
		ޤη׻ϡ

%		(source MAC XOR destination MAC) modulo slave count
%
		( MAC  MAC ¾) 򥹥졼ֿǳä;

%		This algorithm will place all traffic to a particular
%		network peer on the same slave.
%
		Υ르ꥺϡΥͥåȥ̿ؤȥեå
		Ʊ졼־֤ޤ

%		This algorithm is 802.3ad compliant.
%
		Υ르ꥺ 802.3ad Ǥ

	layer2+3

%		This policy uses a combination of layer2 and layer3
%		protocol information to generate the hash.
%
		Υݥꥷϥϥå layer2  layer3 ץȥ
		ȹ礻Ѥޤ
%
%		Uses XOR of hardware MAC addresses and IP addresses to
%		generate the hash.  The formula is
%
		ϥå˥ϡɥ MAC ɥ쥹 IP ɥ쥹
		¾¤Ѥޤμ
%
%		(((source IP XOR dest IP) AND 0xffff) XOR
%			( source MAC XOR destination MAC ))
%				modulo slave count
%
		((( IP  IP ¾) 0xfff )
		( MAC  MAC ¾))¾¤
				졼ֿǳä;
%
%		This algorithm will place all traffic to a particular
%		network peer on the same slave.  For non-IP traffic,
%		the formula is the same as for the layer2 transmit
%		hash policy.
%
		Υ르ꥺΥͥåȥԥؤ̿Ʊ졼
		֤ޤ IP ̿Ǥϡμ layer2 žϥåݥ
		Ʊˤʤޤ
%
%		This policy is intended to provide a more balanced
%		distribution of traffic than layer2 alone, especially
%		in environments where a layer3 gateway device is
%		required to reach most destinations.
%
		ΥݥꥷϡäˤۤȤɤŪϤؤãΰ٤ layer3 
		ǥХ׵ᤵĶˤơlayer2 ñȤʿ경
		줿̿ʬ󶡤տޤƤޤ
%
%		This algorithm is 802.3ad complient.
%
		Υ르ꥺ 802.3ad Ǥ
%
	layer3+4

%		This policy uses upper layer protocol information,
%		when available, to generate the hash.  This allows for
%		traffic to a particular network peer to span multiple
%		slaves, although a single connection will not span
%		multiple slaves.
%
		Υݥꥷ(Ѳǽʾ)ϥå˾̥쥤Υץ
		ξѤޤΥͥåȥ̿ؤ̿
		ΤˡʣΥ졼֤ǽ緫ˤĤޤñ³
		ʣΥ졼֤˽緫ꤵޤ

%		The formula for unfragmented TCP and UDP packets is
%
		ҲƤʤ TCP  UDP ѥåȤΰ٤μ

%		((source port XOR dest port) XOR
%			 ((source IP XOR dest IP) AND 0xffff)
%				modulo slave count
%
		((Υݡֹ¾) 
		 (( IP ɥ쥹¾)  0xffff )
		 ¾) 򥹥졼ֿǳä;

%		For fragmented TCP or UDP packets and all other IP
%		protocol traffic, the source and destination port
%		information is omitted.  For non-IP traffic, the
%		formula is the same as for the layer2 transmit hash
%		policy.
%
		Ҳ TCP ޤ UDP ѥåȤȤ¾Ƥ IP ץȥ
		ˤϡΥݡȾ󤬾άޤ IP ̿ˤϡ
		μ layer2 ϥåݥꥷƱǤ

%		This policy is intended to mimic the behavior of
%		certain switches, notably Cisco switches with PFC2 as
%		well as some Foundry and IBM products.
%
		ΥݥꥷϡΥåFoundry  IBM ʤƱ͡
		ä PFC2 դ Cisco Υåεư򿿻褦˰տޤ
		Ƥޤ

%		This algorithm is not fully 802.3ad compliant.  A
%		single TCP or UDP conversation containing both
%		fragmented and unfragmented packets will see packets
%		striped across two interfaces.  This may result in out
%		of order delivery.  Most traffic types will not meet
%		this criteria, as TCP rarely fragments traffic, and
%		most UDP traffic is not involved in extended
%		conversations.  Other implementations of 802.3ad may
%		or may not tolerate this noncompliance.
%
		Υ르ꥺϴ 802.3ad ǤϤޤ󡣥ե饰
		ȤѥåȤȤƤʤѥåȤξޤñ TCP ޤ 
		UDP ̿ǤϡѥåȤĤΥ󥿡ե٤Ǹߤ㤤
		ʤǤ礦Ͻ̤Ǥʤη̤ˤʤ뤫Τޤ
		ۤȤɤ̿פǤϤΤ褦ʤȤˤϤʤʤǤ礦ʤ
		ʤ TCP ϵˤ̿ҲۤȤɤ UDP ̿Ĺä
		ޤޤʤǤ802.3ad ¾μϤߴ뤫
		Τޤ󤷡ʤ⤷ޤ

%	The default value is layer2.  This option was added in bonding
%	version 2.6.3.  In earlier versions of bonding, this parameter
%	does not exist, and the layer2 policy is the only policy.  The
%	layer2+3 value was added for bonding version 3.2.2.
%
	ǥեͤ layer2 ǤΥץ bonding С 2.6.3 
	ɲäޤΥС bonding ǤϤΥѥ᡼¸ߤ
	layer2 ݥꥷͣΥݥꥷǤlayer2+3 ͤ bonding С
	 3.2.2 ɲäޤ

%3. Configuring Bonding Devices
%==============================
%
3. Bonding ǥХ
=========================

%	You can configure bonding using either your distro's network
%initialization scripts, or manually using either ifenslave or the
%sysfs interface.  Distros generally use one of two packages for the
%network initialization scripts: initscripts or sysconfig.  Recent
%versions of these packages have support for bonding, while older
%versions do not.
%
ǥȥӥ塼ΥͥåȥץȤifenslave ޤ sysfs 
󥿡եΤɤ餫ưǻѤơbonding ꤹǤޤ
ˡǥȥӥ塼ϥͥåȥץȤΰ٤ΣĤΥѥå
(initscripts ޤ sysconfig)ΤΣĤѤޤΥѥåκǶ
ΥСǤ bonding 򥵥ݡȤƤޤǸŤСǤϥݡ
ȤƤޤ

%	We will first describe the options for configuring bonding for
%distros using versions of initscripts and sysconfig with full or
%partial support for bonding, then provide information on enabling
%bonding without support from the network initialization scripts (i.e.,
%older versions of initscripts or sysconfig).
%
ǽˡƥǥȥӥ塼 bonding δޤʬݡդС
 initscripts  sysconfig Ѥ bonding ꤹ륪ץ
줫顢ͥåȥץ(ĤޤꡢŤС initscripts ޤ
 sysconfig)ΥݡȤʤ bonding ͭˤ󶡤ޤ

%	If you're unsure whether your distro uses sysconfig or
%initscripts, or don't know if it's new enough, have no fear.
%Determining this is fairly straightforward.
%
ʤΥǥȥӥ塼 sysconfig ޤ initscripts ΤɤȤäƤ
뤫ʾ硢뤤Ϥ줬ʬ˿Τʤ硢ۤϤޤ
Ƚ̤ϼ¤ΨľǤ

%	First, issue the command:
%
ǽˡΥޥɤ¹Ԥޤ

$ rpm -qf /sbin/ifup

%	It will respond with a line of text starting with either
%"initscripts" or "sysconfig," followed by some numbers.  This is the
%package that provides your network initialization scripts.
%
ϡinitscriptsפ뤤ϡsysconfigפΤɤ餫ǻϤޤꡢ˿³
ԤΥƥȤǱޤ줬ȤΥͥåȥץȤ󶡤Ƥ
ѥåǤ

%	Next, to determine if your installation supports bonding,
%issue the command:
%
ˡΥ󥹥ȡ뤵줿Τ bonding 򥵥ݡȤ뤫ɤĴ٤٤ˡ
Υޥɤ¹Ԥޤ

$ grep ifenslave /sbin/ifup

%	If this returns any matches, then your initscripts or
%sysconfig has support for bonding.
%
Ǥ餫Υޥå֤С initscripts ޤ sysconfig  bonding 
򥵥ݡȤƤޤ

%3.1 Configuration with Sysconfig Support
%----------------------------------------
%
3.1 sysconfig ݡȤˤ
----------------------------------

%	This section applies to distros using a version of sysconfig
%with bonding support, for example, SuSE Linux Enterprise Server 9.
%
Υϡbonding 򥵥ݡȤ sysconfig ΥСȤäǥ
ӥ塼(㡧SuSE Linux Enterprise Server 9)ŬѤޤ

%	SuSE SLES 9's networking configuration system does support
%bonding, however, at this writing, the YaST system configuration
%front end does not provide any means to work with bonding devices.
%Bonding devices can be managed by hand, however, as follows.
%
SuSE SLES 9 Υͥåȥꥷƥ bonding 򥵥ݡȤޤʤ
顢񤤤ƤǤϡ YaST ƥեȥɤ bonding ǥХ
ư뵡ǽ򲿤󶡤Ƥޤ󡣤ʤ顢ҤΤ褦ˡbonding 
ХưǴޤ

%	First, if they have not already been configured, configure the
%slave devices.  On SLES 9, this is most easily done by running the
%yast2 sysconfig configuration utility.  The goal is for to create an
%ifcfg-id file for each slave device.  The simplest way to accomplish
%this is to configure the devices for DHCP (this is only to get the
%file ifcfg-id file created; see below for some issues with DHCP).  The
%name of the configuration file for each device will be of the form:
%
ǽˡ餬ޤꤵƤʤ硢졼֥ǥХꤷޤSLES9 
ϡ yast2 sysconfig 桼ƥƥ¹ԤǼ¤˴ñ˹Ԥޤ
ϳƥ졼֥ǥХˣĤ ifcfg-id եǤ
ִñˡϡƥǥХ DHCP ꤹǤ(ϡ줿 
ifcfg-id ե뤿ǤDHCP ΤĤˤĤƤϲ򻲾
Ʋ)ƥǥХե̾ϤΤ褦ʷˤʤޤ

ifcfg-id-xx:xx:xx:xx:xx:xx

%	Where the "xx" portion will be replaced with the digits from
%the device's permanent MAC address.
%
xxʬϡǥХξ MAC ɥ쥹 16 ʿִޤ

%	Once the set of ifcfg-id-xx:xx:xx:xx:xx:xx files has been
%created, it is necessary to edit the configuration files for the slave
%devices (the MAC addresses correspond to those of the slave devices).
%Before editing, the file will contain multiple lines, and will look
%something like this:
%
ö ifcfg-id-xx:xx:xx:xx:xx:xx եΥåȤ줿顢졼֥ǥХ
ѤեԽɬפޤ(MAC ɥ쥹ϥ졼֥ǥХΤΤ
פޤ)ԽΥեʣιԤޤߡΤ褦ʴ˸Ǥ


BOOTPROTO='dhcp'
STARTMODE='on'
USERCTL='no'
UNIQUE='XNzu.WeZGOGF+4wE'
_nm_name='bus-pci-0001:61:01.0'

%	Change the BOOTPROTO and STARTMODE lines to the following:
%
BOOTPROTO Ԥ STARTMODE Ԥ򼡤Τ褦ѹޤ

BOOTPROTO='none'
STARTMODE='off'

%	Do not alter the UNIQUE or _nm_name lines.  Remove any other
%lines (USERCTL, etc).
%
UNIQUE Ԥ _nm_name ԤѹƤϤʤޤ¾ι(USERCTL )ϺƤ


%	Once the ifcfg-id-xx:xx:xx:xx:xx:xx files have been modified,
%it's time to create the configuration file for the bonding device
%itself.  This file is named ifcfg-bondX, where X is the number of the
%bonding device to create, starting at 0.  The first such file is
%ifcfg-bond0, the second is ifcfg-bond1, and so on.  The sysconfig
%network configuration system will correctly start multiple instances
%of bonding.
%
ö ifcfg-id-xx:xx:xx:xx:xx:xx ե顢bonding ǥХȤ
ե֤ǤΥե ifcfg-bondX Ȥ̾ǡX   
bonding ǥХֹǡ0 ϤޤޤΤ褦ʥեΣ֤ 
ifcfg-bond0֤ ifcfg-bond1sysconfig ͥåȥꥷƥʣ
 bonding 󥹥󥹤Ȥޤ

%	The contents of the ifcfg-bondX file is as follows:
%
ifcfg-bondX եȤϼΤ褦ʤΤǤ

BOOTPROTO="static"
BROADCAST="10.0.2.255"
IPADDR="10.0.2.10"
NETMASK="255.255.0.0"
NETWORK="10.0.2.0"
REMOTE_IPADDR=""
STARTMODE="onboot"
BONDING_MASTER="yes"
BONDING_MODULE_OPTS="mode=active-backup miimon=100"
BONDING_SLAVE0="eth0"
BONDING_SLAVE1="bus-pci-0000:06:08.1"

%	Replace the sample BROADCAST, IPADDR, NETMASK and NETWORK
%values with the appropriate values for your network.

ץ BROADCASTIPADDRNETMASKNETWORK ͤ򤢤ʤΥͥåȥŬڤ
֤ͤƲ

%	The STARTMODE specifies when the device is brought online.
%The possible values are:

STARTMODE ϥǥХĥ饤ˤʤ뤫ꤷޤǽͤϡ

%	onboot:	 The device is started at boot time.  If you're not
%		 sure, this is probably what you want.
%
	onboot:  ǥХϵư˳Ϥޤ褯ʬʤС¿ʬ줬
		 ʤδ˾ΤǤ

%	manual:	 The device is started only when ifup is called
%		 manually.  Bonding devices may be configured this
%		 way if you do not wish them to start automatically
%		 at boot for some reason.
%
	manual:  ǥХϼư ifup ƤФ줿Τ߳Ϥޤ餫ͳ
		 ǡư˼ưŪ bonding ǥХ򳫻Ϥʤˤ
		 ˡǤޤ

%	hotplug: The device is started by a hotplug event.  This is not
%		 a valid choice for a bonding device.
%
	hotplug: ǥХ hotplug ٥ȤˤäƳϤޤ bonding 
		 ǥХˤȤäǤϤޤ

%	off or ignore: The device configuration is ignored.
%
	off ޤ ignore: ǥХ̵뤵ޤ

%	The line BONDING_MASTER='yes' indicates that the device is a
%bonding master device.  The only useful value is "yes."
%
BONDING_MASTER='yes' ԤϡǥХ bonding ޥǥХǤ򼨤Ƥ
ޤͣͭͤϡyesפǤ

%	The contents of BONDING_MODULE_OPTS are supplied to the
%instance of the bonding module for this device.  Specify the options
%for the bonding mode, link monitoring, and so on here.  Do not include
%the max_bonds bonding parameter; this will confuse the configuration
%system if you have multiple bonding devices.
%
BONDING_MODULE_OPTS ƤϡΥǥХ bonding ⥸塼륤󥹥󥹤
ޤbonding ⡼ɡ󥯴ƻΥץ򤳤ǻꤷޤ
max_bonds bonding ѥ᡼ޤʤǤϡʣ bonding ǥ
硢ꥷƥ𤵤ޤ

%	Finally, supply one BONDING_SLAVEn="slave device" for each
%slave.  where "n" is an increasing value, one for each slave.  The
%"slave device" is either an interface name, e.g., "eth0", or a device
%specifier for the network device.  The interface name is easier to
%find, but the ethN names are subject to change at boot time if, e.g.,
%a device early in the sequence has failed.  The device specifiers
%(bus-pci-0000:06:08.1 in the example above) specify the physical
%network device, and will not change unless the device's bus location
%changes (for example, it is moved from one PCI slot to another).  The
%example above uses one of each type for demonstration purposes; most
%configurations will choose one or the other for all slave devices.
%
Ǹˡƥ졼ˡBONDING_SLAVEn="졼֥ǥХ"פ򣱤Ϳޤn
βսϳƥ졼 1ĤäͤǤ֥졼֥ǥХפϡeth0
󥿡ե̾ͥåȥǥХΥǥХؼҤΤɤ餫Ǥ󥿡
ե̾ϸĤפǤethN ̾ϵưѹ(㤨СϢΤ
ǥХԤ)ˤʤޤǥХؼ(嵭Ǥ 
bus-pci-0000:06:08.1)ʪŪʥͥåȥǥХɽ路ΥǥХΥХ
ΰ֤ѹ(㤨СĤ PCI åȤ̤ΥåȤ˰ư)ʤ
Ѥޤ󡣾嵭ǤϡǥŪǳƥפ1ĤȤäƤޤۤȤ
ɤƤΥ졼֥ǥХˤɤ餫1Ĥ򤷤ޤ

%	When all configuration files have been modified or created,
%networking must be restarted for the configuration changes to take
%effect.  This can be accomplished via the following:
%
Ƥե뤬ޤϺ줿ѹȿǤ٤˥ͥåȥ
ƵưʤȤޤ󡣤ϡ𤷤Ƽ¹ԤǤޤ

# /etc/init.d/network restart

%	Note that the network control script (/sbin/ifdown) will
%remove the bonding module as part of the network shutdown processing,
%so it is not necessary to remove the module by hand if, e.g., the
%module parameters have changed.
%
ͥåȥ楹ץ(/sbin/ifdown)ϥͥåȥ߽ΰȤ 
bonding ⥸塼Τǡ㤨Х⥸塼Υѥ᡼ѹ줿
ưǥ⥸塼ɬפʤդƲ

%	Also, at this writing, YaST/YaST2 will not manage bonding
%devices (they do not show bonding interfaces on its list of network
%devices).  It is necessary to edit the configuration file by hand to
%change the bonding configuration.
%
ޤʸϤμɮǤϡYaST/YaST2  bonding ǥХޤ(
ϥͥåȥǥХΰ bonding 󥿡եɽޤ)bonding 
ѹΰ٤ˡưեԽɬפޤ

%	Additional general options and details of the ifcfg file
%format can be found in an example ifcfg template file:
%
ɲŪʰ̥ץ ifcfg եեޥåȤξܺ٤ϡifcfg ƥץ졼
եǸޤ

/etc/sysconfig/network/ifcfg.template

%	Note that the template does not document the various BONDING_
%settings described above, but does describe many of the other options.
%
Υƥץ졼ȤϾ嵭͡ BONDING_ ΥɥȤǤϤޤ
¾Υץ¿ƤդƲ

%3.1.1 Using DHCP with Sysconfig
%-------------------------------
%
3.1.1 sysconfig Ѥ DHCP λ
------------------------------------

%	Under sysconfig, configuring a device with BOOTPROTO='dhcp'
%will cause it to query DHCP for its IP address information.  At this
%writing, this does not function for bonding devices; the scripts
%attempt to obtain the device address from DHCP prior to adding any of
%the slave devices.  Without active slaves, the DHCP requests are not
%sent to the network.
%
sysconfig ǤϡBOOTPROTO='dhcp' ˤǥХˤä IP ɥ쥹
ΰ٤ DHCP 䤤碌ԤޤɮǤϡΥץ bonding ǥ
Ǥϵǽޤ󡣢ץȤϥ졼֥ǥХΤ줫ä DHCP 
ǥХΥɥ쥹褦Ȥޤƥ֤ʥ졼֤ʤȡDHCP 
ꥯȤϥͥåȥޤ

%3.1.2 Configuring Multiple Bonds with Sysconfig
%-----------------------------------------------
%
3.1.2 sysconfig ˤʣ bond 
------------------------------------------

%	The sysconfig network initialization system is capable of
%handling multiple bonding devices.  All that is necessary is for each
%bonding instance to have an appropriately configured ifcfg-bondX file
%(as described above).  Do not specify the "max_bonds" parameter to any
%instance of bonding, as this will confuse sysconfig.  If you require
%multiple bonding devices with identical parameters, create multiple
%ifcfg-bondX files.
%
sysconfig ͥåȥƥʣ bonding ǥХμ谷ǽǤ
ɬפʤΤϡ(嵭̤) bonding 󥹥󥹤ΰ٤Ŭڤꤵ줿 
ifcfg-bondX ե뤬Ǥsysconfig 𤹤Τǡɤ bonding 
󥹥󥹤ˤmax_bondsץѥ᡼ꤷʤǲġΥѥ᡼
ʣ bonding ǥХɬפʾϡʣ ifcfg-bondX եƲ


%	Because the sysconfig scripts supply the bonding module
%options in the ifcfg-bondX file, it is not necessary to add them to
%the system /etc/modules.conf or /etc/modprobe.conf configuration file.
%
sysconfig ץȤ ifcfg-bondX ե bonding ⥸塼륪ץ
ΤǡΥץ򥷥ƥ /etc/modules.conf 뤤 
/etc/modprobe.conf եɲäɬפϤޤ

%3.2 Configuration with Initscripts Support
%------------------------------------------
%
3.2 initscripts ݡȤˤ
------------------------------------

%	This section applies to distros using a recent version of
%initscripts with bonding support, for example, Red Hat Enterprise Linux
%version 3 or later, Fedora, etc.  On these systems, the network
%initialization scripts have knowledge of bonding, and can be configured to
%control bonding devices.  Note that older versions of the initscripts
%package have lower levels of support for bonding; this will be noted where
%applicable.
%
Υϡbonding ݡȤ initscripts κǶΥСѤ
ǥȥӥ塼(㡧Red Hat Linux 9 ޤ Red Hat Enterprise Linux С
 3 ʹߡFedora¾)ŬѤޤΥƥǤϡͥåȥ
ץȤ bonding 򤢤򤷡bonding ǥХΰ٤ꤹ
Ǥޤinitscript ѥåΤŤС bonding ΰ٤Τ㤤
ΥݡȤʤդƲɤäƳս˵Ҥޤ

%	These distros will not automatically load the network adapter
%driver unless the ethX device is configured with an IP address.
%Because of this constraint, users must manually configure a
%network-script file for all physical adapters that will be members of
%a bondX link.  Network script files are located in the directory:
%
Υǥȥӥ塼ϡethX ǥХ IP ɥ쥹äꤵ
¤ꡢưŪˤϥͥåȥץɥ饤Фɤޤ󡣤ΰ١桼
 bondX 󥯤ΥФˤʤƤʪץ ͥåȥץȥե
ưꤹɬפޤͥåȥץȥեϰʲΥǥ쥯
ȥ֤ޤ

/etc/sysconfig/network-scripts

%	The file name must be prefixed with "ifcfg-eth" and suffixed
%with the adapter's physical adapter number.  For example, the script
%for eth0 would be named /etc/sysconfig/network-scripts/ifcfg-eth0.
%Place the following text in the file:
%
ե̾ϡifcfg-ethפǻϤޤꡢΥץʪץֹǽʤ
Фʤޤ㤨Сeth0 ѤΥץȤ 
/etc/sysconfig/network-scripts/ifcfg-eth0 Ȥ̾ˤʤޤΥե
ΥƥȤ֤ޤ

DEVICE=eth0
USERCTL=no
ONBOOT=yes
MASTER=bond0
SLAVE=yes
BOOTPROTO=none

%	The DEVICE= line will be different for every ethX device and
%must correspond with the name of the file, i.e., ifcfg-eth1 must have
%a device line of DEVICE=eth1.  The setting of the MASTER= line will
%also depend on the final bonding interface name chosen for your bond.
%As with other network devices, these typically start at 0, and go up
%one for each device, i.e., the first bonding instance is bond0, the
%second is bond1, and so on.
%
DEVICE= ԤƤ ethX ǥХǰۤʤꡢե̾˰פʤФʤޤ
Ĥޤꡢifcfg-eth1  DEVICE=eth1 ΥǥХԤʤФʤޤMASTER= Ԥ
⡢ʤ bond դǽŪ bonding 󥿡ե̾˰¸ޤ
¾ΥͥåȥǥХǤ⡢̾ 0 ϤޤꡢƥǥХ 1 
ƤޤĤޤꡢǽ bonding 󥹥󥹤 bond0֤ bond1
Ȥʤޤ

%	Next, create a bond network script.  The file name for this
%script will be /etc/sysconfig/network-scripts/ifcfg-bondX where X is
%the number of the bond.  For bond0 the file is named "ifcfg-bond0",
%for bond1 it is named "ifcfg-bond1", and so on.  Within that file,
%place the following text:
%
ˡbond ΥͥåȥץȤޤΥץȤΥե̾ 
/etc/sysconfig/network-scripts/ifcfg-bondX (X  bond ֹ) ˤʤޤbond0 
ѤΥեϡifcfg-bond0פȤ̾bond1 Ѥϡifcfg-bond1פȤ̾
ĤˤʤޤΥեˡΥƥȤ֤ޤ

DEVICE=bond0
IPADDR=192.168.1.1
NETMASK=255.255.255.0
NETWORK=192.168.1.0
BROADCAST=192.168.1.255
ONBOOT=yes
BOOTPROTO=none
USERCTL=no

%	Be sure to change the networking specific lines (IPADDR,
%NETMASK, NETWORK and BROADCAST) to match your network configuration.
%
ͥåȥͭ(IPADDRNETMASKNETWORKBROADCAST)򤢤ʤΥͥåȥ
˰פ褦˳μ¤ѹƲ

%	For later versions of initscripts, such as that found with Fedora
%7 and Red Hat Enterprise Linux version 5 (or later), it is possible, and,
%indeed, preferable, to specify the bonding options in the ifcfg-bond0
%file, e.g. a line of the format:
%
Fedora 7  Red Hat Enterprise Linux С 5 (ޤϰʹ)Ǹ褦 
initscripts κǿСǤϡifcfg-bond0 ե bonding ץ
ꤹǽǡºݡषޤǤ㤨СΥեޥåȤι

BONDING_OPTS="mode=active-backup arp_interval=60 arp_ip_target=+192.168.1.254"

%	will configure the bond with the specified options.  The options
%specified in BONDING_OPTS are identical to the bonding module parameters
%except for the arp_ip_target field.  Each target should be included as a
%separate option and should be preceded by a '+' to indicate it should be
%added to the list of queried targets, e.g.,
%
ϻꤵ줿ץ bond ꤷޤBONDING_OPTS ǻꤵ줿ץ
ϡarp_ip_target եɤ bonding ⥸塼ѥ᡼ƱǤ
ƥåȤϸ̤ΥץȤƴޤ٤ǡ䤤碌륿åȤΥ
Ȥ˲ä򼨤٤ˡ'+' դ٤Ǥ㤨С

	arp_ip_target=+192.168.1.1 arp_ip_target=+192.168.1.2

%	is the proper syntax to specify multiple targets.  When specifying
%options via BONDING_OPTS, it is not necessary to edit /etc/modules.conf or
%/etc/modprobe.conf.
%
ʣΥåȤꤹ٤Ŭڤʽ񼰤ǤBONDING_OPTS 𤷤ץ
λ/etc/modules.conf ޤ /etc/modprobe.conf ԽɬפϤޤ
%
%	For older versions of initscripts that do not support
%BONDING_OPTS, it is necessary to edit /etc/modules.conf (or
%/etc/modprobe.conf, depending upon your distro) to load the bonding module
%with your desired options when the bond0 interface is brought up.  The
%following lines in /etc/modules.conf (or modprobe.conf) will load the
%bonding module, and select its options:
%
BONDING_OPTS 򥵥ݡȤʤ initscripts ΤŤСǤϡbond0 󥿡
եưݡʤ˾륪ץä bonding ⥸塼뤬
ɤ褦/etc/modules.conf(ޤ /etc/modprobe.confǥȥӥ塼
˰¸ޤ)Խɬפޤ/etc/modules.conf (뤤 
modprobe.conf) μιԤ bonding ⥸塼ɤΥץ
ޤ

alias bond0 bonding
options bond0 mode=balance-alb miimon=100

%	Replace the sample parameters with the appropriate set of
%options for your configuration.
%
ץѥ᡼򤢤ʤŬڤʥץΥåȤ֤Ʋ

%	Finally run "/etc/rc.d/init.d/network restart" as root.  This
%will restart the networking subsystem and your bond link should be now
%up and running.
%
Ǹˡroot ǡ/etc/rc.d/init.d/network restartפ¹ԤƤǥͥ
ȥ֥ƥƵưbond 󥯤ưƲƯޤ

%3.2.1 Using DHCP with Initscripts
%---------------------------------
%
3.2.1 initscripts ˤ DHCP λ
--------------------------------------

%	Recent versions of initscripts (the versions supplied with Fedora
%Core 3 and Red Hat Enterprise Linux 4, or later versions, are reported to
%work) have support for assigning IP information to bonding devices via
%DHCP.
%
initscripts κǶΥС(Fedora Core 3  Red Hat Enterprise Linux 4
ϰʹߤΥСư𤵤Ƥޤ) DHCP 𤷤 bonding ǥХ 
IP Ƥ٤ΥݡȤޤ

%	To configure bonding for DHCP, configure it as described
%above, except replace the line "BOOTPROTO=none" with "BOOTPROTO=dhcp"
%and add a line consisting of "TYPE=Bonding".  Note that the TYPE value
%is case sensitive.
%
DHCP Ѥ binding ꤹ뤿ˡBOOTPROTO=noneפBOOTPROTO=dhcpפ֤
ʳϾ嵭褦ꤷTYPE=BondingפޤԤɲäޤ
TYPE ͤ羮ʸ̤դƲ

%3.2.2 Configuring Multiple Bonds with Initscripts
%-------------------------------------------------
%
3.2.2 initscripts ˤʣ bond 
--------------------------------------------

%	Initscripts packages that are included with Fedora 7 and Red Hat
%Enterprise Linux 5 support multiple bonding interfaces by simply
%specifying the appropriate BONDING_OPTS= in ifcfg-bondX where X is the
%number of the bond.  This support requires sysfs support in the kernel,
%and a bonding driver of version 3.0.0 or later.  Other configurations may
%not support this method for specifying multiple bonding interfaces; for
%those instances, see the "Configuring Multiple Bonds Manually" section,
%below.
%
Fedora 7  Red Hat Enterprise Linux 5 ˴ޤޤƤ initscript ѥåϡ
ñ ifcfg-bondX (X  bond ֹ)Ŭڤ BONDING_OPTS= ꤹʣ 
bonding 󥿡ե򥵥ݡȤƤޤΥݡȤϥͥ sysfs 
ݡȤ bonding ɥ饤ХС 3.0.0 ʹߤɬפǤ¾δĶǤϡʣ
 bonding 󥿡եλˡ򥵥ݡȤƤޤ󡣢ξϡ
ҤΡּưǤʣ bond ׾Ϥ򻲾ȤƲ

%3.3 Configuring Bonding Manually with Ifenslave
%-----------------------------------------------
%
3.3 ifenslave ˤ bonding μư
-----------------------------------------

%	This section applies to distros whose network initialization
%scripts (the sysconfig or initscripts package) do not have specific
%knowledge of bonding.  One such distro is SuSE Linux Enterprise Server
%version 8.
%
Υϡͥåȥץ(sysconfig  initscripts ѥå
) bonding Ϣ򤬤ʤǥȥӥ塼ŬޤΤ褦ʥǥ
ȥӥ塼ΣĤ SuSE Linux Enterprise Server С 8 Ǥ

%	The general method for these systems is to place the bonding
%module parameters into /etc/modules.conf or /etc/modprobe.conf (as
%appropriate for the installed distro), then add modprobe and/or
%ifenslave commands to the system's global init script.  The name of
%the global init script differs; for sysconfig, it is
%/etc/init.d/boot.local and for initscripts it is /etc/rc.d/rc.local.
%
ΥƥǤΰŪˡϡbonding ⥸塼ѥ᡼ 
/etc/modules.conf ޤ /etc/modprobe.conf (󥹥ȡ뤷ǥȥӥ塼
Ŭڤ)֤줫 modprobe 뤤 ifenslave ޥɤ򥷥ƥ
Ū init ץȤ˵ҤǤŪ init ץȤ̾ϰۤʤ
sysconfig Ǥ /etc/init.d/boot.localinitscripts Ǥ /etc/rc.d/rc.local 
Ǥ

%	For example, if you wanted to make a simple bond of two e100
%devices (presumed to be eth0 and eth1), and have it persist across
%reboots, edit the appropriate file (/etc/init.d/boot.local or
%/etc/rc.d/rc.local), and add the following:
%
㤨С2 Ĥ e100 ǥХ(eth0eth1 Ȳꤷޤ)δñ bond 
ưФƤ³褦ˤ硢Ŭڤʥե(/etc/init.d/boot.local 
 /etc/rc.d/rc.local)Խɲäޤ

modprobe bonding mode=balance-alb miimon=100
modprobe e100
ifconfig bond0 192.168.1.1 netmask 255.255.255.0 up
ifenslave bond0 eth0
ifenslave bond0 eth1

%	Replace the example bonding module parameters and bond0
%network configuration (IP address, netmask, etc) with the appropriate
%values for your configuration.
%
 bonding ⥸塼ѥ᡼ bond0 ͥåȥ(IP ɥ쥹ͥ
ȥޥ)򤢤ʤŬڤ֤ͤƲ

%	Unfortunately, this method will not provide support for the
%ifup and ifdown scripts on the bond devices.  To reload the bonding
%configuration, it is necessary to run the initialization script, e.g.,
%
ˤˡ bond ǥХǤ ifup  ifdown ץȤΥݡȤ
ʤǤ礦bonding ɤ٤ˡץȤ¹Ԥɬ
ޤ㤨С

# /etc/init.d/boot.local

%	or
	ޤ

# /etc/rc.d/rc.local

%	It may be desirable in such a case to create a separate script
%which only initializes the bonding configuration, then call that
%separate script from within boot.local.  This allows for bonding to be
%enabled without re-running the entire global init script.
%
Τ褦ʥǡbonding νԤ̥ץȤθ
̥ץȤ boot.local ⤫ƤӽФǤޤǡŪ init 
ץΤƼ¹Ԥˡbonding ͭˤǤޤ

%	To shut down the bonding devices, it is necessary to first
%mark the bonding device itself as being down, then remove the
%appropriate device driver modules.  For our example above, you can do
%the following:
%
bonding ǥХߤ٤ˡǽ bonding ǥХΤ󤵤Ŭ
ڤʥǥХɥ饤Х⥸塼ɬפޤ嵭Ǥϡ̤
ԤǤޤ

# ifconfig bond0 down
# rmmod bonding
# rmmod e100

%	Again, for convenience, it may be desirable to create a script
%with these commands.
%
Ʊ͡صΰ٤ˡΥޥɤĥץȤǤޤ

%3.3.1 Configuring Multiple Bonds Manually
%-----------------------------------------
%
3.3.1 ưǤʣ bond 
--------------------------------

%	This section contains information on configuring multiple
%bonding devices with differing options for those systems whose network
%initialization scripts lack support for configuring multiple bonds.
%
ξϤǤϡͥåȥץȤʣ bond Ѥ򥵥ݡȤƤ
ƥΰ٤ˡۤʤ륪ץʣ bonding ǥХˤĤƤ
ޤǤޤ

%	If you require multiple bonding devices, but all with the same
%options, you may wish to use the "max_bonds" module parameter,
%documented above.
%
ʣ bonding ǥХ׵᤹뤬Ʊץľ硢嵭
max_bondsץ⥸塼ѥ᡼ѤƤ⹽ޤ

%	To create multiple bonding devices with differing options, it is
%preferrable to use bonding parameters exported by sysfs, documented in the
%section below.
%
ۤʤ륪ץʣ bonding ǥХ٤ˤϡsysfs ǥݡ
Ȥ줿 bonding ѥ᡼ѤޤǤ(ҤξϤǵ)
%
%	For versions of bonding without sysfs support, the only means to
%provide multiple instances of bonding with differing options is to load
%the bonding driver multiple times.  Note that current versions of the
%sysconfig network initialization scripts handle this automatically; if
%your distro uses these scripts, no special action is needed.  See the
%section Configuring Bonding Devices, above, if you're not sure about your
%network initialization scripts.
%
sysfs ݡȤΤʤ bonding ΥСǤϡۤʤ륪ץ bonding 
ʣ󥹥󥹤󶡤ͣˡ bonding ɥ饤ФʣɤǤ
ߤΥС sysconfig ͥåȥץȤϤưŪ˰
դƲʤΥǥȥӥ塼󤬤ΥץȤѤ
硢̤ʥɬפޤ󡣥ͥåȥץȤˤĤƤ褯
ʬʤ硢ҤΡbonding ǥХפ򻲾ȤƲ
%
%	To load multiple instances of the module, it is necessary to
%specify a different name for each instance (the module loading system
%requires that every loaded module, even multiple instances of the same
%module, have a unique name).  This is accomplished by supplying multiple
%sets of bonding options in /etc/modprobe.conf, for example:
%
ʣΥ⥸塼륤󥹥󥹤ɤ硢ƥ󥹥󥹤˰ۤʤ̾ꤹ
ɬפޤ(⥸塼ɥƥϡƱ⥸塼ʣ󥹥󥹤
ơɤ⥸塼˸̤̾׵ᤷޤ)ϡ
/etc/modprobe.conf  bonding ץʣå󶡤Ǽ¸ޤ
С

alias bond0 bonding
options bond0 -o bond0 mode=balance-rr miimon=100

alias bond1 bonding
options bond1 -o bond1 mode=balance-alb miimon=50

%	will load the bonding module two times.  The first instance is
%named "bond0" and creates the bond0 device in balance-rr mode with an
%miimon of 100.  The second instance is named "bond1" and creates the
%bond1 device in balance-alb mode with an miimon of 50.
%
 bonding ⥸塼򣲲ɤޤĤΥ󥹥󥹤 bond0 Ȥ̾
ǡbalance-rr ⡼ɡmiimon=100  bond0 ǥХޤĤΥ
󥹤 bond1 Ȥ̾ǡbalance-alb ⡼ɡmiimon=50  bond1 ǥХ
ޤ
%
%	In some circumstances (typically with older distributions),
%the above does not work, and the second bonding instance never sees
%its options.  In that case, the second options line can be substituted
%as follows:
%
ĤδĶ(ŵŪˤϸŤǥȥӥ塼)Ǥϡ嵭ưĤ 
bonding 󥹥󥹤ˤΥץ󤬷褷Ƹޤ󡣤ΥǤϡĤ
ץԤ򼡤Τ褦夨ޤ

install bond1 /sbin/modprobe --ignore-install bonding -o bond1 \
	mode=balance-alb miimon=50

%	This may be repeated any number of times, specifying a new and
%unique name in place of bond1 for each subsequent instance.
%
ϡġϢ³륤󥹥Ѥˡbond1 ξ˿̤̾ꤷ
顢Ǥ֤ⷫǤޤ
 
%	It has been observed that some Red Hat supplied kernels are unable
%to rename modules at load time (the "-o bond1" part).  Attempts to pass
%that option to modprobe will produce an "Operation not permitted" error.
%This has been reported on some Fedora Core kernels, and has been seen on
%RHEL 4 as well.  On kernels exhibiting this problem, it will be impossible
%to configure multiple bonds with differing parameters (as they are older
%kernels, and also lack sysfs support).
%
Ĥ Red Hat 󶡤Υͥϡ⥸塼Υɻ(-o bond1פʬ) 
̾ѤʤȸƤޤmodprobe ˤΥץϤߤ
Operation not permittedץ顼ޤϤĤ Fedora Core 
𤵤졢RHEL 4 ǤƱͤ˸ޤ꤬륫ͥǤϡۤ
ѥ᡼ʣ bond ꤹԲǽǤ(ͥ뤬Ťޤ 
sysfs ݡȤʤ)

%3.4 Configuring Bonding Manually via Sysfs
%------------------------------------------
%
3.4 sysfs ͳ bonding μư
-------------------------------------

%	Starting with version 3.0.0, Channel Bonding may be configured
%via the sysfs interface.  This interface allows dynamic configuration
%of all bonds in the system without unloading the module.  It also
%allows for adding and removing bonds at runtime.  Ifenslave is no
%longer required, though it is still supported.
%
С 3.0.0 顢ͥ sysfs 󥿡ե𤷤Ǥޤ
Υ󥿡եϡ⥸塼Υɤʤ˥ƥ bond ưŪ
꤬ޤϤޤ¹ bond ɲäȺǽǤifenslave Ϻ
ɬפޤ󤬡ǤޤݡȤƤޤ

%	Use of the sysfs interface allows you to use multiple bonds
%with different configurations without having to reload the module.
%It also allows you to use multiple, differently configured bonds when
%bonding is compiled into the kernel.
%
sysfs 󥿡եλѤˤꡢ⥸塼κƥɤɬפʤ˰ۤʤ
ʣ bond ѤǤޤϤޤͥȤ߹ߤ bonding 
뤵줿ݤ⡢ʣΰۤʤ bond ѤǤޤ

%	You must have the sysfs filesystem mounted to configure
%bonding this way.  The examples in this document assume that you
%are using the standard mount point for sysfs, e.g. /sys.  If your
%sysfs filesystem is mounted elsewhere, you will need to adjust the
%example paths accordingly.
%
ˡ bonding ꤹ٤ˤϡޥȤ줿 sysfs ե륷ƥबʤ
Фʤޤ󡣤ΥɥȤϡsysfs ɸŪʥޥȥݥȡĤޤ 
/sys ѤƤˤƤޤʤ sysfs ե륷ƥब̤ξ
˥ޥȤƤ硢Ŭ㼨Υѥ碌ɬפޤ

%Creating and Destroying Bonds
%-----------------------------
%
bond κ˲
-----------------
%
%To add a new bond foo:
%
 bondfooפɲá
%
# echo +foo > /sys/class/net/bonding_masters

%To remove an existing bond bar:
%
¸ bondbarפκ
%
# echo -bar > /sys/class/net/bonding_masters

%To show all existing bonds:
%
¸ bond ɽ
%
# cat /sys/class/net/bonding_masters

%NOTE: due to 4K size limitation of sysfs files, this list may be
%truncated if you have more than a few hundred bonds.  This is unlikely
%to occur under normal operating conditions.
%
աsysfs ե 4KB Υ¤ˤꡢɴʾ bond ˤ
ꥹȤڤͤ뤫Τޤ̾ǤϡϤۤȤɵ
Ǥ礦

%Adding and Removing Slaves
%--------------------------
%
졼֤ɲäȺ
--------------------
%	Interfaces may be enslaved to a bond using the file
%/sys/class/net/<bond>/bonding/slaves.  The semantics for this file
%are the same as for the bonding_masters file.
%
󥿡ե /sys/class/net/<bond>/bonding/slaves եȤä bond 
졼֤ˤޤΥեˡ bonding_masters եƱ
Ǥ

%To enslave interface eth0 to bond bond0:
%
󥿡ե eth0  bond (bond0) Υ졼ֲ
%
# ifconfig bond0 up
# echo +eth0 > /sys/class/net/bond0/bonding/slaves

%To free slave eth0 from bond bond0:
%
bond (bond0) 饹졼 eth0 
%
# echo -eth0 > /sys/class/net/bond0/bonding/slaves

%	When an interface is enslaved to a bond, symlinks between the
%two are created in the sysfs filesystem.  In this case, you would get
%/sys/class/net/bond0/slave_eth0 pointing to /sys/class/net/eth0, and
%/sys/class/net/eth0/master pointing to /sys/class/net/bond0.
%
󥿡ե bond Υ졼֤ˤʤݡĤδ֤Υܥå󥯤 sysfs 
ե륷ƥ˺ޤξ硢/sys/class/net/bond0/slave_eth0  
/sys/class/net/eth0 ؤ/sys/class/net/eth0/master  /sys/class/net/bond0 
ؤޤ

%	This means that you can tell quickly whether or not an
%interface is enslaved by looking for the master symlink.  Thus:
%
ϡ륤󥿡ե master ǥ쥯ȥΥܥåΥ
졼֤ɤ¨¤뤳Ȥ̣ޤäơ

# echo -eth0 > /sys/class/net/eth0/master/bonding/slaves

%will free eth0 from whatever bond it is enslaved to, regardless of
%the name of the bond interface.
%
ϡbond 󥿡ե̾˴ؤ餺eth0 졼֤ˤʤäƤ벿餫 
bond  eth0 ޤ

%Changing a Bond's Configuration
%-------------------------------
%
bond ѹ
-----------------
%	Each bond may be configured individually by manipulating the
%files located in /sys/class/net/<bond name>/bonding
%
/sys/class/net/<bond̾>/bonding ˤեǡ bond ̡
Ǥޤ

%	The names of these files correspond directly with the command-
%line parameters described elsewhere in this file, and, with the
%exception of arp_ip_target, they accept the same values.  To see the
%current setting, simply cat the appropriate file.
%
Υե̾ϡΥե̤ξޥɥ饤ѥ᡼
ľܰפơarp_ip_target ơƱͤդޤ
ߤ򸫤뤿ˤϡñŬڤʥե cat Ʋ

%	A few examples will be given here; for specific usage
%guidelines for each parameter, see the appropriate section in this
%document.
%
򤳤ǵ󤲤ޤ礦ƥѥ᡼Ѥλѥɥ饤ˤϡ
ΥɥȤŬڤʾϤ򸫤Ƥ

%To configure bond0 for balance-alb mode:
%
bond0  balance-alb ⡼ɤꡧ
%
# ifconfig bond0 down
# echo 6 > /sys/class/net/bond0/bonding/mode
%
% - or -
 - ޤ -
%
# echo balance-alb > /sys/class/net/bond0/bonding/mode

%	NOTE: The bond interface must be down before the mode can be
%changed.
%
աbond 󥿡եϥ⡼ɤѹ˥󤵤ƤʤФʤޤ


%To enable MII monitoring on bond0 with a 1 second interval:
%
bond0  MII ƻôֳ֤ͭ
%
# echo 1000 > /sys/class/net/bond0/bonding/miimon

%	NOTE: If ARP monitoring is enabled, it will disabled when MII
%monitoring is enabled, and vice-versa.
%
աARP ƻ뤬ͭʾ硢MII ƻͭˤݤ ARP ƻ̵ޤ
դƱͤǤ

%To add ARP targets:
%
ARP åȤɲá
%
# echo +192.168.0.100 > /sys/class/net/bond0/bonding/arp_ip_target
# echo +192.168.0.101 > /sys/class/net/bond0/bonding/arp_ip_target

%	NOTE:  up to 10 target addresses may be specified.
%
	ա 10 åȥɥ쥹Ǥޤ

%To remove an ARP target:
%
ARP åȤκ
%
# echo -192.168.0.100 > /sys/class/net/bond0/bonding/arp_ip_target

%Example Configuration
%---------------------
%

--------
%	We begin with the same example that is shown in section 3.3,
%executed with sysfs, and without using ifenslave.
%
sysfs Ȥifenslave ʤ 3.3 ϤǼΤƱǻϤƤߤޤ礦

%	To make a simple bond of two e100 devices (presumed to be eth0
%and eth1), and have it persist across reboots, edit the appropriate
%file (/etc/init.d/boot.local or /etc/rc.d/rc.local), and add the
%following:
%
e100 ǥХ(eth0,eth1 Ȳ)ñ bond Ƶư bond 
꤬³褦ˤ٤ˡŬڤʥե(/etc/init.d/boot.local ޤ 
/etc/rc.d/rc.local)Խɲäޤ

modprobe bonding
modprobe e100
echo balance-alb > /sys/class/net/bond0/bonding/mode
ifconfig bond0 192.168.1.1 netmask 255.255.255.0 up
echo 100 > /sys/class/net/bond0/bonding/miimon
echo +eth0 > /sys/class/net/bond0/bonding/slaves
echo +eth1 > /sys/class/net/bond0/bonding/slaves

%	To add a second bond, with two e1000 interfaces in
%active-backup mode, using ARP monitoring, add the following lines to
%your init script:
%
e1000 󥿡եĤǡactive-backup ⡼ɡARP ƻΣĤ bond 
ä٤ˡιԤ init ץȤɲäޤ

modprobe e1000
echo +bond1 > /sys/class/net/bonding_masters
echo active-backup > /sys/class/net/bond1/bonding/mode
ifconfig bond1 192.168.2.1 netmask 255.255.255.0 up
echo +192.168.2.100 /sys/class/net/bond1/bonding/arp_ip_target
echo 2000 > /sys/class/net/bond1/bonding/arp_interval
echo +eth2 > /sys/class/net/bond1/bonding/slaves
echo +eth3 > /sys/class/net/bond1/bonding/slaves


%4. Querying Bonding Configuration 
%=================================
%
4. bonding γǧ
=====================

%4.1 Bonding Configuration
%-------------------------
%
4.1 bonding 
------------------

%	Each bonding device has a read-only file residing in the
%/proc/net/bonding directory.  The file contents include information
%about the bonding configuration, options and state of each slave.
%
 bonding ǥХˤ /proc/net/bonding ǥ쥯ȥ֤ɤ߼ѤΥե
뤬ޤΥեƤ bonding ꡢץ󡢳ƥ졼֤ξ
˴ؤޤǤޤ

%	For example, the contents of /proc/net/bonding/bond0 after the
%driver is loaded with parameters of mode=0 and miimon=1000 is
%generally as follows:
%
㤨Сmode=0, miimon=1000 Υѥ᡼ǥɥ饤Фɤ줿塢
/proc/net/bonding/bond0 Ƥϰ̤˼Τ褦ˤʤޤ

	Ethernet Channel Bonding Driver: 2.6.1 (October 29, 2004)
        Bonding Mode: load balancing (round-robin)
        Currently Active Slave: eth0
        MII Status: up
        MII Polling Interval (ms): 1000
        Up Delay (ms): 0
        Down Delay (ms): 0

        Slave Interface: eth1
        MII Status: up
        Link Failure Count: 1

        Slave Interface: eth0
        MII Status: up
        Link Failure Count: 1

%	The precise format and contents will change depending upon the
%bonding configuration, state, and version of the bonding driver.
%
ΤʥեޥåȤƤ bonding ꡢ֡bonding ɥ饤ФΥС
¸Ѳޤ

%4.2 Network configuration
%-------------------------
%
4.2 ͥåȥ
----------------------

%	The network configuration can be inspected using the ifconfig
%command.  Bonding devices will have the MASTER flag set; Bonding slave
%devices will have the SLAVE flag set.  The ifconfig output does not
%contain information on which slaves are associated with which masters.
%
ͥåȥ ifconfig ޥɤȤäĴ٤ޤbonding ǥХˤ 
MASTER ե饰åȤޤbonding 졼֥ǥХˤ SLAVE ե饰å
ޤifconfig ϤˤϤɤΥ졼֤ɤΥޥ˴Ϣ뤫ξ󤬴ޤ
Ƥޤ

%	In the example below, the bond0 interface is the master
%(MASTER) while eth0 and eth1 are slaves (SLAVE). Notice all slaves of
%bond0 have the same MAC address (HWaddr) as bond0 for all modes except
%TLB and ALB that require a unique MAC address for each slave.
%
Ǥϡbond0 󥿡եϥޥ(MASTER)ǡ eth0  eth1 ϥ
졼(SLAVE)Ǥbond0 졼֤ϡƥ졼֤ȼ MAC ɥ쥹ɬפ
 TLB  ALB ʳƤΥ⡼ɤ bond0 Ʊ MAC ɥ쥹(HWaddr) Ļ
դƲ

# /sbin/ifconfig
bond0     Link encap:Ethernet  HWaddr 00:C0:F0:1F:37:B4
          inet addr:XXX.XXX.XXX.YYY  Bcast:XXX.XXX.XXX.255  Mask:255.255.252.0
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
          RX packets:7224794 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3286647 errors:1 dropped:0 overruns:1 carrier:0
          collisions:0 txqueuelen:0

eth0      Link encap:Ethernet  HWaddr 00:C0:F0:1F:37:B4
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:3573025 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1643167 errors:1 dropped:0 overruns:1 carrier:0
          collisions:0 txqueuelen:100
          Interrupt:10 Base address:0x1080

eth1      Link encap:Ethernet  HWaddr 00:C0:F0:1F:37:B4
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:3651769 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1643480 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          Interrupt:9 Base address:0x1400

%5. Switch Configuration
%=======================
%
5. å
=================

%	For this section, "switch" refers to whatever system the
%bonded devices are directly connected to (i.e., where the other end of
%the cable plugs into).  This may be an actual dedicated switch device,
%or it may be another regular system (e.g., another computer running
%Linux),
%
ΥǤϡ֥åפbond 줿ǥХľ³줿(Ĥޤꡢ
֥Τ⤦ü³줿)ɤʥƥˤطޤϼº³
줿ǥХΤޤ󤷡¾̾亮ƥ(㤨СLinux ưƤ̤
ԥ塼)Τޤ

%	The active-backup, balance-tlb and balance-alb modes do not
%require any specific configuration of the switch.
%
active-backupbalance-tlbbalance-alb ⡼ɤϥå̤ɬפȤ


%	The 802.3ad mode requires that the switch have the appropriate
%ports configured as an 802.3ad aggregation.  The precise method used
%to configure this varies from switch to switch, but, for example, a
%Cisco 3550 series switch requires that the appropriate ports first be
%grouped together in a single etherchannel instance, then that
%etherchannel is set to mode "lacp" to enable 802.3ad (instead of
%standard EtherChannel).
%
802.3ad ⡼ɤϡå 802.3ad ȤŬڤʥݡäƤ
׵ᤷޤꤹ٤˻ѤΤˡϥå˰ۤʤޤ㤨
СCisco 3550 ꡼Υåϡǽñ쥤ͥ륤󥹥󥹤˰
˥롼ײ졢줫餳Υͥ뤬(ɸΥͥ)
802.3adͭˤ뤿ˡlacpץ⡼ɤꤵ׵ᤷޤ

%	The balance-rr, balance-xor and broadcast modes generally
%require that the switch have the appropriate ports grouped together.
%The nomenclature for such a group differs between switches, it may be
%called an "etherchannel" (as in the Cisco example, above), a "trunk
%group" or some other similar variation.  For these modes, each switch
%will also have its own configuration options for the switch's transmit
%policy to the bond.  Typical choices include XOR of either the MAC or
%IP addresses.  The transmit policy of the two peers does not need to
%match.  For these three modes, the bonding mode really selects a
%transmit policy for an EtherChannel group; all three will interoperate
%with another EtherChannel group.
%
balance-rrbalance-xorbroadcast ⡼ɤϰ̤ˡå롼ײ줿Ŭ
ڤʥݡȷĻ׵ᤷޤΤ褦ʥ롼פѸϥå֤ǰۤ
ޤ(嵭 Cisco ˤ褦)֥ͥ(etherchannel)פȸƤ
뤫Τޤ󤷡֥ȥ󥯥롼(trunk group)פ뤤¾β餫λ
褦ʥХꥨǸƤФ뤫Τޤ󡣤Υ⡼ɤǤϡbond ؤΥ
̿ݥꥷΰ٤ˡƥåˤȼꥪץ󤬤ޤŵŪ
 MAC ޤ IP ɥ쥹Τɤ餫¾¤ޤޤޤξü̿ݥꥷ
ϰפɬפޤ󡣤飳ĤΥ⡼ɤǤϡbonding ⡼ɤϼºݤ˥
ͥ륰롼Ѥžݥꥷ򤷤ޤƤ¾Υͥ륰롼
פߺѤޤ


%6. 802.1q VLAN Support
%======================
%
6. 802.1q VLAN ݡ
=======================

%	It is possible to configure VLAN devices over a bond interface
%using the 8021q driver.  However, only packets coming from the 8021q
%driver and passing through bonding will be tagged by default.  Self
%generated packets, for example, bonding's learning packets or ARP
%packets generated by either ALB mode or the ARP monitor mechanism, are
%tagged internally by bonding itself.  As a result, bonding must
%"learn" the VLAN IDs configured above it, and use those IDs to tag
%self generated packets.
%
8021q ɥ饤ФѤ bond 󥿡եۤ VLAN ǥХꤹ
ޤʤ顢8021q ɥ饤Ф bonding ̤äѥåȤΤߡǥե
ȤǥŤޤѥå(㤨СALB ⡼ɤ ARP ƻ뵡
줫줿 bonding γؽѥåȤ ARP ѥå) bonding ȤǤ
ǥŤޤ󡣤η̡bonding Ϥξꤵ줿 VLAN ID ֳؽ
ʤФʤ餺ѥåȤ򥿥Ť뤿ˤ ID Ѥ
Фʤޤ

%	For reasons of simplicity, and to support the use of adapters
%that can do VLAN hardware acceleration offloading, the bonding
%interface declares itself as fully hardware offloading capable, it gets
%the add_vid/kill_vid notifications to gather the necessary
%information, and it propagates those actions to the slaves.  In case
%of mixed adapter types, hardware accelerated tagged packets that
%should go through an adapter that is not offloading capable are
%"un-accelerated" by the bonding driver so the VLAN tag sits in the
%regular location.
%
ñͳΰ١ VLAN ϡɥ졼󥪥եǥ󥰢
륢ץλѤ򥵥ݡȤ١bonding 󥿡եϴ˥ϡɥ
եǥбȤƤ켫ȤƤꡢɬפʾ򽸤뤿 
add_vid/kill_vid Τꡢ졼֤ˤΥ򹭤ޤ
ΥפξǤϡեǥ󥰤бƤʤץ̲ᤷϡ
ɥǥ졼󤵤줿ĤѥåȤϡbonding ɥ饤Фǡ֥
졼󤵤ʤפΤǤꡢVLAN ̾ΰ֤Τޤޤˤʤޤ

VLAN Υץȥΰͥåȥ󥿡ե(ϡ
ɥ)¦ǹԤ

%	VLAN interfaces *must* be added on top of a bonding interface
%only after enslaving at least one slave.  The bonding interface has a
%hardware address of 00:00:00:00:00:00 until the first slave is added.
%If the VLAN interface is created prior to the first enslavement, it
%would pick up the all-zeroes hardware address.  Once the first slave
%is attached to the bond, the bond device itself will pick up the
%slave's hardware address, which is then available for the VLAN device.
%
VLAN 󥿡եϡʤƤ⣱ĤΥ졼֤򥹥졼ֲǤΤ 
bonding 󥿡եΰ־ɲäʤС֤ʤޤסbonding 󥿡
եϡǽΥ졼֤ɲäޤǡϡɥɥ쥹 00:00:00:00:00:00 
äƤޤǽΥ졼ֲ VLAN 󥿡ե줿硢
VLAN 󥿡ե 0 Υϡɥɥ쥹򽦤äƤޤޤöǽ
Υ졼֤ bond ˲äȡbond ǥХȤϤΥ졼֤Υϡɥ
쥹򽦤줬θ VLAN ǥХΤΤȤѤǤޤ

%	Also, be aware that a similar problem can occur if all slaves
%are released from a bond that still has one or more VLAN interfaces on
%top of it.  When a new slave is added, the bonding interface will
%obtain its hardware address from the first slave, which might not
%match the hardware address of the VLAN interfaces (which was
%ultimately copied from an earlier slave).
%
ޤbond 󥿡եΰ־ˣĤ뤤ʣ VLAN 󥿡ե
ޤ֤ǡƤΥ졼֤ bond 鳫줿硢Ʊ꤬ͤꤦ
ռƤ졼֤ɲäȡbonding 󥿡եϺ
Υ졼֤ϡɥɥ쥹ޤ VLAN 󥿡ե
ϡɥɥ쥹(ɤΤȤΥ졼֤饳ԡ줿ΤǤ)Ȥϰ
פޤ

%	There are two methods to insure that the VLAN device operates
%with the correct hardware address if all slaves are removed from a
%bond interface:
%
Ĥ bond 󥿡եƤΥ졼֤줿硢VLAN ǥХ
Ŭڤʥϡɥɥ쥹򰷤ݾڤˡĤޤ

%	1. Remove all VLAN interfaces then recreate them
%
	1. Ƥ VLAN 󥿡եƺ

%	2. Set the bonding interface's hardware address so that it
%matches the hardware address of the VLAN interfaces.
%
	2. VLAN 󥿡եΥϡɥɥ쥹˰פ褦 bonding 
󥿡եΥϡɥɥ쥹ꤹ롣

%	Note that changing a VLAN interface's HW address would set the
%underlying device -- i.e. the bonding interface -- to promiscuous
%mode, which might not be what you want.
%
VLAN 󥿡եΥϡɥɥ쥹ѹϡΥǥХݤĤ
 bonding 󥿡եݤ(ʤ˾ޤʤ⤷ʤ) ץߥ⡼
ꤹդƲ


%7. Link Monitoring
%==================
%
7. 󥯴ƻ
=============

%	The bonding driver at present supports two schemes for
%monitoring a slave device's link state: the ARP monitor and the MII
%monitor.
%
ߤ bonding ɥ饤Фϥ졼֥ǥХΥ󥯾֤ƻ뤹򣲤ĥݡ
ȤƤޤARP ƻ MII ƻǤ

%	At the present time, due to implementation restrictions in the
%bonding driver itself, it is not possible to enable both ARP and MII
%monitoring simultaneously.
%
Ǥϡbonding ɥ饤мΤμ¤ΰ١ARP ƻ MII ƻƱ
ͭˤϽޤ

%7.1 ARP Monitor Operation
%-------------------------
%
7.1 ARP ƻ
----------------

%	The ARP monitor operates as its name suggests: it sends ARP
%queries to one or more designated peer systems on the network, and
%uses the response as an indication that the link is operating.  This
%gives some assurance that traffic is actually flowing to and from one
%or more peers on the local network.
%
ARP ƻϤ̾褦˺ưޤ󥯤ưƤ򼨤٤ˡͥ
ȥΣĤޤʣλꤵ줿оݥƥ ARP 䤤碌
󥯤ưƤ򼨤 ARP Ȥޤˤꡢͥåȥ
ΣĤ뤤ʣоݤء̿ºݤήƤμ¤ˤʤޤ

%	The ARP monitor relies on the device driver itself to verify
%that traffic is flowing.  In particular, the driver must keep up to
%date the last receive time, dev->last_rx, and transmit start time,
%dev->trans_start.  If these are not updated by the driver, then the
%ARP monitor will immediately fail any slaves using that driver, and
%those slaves will stay down.  If networking monitoring (tcpdump, etc)
%shows the ARP requests and replies on the network, then it may be that
%your device driver is not updating last_rx and trans_start.
%
ARP ƻϡ̿ήƤ򸡾ڤ٤ˡǥХɥ饤мΤ˰¸Ƥ
äˡɥ饤ФǸ˼λ(dev->last_rx)򳫻Ϥ
(dev->trans_start)ݻʤФʤޤ󡣤餬ɥ饤Фˤäƹ
硢ARP ƻϤΥɥ饤ФѤƤ륹졼֤Ϥɤ¨¤˼Ԥ
Υ졼֤ϥ֤Τޤޤˤʤޤͥåȥƻ(tcpdump )ͥåȥ
 ARP ׵ȱɽ硢ǥХɥ饤Ф last_rc  trans_start 
򹹿Ƥʤǽޤ

%7.2 Configuring Multiple ARP Targets
%------------------------------------
%
7.2 ʣ ARP åȤ
-------------------------------

%	While ARP monitoring can be done with just one target, it can
%be useful in a High Availability setup to have several targets to
%monitor.  In the case of just one target, the target itself may go
%down or have a problem making it unresponsive to ARP requests.  Having
%an additional target (or several) increases the reliability of the ARP
%monitoring.
%
ARP ƻ뤬ñ쥿åȤǼ»ܲǽǤ ARP ƻʣΥ
åȤĤ褦ˤǤñ쥿åȤξ硢åȼΤ
 ARP ׵˱Ǥʤʤ꤬뤫Τޤ1(뤤ʣ)
äΥåȤϡARP ƻο夷ޤ

%	Multiple ARP targets must be separated by commas as follows:
%
ʣ ARP åȤϼΤ褦˥ޤǶڤʤФʤޤ	

# example options for ARP monitoring with three targets
alias bond0 bonding
options bond0 arp_interval=60 arp_ip_target=192.168.0.1,192.168.0.3,192.168.0.9

%	For just a single target the options would resemble:
%
ñ쥿åȤǤϡץϻ褦ʤΤˤʤޤ

# example options for ARP monitoring with one target
alias bond0 bonding
options bond0 arp_interval=60 arp_ip_target=192.168.0.100


%7.3 MII Monitor Operation
%-------------------------
%
7.3 MII ƻ
----------------

%	The MII monitor monitors only the carrier state of the local
%network interface.  It accomplishes this in one of three ways: by
%depending upon the device driver to maintain its carrier state, by
%querying the device's MII registers, or by making an ethtool query to
%the device.
%
MII ƻϥΥͥåȥ󥿡եΥꥢ֤Τߴƻ뤷ޤ
ϣĤˡΤ줫Ǽ»ܤޤꥢ֤δǥХɥ饤Ф
¸ˡǥХ MII 쥸䤤碌Ԥˡethtool 䤤碌
ǥХ˹ԤˡǤ

%	If the use_carrier module parameter is 1 (the default value),
%then the MII monitor will rely on the driver for carrier state
%information (via the netif_carrier subsystem).  As explained in the
%use_carrier parameter information, above, if the MII monitor fails to
%detect carrier loss on the device (e.g., when the cable is physically
%disconnected), it may be that the driver does not support
%netif_carrier.
%
use_carrier ⥸塼ѥ᡼(ǥե)ξ硢MII ƻϥꥢ
ΰ٤(netif_carrier ֥ƥ𤷤)ɥ饤Фޤ嵭 
user_carrier ѥ᡼̤ꡢMII ƻ뤬ǥХΥꥢθ
Τ˼Ԥ(㤨С֥뤬ʪŪǤ줿)ɥ饤Ф 
netif_carrier 򥵥ݡȤʤΤޤ

%	If use_carrier is 0, then the MII monitor will first query the
%device's (via ioctl) MII registers and check the link state.  If that
%request fails (not just that it returns carrier down), then the MII
%monitor will make an ethtool ETHOOL_GLINK request to attempt to obtain
%the same information.  If both methods fail (i.e., the driver either
%does not support or had some error in processing both the MII register
%and ethtool requests), then the MII monitor will assume the link is
%up.
%
user_carrier  0 ξ硢MII ƻϺǽ(ioctl ͳ)ǥХ MII 쥸
䤤碌󥯾֤åޤ׵᤬Ԥ(ñ˥ꥢ
֤ΤȤϰۤʤ)MII ƻƱ褦Ȥ ethtool ETHOOL_GLINK 
׵ԤޤξˡȤ⼺Ԥ(Ĥޤꡢɥ饤Ф MII 쥸 
ethtool ꥯȤξν򥵥ݡȤʤ餫Υ顼ȯ)
MII ƻϥ󥯤åפƤΤȲꤷޤ

%8. Potential Sources of Trouble
%===============================
%
8. Ū긻
=================

%8.1 Adventures in Routing
%-------------------------
%
8.1 롼ƥ󥰤Ǥ
------------------------

%	When bonding is configured, it is important that the slave
%devices not have routes that supersede routes of the master (or,
%generally, not have routes at all).  For example, suppose the bonding
%device bond0 has two slaves, eth0 and eth1, and the routing table is
%as follows:
%
bonding ꤵ줿硢졼֥ǥХޥΥ롼Ȥ촹롼Ȥ
Ƥʤ(뤤ϡ̤˲롼ȤäƤʤ)פǤ㤨Сbonding 
ǥХ bond0 ĤΥ졼 eth0, eth1 롼ƥ󥰥ơ֥뤬Τ
ʾ֤ꤷޤ

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
10.0.0.0        0.0.0.0         255.255.0.0     U        40 0          0 eth0
10.0.0.0        0.0.0.0         255.255.0.0     U        40 0          0 eth1
10.0.0.0        0.0.0.0         255.255.0.0     U        40 0          0 bond0
127.0.0.0       0.0.0.0         255.0.0.0       U        40 0          0 lo

%	This routing configuration will likely still update the
%receive/transmit times in the driver (needed by the ARP monitor), but
%may bypass the bonding driver (because outgoing traffic to, in this
%case, another host on network 10 would use eth0 or eth1 before bond0).
%
Υ롼ƥ(ARP ƻɬפ)ɥ饤Фμ/ˤޤ줽
Ǥbonding ɥ饤Ф򱪲󤹤뤫Τޤ(ʤʤ顢ξ硢ͥåȥ
 10 ̤ΥۥȤؤγԤ bond0  eth0 ޤ eth1 ȤΤ)

%	The ARP monitor (and ARP itself) may become confused by this
%configuration, because ARP requests (generated by the ARP monitor)
%will be sent on one interface (bond0), but the corresponding reply
%will arrive on a different interface (eth0).  This reply looks to ARP
%as an unsolicited ARP reply (because ARP matches replies on an
%interface basis), and is discarded.  The MII monitor is not affected
%by the state of the routing table.
%
ARP ƻ( ARP )ϤǤϺ𤹤뤫⤷ޤ󡣤ʤʤ(ARP ƻ
줿) ARP ׵᤬ĤΥ󥿡ե(bond0)ޤ
ϰۤʤ륤󥿡ե(eth0)Ϥޤαϡ(ARP ϥ󥿡ե١
ǱޥåΤ)׵ᤵƤʤ ARP Ȥ ARP ˸졢˴
ޤMII ƻϥ롼ƥ󥰥ơ֥ξ֤˱ƶޤ

%	The solution here is simply to insure that slaves do not have
%routes of their own, and if for some reason they must, those routes do
%not supersede routes of their master.  This should generally be the
%case, but unusual configurations or errant manual or automatic static
%route additions may cause trouble.
%
βˡñ˥졼֤ȤΥ롼Ȥʤݾڤǡ餫λ
ǥ롼ƥ󥰤ɬפʾ硢Υ롼ȤޥΥ롼Ȥ˼äʤ
ˤޤ̤Ϥξ֤ˤʤϤǤ̾Ǥʤְäư⤷
ưŪŪ롼ɲäϡȥ֥Τޤ

%8.2 Ethernet Device Renaming
%----------------------------
%
8.2 ͥåȥǥХ̾ѹ
----------------------------------

%	On systems with network configuration scripts that do not
%associate physical devices directly with network interface names (so
%that the same physical device always has the same "ethX" name), it may
%be necessary to add some special logic to either /etc/modules.conf or
%/etc/modprobe.conf (depending upon which is installed on the system).
%
ʪǥХľܥͥåȥ󥿡ե̾˴Ϣդ(ƱʪǥХ
ƱethX̾ˤʤ)ȤʤͥåȥꥹץȤΥƥǤϡ
/etc/modules.conf ޤ /etc/modprobe.conf (ƥ˥󥹥ȡ뤵줿Τ
¸ޤ)Τɤ餫˲餫̤ʥåɲäɬפ뤫Τޤ

%	For example, given a modules.conf containing the following:
%
㤨Сޤ modules.conf Ϳ줿硧

alias bond0 bonding
options bond0 mode=some-mode miimon=50
alias eth0 tg3
alias eth1 tg3
alias eth2 e1000
alias eth3 e1000

%	If neither eth0 and eth1 are slaves to bond0, then when the
%bond0 interface comes up, the devices may end up reordered.  This
%happens because bonding is loaded first, then its slave device's
%drivers are loaded next.  Since no other drivers have been loaded,
%when the e1000 driver loads, it will receive eth0 and eth1 for its
%devices, but the bonding configuration tries to enslave eth2 and eth3
%(which may later be assigned to the tg3 devices).
%
eth0eth1 Τɤ bond0 Υ졼֤Ǥʤ硢bond0 󥿡եư
ݡǥХֹ椬¤ؤäƤޤΤޤ󡣤ϡbonding ǽ
ɤ߹ޤ졢ˤΥ졼֥ǥХΥɥ饤Фɤˤޤ¾Υ
饤Фɤˡe1000 ɥ饤Фɤ줿硢ΥǥХ eth0
eth1 Ϳޤbonding  eth2  eth3 (ϸۤ tg3 ǥХ
Ϳޤ)򥹥졼֤ˤ褦Ȥޤ

%	Adding the following:
%
ɲäϡ

add above bonding e1000 tg3

%	causes modprobe to load e1000 then tg3, in that order, when
%bonding is loaded.  This command is fully documented in the
%modules.conf manual page.
%
bonding ɤݡe1000 ɤƤ tg3 ɤ褦(ν
) modprobe ˻ؼޤΥޥɤ modules.conf ޥ˥奢ڡǴ
ʸ񲽤Ƥޤ

%	On systems utilizing modprobe.conf (or modprobe.conf.local),
%an equivalent problem can occur.  In this case, the following can be
%added to modprobe.conf (or modprobe.conf.local, as appropriate), as
%follows (all on one line; it has been split here for clarity):
%
modprobe.conf (ޤ modprobe.conf.local)Ѥ륷ƥǤϡƱ꤬ͤ
ޤξ硢Τ褦(ƣԤǢǤŪʬ䤷Ƥޤ)
modprobe.conf (ޤ modprobe.conf.localŬڤ)ɲäǤޤ

install bonding /sbin/modprobe tg3; /sbin/modprobe e1000;
	/sbin/modprobe --ignore-install bonding

%	This will, when loading the bonding module, rather than
%performing the normal action, instead execute the provided command.
%This command loads the device drivers in the order needed, then calls
%modprobe with --ignore-install to cause the normal action to then take
%place.  Full documentation on this can be found in the modprobe.conf
%and modprobe manual pages.
%
ˤꡢbonding ⥸塼ɤݡ̾ưԤΤǤϤʤ
Ϳ줿ޥɤ¹ԤޤΥޥɤϥǥХɥ饤Фɬפʽǥ
ɤ줫̾ΥԤ٤ --ignore-install դ modprobe 򥳡
뤷ޤδʥɥ modprobe.conf  modprobe Υޥ˥奢ڡ
ޤ

%8.3. Painfully Slow Or No Failed Link Detection By Miimon
%---------------------------------------------------------
%
8.3. miimon ˤỴ٤ 뤤 󥯼ԸΤ
--------------------------------------------------------

%	By default, bonding enables the use_carrier option, which
%instructs bonding to trust the driver to maintain carrier state.
%
ǥեȤǤϡbonding  use_carrier ץͭˤˤꥭꥢ
֤Τ˥ɥ饤ФѤ褦 bonding ˻ؼޤ

%	As discussed in the options section, above, some drivers do
%not support the netif_carrier_on/_off link state tracking system.
%With use_carrier enabled, bonding will always see these links as up,
%regardless of their actual state.
%
嵭ץξϤǵ褦ˡĤΥɥ饤Ф netif_carrier_on/_off 
󥯾ץƥ򥵥ݡȤƤޤuse_carrier ͭˤȡºݤ
󥯾֤˴ؤ餺bonding ϾˤΥ󥯤åפƤȸޤ

%	Additionally, other drivers do support netif_carrier, but do
%not maintain it in real time, e.g., only polling the link state at
%some fixed interval.  In this case, miimon will detect failures, but
%only after some long period of time has expired.  If it appears that
%miimon is very slow in detecting link failures, try specifying
%use_carrier=0 to see if that improves the failure detection time.  If
%it does, then it may be that the driver checks the carrier state at a
%fixed interval, but does not cache the MII register values (so the
%use_carrier=0 method of querying the registers directly works).  If
%use_carrier=0 does not improve the failover, then the driver may cache
%the registers, or the problem may be elsewhere.
%
äơ¾Υɥ饤Ф netif_carrier 򥵥ݡȤ뤬ꥢ륿Ǵ
ʤޤ(㤨С餫θֳ֤ǥ󥯾֤ݡ󥰤Τ)
ξ硢miimon ϼԤΤޤ餫Ĺ֤ĶᤷǤΤߤˤʤ
󥯼ԤθΤ miimon ٤褦˻פ硢use_carrier=0 
ꤷƤԸλ֤뤫Ƥ⤷ʤ顢ɥ饤Ф
ꥢֳ֤֤ǥåƤޤMII 쥸ͤ򥭥å夷Ƥ
(äơ쥸ľ䤤碌 use_carrier=0 ˡǽޤ)Τ
use_carrier=0 ե륪Фʤ硢ɥ饤Фϥ쥸򥭥
夷Ƥ뤫¾Τɤ꤬ޤ

%	Also, remember that miimon only checks for the device's
%carrier state.  It has no way to determine the state of devices on or
%beyond other ports of a switch, or if a switch is refusing to pass
%traffic while still maintaining carrier on.
%
ޤmiimon ǥХΥꥢ֤ΤߥåФƤƲ
å¾ΥݡȾ夢뤤ϸΥǥХξ֤ʤΤ뤤ϥå
ꥢδ̿ϤݤƤ礫ȽǤˡϤ
ޤ

%9. SNMP agents
%===============
%
9. SNMP 
====================

%	If running SNMP agents, the bonding driver should be loaded
%before any network drivers participating in a bond.  This requirement
%is due to the interface index (ipAdEntIfIndex) being associated to
%the first interface found with a given IP address.  That is, there is
%only one ipAdEntIfIndex for each IP address.  For example, if eth0 and
%eth1 are slaves of bond0 and the driver for eth0 is loaded before the
%bonding driver, the interface for the IP address will be associated
%with the eth0 interface.  This configuration is shown below, the IP
%address 192.168.1.1 has an interface index of 2 which indexes to eth0
%in the ifDescr table (ifDescr.2).
%
SNMP Ȥ¹ԤƤ硢餫Υͥåȥɥ饤Ф bond ˻
 bonding ɥ饤ФɤƤʤФʤޤ󡣤׷ϡͿ
줿 IP ɥ쥹ΤǽΥ󥿡եϢդ륤󥿡ե
ǥå(ipAdEntIfIndex)ΰ٤Ǥϡ IP ɥ쥹Ѥͣ 
ipAdEntIfIndex ȤǤ㤨Сeth0  eth1  bond0 Υ졼֤Ǥ
ꡢeth0 Υɥ饤Ф bonding ɥ饤Ф˥ɤ硢 IP ɥ쥹
٤Υ󥿡ե eth0 󥿡ե˴Ϣդޤϰʲ
褦˼졢IP ɥ쥹 192.168.1.1 ϡifDesc ơ֥ eth0  ID
(ifDescr.2) Ǥ륤󥿡եǥå 2 ֤ޤ

     interfaces.ifTable.ifEntry.ifDescr.1 = lo
     interfaces.ifTable.ifEntry.ifDescr.2 = eth0
     interfaces.ifTable.ifEntry.ifDescr.3 = eth1
     interfaces.ifTable.ifEntry.ifDescr.4 = eth2
     interfaces.ifTable.ifEntry.ifDescr.5 = eth3
     interfaces.ifTable.ifEntry.ifDescr.6 = bond0
     ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.10.10.10 = 5
     ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.192.168.1.1 = 2
     ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.74.20.94 = 4
     ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.127.0.0.1 = 1

%	This problem is avoided by loading the bonding driver before
%any network drivers participating in a bond.  Below is an example of
%loading the bonding driver first, the IP address 192.168.1.1 is
%correctly associated with ifDescr.2.
%
 bond ˻äɤΥͥåȥɥ饤Ф bonding ɥ饤Ф
ɤǲǤޤ bonding ɥ饤Фǽ˥ɤǡIP ɥ
 192.168.1.1 Ŭڤ ifDescr.2 ˳ƤƤޤ

     interfaces.ifTable.ifEntry.ifDescr.1 = lo
     interfaces.ifTable.ifEntry.ifDescr.2 = bond0
     interfaces.ifTable.ifEntry.ifDescr.3 = eth0
     interfaces.ifTable.ifEntry.ifDescr.4 = eth1
     interfaces.ifTable.ifEntry.ifDescr.5 = eth2
     interfaces.ifTable.ifEntry.ifDescr.6 = eth3
     ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.10.10.10 = 6
     ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.192.168.1.1 = 2
     ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.74.20.94 = 5
     ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.127.0.0.1 = 1

%	While some distributions may not report the interface name in
%ifDescr, the association between the IP address and IfIndex remains
%and SNMP functions such as Interface_Scan_Next will report that
%association.
%
ĤΥǥȥӥ塼 ifDescr Υ󥿡ե̾𤵤ʤ
Τޤ󤬡 IP ɥ쥹 IfIndex ֤δطϻĤꡢInterface_Scan_Next 
Τ褦 SNMP ǽϤδط𤷤ޤ

%10. Promiscuous mode
%====================
%
10. Promiscuous ⡼
======================

%	When running network monitoring tools, e.g., tcpdump, it is
%common to enable promiscuous mode on the device, so that all traffic
%is seen (instead of seeing only traffic destined for the local host).
%The bonding driver handles promiscuous mode changes to the bonding
%master device (e.g., bond0), and propagates the setting to the slave
%devices.
%
ͥåȥƻġ(㡧tcpdump)μ¹Ի̤˥ǥХ promiscuous ⡼
ɤͭˤʤꡢˤä(ۥȤ˸äƤ̿Τ߸) 
Ƥ̿ޤbonding ɥ饤Ф bonding ޥǥХ(㡧bond0) 
promiscuous ⡼ɤѹ򰷤졼֥ǥХ˹ޤ

%	For the balance-rr, balance-xor, broadcast, and 802.3ad modes,
%the promiscuous mode setting is propagated to all slaves.
%
balance-rrbalance-xorbroadcast802.3ad ⡼ɤǤϡpromiscuous ⡼
ƤΥ졼֤˹ޤ

%	For the active-backup, balance-tlb and balance-alb modes, the
%promiscuous mode setting is propagated only to the active slave.
%
active-backupbalance-tlbbalance-alb ⡼ɤǤϡpromiscuous ⡼ϥ
ƥ֤ʥ졼֤ˤΤ߹ޤ

%	For balance-tlb mode, the active slave is the slave currently
%receiving inbound traffic.
%
balance-tlb ⡼ɤǤϡƥ֤ʥ졼֤ϸ̿Ƥ륹졼
֤ˤʤޤ

%	For balance-alb mode, the active slave is the slave used as a
%"primary."  This slave is used for mode-specific control traffic, for
%sending to peers that are unassigned or if the load is unbalanced.
%
balance-alb ⡼ɤǤϡƥ֥졼֤ϡ֣֤(primary)פȤƻѤ
졼֤ǤΥ졼֤ϡ̤Ƥ̿оݤؤ̿٤Զʾ
Υ⡼ɸͭ̿˻Ѥޤ

%	For the active-backup, balance-tlb and balance-alb modes, when
%the active slave changes (e.g., due to a link failure), the
%promiscuous setting will be propagated to the new active slave.
%
active-backupbalance-tlbbalance-alb ⡼ɤǤϡƥ֥졼֤ѹ
(㡧󥯼Ԥΰ)promiscuous Ͽƥ֥졼֤˹ޤ

%11. Configuring Bonding for High Availability
%=============================================
%
11. Ѥ bonding 
=============================

%	High Availability refers to configurations that provide
%maximum network availability by having redundant or backup devices,
%links or switches between the host and the rest of the world.  The
%goal is to provide the maximum availability of network connectivity
%(i.e., the network always works), even though other configurations
%could provide higher throughput.
%
ȤϡΥۥȤȤʳȤδ֤ˡĹޤϥХååץǥХ
󥯤뤤ϥåǡ¤Υͥåȥ󶡤ؤ
ޤŪϡ¾ˤ⤤롼ץåȤˤȤƤ⡢ͥåȥ
³󶡤Ǥ(Ĥޤꡢͥåȥ˵ǽƤ)

%11.1 High Availability in a Single Switch Topology
%--------------------------------------------------
%
11.1 ñ쥹åȥݥˤ
-----------------------------------------

%	If two hosts (or a host and a single switch) are directly
%connected via multiple physical links, then there is no availability
%penalty to optimizing for maximum bandwidth.  In this case, there is
%only one switch (or peer), so if it fails, there is no alternative
%access to fail over to.  Additionally, the bonding load balance modes
%support link monitoring of their members, so if individual links fail,
%the load will be rebalanced across the remaining devices.
%
ĤΥۥ(뤤ñۥȤñ쥹å)ʣʪŪ󥯤𤷤ľ
³Ƥ硢Хΰ٤κŬˤڥʥƥϤޤ󡣤
ΥǤϡñΥå(뤤̿)ΤߤΤǡ줬Ԥ硢
ե륪Сإޤ󡣲äơbonding ɥХ󥹥⡼
ɤϥСΥ󥯴ƻ󶡤ΤǡΩ󥯤Ԥ硢٤ϻĤ
줿ǥХǺٶޤ

%	See Section 13, "Configuring Bonding for Maximum Throughput"
%for information on configuring bonding with one peer device.
%
ĤΥԥǥХǤ bonding ξ 13 ϡֺ祹롼ץåȤΰ٤ 
bonding פ򻲾ȤƤ

%11.2 High Availability in a Multiple Switch Topology
%----------------------------------------------------
%
11.2 ʣΥåȥݥˤ
-------------------------------------------

%	With multiple switches, the configuration of bonding and the
%network changes dramatically.  In multiple switch topologies, there is
%a trade off between network availability and usable bandwidth.
%
ʣΥåǤϡbonding ȥͥåȥϷŪѲޤʣΥ
ȥݥǤϥͥåȥβѤǤХδ֤ˤϥȥ졼ɥդ
ޤ

%	Below is a sample network, configured to maximize the
%availability of the network:
%
ϡͥåȥβ粽褦ꤵ줿ͥåȥǤ

%                |                                     |
%                |port3                           port3|
%          +-----+----+                          +-----+----+
%          |          |port2       ISL      port2|          |
%          | switch A +--------------------------+ switch B |
%          |          |                          |          |
%          +-----+----+                          +-----++---+
%                |port1                           port1|
%                |             +-------+               |
%                +-------------+ host1 +---------------+
%                         eth0 +-------+ eth1
%

                |                                     |
                |ݡ3                       ݡ3|
          +-----+----+                          +-----+----+
          |          |ݡ2     ISL    ݡ2|          |
          |åA +--------------------------+åB |
          |          |                          |          |
          +-----+----+                          +-----+----+
                |ݡ1                       ݡ1|
                |             +-------+               |
                +-------------+ۥ1+---------------+
                         eth0 +-------+ eth1


%	In this configuration, there is a link between the two
%switches (ISL, or inter switch link), and multiple ports connecting to
%the outside world ("port3" on each switch).  There is no technical
%reason that this could not be extended to a third switch.
%

ǤϡĤΥå֤˥(ISLޤϥå֥: inter switch
link)ȡˤĤʤʣΥݡ(ƥåΡport3)ޤ֤
Υå˳ĥǤʤŪͳϤޤ

%11.2.1 HA Bonding Mode Selection for Multiple Switch Topology
%-------------------------------------------------------------
%
11.2.1 ʣΥåȥݥˤ bonding ⡼ɤ
------------------------------------------------------------------

%	In a topology such as the example above, the active-backup and
%broadcast modes are the only useful bonding modes when optimizing for
%availability; the other modes require all links to terminate on the
%same peer for them to behave rationally.
%
嵭Τ褦ʥȥݥǤϡ˺Ŭݤ active-backup  broadcast 
⡼ɤΤߤͭѤ bonding ⡼ɤǤ¾Υ⡼ɤϡƤΥ󥯤Ū˿
񤦤Ʊ̿оݤ³Ƥ׵ᤷޤ

%active-backup: This is generally the preferred mode, particularly if
%	the switches have an ISL and play together well.  If the
%	network configuration is such that one switch is specifically
%	a backup switch (e.g., has lower capacity, higher cost, etc),
%	then the primary option can be used to insure that the
%	preferred link is always used when it is available.
%
active-backup: ̤ˤϤ줬Υ⡼ɤǡä˥å ISL ꡢ
	ޤưƤϤǤĤΥåä˥Хååץå
	(㡧㤤̡⤤ȡ)Ǥ褦ʥͥåȥξ硢ͥ
	󥯤ѤǤ˾˻Ѥݾڤ٤ primary ץ
	ѤǤޤ

%broadcast: This mode is really a special purpose mode, and is suitable
%	only for very specific needs.  For example, if the two
%	switches are not connected (no ISL), and the networks beyond
%	them are totally independent.  In this case, if it is
%	necessary for some specific one-way traffic to reach both
%	independent networks, then the broadcast mode may be suitable.
%
broadcast: Υ⡼ɤüŪΥ⡼ɤǡüʥˡˤΤŬ
	Ǥ㤨СĤΥå³Ƥ餺(ISL ʤ)θ
	ΥͥåȥΩƤǤΤ褦ʥǤϡĤ
	̤ƻ̿ξΩͥåȥǼɬפʾ硢
	broadcast ⡼ɤŬΤޤ

%11.2.2 HA Link Monitoring Selection for Multiple Switch Topology
%----------------------------------------------------------------
%
11.2.2 ʣΥåȥݥˤ󥯴ƻ
-------------------------------------------------------

%	The choice of link monitoring ultimately depends upon your
%switch.  If the switch can reliably fail ports in response to other
%failures, then either the MII or ARP monitors should work.  For
%example, in the above example, if the "port3" link fails at the remote
%end, the MII monitor has no direct means to detect this.  The ARP
%monitor could be configured with a target at the remote end of port3,
%thus detecting that failure without switch support.
%
󥯴ƻϡɥå˰¸ޤå¾μԤؤαˤ
ݡȤμ¤˼Ԥ硢MII ƻ뤢뤤 ARP ƻΤɤⵡǽǤ礦
㤨С嵭ǡȿ¦νüǡport3ץ󥯤Ԥ硢MII ƻˤϤ
μԤ򸡽ФľܤμʤޤARP ƻ port3 ȿ¦νüˤ륿
åȤ˴ƻǤޤäƥåΥݡȤʤ˼ԤΤޤ

%	In general, however, in a multiple switch topology, the ARP
%monitor can provide a higher level of reliability in detecting end to
%end connectivity failures (which may be caused by the failure of any
%individual component to pass traffic for any reason).  Additionally,
%the ARP monitor should be configured with multiple targets (at least
%one for each switch in the network).  This will insure that,
%regardless of which switch is active, the ARP monitor has a suitable
%target to query.
%
ʤ顢̤ˡʣΥåȥݥǤϡARP ƻüüؤ³
(ϡ餫ͳ̿Ϥ٤ǤդΩݡͥȤμԤ˵
뤫Τޤ)θΤˤơ˹٥ο󶡤ޤäơ
ARP ƻʣΥåȤ(ʤȤ⡢ͥåȥγƥåˣ)
ǤޤϡɤΥåƥ֤Ǥ뤫˴ؤ餺ARP ƻ뤬䤤
ŬڤʥåȤݾڤޤ

%	Note, also, that of late many switches now support a functionality
%generally referred to as "trunk failover."  This is a feature of the
%switch that causes the link state of a particular switch port to be set
%down (or up) when the state of another switch port goes down (or up).
%It's purpose is to propogate link failures from logically "exterior" ports
%to the logically "interior" ports that bonding is able to monitor via
%miimon.  Availability and configuration for trunk failover varies by
%switch, but this can be a viable alternative to the ARP monitor when using
%suitable switches.
%
ޤǶ¿ΥåϺ֥ȥ󥯥ե륪(trunk failover)פȤ
̤˸뵡ǽ򥵥ݡȤƤޤϡ̤ΥåݡȤξ֤
(ޤϥå)ݡΥåݡȤΥ󥯾֤(ޤϥå)
ȤåεǽǤŪϡŪˡֳΡץݡȤΥ󥯼
Ԥbonding  miimon 𤷤ƴƻǤ롢ŪˡΡץݡȤ˹
Ǥȥ󥯥ե륪ФβϥåˤäѤޤŬ
ʥåѤݡ ARP ƻμŪغˤʤޤ

%12. Configuring Bonding for Maximum Throughput
%==============================================
%
12. 祹롼ץåȤΰ٤ bonding 
=======================================

%12.1 Maximizing Throughput in a Single Switch Topology
%------------------------------------------------------
%
12.1 ñ쥹åȥݥˤ祹롼ץå
-------------------------------------------------

%	In a single switch configuration, the best method to maximize
%throughput depends upon the application and network environment.  The
%various load balancing modes each have strengths and weaknesses in
%different environments, as detailed below.
%
ñ쥹åǤϡ롼ץåȤ粽ɤˡϡץꥱȥͥ
ȥĶ˰¸ޤ͡ʬ⡼ɤϡ褦ˡۤʤ
ˤƤ줾Ĺû꤬ޤ

%	For this discussion, we will break down the topologies into
%two categories.  Depending upon the destination of most traffic, we
%categorize them into either "gatewayed" or "local" configurations.
%
εǤϡȥݥ򣲤ĤΥƥʬޤۤȤɤ̿ˤäơ
ȥݥ֥ȥͳȡ֥Τɤ餫ʬषޤ

%	In a gatewayed configuration, the "switch" is acting primarily
%as a router, and the majority of traffic passes through this router to
%other networks.  An example would be the following:
%
ȥͳǤϡ֥åפϼ˥롼ȤƵǽ̿ʬ
Υ롼̤ä¾ΥͥåȥϤޤϼ̤Ǥ

%     +----------+                     +----------+
%     |          |eth0            port1|          | to other networks
%     | Host A   +---------------------+ router   +------------------->
%     |          +---------------------+          | Hosts B and C are out
%     |          |eth1            port2|          | here somewhere
%     +----------+                     +----------+
%
     +----------+                     +----------+
     |          |eth0          ݡ1|          | ¾Υͥåȥ
     | ۥA  +---------------------+ 롼 +------------------->
     |          +---------------------+          | ۥB  C 
     |          |eth1          ݡ2|          | γΤɤ
     +----------+                     +----------+

%	The router may be a dedicated router device, or another host
%acting as a gateway.  For our discussion, the important point is that
%the majority of traffic from Host A will pass through the router to
%some other network before reaching its final destination.
%
롼ϥ롼ѥǥХΤޤ󤷡ȥȤƿ̤Υ
ȤΤޤ󡣲桹εǤϡפʥݥȤϡۥ A ̿
ʬǽŪŪϤãˡĤ¾ͥåȥؤΥ롼̲᤹
Ǥ

%	In a gatewayed network configuration, although Host A may
%communicate with many other systems, all of its traffic will be sent
%and received via one other peer on the local network, the router.
%
ȥͳΥͥåȥǤϡ㤨ۥ A ¿¾Υƥ̿
ǤȤƤ⡢ΥȥեåƥͥåȥΣĤ̿ꡢ
롼𤷤ޤ

%	Note that the case of two systems connected directly via
%multiple physical links is, for purposes of configuring bonding, the
%same as a gatewayed configuration.  In that case, it happens that all
%traffic is destined for the "gateway" itself, not some other network
%beyond the gateway.
%
ʣʪŪ󥯤𤷤ľ³줿ĤΥƥξ(bonding ꤹ
Ū)ȥͳƱǤդƲξ硢
̿ϥȥθ¾ΥͥåȥǤϤʤ֥ȥװ
ޤ

%	In a local configuration, the "switch" is acting primarily as
%a switch, and the majority of traffic passes through this switch to
%reach other stations on the same network.  An example would be the
%following:
%
Ǥϡ֥åפϼ˥åȤƵǽ̿ʬƱͥ
ȥ¾Υơ夹٤ˤΥå̲ᤷޤϼ
Ǥ

%    +----------+            +----------+       +--------+
%    |          |eth0   port1|          +-------+ Host B |
%    |  Host A  +------------+  switch  |port3  +--------+
%    |          +------------+          |                  +--------+
%    |          |eth1   port2|          +------------------+ Host C |
%    +----------+            +----------+port4             +--------+
%
    +----------+            +----------+         +--------+
    |          |eth0 ݡ1|          +---------+ۥB |
    | ۥA  +------------+ å |ݡ3  +--------+
    |          +------------+          |                  +--------+
    |          |eth1 ݡ2|          +------------------+ۥC |
    +----------+            +----------+ݡ4           +--------+

%	Again, the switch may be a dedicated switch device, or another
%host acting as a gateway.  For our discussion, the important point is
%that the majority of traffic from Host A is destined for other hosts
%on the same local network (Hosts B and C in the above example).
%
ǤϡåϥåѥǥХ⤷ޤ󤷡ȥȤƿ
̤ΥۥȤΤޤ󡣲桹εǤϡפʥݥȤϥۥ A 
ʬƱͥåȥ¾Υۥ(嵭Ǥϥۥ B  ۥ 
C)ȤǤ

%	In summary, in a gatewayed configuration, traffic to and from
%the bonded device will be to the same MAC level peer on the network
%(the gateway itself, i.e., the router), regardless of its final
%destination.  In a local configuration, traffic flows directly to and
%from the final destinations, thus, each destination (Host B, Host C)
%will be addressed directly by their individual MAC addresses.
%
פϡȥͳǤϡbond 줿ǥХԤ褹̿Ϻǽ
Ūʰˤ餺ͥåȥƱ MAC ٥̿(ȥȡ
Ĥޤ롼)ǤȤǤǤϡ̿ϺǽŪϤľܹ
褷ޤäƳŪ(ۥ Bۥ C)ϤΩ MAC ɥ쥹
äľܰդޤ

%	This distinction between a gatewayed and a local network
%configuration is important because many of the load balancing modes
%available use the MAC addresses of the local network source and
%destination to make load balancing decisions.  The behavior of each
%mode is described below.
%
ȥͳȥͥåȥ̤ΤϽפǤʤ
顢Ѳǽʬ⡼ɤ¿ʬηԤ٤˥ͥåȥ
 MAC ɥ쥹Ѥ뤫Ǥƥ⡼ɤο񤤤ϲ
̤Ǥ

%12.1.1 MT Bonding Mode Selection for Single Switch Topology
%-----------------------------------------------------------
%
12.1.1 ñ쥹åȥݥˤ祹롼ץåȤ bonding ⡼ɤ
--------------------------------------------------------------------------

%	This configuration is the easiest to set up and to understand,
%although you will have to decide which bonding mode best suits your
%needs.  The trade offs for each mode are detailed below:
%
ϡ򤬤äȤñǤǤ⡢ɤ bonding ⡼ɤʤΥˡ
˺ǤŬƤ뤫ʤƤФʤޤ󡣳ƥ⡼ɤΥȥ졼ɥդξܺ٤򲼵
˵󤲤ޤ


%balance-rr: This mode is the only mode that will permit a single
%	TCP/IP connection to stripe traffic across multiple
%	interfaces. It is therefore the only mode that will allow a
%	single TCP/IP stream to utilize more than one interface's
%	worth of throughput.  This comes at a cost, however: the
%	striping generally results in peer systems receiving packets out
%	of order, causing TCP/IP's congestion control system to kick
%	in, often by retransmitting segments.
%
balance-rr: Υ⡼ɤϡ̿ʣΥ󥿡եϤƥȥ饤ԥ󥰤
	ñ TCP/IP ³ĤͣΥ⡼ɤǤäơñ TCP/IP 
	ȥ꡼बñ쥤󥿡եΥ롼ץå̰ʾѤͣΥ⡼
	ǤˤϥȤޤʤ顧ȥ饤ԥ󥰤ϰ̤ˡ
	(TCP/IP ̩楷ƥ˵)Ȥˤäоݥƥ
	ѥåȤ֤򳰤Ϥ̤ˤʤޤ

%	It is possible to adjust TCP/IP's congestion limits by
%	altering the net.ipv4.tcp_reordering sysctl parameter.  The
%	usual default value is 3, and the maximum useful value is 127.
%	For a four interface balance-rr bond, expect that a single
%	TCP/IP stream will utilize no more than approximately 2.3
%	interface's worth of throughput, even after adjusting
%	tcp_reordering.
%
	net.ipv4.tcp_reordering sysctl ѥ᡼ѹˤꡢTCP/IP 
	ĴǤޤ̾Υǥեͤ 3 ǡѲǽʺͤ 
	127 ǤĤΥ󥿡ե balance-rr bond Ǥϡtcp_reordering 
	ĴǤñ TCP/IP ȥ꡼Ϥ褽 2.3 󥿡ե
	Υ롼ץå̰ʲѤˤʤͽۤޤ

%	Note that the fraction of packets that will be delivered out of
%	order is highly variable, and is unlikely to be zero.  The level
%	of reordering depends upon a variety of factors, including the
%	networking interfaces, the switch, and the topology of the
%	configuration.  Speaking in general terms, higher speed network
%	cards produce more reordering (due to factors such as packet
%	coalescing), and a "many to many" topology will reorder at a
%	higher rate than a "many slow to one fast" configuration.
%
%	Many switches do not support any modes that stripe traffic
%	(instead choosing a port based upon IP or MAC level addresses);
%	for those devices, traffic for a particular connection flowing
%	through the switch to a balance-rr bond will not utilize greater
%	than one interface's worth of bandwidth.
%

	ѥåȤΨѤ䤹ޤ 0 ˤʤꤽ
	ʤդƲѥåȤκΥ٥ϥͥåȥ󥿡
	եåΥȥݥޤ͡װ˰¸ޤŪ
	С®Υͥåȥɤ(ѥåͻʤɤװˤ
	)¿κ¿¿ץȥݥϡ¿а®(many slow to
	one fast)⤤ΨǺ󤷤ޤ

	¿Υåϡ(IP ޤ MAC ٥Υɥ쥹ˤݡ
	)̿򥹥ȥ饤(緫)벿餫Υ⡼ɤ򥵥ݡȤƤޤ
	󡣢ΥǥХǤϡå̤ balance-rr bond ή
	ΥͥѤ̿ϡĤΥ󥿡եΥХʾѤ
	Ϥޤ

%	If you are utilizing protocols other than TCP/IP, UDP for
%	example, and your application can tolerate out of order
%	delivery, then this mode can allow for single stream datagram
%	performance that scales near linearly as interfaces are added
%	to the bond.
%
	TCP/IP ʳΥץȥ(㡧UDP)ѤƤꡢץꥱ󤬽
	ۿѤ硢Υ⡼ɤbond ˲ä줿󥿡եǽ
	ˤۤ˥뤹ñ쥹ȥ꡼ǡǽޤ

%	This mode requires the switch to have the appropriate ports
%	configured for "etherchannel" or "trunking."

	Υ⡼ɤϡ֥ͥפޤϡ֥ȥ󥭥󥰡ѤŬڤʥݡ
	꤬åˤ׵ᤷޤ

%active-backup: There is not much advantage in this network topology to
%	the active-backup mode, as the inactive backup devices are all
%	connected to the same peer as the primary.  In this case, a
%	load balancing mode (with link monitoring) will provide the
%	same level of network availability, but with increased
%	available bandwidth.  On the plus side, active-backup mode
%	does not require any configuration of the switch, so it may
%	have value if the hardware available does not support any of
%	the load balance modes.
%
active-backup: ƥ֤ǤʤХååץǥХƱ̿ primary 
	Ȥ³Ƥ١active-backup ⡼ɤϡΥͥåȥȥݥ
	ˤޤꤢޤ󡣤ξ硢(󥯴ƻͭ)ʬ⡼
	ɤƱ٥Υͥåȥ󶡤ޤѲǽʥХ
	ޤץ饹̤Ǥϡactive-backup ⡼ɤϥå˲餫׵
	ʤΤǡѲǽʥϡɥʬ⡼ɤ򲿤⥵ݡȤʤ
	˲ͤޤ


%balance-xor: This mode will limit traffic such that packets destined
%	for specific peers will always be sent over the same
%	interface.  Since the destination is determined by the MAC
%	addresses involved, this mode works best in a "local" network
%	configuration (as described above), with destinations all on
%	the same local network.  This mode is likely to be suboptimal
%	if all your traffic is passed through a single router (i.e., a
%	"gatewayed" network configuration, as described above).
%
balance-xor: Υ⡼ɤϡ̿˱̿դ줿ѥåȤƱ
	եͳ褦̿¤ޤŪϤ MAC 
	쥹Ƿꤵ١Υ⡼ɤ(嵭褦) Ʊͥ
	ȥƤŪϤ֤Ρ֥ץͥåȥǺǤ
	ưޤΥ⡼ɤϡƤ̿ñΥ롼̲᤹(Ĥ
	ꡢ嵭֥ȥͳץͥåȥ)ˤԴˤʤ
	Ǥ

%	As with balance-rr, the switch ports need to be configured for
%	"etherchannel" or "trunking."
%
	balance-rr Ʊ͡åݡȤϡ֥ͥפޤϡ֥ȥ󥭥
	פꤵɬפޤ

%broadcast: Like active-backup, there is not much advantage to this
%	mode in this type of network topology.
%
broadcast: active-backup ˻ơΥפΥͥåȥȥݥǤϤΥ⡼
	Ϥޤޤ

%802.3ad: This mode can be a good choice for this type of network
%	topology.  The 802.3ad mode is an IEEE standard, so all peers
%	that implement 802.3ad should interoperate well.  The 802.3ad
%	protocol includes automatic configuration of the aggregates,
%	so minimal manual configuration of the switch is needed
%	(typically only to designate that some set of devices is
%	available for 802.3ad).  The 802.3ad standard also mandates
%	that frames be delivered in order (within certain limits), so
%	in general single connections will not see misordering of
%	packets.  The 802.3ad mode does have some drawbacks: the
%	standard mandates that all devices in the aggregate operate at
%	the same speed and duplex.  Also, as with all bonding load
%	balance modes other than balance-rr, no single connection will
%	be able to utilize more than a single interface's worth of
%	bandwidth.  
%
802.3ad: Υ⡼ɤϤΥפΥͥåȥȥݥǤɤˤʤޤ
	802.3ad ⡼ɤ IEEE ɸʤΤǡ802.3ad Ƥ̿ȤϤ
	ޤ߱ѤǤޤ802.3ad ץȥϽμưޤǤΤǡ
	åκ¤μư꤬ɬפǤ(ŵŪˤϡǥХβ餫Υ
	Ȥ 802.3ad ѤǤ褦ꤹΤ)802.3ad ɸϤޤե졼
	()ۿ褦ؼФޤΤǡ̤ˤñ³
	ѥåȤν֥ߥޤ802.3ad ⡼ɤϤĤη
	ɸϡƤΥǥХƱԡɤƱȾŤ
	褦ؼФޤޤbalance-rr ʳƤ bonding ʬ⡼
	ɤξƱͤˡñ³ϣĤΥ󥿡եΥХ깭
	ѤǤޤ

%	Additionally, the linux bonding 802.3ad implementation
%	distributes traffic by peer (using an XOR of MAC addresses),
%	so in a "gatewayed" configuration, all outgoing traffic will
%	generally use the same device.  Incoming traffic may also end
%	up on a single device, but that is dependent upon the
%	balancing policy of the peer's 8023.ad implementation.  In a
%	"local" configuration, traffic will be distributed across the
%	devices in the bond.
%
	äơLinux  bonding 802.3ad ϡ̿̿ʬޤ(MAC 
	ɥ쥹¾¤)Τǡ֥ȥͳפǤϡƤ
	Ԥ̿ϰ̤ƱǥХѤޤ̿ǽŪˤñ
	Х̲᤹뤫Τޤ󤬡̿ 802.3ad ʬݥ
	˰¸ޤ֥ˤơ̿ bond ΥǥХ
	Ϥäʬޤ

%	Finally, the 802.3ad mode mandates the use of the MII monitor,
%	therefore, the ARP monitor is not available in this mode.
%
	Ǹˡ802.3ad ⡼ɤ MII ƻλѤؼޤΤǡΥ⡼ɤ 
	ARP ƻѤǤޤ

%balance-tlb: The balance-tlb mode balances outgoing traffic by peer.
%	Since the balancing is done according to MAC address, in a
%	"gatewayed" configuration (as described above), this mode will
%	send all traffic across a single device.  However, in a
%	"local" network configuration, this mode balances multiple
%	local network peers across devices in a vaguely intelligent
%	manner (not a simple XOR as in balance-xor or 802.3ad mode),
%	so that mathematically unlucky MAC addresses (i.e., ones that
%	XOR to the same value) will not all "bunch up" on a single
%	interface.
%
balance-tlb: balance-tlb ⡼ɤϡ̿̿ʬޤMAC 
	ɥ쥹˽äʬԤޤΤǡ֥ȥͳǤ
	(嵭̤)Υ⡼ɤñΥǥХϤäƤ̿
	ޤʤ顢֥ץͥåȥǤϡΥ⡼ɤϡ
	Ȥƥꥸȥޥʡ(balance-xor  802.3ad ⡼ɤΤ褦ñ
	 XOR ǤϤʤ)ǥǥХϤäʣΥͥåȥ̿
	ʬޤΤǡŪˤԹ MAC ɥ쥹(ĤޤꡢXOR Ʊ
	ˤʤ)ñΥ󥿡եơ«ˤʤ׻ޤ

%	Unlike 802.3ad, interfaces may be of differing speeds, and no
%	special switch configuration is required.  On the down side,
%	in this mode all incoming traffic arrives over a single
%	interface, this mode requires certain ethtool support in the
%	network device driver of the slave interfaces, and the ARP
%	monitor is not available.
%
	802.3ad Ȱۤʤꡢ󥿡եϰۤʤ륹ԡɤǤɤ̤ʥ
	꤬ɬפޤ󡣷ȤƤϡΥ⡼ɤǤƤ̿
	ñ쥤󥿡եۤ夹뤳ȤȡΥ⡼ɤϥ졼֥󥿡
	եΥͥåȥǥХɥ饤Ф ethtool ݡȤ׵᤹
	뤳ȡARP ƻ뤬ѤǤʤȤǤ

%balance-alb: This mode is everything that balance-tlb is, and more.
%	It has all of the features (and restrictions) of balance-tlb,
%	and will also balance incoming traffic from local network
%	peers (as described in the Bonding Module Options section,
%	above).
%
balance-alb: Υ⡼ɤ balance-tlb ưʾǤbalance-tlb ǽ(
	)ꡢΤ(嵭 bonding ⥸塼륪ץϤ褦
	)ͥåȥ꤫̿̿ʬޤ

%	The only additional down side to this mode is that the network
%	device driver must support changing the hardware address while
%	the device is open.
%
	Υ⡼ɤͣɲä줿ϡͥåȥǥХɥ饤ФǥХ
	ץ󤵤Ƥ֤Υϡɥɥ쥹ѹ򥵥ݡȤʤ
	ʤʤǤ

%12.1.2 MT Link Monitoring for Single Switch Topology
%----------------------------------------------------
%
12.1.2 ñ쥹åȥݥˤ祹롼ץåȤΥ󥯴ƻ
---------------------------------------------------------------

%	The choice of link monitoring may largely depend upon which
%mode you choose to use.  The more advanced load balancing modes do not
%support the use of the ARP monitor, and are thus restricted to using
%the MII monitor (which does not provide as high a level of end to end
%assurance as the ARP monitor).
%
󥯴ƻϡɤΥ⡼ɤѤ뤫˼˰¸Ƥޤʤ
ʬ⡼ɤ ARP ƻλѤ򥵥ݡȤƤ餺Τ MII ƻλѤ
¤Ƥޤޤ( ARP ƻۤɡüüؤγμ⤤٥󶡤
)

%12.2 Maximum Throughput in a Multiple Switch Topology
%-----------------------------------------------------
%
12.2 ʣΥåȥݥˤ祹롼ץå
---------------------------------------------------

%	Multiple switches may be utilized to optimize for throughput
%when they are configured in parallel as part of an isolated network
%between two or more systems, for example:
%
İʾΥƥδ֤ˤΩͥåȥʬꤹݡ롼
ץåȤŬ٤ʣΥåѤǤޤ㤨С

%                       +-----------+
%                       |  Host A   | 
%                       +-+---+---+-+
%                         |   |   |
%                +--------+   |   +---------+
%                |            |             |
%         +------+---+  +-----+----+  +-----+----+
%         | Switch A |  | Switch B |  | Switch C |
%         +------+---+  +-----+----+  +-----+----+
%                |            |             |
%                +--------+   |   +---------+
%                         |   |   |
%                       +-+---+---+-+
%                       |  Host B   | 
%                       +-----------+
%
                       +-----------+
                       | ۥ A  | 
                       +-+---+---+-+
                         |   |   |
                +--------+   |   +---------+
                |            |             |
         +------+---+  +-----+----+  +-----+----+
         |åA |  |åB |  |åC |
         +------+---+  +-----+----+  +-----+----+
                |            |             |
                +--------+   |   +---------+
                         |   |   |
                       +-+---+---+-+
                       | ۥ B  | 
                       +-----------+

%	In this configuration, the switches are isolated from one
%another.  One reason to employ a topology such as this is for an
%isolated network with many hosts (a cluster configured for high
%performance, for example), using multiple smaller switches can be more
%cost effective than a single larger switch, e.g., on a network with 24
%hosts, three 24 port switches can be significantly less expensive than
%a single 72 port switch.
%
ǤϡåϸߤΩƤޤΤ褦ʥȥݥȤĤ
ͳϡ¿ΥۥȤΩͥåȥΰ٤(㤨С®׻Ѥꤵ
饹)ʣξʥåλѤñ礭ʥå⥳ȸ̤
⤯Ǥޤ(㤨С24 ۥȤͥåȥǤϡ3 Ĥ 24 ݡȥå
ñ 72 ݡȥåˤʤѤǤޤ)

%	If access beyond the network is required, an individual host
%can be equipped with an additional network device connected to an
%external network; this host then additionally acts as a gateway.
%
ͥåȥθȥɬפ硢Υͥåȥ³줿
ɲåͥåȥǥХΩۥȤޤäơΥ
ȤϤθ夵˥ȥȤƤ⿶񤤤ޤ

%12.2.1 MT Bonding Mode Selection for Multiple Switch Topology
%-------------------------------------------------------------
%
12.2.1 ʣΥåȥݥˤ祹롼ץåȤ bonding ⡼ɤ
----------------------------------------------------------------------------

%	In actual practice, the bonding mode typically employed in
%configurations of this type is balance-rr.  Historically, in this
%network configuration, the usual caveats about out of order packet
%delivery are mitigated by the use of network adapters that do not do
%any kind of packet coalescing (via the use of NAPI, or because the
%device itself does not generate interrupts until some number of
%packets has arrived).  When employed in this fashion, the balance-rr
%mode allows individual connections between two hosts to effectively
%utilize greater than one interface's bandwidth.
%
ºݤθǤϡΥפŵŪѤ bonding ⡼ɤ balance-rr 
ǤŪˡΥͥåȥǤϡΥѥå˴ؤ̾
ϤΥѥåͻ(NAPI Ѥ𤷤ơ뤤ϥǥХΤ٤
ѥåȤ夷ʤȳߤʤˤ)Ԥʤͥåȥ
λѤˤ¤ޤηѤ硢󥿡եΥХ
ŪѤ٤ˡbalance-rr ⡼ɤǣۥȴ֤Ω³ǽˤ
ޤ

%12.2.2 MT Link Monitoring for Multiple Switch Topology
%------------------------------------------------------
%
12.2.2 ʣΥͥåȥȥݥˤ祹롼ץåȤΥ󥯴ƻ
---------------------------------------------------------------------

%	Again, in actual practice, the MII monitor is most often used
%in this configuration, as performance is given preference over
%availability.  The ARP monitor will function in this topology, but its
%advantages over the MII monitor are mitigated by the volume of probes
%needed as the number of systems involved grows (remember that each
%host in the network is configured with bonding).
%
١ºݤθǤϡǽͥ褵١Ǥ MII ƻ뤬Ǥ
¿ѤƤޤΥȥݥ ARP ƻϵǽǤ礦ƥοˤ
ɬפʥץ֤̤ʣĹˤꡢMII ƻФ ARP ƻͥ
㤯ʤޤ(ͥåȥγƥۥȤ bonding ³פФƤ
)

%13. Switch Behavior Issues
%==========================
%
13. åεư
========================

%13.1 Link Establishment and Failover Delays
%-------------------------------------------
%
13.1 󥯳Ωȥե륪ٱ
-----------------------------------

%	Some switches exhibit undesirable behavior with regard to the
%timing of link up and down reporting by the switch.
%
ĤΥåϡå𤹤󥯥åסΥߥ󥰤˴ؤ
˾ޤʤư򼨤ޤ

%	First, when a link comes up, some switches may indicate that
%the link is up (carrier available), but not pass traffic over the
%interface for some period of time.  This delay is typically due to
%some type of autonegotiation or routing protocol, but may also occur
%during switch initialization (e.g., during recovery after a switch
%failure).  If you find this to be a problem, specify an appropriate
%value to the updelay bonding module option to delay the use of the
%relevant interface(s).
%
ˡ󥯤åפĤΥåϥ󥯤å(ꥢ
ǽ)򼨤Ƥ⡢٤δ֥󥿡եۤ̿Ǥʤ
Τޤ󡣤ٱϡŵŪˤϿפΥȥͥ롼ƥ
ץȥΰ٤Ǥåνδ֤ˤȯ뤫Τޤ(㤨С
åԸΥꥫХδ)줬ˤʤ򸫤Ĥ硢Ϣ󥿡
եλѤٱ䤵١bonding ⥸塼륪ץ updelay Ŭڤͤ
ꤷޤ

%	Second, some switches may "bounce" the link state one or more
%times while a link is changing state.  This occurs most commonly while
%the switch is initializing.  Again, an appropriate updelay value may
%help.
%
ˡĤΥåϥ󥯤֤ѹ֡󤢤뤤ʣ󥯤
֤ķ֤(bounce)פΤޤ󡣤ϡåν˺Ǥ褯ȯ
ޤξ⡢Ŭڤ updelay ͤߤˤʤ뤫Τޤ

%	Note that when a bonding interface has no active links, the
%driver will immediately reuse the first link that goes up, even if the
%updelay parameter has been specified (the updelay is ignored in this
%case).  If there are slave interfaces waiting for the updelay timeout
%to expire, the interface that first went into that state will be
%immediately reused.  This reduces down time of the network if the
%value of updelay has been overestimated, and since this occurs only in
%cases with no connectivity, there is no additional penalty for
%ignoring the updelay.
%
bonding 󥿡ե˥ƥ֤ʥ󥯤ʤ硢updelay ѥ᡼
ƤȤƤ⡢bonding ɥ饤ФϺǽ˥åפ󥯤¨¤˺Ѥޤ
(ξ硢updelay ̵뤵ޤ)updelay ॢȤԤäƤ륹졼֥
եСǽˤξ֤ˤʤä󥿡ե¨¤˺Ѥ
ϡupdelay ͤ˸ѤƤˡͥåȥΥ󥿥
︺ޤ³ƤʤΤߤȯǤ뤿ᡢupdelay ̵뤹
뤳Ȥˤڥʥƥä뤳ȤϤޤ

%	In addition to the concerns about switch timings, if your
%switches take a long time to go into backup mode, it may be desirable
%to not activate a backup interface immediately after a link goes down.
%Failover may be delayed via the downdelay bonding module option.
%
åߥ󥰴ϢǲäȡåХååץ⡼ɤˤʤΤĹ
硢󥯤󤷤¨˥Хååץ󥿡ե򥢥ƥ
֤ˤʤ˾ޤ뤫Τޤ󡣥ե륪Ф bonding ⥸塼륪ץ
 downdelay ٱǤޤ

%13.2 Duplicated Incoming Packets
%--------------------------------
%
13.2 ʣѥå
---------------------------

%	NOTE: Starting with version 3.0.2, the bonding driver has logic to
%suppress duplicate packets, which should largely eliminate this problem.
%The following description is kept for reference.
%
աС 3.0.2 ʹߡbonding ɥ饤ФϽʣѥåȤå
ޤϡ礤˼ޤʲϻͤΰ٤ݻޤ

%	It is not uncommon to observe a short burst of duplicated
%traffic when the bonding device is first used, or after it has been
%idle for some period of time.  This is most easily observed by issuing
%a "ping" to some other host on the network, and noticing that the
%output from ping flags duplicates (typically one per slave).
%
bonding ǥХǽ˻Ѥݡ뤤 bonding ٤δԵ
äǡȯŪʽʣ̿ޤ󡣤ϡͥåȥ
¾ΥۥȤˡpingפǤping Ϥֽʣ(duplicate)ץե饰(ŵŪ
ˤϡ졼1)˵ŤǤñ˴¬Ǥޤ

%	For example, on a bond in active-backup mode with five slaves
%all connected to one switch, the output may appear as follows:
%
㤨СƣĤΥå³줿5ĤΥ졼֤ active-backup ⡼ɤ 
bond ǤϡϤϼΤ褦ˤʤ뤫Τޤ

# ping -n 10.0.4.2
PING 10.0.4.2 (10.0.4.2) from 10.0.3.10 : 56(84) bytes of data.
64 bytes from 10.0.4.2: icmp_seq=1 ttl=64 time=13.7 ms
64 bytes from 10.0.4.2: icmp_seq=1 ttl=64 time=13.8 ms (DUP!)
64 bytes from 10.0.4.2: icmp_seq=1 ttl=64 time=13.8 ms (DUP!)
64 bytes from 10.0.4.2: icmp_seq=1 ttl=64 time=13.8 ms (DUP!)
64 bytes from 10.0.4.2: icmp_seq=1 ttl=64 time=13.8 ms (DUP!)
64 bytes from 10.0.4.2: icmp_seq=2 ttl=64 time=0.216 ms
64 bytes from 10.0.4.2: icmp_seq=3 ttl=64 time=0.267 ms
64 bytes from 10.0.4.2: icmp_seq=4 ttl=64 time=0.222 ms

%	This is not due to an error in the bonding driver, rather, it
%is a side effect of how many switches update their MAC forwarding
%tables.  Initially, the switch does not associate the MAC address in
%the packet with a particular switch port, and so it may send the
%traffic to all ports until its MAC forwarding table is updated.  Since
%the interfaces attached to the bond may occupy multiple ports on a
%single switch, when the switch (temporarily) floods the traffic to all
%ports, the bond device receives multiple copies of the same packet
%(one per slave device).
%
 bonding ɥ饤Фˤ륨顼ΰ٤ǤϤʤϡ¿Υå
 MAC žơ֥򹹿ˡѤǤϤˡåΥ
åݡȤ˥ѥåȤ MAC ɥ쥹ϢդƤ餺Τ MAC žơ
뤬ޤƤΥݡȤ̿ǽޤbond ˽°륤
եñ쥹åʣΥݡȤ뤫⤷ʤΤǡå(
Ū)ƤΥݡȤ̿ݡbond ǥХƱѥåȤʣΥԡ(1
졼֥ǥХ1)ޤ

%	The duplicated packet behavior is switch dependent, some
%switches exhibit this, and some do not.  On switches that display this
%behavior, it can be induced by clearing the MAC forwarding table (on
%most Cisco switches, the privileged command "clear mac address-table
%dynamic" will accomplish this).
%
ʣѥåȤεưϥå˰¸εư򼨤å⤢Сʤ
å⤢ޤεư򼨤åǤϡMAC žơ֥ΥꥢͶ
ȯޤ(ۤȤɤ Cisco åǤϡøޥɡclear mac
address-table dynamicפ¹Ԥޤ)

%14. Hardware Specific Considerations
%====================================
%
14. ϡɥ̤ιθ
========================

%	This section contains additional information for configuring
%bonding on specific hardware platforms, or for interfacing bonding
%with particular switches or other devices.
%
Υϡϡɥץåȥե bonding ꡢ뤤
Υå¾ΥǥХȤ bonding ³ˤĤƤɲþޤߤޤ

14.1 IBM BladeCenter
--------------------

%	This applies to the JS20 and similar systems.
%
 JS20 ȡƱͤΥƥŬѤޤ

%	On the JS20 blades, the bonding driver supports only
%balance-rr, active-backup, balance-tlb and balance-alb modes.  This is
%largely due to the network topology inside the BladeCenter, detailed
%below.
%
JS20 ֥졼ɤǤϡbonding ɥ饤Ф balance-rractive-backupbalance-tlb
balance-alb ⡼ɤΤߥݡȤޤϼˡ BladeCenter 
ΥͥåȥȥݥˤΤǤ

%JS20 network adapter information
%--------------------------------
%
JS20 ͥåȥץ
-----------------------------

%	All JS20s come with two Broadcom Gigabit Ethernet ports
%integrated on the planar (that's "motherboard" in IBM-speak).  In the
%BladeCenter chassis, the eth0 port of all JS20 blades is hard wired to
%I/O Module #1; similarly, all eth1 ports are wired to I/O Module #2.
%An add-on Broadcom daughter card can be installed on a JS20 to provide
%two more Gigabit Ethernet ports.  These ports, eth2 and eth3, are
%wired to I/O Modules 3 and 4, respectively.
%
ƤJS20 ˤϡplanar (줬 IBM θ֥ޥܡɡפǤ)礵줿 
Broadcom ΥӥåȥͥåȥݡȤĤޤBlaceCenter Υ㡼
ϡ JS20 ֥졼ɤ eth0 ݡȤI/O ⥸塼룱֤ľ(hard wired)
ƤޤƱͤˡƤ eth1 ݡȤ I/O ⥸塼룲֤Ƥޤ
ȣĤΥӥåȥͥåȥݡȤ󶡤١ɲä Broadcom ɡ
 JS20 ƳǤޤΥݡȡeth2  eth3  I/O ⥸塼룳֤ȣ
֤ˤ줾Ƥޤ

%	Each I/O Module may contain either a switch or a passthrough
%module (which allows ports to be directly connected to an external
%switch).  Some bonding modes require a specific BladeCenter internal
%network topology in order to function; these are detailed below.
%
 I/O ⥸塼ϣĤΥå(ݡȤľܳΥå³)ѥ
롼⥸塼Τɤ餫ޤߤޤĤ bonding ⡼ɤϡǽ뤿
 BladeCenter ͥåȥ⥸塼ȥݥ׵ᤷޤϲ
ǾҲ𤷤ޤ

%	Additional BladeCenter-specific networking information can be
%found in two IBM Redbooks (www.ibm.com/redbooks):
%
ɲä BladeCenter òͥåȥ IBM åɥ֥å
(www.ibm.com/redbooks)ˤޤ

"IBM eServer BladeCenter Networking Options"
"IBM eServer BladeCenter Layer 2-7 Network Switching"

%BladeCenter networking configuration
%------------------------------------
%
BladeCenter ͥåȥ
----------------------------

%	Because a BladeCenter can be configured in a very large number
%of ways, this discussion will be confined to describing basic
%configurations.
%
BladeCenter ¿ˡǤΤǡεǤϴŪ
¤ޤ

%	Normally, Ethernet Switch Modules (ESMs) are used in I/O
%modules 1 and 2.  In this configuration, the eth0 and eth1 ports of a
%JS20 will be connected to different internal switches (in the
%respective I/O modules).
%
̾ͥåȥå⥸塼(ESM) I/O ⥸塼룱֤ȣ֤Ѥޤ
ǤϡJS20  eth0  eth1 ݡȤ(줾 I/O ⥸塼ˤ)ۤ
å³ޤ

%	A passthrough module (OPM or CPM, optical or copper,
%passthrough module) connects the I/O module directly to an external
%switch.  By using PMs in I/O module #1 and #2, the eth0 and eth1
%interfaces of a JS20 can be redirected to the outside world and
%connected to a common external switch.
%
ѥ롼⥸塼(OPM()ޤ CPM(Ƽ)ѥ롼⥸塼) I/O ⥸塼
ľܳå³ޤI/O ⥸塼룱֤ȣ֤Υѥ롼⥸塼
λѤˤꡢJS20  eth0  eth1 󥿡ե˥쥯Ȥ
Ūʳå³ޤ

%	Depending upon the mix of ESMs and PMs, the network will
%appear to bonding as either a single switch topology (all PMs) or as a
%multiple switch topology (one or more ESMs, zero or more PMs).  It is
%also possible to connect ESMs together, resulting in a configuration
%much like the example in "High Availability in a Multiple Switch
%Topology," above.
%
ESM ȥѥ롼⥸塼(PM)κˤꡢͥåȥñ쥹åȥݥ
( PM)ʣͥåȥȥݥ(1İʾ ESM0 ʾ PM)Τ줫Ȥ 
bonding 鸫ޤϤޤESM ³̤Ȥƾ嵭Ρʣ
ȥݥιפǤˤ褯ˤǤޤ

%Requirements for specific modes
%-------------------------------
%
Υ⡼ɤ׷
------------------

%	The balance-rr mode requires the use of passthrough modules
%for devices in the bond, all connected to an common external switch.
%That switch must be configured for "etherchannel" or "trunking" on the
%appropriate ports, as is usual for balance-rr.
%
balance-rr ⡼ɤϡbond ΥǥХѤˡ̤γåؤ٤Ƥ³
ѥ롼⥸塼뷲λѤ׵ᤷޤΥåϡŬڤʥݡȤ֥
ͥϡ֥ȥ󥭥󥰡פꤹɬפޤbalance-rr ѤˤϤ
Τ̤Ǥ

%	The balance-alb and balance-tlb modes will function with
%either switch modules or passthrough modules (or a mix).  The only
%specific requirement for these modes is that all network interfaces
%must be able to reach all destinations for traffic sent over the
%bonding device (i.e., the network must converge at some point outside
%the BladeCenter).
%
balance-alb  balance-tlb ⡼ɤϥå⥸塼ȥѥ롼⥸塼Τ
餫(뤤Ϻ)ǵǽޤΥ⡼ɤͣͭ׷ϡƤΥͥå
󥿡եbonding ǥХͳ̿ΰ٤ˡƤŪ
ǤʤƤϤʤʤǤ(Ĥޤꡢͥåȥ BladeCenter γ¦Τɤ
˽椷Ƥɬפޤ)

%	The active-backup mode has no additional requirements.
%
active-backup ⡼ɤˤɲ׷Ϥޤ

%Link monitoring issues
%----------------------
%
󥯴ƻ
--------------

%	When an Ethernet Switch Module is in place, only the ARP
%monitor will reliably detect link loss to an external switch.  This is
%nothing unusual, but examination of the BladeCenter cabinet would
%suggest that the "external" network ports are the ethernet ports for
%the system, when it fact there is a switch between these "external"
%ports and the devices on the JS20 system itself.  The MII monitor is
%only able to detect link failures between the ESM and the JS20 system.
%
ͥåȥå⥸塼뤬Ȥ߹ޤƤARP ƻΤߤΥå
ȤΥ󥯥μ¤˸Τޤ̤ʻǤϤʤBladeCenter Ȣ
ˤ褦ˡֳץͥåȥݡȤϤΥƥΥͥåȥݡȤǤꡢ
ֳץݡȤ JS20 ƥ༫ΤΥǥХȤδ֤ˤϥåĤȤ
ǤMII ƻESM  JS20 ƥ֤Υ󥯼ԤθΤΤ߲ǽǤ

%	When a passthrough module is in place, the MII monitor does
%detect failures to the "external" port, which is then directly
%connected to the JS20 system.
%
ѥ롼⥸塼뤬Ȥ߹ޤƤ硢MII ƻ JS20 ƥľ³
줿ֳץݡȤμԤΤޤ

%Other concerns
%--------------
%
¾δϢ
------------

%	The Serial Over LAN (SoL) link is established over the primary
%ethernet (eth0) only, therefore, any loss of link to eth0 will result
%in losing your SoL connection.  It will not fail over with other
%network traffic, as the SoL system is beyond the control of the
%bonding driver.
%
ꥢ Over LAN (SoL) 󥯤ϤҤȤܤΥͥå(eth0)ǤΤ߳Ωޤ 
äơeth0 ؤΥ󥯥 SoL ³򼺤̤ˤʤޤSoL ƥˤ 
bonding ɥ饤Ф椬ڤФʤΤǡ¾Υͥåȥ̿˥ե륪Фޤ


%	It may be desirable to disable spanning tree on the switch
%(either the internal Ethernet Switch Module, or an external switch) to
%avoid fail-over delay issues when using bonding.
%
bonding ѻ˥ե륪ٱ򤹤٤ˤϡ( ESM ȳΥ
Τɤ餫)åΥѥ˥󥰥ĥ꡼̵˾ޤ⤷ޤ

%15. Frequently Asked Questions
%==============================
%
15. 褯
================

%1.  Is it SMP safe?
1.  bonding  SMP դǤ

%	Yes. The old 2.0.xx channel bonding patch was not SMP safe.
%The new driver was designed to be SMP safe from the start.
%
ϤŤ 2.0.xx ͥѥå SMP դǤϤޤǤ
饤ФϺǽ餫 SMP դˤʤ褦߷פޤ

%2.  What type of cards will work with it?
%
2. ɤΥפΥɤ bonding ǵǽޤ

%	Any Ethernet type cards (you can even mix cards - a Intel
%EtherExpress PRO/100 and a 3com 3c905b, for example).  For most modes,
%devices need not be of the same speed.
%
ɤΥͥåȥפΥɤǤⵡǽޤ(ɤκǤǤޤ㤨С
Intel EtherExpress PRO/100  3com 3c905b)ۤȤɤΥ⡼ɤǤϡǥХƱ
®٤Ǥɬפޤ

%	Starting with version 3.2.1, bonding also supports Infiniband
%slaves in active-backup mode.
%
С 3.2.1 ꡢbonding  active-backup ⡼ɤ Infiniband 졼֤⥵
ݡȤޤ

%3.  How many bonding devices can I have?
%
3.  bonding ǥХϤĺޤ

%	There is no limit.
%
̵¤Ǥ

%4.  How many slaves can a bonding device have?
%
4.  Ĥ bonding ǥХˤϥ졼֤򤤤Ĳäޤ

%	This is limited only by the number of network interfaces Linux
%supports and/or the number of network cards you can place in your
%system.
%
Linux ݡȤͥåȥ󥿡ե뤤ϥƥȤ߹
ͥåȥɿǤΤ¤ޤ

%5.  What happens when a slave link dies?
%
5.  졼֥󥯤˲ޤ

%	If link monitoring is enabled, then the failing device will be
%disabled.  The active-backup mode will fail over to a backup link, and
%other modes will ignore the failed link.  The link will continue to be
%monitored, and should it recover, it will rejoin the bond (in whatever
%manner is appropriate for the mode). See the sections on High
%Availability and the documentation for each mode for additional
%information.
%
󥯴ƻ뤬ͭʾ硢ԤǥХ̵ޤactive-backup ⡼ɤ
ϥХååץ󥯤˥ե륪Ф¾Υ⡼ɤǤϼԤ󥯤̵뤵
󥯴ƻϷ³졢θ󥯤줷硢󥯤 bond ˺ٲä
ޤ(⡼ɤˤդ路餫ˡ)ʾξϹξϤȳƥ⡼
ΥɥȤ򻲾ȤƤ
	
%	Link monitoring can be enabled via either the miimon or
%arp_interval parameters (described in the module parameters section,
%above).  In general, miimon monitors the carrier state as sensed by
%the underlying network device, and the arp monitor (arp_interval)
%monitors connectivity to another host on the local network.
%
󥯴ƻ(嵭⥸塼ѥ᡼Ϥ) miimon ޤ arp_interval 
᡼Τɤ餫ͭˤǤޤ̤ˡmiimon ϺΥͥåȥǥХ
ˤ긡Τ줿ꥢ֤ƻ뤷ARP ƻ(arp_interval) LAN ¾Υۥ
ȤȤ³ƻ뤷ޤ

%	If no link monitoring is configured, the bonding driver will
%be unable to detect link failures, and will assume that all links are
%always available.  This will likely result in lost packets, and a
%resulting degradation of performance.  The precise performance loss
%depends upon the bonding mode and network configuration.
%
󥯴ƻ뤬ꤵƤʤ硢bonding ɥ饤Фϥ󥯼ԤΤǤ
Υ󥯤ѲǽǤȲꤷޤϥѥåȥǽ㲼η̤ˤ
꤫ͤޤ󡣸̩ǽ㲼 bonding ⡼ɤȥͥåȥ˰¸ޤ

%6.  Can bonding be used for High Availability?
%
6.  bonding ϹѤ˻ѤǤޤ

%	Yes.  See the section on High Availability for details.
%
Ϥܺ٤ϹξϤ򻲾Ȳ

%7.  Which switches/systems does it work with?
%
7.  ɤΥåƥब bonding Ȱ˻Ȥޤ

%	The full answer to this depends upon the desired mode.
%
δʲϴ˾⡼ɤ˰¸ޤ

%	In the basic balance modes (balance-rr and balance-xor), it
%works with any system that supports etherchannel (also called
%trunking).  Most managed switches currently available have such
%support, and many unmanaged switches as well.
%
Ūʬ⡼(balance-rr  balance-xor)Ǥϡͥ(ȥ󥭥
ȤƤФ)򥵥ݡȤɤΥƥȤǤⵡǽޤѤǤۤȤ
ɤǽåϤΥݡȤꡢ¿μưåǤƱͤǤ

%	The advanced balance modes (balance-tlb and balance-alb) do
%not have special switch requirements, but do need device drivers that
%support specific features (described in the appropriate section under
%module parameters, above).
%
ʬ⡼(balance-tlbbalance-alb)̤ʥå׷郎ޤ󤬡
εǽ򥵥ݡȤǥХɥ饤ФɬפǤ(嵭Υ⥸塼ѥ᡼
ŬڤʥƤޤ)

%	In 802.3ad mode, it works with systems that support IEEE
%802.3ad Dynamic Link Aggregation.  Most managed and many unmanaged
%switches currently available support 802.3ad.
%
802.3ad ⡼ɤǤϡIEEE 802.3ad ưŪ󥯽򥵥ݡȤƥȰư
ޤߡۤȤɤǽʥå¿μưå 802.3ad 
ݡȤޤ

%        The active-backup mode should work with any Layer-II switch.
%
active-backup ⡼ɤϥ쥤䡼åȰưޤ

%8.  Where does a bonding device get its MAC address from?
%
8.  bonding ǥХϤɤ MAC ɥ쥹ޤ

%	When using slave devices that have fixed MAC addresses, or when
%the fail_over_mac option is enabled, the bonding device's MAC address is
%the MAC address of the active slave.
%
 MAC ɥ쥹ĥ졼֥ǥХѻ뤤 fail_over_mac ץ
ͭbonding ǥХ MAC ɥ쥹ϥƥ֥졼֤ MAC ɥ쥹Ǥ
%
%	For other configurations, if not explicitly configured (with
%ifconfig or ip link), the MAC address of the bonding device is taken from
%its first slave device.  This MAC address is then passed to all following
%slaves and remains persistent (even if the first slave is removed) until
%the bonding device is brought down or reconfigured.
%
¾Ǥϡ(ifconfig ޤ ip link )ŪꤷƤʤ硢bonding 
Х MAC ɥ쥹ϤκǽΥ졼֥ǥХޤ MAC ɥ
Ϥθ³졼ƤϤ졢bonding ǥХˤʤ뤫ꤵ
ޤ(ǽΥ졼֤줿Ǥ)³Ū˻Ĥޤ

%	If you wish to change the MAC address, you can set it with
%ifconfig or ip link:
%
MAC ɥ쥹ѹ硢ifconfig ޤ ip link Ǥޤ

# ifconfig bond0 hw ether 00:11:22:33:44:55

# ip link set bond0 address 66:77:88:99:aa:bb

%	The MAC address can be also changed by bringing down/up the
%device and then changing its slaves (or their order):
%
ޤǥХΥ󥢥åפȡ줫饹졼(뤤ϥ졼֤ν)ѹ
줿ˤ MAC ɥ쥹ѹޤ

# ifconfig bond0 down ; modprobe -r bonding
# ifconfig bond0 .... up
# ifenslave bond0 eth...

%	This method will automatically take the address from the next
%slave that is added.
%
ˡϡɲä줿Υ졼֤饢ɥ쥹ưŪ˼ޤ

%	To restore your slaves' MAC addresses, you need to detach them
%from the bond (`ifenslave -d bond0 eth0'). The bonding driver will
%then restore the MAC addresses that the slaves had before they were
%enslaved.
%
졼֤ MAC ɥ쥹٤ˤϡbond 饹졼֤곰ɬפ
(`ifenslave -d bond0 eth0`)ˤꡢbonding ɥ饤Фϥ졼ֲ
˥졼֤äƤ MAC ɥ쥹ޤ

%16. Resources and Links
%=======================
%
16. ȥ
================

%The latest version of the bonding driver can be found in the latest
%version of the linux kernel, found on http://kernel.org
%
bonding ɥ饤ФκǿС http://kernel.org ˤǿ Linux ͥ
ˤޤ

%The latest version of this document can be found in either the latest
%kernel source (named Documentation/networking/bonding.txt), or on the
%bonding sourceforge site:
%
ΥɥȤκǿС⡢ǿΥͥ륽
(Documentation/networking/bonding.txt Ȥ̾)bonding sourceforge 
Τ줫ˤޤ

http://www.sourceforge.net/projects/bonding

%Discussions regarding the bonding driver take place primarily on the
%bonding-devel mailing list, hosted at sourceforge.net.  If you have
%questions or problems, post them to the list.  The list address is:
%
bonding ɥ饤Ф˴ؤϡsourceforge.net ǥۥƥ󥰤Ƥ 
bonding-devel ᡼󥰥ꥹȤǼ˹ԤƤޤ꤬С᡼
󥰥ꥹȤƤƤɥ쥹Ϥ顧

bonding-devel@lists.sourceforge.net

%	The administrative interface (to subscribe or unsubscribe) can
%be found at:
%
᡼󥰥ꥹȤδ󥿡ե(뤤æ)Ϥ顧

https://lists.sourceforge.net/lists/listinfo/bonding-devel

%Donald Becker's Ethernet Drivers and diag programs may be found at :
%
Donald Becker Υͥåȥɥ饤ФȸץϤ顧

 - http://www.scyld.com/network/

%You will also find a lot of information regarding Ethernet, NWay, MII,
%etc. at www.scyld.com.
%
ͥåȡNWayMII ˴ؤ̤ξ www.scyld.com ˤޤ

-- END --
