Linux LACPボンディング：設定、検証、およびトラブルシューティング

Linux LACPボンディングは、複数のイーサネットインターフェースを単一の論理リンクに結合し、集約帯域幅の拡大と物理NIC間の自動フェイルオーバーを実現します。IEEE 802.3ad規格を採用しており、サーバー側とスイッチ側の双方が、どのリンクをアクティブにするか、およびトラフィックをどのように分散させるかをネゴシエーションします。 本記事では、LACPの実際の動作、他のLinuxボンディングモードよりもLACPを選択すべき場合、最新のLinuxサーバーでの設定方法、および正常に動作しているかを確認する方法について解説します。

リンクアグリゲーションとLACPとは何ですか？

リンクアグリゲーションは、複数の物理ネットワーク接続を1つの論理チャネルに結合する技術です。これには2つの目的があります。リンクグループ全体の利用可能な総帯域幅を拡大すること、および構成メンバーのいずれかのリンクがダウンした場合に自動フェイルオーバーを提供することです。

LACP（Link Aggregation Control Protocol）は、IEEE 802.3ad で定義されたリンクアグリゲーションの動的バージョンです。LACP は、両端での静的な設定に依存する代わりに、サーバーとスイッチの間で LACPDU と呼ばれる制御パケットを交換します。 両端は、どのリンクを集約に含めるかをネゴシエーションし、各リンクの状態を監視し、状況の変化に応じてメンバーをグループに追加または除外します。

Linux環境では、LACPはカーネルのボンディングドライバのモード4（802.3ad）として動作します。ドライバは、IPアドレスを所有する論理インターフェース（通常は bond0)を作成し、IPアドレスを割り当てます。一方、物理インターフェースである eth0 および eth1 などの物理インターフェースはボンディングの構成要素となります。OSの観点からは1つのネットワークインターフェースが存在し、物理的な観点からは複数の並列イーサネットリンクが存在します。

LACPが特に実行しないが、人々がしばしば期待するいくつかの点：

• 単一のTCP接続は、依然として1つの物理リンクを経由します。LACPはフロー全体の負荷分散を行うものであり、フロー内の個々のパケットの分散を行うものではありません。2つの1GbEリンクをボンディングしても、単一のダウンロード速度が1Gbpsを超えることはありません。
• LACPには802.3adをサポートするスイッチが必要です。非管理型スイッチやLACP非対応のスイッチに対してはボンディングを形成できません。
• すべての構成リンクは、同じ速度およびデュプレックスで動作している必要があります。1 GbEポートと10 GbEポートをボンディングすることはできません。

Linuxのボンディングモード：LACPを使用すべき場合

Linuxのボンディングドライバは7つのモードをサポートしています。実稼働環境での導入では、そのうちの3つのいずれかが使用されることがほとんどです。

モード 1: active-backup

1つのメンバーインターフェースがアクティブで、他はアイドル状態です。アクティブなインターフェースが障害を起こした場合、数100ミリ秒以内に別のインターフェースが引き継ぎます。スイッチの設定は不要であるため、スイッチが管理下になかったり、802.3adをサポートしていない場合に最適な選択肢となります。冗長性は確保されますが、帯域幅の増加はありません。

モード4：802.3ad (LACP)

すべてのメンバーがトラフィックを転送します。ボンディングドライバとスイッチはLACPを使用してアクティブセットをネゴシエートし、障害を検出します。送信トラフィックは、設定したハッシュポリシーに基づいてメンバー間で分散されます。これは、冗長性とマルチフローワークロード向けの追加帯域幅の両方を必要とする場合、管理対象スイッチに接続された専用サーバー向けの標準的な選択肢です。

モード 6: balance-alb

スイッチのサポートを必要としない、双方向の適応型ロードバランシングです。ドライバがARP応答をインターセプトしてMACアドレスを書き換え、着信トラフィックを分散させます。機能はしますが、LACPと比較すると不安定です。スイッチ側の設定が真に不可能な場合にのみ使用してください。

決定ルール:

• マネージドスイッチがない場合、またはフェイルオーバーのみが必要な場合：モード 1 (active-backup)。
• 管理対象スイッチがあり、複数のフローがあり、帯域幅と冗長性の両方が必要な場合：モード 4 (LACP)。
• 管理対象スイッチの導入が不可能だが、双方向の負荷分散が必要な場合：モード 6 (balance-alb)。

モード0（balance-rr）、2（balance-xor）、3（broadcast）、および5（balance-tlb）も存在しますが、最新のハードウェアでは適切な選択肢となることはほとんどありません。特に理由がない限り、モード1またはモード4を選択してください。

Linux での LACP ボンディングの設定

最新の Ubuntu および Debian システムでは、LACP は netplan を通じて設定します。RHEL、CentOS Stream、AlmaLinux、および Rocky Linux では、 nmcli または基盤となる接続ファイルを編集して設定します。

Netplan (Ubuntu、Debian)

以下の内容を /etc/netplan/01-lacp.yaml:

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: no
    eth1:
      dhcp4: no
  bonds:
    bond0:
      interfaces: [eth0, eth1]
      addresses: [10.0.0.5/24]
      gateway4: 10.0.0.1
      parameters:
        mode: 802.3ad
        lacp-rate: fast
        mii-monitor-interval: 100
        transmit-hash-policy: layer3+4

その後、以下を実行して適用します netplan applyで適用します。主なパラメータ：

