systemd-networkd Bond／LACP 設定移行と NIC フェイルオーバー検証

レガシー設定から systemd-networkd への移行が求められる背景

サーバの冗長化構成では、複数のNICを束ねるBonding（チーミング）が定番手法です。従来はNetworkManagerやifupdown（/etc/network/interfaces）、あるいはディストリビューション独自のifcfgスクリプトで管理するのが一般的でした。しかし現在のUbuntu 22.04/24.04やRHEL 9系では、systemdが提供するsystemd-networkdを標準ネットワークバックエンドとして採用するケースが増えており、コンテナ・クラウド・自動プロビジョニング環境との親和性の高さから移行が進んでいます。

LACP（IEEE 802.3ad、Bondingモード4）はスイッチ側とのリンクアグリゲーションを実現するプロトコルです。帯域集約と冗長性を同時に得られる構成として、データセンターや仮想化ホストで広く使われています。systemd-networkdではこのLACPを含むすべてのBondingモードを宣言的なINIスタイルのファイルで管理できます。NetworkManagerの設定とは構文が異なるため、既存環境からの移行時には設定ファイルの書き直しが必要です。

systemd-networkd の Bond 設定に使う2種類のファイル

systemd-networkdでBondを構成するには、主に.netdevファイルと.networkファイルの2種類を/etc/systemd/network/配下に配置します。両者の役割を整理しておきます。

• .netdev：仮想ネットワークデバイス（Bond・VLAN・Bridgeなど）そのものを定義します。デバイス名やBondingモードはここで指定します。
• .network：物理NICや仮想デバイスのIP設定、どのBondデバイスに属するかを定義します。メンバーNICにはBond=で親デバイスを指定します。

ファイル名の先頭数字はロード順を制御します。10-bond0.netdev→20-eth0.network→20-eth1.network→30-bond0.networkのような命名規則が一般的です。ファイルの評価順序が依存関係に影響するため、.netdevを先に処理させる番号を振るとトラブルを避けやすくなります。

設定手順：LACP（mode 4）の具体的な記述例

以下は物理NIC 2枚（eth0・eth1）をLACPでまとめる想定例です。実際のNIC名はディストリビューションや予測可能デバイス名（ens3・enp2s0など）に合わせてください。

/etc/systemd/network/10-bond0.netdev

[NetDev]
Name=bond0
Kind=bond

[Bond]
Mode=802.3ad
TransmitHashPolicy=layer2+3
LACPTransmitRate=fast
MIIMonitorSec=100ms

Mode=802.3adがLACPに相当します。TransmitHashPolicy=layer2+3はMACアドレスとIPアドレスを組み合わせて送信先NICを選択するポリシーで、L3トラフィックの分散効率が向上します。LACPTransmitRate=fastはLACPDUを1秒ごとに送信する設定で、フェイルオーバー検知を早めたい場合に指定します（デフォルトは30秒ごとのslow）。

/etc/systemd/network/20-eth0.network および 20-eth1.network

[Match]
Name=eth0

[Network]
Bond=bond0

eth1側も同様にName=eth1・Bond=bond0と記述します。メンバーNICにはIPアドレスを付与せず、Bond親デバイスへの帰属だけを定義します。

/etc/systemd/network/30-bond0.network

[Match]
Name=bond0

[Network]
Address=192.168.10.100/24
Gateway=192.168.10.1
DNS=192.168.10.1

DHCPを使う場合はAddress=とGateway=の代わりにDHCP=yesを記述します。ファイルを作成したら以下のコマンドで反映します。

sudo systemctl restart systemd-networkd

設定適用後の動作確認

設定が正常に適用されたかはnetworkctlコマンドで確認できます。

networkctl status bond0

出力にState: routable (configured)とBond Slaves: eth0 eth1が含まれていれば基本動作は問題ありません。IPアドレスの付与状況はip addr show bond0で確認します。

