LinuxのNICを冗長化するボンディング設定｜nmcliでactive-backup・balance-rrを構成してフェイルオーバーを確認する

この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）

ＨＯＭＥ＞ Linux技術リナックスマスター.JP（Linuxマスター.JP）＞ Linuxtips ＞ネットワーク＞ LinuxのNICを冗長化するボンディング設定｜nmcliでactive-backup・balance-rrを構成してフェイルオーバーを確認する

「本番サーバーのNICが壊れて、夜中に突然ネットワークが切れた」— そういうインシデントはどのエンジニアのキャリアにも一度は訪れる。
物理ポートの接触不良、NICチップの故障、スイッチ側のポート障害は予告なくやってくる。だからこそ「NICを2枚束ねて、片方が落ちても通信を継続させる」ボンディング設定が、本番Linuxサーバーの基本設計として重要になる。

この記事では、RHEL 9 / Rocky Linux 9 を例に、nmcliコマンドでNICボンディングを構成する実践手順を解説する。フェイルオーバー専用の active-backup モードと負荷分散の balance-rr モードの使い分け、/proc/net/bonding/ での動作確認、フェイルオーバーテストの方法、よくある設定ミスの対処まで、ハンズオン形式でまとめた。

この記事のポイント

・nmcliでbondインターフェースを作りスレーブNICを追加する3ステップで設定できる
・active-backupはスイッチ設定不要で冗長化できるため、現場での第一選択肢
・/proc/net/bonding/bond0でアクティブスレーブの状態をリアルタイムに把握できる
・フェイルオーバーはip link set downでシミュレーションして本番投入前に必ず確認する

「このままじゃマズい」と感じていませんか？

参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。

姓・名・メールの3つだけ／30秒／解除は3秒／詳細はこちら

NICボンディングとは何か — ネットワーク冗長化の仕組み

NICボンディング（またはリンクアグリゲーション）とは、複数の物理NICを1つの論理インターフェースとして束ねるLinuxカーネルの機能だ。Windowsではチーミングとも呼ばれる。

ボンディングには大きく2つの目的がある。

・フェイルオーバー（冗長化）: 片方のNICが故障・切断されても、もう一方が即座に引き継ぎ、通信断の時間を最小化する
・負荷分散（スループット向上）: 複数のNICにパケットを振り分け、実効帯域幅を向上させる

コスト面でも優れている。高価なデュアルポートNICを1枚使うより、安価なシングルポートNICを2枚使ってボンディングする構成のほうが現場では多い。

ボンディングモードの種類と選び方

Linuxのボンディングモードは7種類ある。現場で使うのはほぼ以下の3つに絞られる。

モード	名称	特徴	スイッチ側の設定
mode=1	active-backup	1枚がアクティブ・残りは待機。フェイルオーバー専用	不要（通常ポートでOK）
mode=0	balance-rr	パケットをRound-RobinでNICに振り分ける。スループット向上	ポートトランク等が必要
mode=4	802.3ad (LACP)	LACPプロトコルで動的なリンク集約。冗長性とスループットを両立	LACP対応スイッチ必須

1. どのモードを選ぶか

現場での優先基準はシンプルだ。

・まずactive-backupから始める: スイッチ側の設定変更が不要で、トラブル時のリスクが最小。物理サーバーに2枚NICがあればこれ一択
・スループット向上が必要なら802.3ad: スイッチがLACPをサポートしており、ネットワーク担当と連携できる場合のみ検討する
・balance-rrは原則避ける: スイッチ側の対応なしにbalance-rrを使うと同一フローのパケットが複数ポートから出て順序が乱れ、TCP通信に悪影響が出ることがある

2. miimon（リンク監視間隔）の設定

ボンディングが障害を検知する方法には「MIIモニタリング（miimon）」と「ARPモニタリング（arp_interval）」の2種類がある。NICがリンク状態を正確に報告できる環境（物理サーバーの大半）では miimon=100（100ミリ秒間隔）を指定するのが定番だ。この値が小さすぎると不要なフェイルオーバーが発生し、大きすぎると障害検知が遅くなる。

nmcliでactive-backupボンディングを設定する手順

実行環境: Rocky Linux 9.3 / RHEL 9.4（NetworkManager 1.44）
使用NIC: eno1（物理NIC1）、eno2（物理NIC2）

1. 現在のNICとコネクション名を確認する

まず既存の構成を確認する。

# デバイス一覧と接続状態を確認 nmcli device status

実行結果（svr01 での確認例）:

DEVICE TYPE STATE CONNECTION eno1 ethernet connected eno1-connection eno2 ethernet disconnected -- lo loopback unmanaged --

eno1 に既存コネクション（eno1-connection 等）がある場合、ボンディング設定後に削除または無効化する必要がある。

2. bondインターフェースを作成する

nmcli connection add type bond con-name bond0 ifname bond0 bond.options "mode=active-backup,miimon=100"

・type bond: ボンドタイプのコネクションを作成
・con-name bond0: NetworkManagerが管理するコネクション名
・ifname bond0: カーネルが認識するネットワークインターフェース名
・bond.options "mode=active-backup,miimon=100": ボンディングモードとリンク監視間隔

3. スレーブインターフェース（eno1・eno2）をbond0に追加する

# eno1をbond0のスレーブとして追加 nmcli connection add type ethernet con-name bond0-slave-eno1 ifname eno1 master bond0 # eno2をbond0のスレーブとして追加 nmcli connection add type ethernet con-name bond0-slave-eno2 ifname eno2 master bond0

重要なのはスレーブ側のコネクションにIPアドレスを設定しないことだ。IPアドレスはbond0インターフェース側にのみ設定する。スレーブにIPを設定してしまうと、フェイルオーバー時にIPが移動せず冗長化の意味がなくなる。

4. IPアドレスとDNSをbond0に設定する

nmcli connection modify bond0 ipv4.method manual ipv4.addresses "192.168.1.100/24" ipv4.gateway "192.168.1.1" ipv4.dns "192.168.1.1"

DNSの設定は /etc/resolv.conf への反映も連動して行われる。nmcli で設定したDNSサーバーがどのように名前解決に使われるかは、Linux DNS 設定の基本で詳しく解説している。

5. コネクションを有効化する

# 先にbond0を有効化してからスレーブを有効化する（順番が重要） nmcli connection up bond0 nmcli connection up bond0-slave-eno1 nmcli connection up bond0-slave-eno2 # 既存のeno1コネクションを切断・削除する nmcli connection down eno1-connection nmcli connection delete eno1-connection

SSHでリモート接続中に設定変更する場合は必ず bond0 を先に up してから既存コネクションを切断すること。順番を逆にすると接続が切れてしまい、リモートから復旧できなくなる。

ボンディングの動作確認（/proc/net/bonding/bond0）

設定後は /proc/net/bonding/bond0 を確認する。カーネルが管理するボンディング状態を最も直接的に確認できるファイルだ。

cat /proc/net/bonding/bond0

実行結果（svr01 での実測例）:

Ethernet Channel Bonding Driver: v6.4.0-0.rc7.20230615gitf78d4d6d8a8c Bonding Mode: fault-tolerance (active-backup) Primary Slave: None Currently Active Slave: eno1 MII Status: up MII Polling Interval (ms): 100 Up Delay (ms): 0 Down Delay (ms): 0 Slave Interface: eno1 MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: 52:54:00:ab:cd:ef Slave queue ID: 0 Slave Interface: eno2 MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: 52:54:00:ab:cd:f0 Slave queue ID: 0

確認ポイント:
・Bonding Mode: fault-tolerance (active-backup) — 設定したモードが反映されていること
・Currently Active Slave: eno1 — 現在どちらのNICがアクティブに通信しているか
・両スレーブの MII Status: up — 両方ともリンクアップしていること
・Link Failure Count: 0 — フェイルオーバーの発生回数（障害後に増える）

加えて、IPアドレスが bond0 に付与されていることも確認する。

ip addr show bond0

実行結果:

3: bond0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 52:54:00:ab:cd:ef brd ff:ff:ff:ff:ff:ff inet 192.168.1.100/24 brd 192.168.1.255 scope global noprefixroute bond0 valid_lft forever preferred_lft forever inet6 fe80::5054:ab:cdef/64 scope link valid_lft forever preferred_lft forever

state UP と inet 192.168.1.100/24 が確認できれば設定は正常だ。

フェイルオーバーのテスト — NIC障害をシミュレートする

設定が正しくても「本当にフェイルオーバーが機能するか」を確認しておかないと意味がない。本番投入前に必ずテストを実施すること。

1. フェイルオーバーのテスト手順

# 別端末からpingを連続実行して監視する ping -i 0.2 192.168.1.100 # アクティブなスレーブ（eno1）を意図的に落とす ip link set eno1 down # フェイルオーバー後の状態を確認する cat /proc/net/bonding/bond0

フェイルオーバー後の出力（抜粋）:

Currently Active Slave: eno2 Slave Interface: eno1 MII Status: down Speed: Unknown Duplex: Unknown Link Failure Count: 1

Currently Active Slave が eno2 に切り替わり、eno1 の MII Status が down、Link Failure Count が 1 に増えていればフェイルオーバーは正常に機能している。ping の応答は miimon=100（100ミリ秒）程度の中断後に継続されるはずだ。

2. テスト後の復旧

# eno1を復帰させる ip link set eno1 up # eno1がスタンバイスレーブとして復帰したことを確認 cat /proc/net/bonding/bond0

復帰後も Currently Active Slave は eno2 のままになる（active-backup では切り替え後にアクティブスレーブは変わらない）。主系を eno1 に戻したい場合は nmcli connection modify bond0 bond.options "mode=active-backup,miimon=100,primary=eno1" で primary スレーブを指定する。

ネットワーク設定の変更に自信がない場合は、Linux Master Pro Seminar のハンズオン環境で仮想NICを使って事前に練習しておくとよい。本番機と同等の構成を安全に試せる。

トラブルシュート

ボンドが有効にならない（state DOWN）

ip addr show bond0 で state DOWN が表示される場合は、スレーブが一つも追加されていないか、スレーブのコネクションが有効化されていない可能性が高い。

# コネクションの状態一覧を確認する nmcli connection show

bond0-slave-eno1 と bond0-slave-eno2 が表示されていても STATE が -- の場合はまだ有効化されていない。

nmcli connection up bond0-slave-eno1 nmcli connection up bond0-slave-eno2

スレーブがbond0に追加されない

eno1 に既存のコネクションが残っていると、スレーブコネクションが競合して接続できないことがある。

# eno1に存在するコネクション一覧を確認 nmcli connection show | grep eno1 # 競合するコネクションを削除 nmcli connection delete eno1-connection

再起動後にボンディングが復活しない

connection.autoconnect が無効になっているケースだ。

# 全コネクションの自動接続を有効化 nmcli connection modify bond0 connection.autoconnect yes nmcli connection modify bond0-slave-eno1 connection.autoconnect yes nmcli connection modify bond0-slave-eno2 connection.autoconnect yes

仮想環境（KVM・VMware）でスレーブが認識されない

仮想NICは物理NICと異なりリンクアップ・ダウンのシグナルがMIIモニタリングで検出されないことがある。この場合は miimon の代わりに arp_interval と arp_ip_target を使ったARPモニタリングに切り替える。


nmcli connection modify bond0   bond.options "mode=active-backup,arp_interval=200,arp_ip_target=192.168.1.1"

balance-rrに変更する場合の注意点

負荷分散が必要でスイッチ側がサポートしている場合は、以下のコマンドでモードを変更できる。

nmcli connection modify bond0 bond.options "mode=balance-rr,miimon=100" nmcli connection down bond0 && nmcli connection up bond0

ただし、balance-rr をスイッチ側の設定なしに使うと同一フローのパケットが2つの物理ポートから出るためTCP接続が不安定になることがある。スイッチがポートトランク（LAG）に対応していない場合は、素直に active-backup を使い続けること。

まとめ

やりたいこと	コマンド
bondインターフェースを作成する	`nmcli connection add type bond con-name bond0 ifname bond0 bond.options "mode=active-backup,miimon=100"`
NICをスレーブとして追加する	`nmcli connection add type ethernet con-name bond0-slave-eno1 ifname eno1 master bond0`
bondにIPアドレスを設定する	`nmcli connection modify bond0 ipv4.method manual ipv4.addresses "192.168.1.100/24" ipv4.gateway "192.168.1.1"`
コネクションを有効化する	`nmcli connection up bond0`（bond0 → スレーブの順で実行）
スレーブの状態を確認する	`cat /proc/net/bonding/bond0`
フェイルオーバーをテストする	`ip link set eno1 down`（テスト後は `ip link set eno1 up`）
再起動後の自動接続を有効化する	`nmcli connection modify bond0 connection.autoconnect yes`

NICボンディングはスイッチ側の設定変更が不要な active-backup から始めるのが現場の定石だ。設定後はフェイルオーバーテストまで実施して、実際にNICを落として切り替わることを確認しておこう。

現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、NICボンディングから実務的なサーバー運用設計まで実機ハンズオンで学べるLinux Master Pro Seminarでは、3,100名以上の受講実績を持つ少人数制・RHEL10対応のカリキュラムを提供しています。詳細・申込はセミナーLPからご確認ください。

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。