 
		Linux Ethernet Bonding Driver HOWTO

%		Latest update: 12 November 2007
%
		最終更新：2007年11月12日

%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年 4月24日
  - 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 ドライバがまだロードされていな
	い場合は、bond0、bond1、bond2 が作成されます。デフォルト値は 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 4、CentOS 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.
%
	どのスレーブが最初のデバイスかを指定する文字列(eth0、eth2、他)。指定され
	たデバイスは、それが利用可能な場合は常にアクティブなスレーブになります。
	最初のデバイスがオフラインになった時のみ、別のデバイスが選択されます。こ
	のオプションは、１つのスレーブが別のものよりも優先される場合、例えば、１
	スレーブが別スレーブより速度が速い場合に便利です。

%	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-bond1、等々。sysconfig ネットワーク設定システムは複
数の 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.

サンプルの BROADCAST、IPADDR、NETMASK、NETWORK 値をあなたのネットワークの適切な
値で置き換えて下さい。

%	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.
%
ネットワーク固有行(IPADDR、NETMASK、NETWORK、BROADCAST)をあなたのネットワーク設
定に一致するように確実に変更して下さい。

%	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.local、initscripts では /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 デバイス(eth0、eth1 と仮定します)の簡単な 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:
%
新しい bond「foo」の追加：
%
# echo +foo > /sys/class/net/bonding_masters

%To remove an existing bond bar:
%
既存の bond「bar」の削除：
%
# 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-backup、balance-tlb、balance-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-rr、balance-xor、broadcast モードは一般に、スイッチがグループ化された適
切なポート群を持つ事を要求します。このようなグループの専門用語はスイッチ間で異な
りますが、(上記の 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).
%
eth0、eth1 のどちらも 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-rr、balance-xor、broadcast、802.3ad モードでは、promiscuous モード設定は
全てのスレーブに広められます。

%	For the active-backup, balance-tlb and balance-alb modes, the
%promiscuous mode setting is propagated only to the active slave.
%
active-backup、balance-tlb、balance-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-backup、balance-tlb、balance-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-rr、active-backup、balance-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つ以上の ESM、0 以上の 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-tlb、balance-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.
%
イーサネット、NWay、MII 等に関する大量の情報が www.scyld.com にあります。

-- END --