LACPのネゴシエーション詳細は/proc/net/bonding/bond0で確認できます。

cat /proc/net/bonding/bond0

スレーブごとのMII Statusがup、Aggregator IDが一致していることを確認します。LACPが正常にネゴシエートされているとPartner KeyとActor Keyが一致した状態で表示されます。スイッチ側でLACPが有効になっていない場合はACTORとPARTNERの情報が揃わず、フォールバック状態になります。スイッチのポートチャネル設定も合わせて確認してください。

NIC フェイルオーバーの検証手順

冗長構成の要はフェイルオーバーが実際に機能するかどうかの確認です。物理環境での代表的な検証手順を示します。

手順1：ping を流しながらメンバー NIC を無効化

# 別ターミナルで継続 ping を起動
ping -i 0.2 192.168.10.1

# 片方の NIC をダウンさせる
sudo ip link set eth0 down

正常なフェイルオーバーであればpingのロストは0～数パケット以内に収まり、その後も疎通が継続します。ロストが長引く場合はMIIMonitorSecの値やスイッチ側のLACP設定を見直します。

手順2：ケーブル抜線によるテスト

実運用環境でケーブルを物理的に抜く方法も有効です。ソフトウェアのダウンと異なり、物理リンクのロスト検知はMIIMonitorSecの間隔に依存します。ただしスイッチが直接リンクロストをドライバへ通知するケースでは実際の検知がより速くなる場合が多く、一般的には数十ms単位でフェイルオーバーが完了します。

手順3：フェイルバック確認

sudo ip link set eth0 up

フェイルバック後に/proc/net/bonding/bond0を再確認し、eth0がスレーブに復帰しているかを確認します。LACPモードではスイッチとの再ネゴシエーションが完了するまでわずかに時間がかかります。LACPTransmitRate=fastを指定した場合は概ね数秒以内に復帰します。

切り戻し手順と 2026 年の現行環境における注意点

設定を元に戻す場合は、作成した/etc/systemd/network/配下のファイルを削除またはリネームしてsystemd-networkdを再起動します。NetworkManagerと共存している環境ではNetworkManagerがBondデバイスを再管理しようとする場合があるため、nmcli dev statusでunmanagedになっているかを確認してください。

2026年時点の主要ディストリビューションにおける注意点は以下のとおりです。

• Ubuntu 24.04 LTS：サーバイメージではsystemd-networkdがデフォルト有効です。Netplanと共存しており、/etc/netplan/配下の設定が優先される場合があります。systemd-networkdを直接管理する場合はNetplanの設定ファイルを退避するか、renderer: networkdをNetplanに記述して委譲する方が競合を防げます。
• RHEL 9 / AlmaLinux 9 / Rocky Linux 9：デフォルトはNetworkManagerです。systemd-networkdを有効化する場合はNetworkManagerを無効化するか、管理対象デバイスを明示的に除外する設定が必要です。nmcli dev set ethX managed noで個別に除外できます。
• Debian 12（Bookworm）：ifupdownが引き続きデフォルトです。systemd-networkdへの移行は手動作業が必要ですが、設定構文は他ディストリビューションと共通です。
• カーネルドライバとの相性：一部のNICドライバ（特に旧世代のIntel e1000e系）でMIIMonitorの挙動が不安定になる報告があります。ethtool -i ethXでドライババージョンを確認し、最新のカーネルアップデートを適用した状態で検証することを推奨します。

systemd-networkdによるBond/LACP管理は、設定ファイルがシンプルで冪等性があり、AnsibleやSaltなどの自動化ツールとの組み合わせでも扱いやすい点が利点です。一方でNetworkManagerに慣れた環境からの移行では設定の重複や競合が起きやすいため、移行前のバックアップと段階的な検証が重要です。本番への適用前にはステージング環境や仮想マシンで一連の手順を試し、フェイルオーバー時の挙動を必ず確認してください。