複数リンクを束ねる魔法の裏側：IEEE 802.3ad (LACP) とロードバランスの深層
こんにちは。幾多のネットワーク障害や夜間メンテの修羅場をくぐり抜けてきた、シニアネットワークエンジニアの私です。
Web APIの設計やモダンなインフラ構築において、私たちは日々「いかにスループットを高め、いかに単一障害点（SPOF）を排除するか」に頭を悩ませています。アプリケーション層でロードバランサーを並べ立てる前に、L2/L3の足回りである物理層・データリンク層で何が起きているか、正しく理解していますか？
今回は、インフラエンジニアの必須教養でありながら、ロードバランスのアルゴリズムを誤ると「なぜか特定のトラフィックだけが偏る」という怪奇現象を引き起こす、IEEE 802.3ad（LACP：Link Aggregation Control Protocol）の深層に迫ります。仕様の裏側から、現場で使えるコンフィグ、そしてトラブルシューティングの勘所まで、徹底的に解説しましょう。
—
1. リンクアグリゲーションとLACPの基本概念
複数の物理インターフェースを束ねて、OSや上位レイヤーからは「1本の太い論理リンク（ポートチャネル / チーム）」に見せかける技術。これがリンクアグリゲーション（IEEE 802.3ad、のちにIEEE 802.1AXへ移行）の正体です。
帯域の拡張（1Gbps×4本＝4Gbps化）はもちろんですが、真の目的は「冗長化（ハイアベイラビリティ）」にあります。4本のうち3本が物理的に断線しようとも、残る1本が生きていればリンクは維持され、トラフィックは無停止でフォワードされ続けます。
静的リンクアグリゲーションの限界とLACPの役割
リンクを束ねるだけなら、スイッチ側で強制的にグループ化する「静的（Static）アグリゲーション（Ciscoでいう on モード）」でも可能です。しかし、静的設定は対向機器のミス（結線違いや設定ミス）を検知できず、ブラックホール（パケットの迷子）を生む危険性があります。
そこで登場するのが、LACPという制御プロトコルです。
LACPは、LACPDU（Link Aggregation Control Protocol Data Unit）と呼ばれる専用のマルチキャストフレーム（宛先MACアドレス：01:80:c2:00:00:02）を定期的に交わし、お互いのポートが正しくリンクアグリゲーションに参加できる状態にあるかを動的に確認・合意します。
ActiveモードとPassiveモードの挙動
LACPのポート設定には、主に以下の2つのモードが存在します。
- Active モード：自ら積極的にLACPDUを送信し、対向デバイスとのネゴシエーションを開始しようと試みます。迷ったら基本はこちらを指定するのが実務の定石です。
- Passive モード：自分からはLACPDUを送信せず、対向から送られてきたLACPDUを受信した場合にのみ応答します。
【現場の教訓】
接続する両端の機器を共に Passive に設定してしまうと、いつまで経ってもLACPDUが送信されず、リンクアグリゲーションが形成されません（これを「LACPが沈黙する」と現場では呼びます）。接続する双方の少なくとも片方は必ず Active に設定するのが鉄則です。
—
2. トラフィック分散（ロードバランス）のメカニズム
「4本のリンクを束ねたから、単純に毎秒のパケットが4つの回線に均等に4分割される」――残念ながら、現実はそんなに甘くありません。
IEEE 802.3adの規格上、「パケットの順序逆転（Out-of-Order）」の発生は厳禁とされています。TCPなどの上位プロトコルは、パケットが順番通りに届くことを前提としているため、同じTCPセッション（あるいは同じマイクロフロー）に属するパケットが異なる物理リンクを経由して到着順序が入れ替わると、膨大な再送が発生し、かえってスループットが急低下します。
そのため、スイッチは以下のいずれかのハッシュアルゴリズムに基づいて、トラフィックをどの物理リンクに割り振るかを決定しています。
src-mac/dst-mac（送信元/宛先MACアドレス）src-ip/dst-ip（送信元/宛先IPアドレス）src-port/dst-port（送信元/宛先L4ポート番号 ※TCP/UDP）
ハッシュ偏りの罠と「マイクロフロー」の概念
ここで、インフラエンジニアが最もハマりやすい罠についてお話ししましょう。
もしハッシュアルゴリズムに src-ip のみを指定している環境で、社内ネットワークから特定の巨大な単一バックアップサーバー（192.168.1.100）に対して大量のバックアップトラフィックを流したとします。この場合、送信元IPアドレス（例えばクライアントのIP）が固定されている、あるいはクライアントが1台しかなければ、すべてのトラフィックが常に同じ1本の物理リンクにハッシュ値が集中してしまいます。4本束ねている意味が完全に失われるわけです。
したがって、実務では可能な限りレイヤー4の情報（ポート番号）まで含めたハッシュアルゴリズム（例：src-dst-ip-port）を選択し、フローの粒度を細かく（マイクロフロー化）して負荷を分散させる必要があります。
—
3. 実機設定サンプル（Cisco IOS / Linux Bonding）
それでは、実際のインフラ構築における設定例を見ていきましょう。
ここでは、Cisco Catalystスイッチと、Linuxサーバー（Ubuntu等）でのLACP設定の具体例を示します。
Cisco IOS での設定例 (EtherChannel + LACP)
Ciscoの世界では、LACPを用いたリンクアグリゲーションを「EtherChannel（LACPプロトコル）」と呼びます。
! 1. 物理インターフェースをポートチャネルグループに割り当てる
interface GigabitEthernet0/1
description === Uplink to Server A (Port 1) ===
channel-group 1 mode active
!
interface GigabitEthernet0/2
description === Uplink to Server A (Port 2) ===
channel-group 1 mode active
!
! 2. 論理インターフェース（ポートチャネル）の設定
interface Port-channel1
description === LACP Trunk to Linux Hypervisor ===
switchport trunk allowed vlan 10,20,30
switchport mode trunk
!
! 3. グローバル設定でのロードバランスアルゴリズムの指定
! （IPアドレスとL4ポート番号をハッシュ計算の要素に含める）
port-channel load-balance src-dst-ip-portLinux (Ubuntu Netplan / Bonding) での設定例
次に、対向となるLinuxサーバー側の設定です。現代のUbuntuではNetplanを使用するのが主流ですが、カーネルのbondingモジュールを裏で利用してLACP（Mode 4 = 802.3ad）を構成します。
/etc/netplan/01-netcfg.yaml の設定例です。
network:
version: 2
renderer: networkd
ethernets:
# 物理インターフェースの定義
eth0:
dhcp4: no
eth1:
dhcp4: no
bonds:
# ボンディングインターフェース（bond0）の定義
bond0:
interfaces: [eth0, eth1]
dhcp4: no
addresses:
- 192.168.10.50/24
routes:
- to: default
via: 192.168.10.1
parameters:
mode: 802.3ad # LACP (IEEE 802.3ad) を指定
mii-mon-100: 100 # リンク監視間隔 (ミリ秒)
transmit-hash-policy: layer3+4 # IPアドレスとL4ポートでハッシュ分散—
4. 現場で役立つトラブルシューティングとデバッグTips
「設定は完璧なはずなのに、なぜかリンクが立ち上がらない」「スループットが出ない」
そんなトラブルに直面したとき、シニアエンジニアが真っ先に確認するチェックリストとコマンドを授けます。
1. ステータスの確認（Cisco編）
まず、LACPのネイバー（対向機器）と正しくネゴシエーションが完了しているかを確信します。
# ポートチャネルの概要と各物理リンクのLACPステータスを確認
show etherchannel 1 summary【見方・判断基準】
出力結果の中に P（Bundled in port-channel）というフラグが表示されていれば、正常にLACPがハンドシェイクを完了し、束ねられています。
もし I（Independent）や D（Down）になっている場合は、対向のモードミスマッチ（片方が active でもう片方が desirable や無効になっている等）や、物理層（ケーブル不良、SFPモジュールの不一致）のトラブルを疑ってください。
# LACPの詳細なパケット送受信状況やPartner情報を確認
show lacp 1 neighborこのコマンドで、対向機器のMACアドレス、System Priority、Port Key、Port Priorityが正しく互いに認識されているかを確認できます。これが一致していないと、LACPは安全のためにリンクをフォワード状態にしません。
2. ステータスの確認（Linux編）
Linux側でLACPの状態を詳細にデバッグするには、以下のカーネル情報を参照します。
# bond0の現在のLACPステータスやアグリゲーション状況を表示
cat /proc/net/bonding/bond0出力結果内の MII Status が up になっているか、また LACP slock や Actor Chally などの値が対向スイッチと正しく同期しているかをログと突き合わせて確認します。
—
5. まとめ
IEEE 802.3ad (LACP) は、単に「線を束ねて速くする」だけの単純なプロトコルではありません。ハードウェアのハッシュ制約、プロトコル上のモードの噛み合わせ、そしてパケットの順序性を守るための緻密な仕組みの上で成り立っています。
Web APIのレスポンスが遅い、あるいは特定の高負荷時に片側の回線だけが飽和するような現象に直面したときは、アプリケーションコードを疑う前に、スイッチとサーバー間の port-channel load-balance の設定や、ハッシュポリシーが適切に機能しているかを疑ってみてください。
ネットワークの足回りを正しく理解し、堅牢なインフラストラクチャを築き上げましょう。それでは、また次の現場でお会いしましょう。
コメント