• mode: 802.3ad LACPを有効にします。
• lacp-rate: fast デフォルトの30秒間隔ではなく、1秒ごとにLACPDUを送信します。スイッチの設定と一致させる必要があります。
• mii-monitor-interval: 100 100ミリ秒ごとにリンク状態をポーリングします。
• transmit-hash-policy: layer3+4 送信元/宛先IPおよびTCP/UDPポートに基づいてフローを分散します。これにより、一般的なWebおよびデータベーストラフィックに対して、デフォルトの layer2 一般的なWebおよびデータベーストラフィックにおいて、デフォルトのポリシーよりも優れた負荷分散を実現します。

NetworkManager (RHEL、AlmaLinux、Rocky)

nmcli con add type bond ifname bond0 con-name bond0 \
  bond.options "mode=802.3ad,miimon=100,lacp_rate=fast,xmit_hash_policy=layer3+4"
nmcli con add type ethernet ifname eth0 master bond0
nmcli con add type ethernet ifname eth1 master bond0
nmcli con mod bond0 ipv4.addresses 10.0.0.5/24 ipv4.gateway 10.0.0.1 ipv4.method manual
nmcli con up bond0

スイッチ側

スイッチには、LACP アクティブモードに設定された LAG グループ（ポートチャネルとも呼ばれる）が必要であり、そのメンバーポート数はボンディングと同じでなければなりません。 正確な構文はベンダーによって異なりますが、要件は変わりません。ポートは同じ VLAN 内にあり、同じ速度とデュプレックスに設定され、少なくとも片側で LACP アクティブモードを使用している必要があります。両側をアクティブにするのが最も安全な設定です。

Cisco IOSの場合：

interface range gigabitethernet0/1 - 2
 channel-group 1 mode active
 channel-protocol lacp

Aruba/ProCurveの場合：

trunk 1-2 trk1 lacp

スイッチ側の lacp_rate スイッチ側の設定はホスト側と一致している必要があります。ここでの不一致は、最も一般的なLACP設定エラーの一つであり、30秒ごとに断続的なフラッピングを引き起こします。

LACPの確認とトラブルシューティング

Linux 側でボンディングの稼働状況を確認します:

cat /proc/net/bonding/bond0

出力結果で確認すべき4つの点：

1. Bonding Mode: IEEE 802.3ad Dynamic link aggregation モード 4 が読み込まれていることを確認します。
2. 各サブインターフェースは MII Status: up でリストされ、 link failure count: 0.
3. 各サブインターフェースごとに Partner Mac Address が割り当てられている。ここがすべてゼロの場合は、ポートがLACPアクティブなLAGに属していないか、ケーブルが間違ったポートに接続されているため、スイッチがLACPパケットをまったく送信していないことを意味する。
4. Aggregator ID がすべてのメンバーで同じです。IDが異なる場合は、メンバーが実際には結合されておらず、独立して動作していることを意味します。

帯域幅が使用されているかどうかを確認する最も手っ取り早い方法は、複数の並列ストリーム（iperf3 -P 8）を実行することです。総スループットが単一リンクの容量を超える場合、LACPは正しく負荷分散を行っています。単一ストリームのテストで1つのリンクの速度が表示されるのは想定された動作であり、バグではありません。

最も一般的なLACPの問題とその原因：

• パートナーMACがすべて0の場合：スイッチポートがLACPアクティブなLAGに属していないか、ケーブルの接続が間違っている。
• ボンディングは確立されるが、スループットが1つのリンクに固定される：ハッシュポリシーがデフォルトで layer2に設定されており、宛先MACアドレスのみでハッシュ化されています。これを layer3+4.
• 30秒ごとに断続的に接続が不安定になる： lacp_rate ホストとスイッチの設定が一致していない。
• 1つのサブordinateは動作するが、もう1つはトラフィックを転送しない：速度/デュプレックスの不一致、またはスイッチ側のポートが同じLAGグループに属していない。

LACPが適切な解決策ではない場合

LACPは特定の課題、すなわち1台のホストと1台のスイッチ（または1つのスイッチスタック）間の複数のリンクをアグリゲートし、冗長性とフローごとの帯域幅を確保するという問題を解決します。しかし、LACPが適切なツールではないシナリオも存在します。

冗長性のみが必要で、かつスイッチが 802.3ad をサポートしていない場合は、代わりにモード 1（アクティブ・バックアップ）を使用してください。これはどのような環境でも機能します。

シャーシレベルの冗長性のために2つの別々のスイッチ間でボンディングを行う必要がある場合、標準のLACPでは関連性のない2つのスイッチをまたぐことはできません。 この場合、2台のスイッチが単一の論理LACPパートナーとして機能する「マルチシャーシ・リンクアグリゲーション（MLAG）」が必要です。ほとんどのエンタープライズスイッチベンダーは、これを独自の名称で実装しています（Cisco vPC、Arista MLAG、Juniper MC-LAGなど）。

単一のフローで1つのリンクの帯域幅を超える必要がある場合、LACPではこれを実現できません。選択肢としては、より高速な物理リンクを使用する（2つの10GbEを1つの25GbEまたは1つの40GbEに置き換える）、あるいは全く異なる技術を使用することです。 SR-IOVは、各VMにハードウェアアクセラレーションされた仮想NICを提供することで、仮想マシンに対してラインレートに近い単一フローのパフォーマンスを実現しますが、これは別の問題を解決するものであり、独自の制約があります。これについては別の記事で取り上げます。

多数の同時接続を処理するほとんどの専用サーバーやコロケーションサーバーにとって、LACPは依然として標準的な解決策です。ハッシュ処理を施した2本のボンディングされた10 GbEリンクは、 layer3+4 ハッシュ処理を行うことで、多数のフローにわたる合計18 Gbps以上のトラフィックを余裕を持って処理し、NICやケーブルの障害が発生してもパケットをドロップすることなく耐え抜きます。