リンクアグリゲーションの深層：IEEE 802.3ad/802.1AXとLACPが紡ぐL2の美学
こんにちは。数々のネットワークの修羅場をくぐり抜けてきたインフラアーキテクトです。
Webアプリケーションの性能限界をチューニングし、APIのレスポンスタイムをミリ秒単位で削り出すエンジニアであっても、その土台を支える物理・L2レイヤーの挙動を知る機会は意外と少ないものです。「複数本のLANケーブルを挿せば勝手に帯域が倍になる魔法の箱」——そう思っていませんか？
今回は、モダンなデータセンターやオンプレミス環境の基盤を支える IEEE 802.3ad（現在のIEEE 802.1AX）リンクアグリゲーション、そしてその頭脳である LACP（Link Aggregation Control Protocol） の深淵へと皆さんをご案内します。パケットがワイヤー上をどう流れているのか、現場で役立つトラブルシューティングの勘所も含めて徹底的に解説しましょう。
—
1. なぜリンクアグリゲーションが必要なのか？
現代のサーバーやスイッチ間では、10Gbps、25Gbps、さらには100Gbpsといった高速イーサネットが当たり前になりました。しかし、どれほど高速なインターフェースであっても、「単一障害点（SPOF）」の恐怖からは逃れられません。NICが壊れればおしまい、ケーブルが抜ければ通信断です。
かといって、スパニングツリープロトコル（STP）を有効にして冗長パスを作ると、ループ防止のために片方のポートが Blocking 状態になり、高価な帯域が遊んでしまいます。「冗長性を確保しつつ、帯域も合算したい」——この現場の切実な要求に応えるのが、複数の物理リンクを束ねて1本の論理リンクに見せる リンクアグリゲーション（LAG / Port Channel） です。
—
2. IEEE 802.3ad から IEEE 802.1AX へ
歴史的背景を少しだけお話ししておきましょう。
元々、リンクアグリゲーションの標準規格は、IEEE 802.3（イーサネット委員会）のタスクフォースによって IEEE 802.3ad として2000年に策定されました。しかし、この技術はイーサネットの枠を超えて、無線LANやその他のレイヤー2技術でも共通して利用できる汎用的なプロトコルであるべきだと判断され、2008年に IEEE 802.1AX（LAN/MAN Bridging委員会）へと移管されました。
実務の世界では、Ciscoのコンフィグ等で今でも channel-group ... mode active のように「802.3ad」という用語が生き残っていますが、プロトコル仕様としての最新の正典はIEEE 802.1AXであることを頭の片隅に入れておいてください。
—
3. LACPの心臓部：SLOW_PROTOCOLSとフレーム構造
LACPは、接続されたデバイス間でアグリゲーションの状態を動的にネゴシエーションするためのプロトコルです。このLACPがどのように流れているか、パケットキャプチャ（Wiresharkなど）を覗いたことがあるでしょうか？
LACPのフレームは、通常のデータフレームとは異なり、特殊な宛先MACアドレスを持っています。それが 01:80:C2:00:00:02 です。
これは、IEEE 802.3で定義された Slow Protocols 用のマルチキャストアドレスであり、L2のブリッジ（スイッチ）によってフラッディングされず、直近のLACPピアで終端される運命にあります。イーサネットタイプには 0x8809（Slow Protocols）が使用され、そのペイロード内にLACP特有のLDU（Link Data Unit）が包まれています。
LACPDUの主なパラメータ
LACPが交換するメッセージ（LACPDU: Link Aggregation Control Protocol Data Unit）には、主に以下の情報が含まれています。
- Actor（送信側）と Partner（受信側）のシステム情報:
- System Priority（2オクテット）：プライオリティ値が小さい方が、LAGのマスター選出において優位になります。
- System ID（6オクテット）：一般的にはデバイスのベースMACアドレスが使用されます。
- Key（2オクテット）：ポートが同じアグリゲーション・グループに属するための識別子。この値が一致しないポート同士は束ねられません。
- Port Priority / Port Number（各2オクテット）：個々のポートを識別し、優先順位をつけるための値。
- State（1オクテット）：フラグの集合であり、LACPがActive/Passiveか、同期（In_Sync）しているか、コレクション/ディストリビューションが可能かを示します。
—
4. 通信フロー（シーケンス）と状態遷移
LACPが有効化されたポート同士がどのようにリンクを確立するのか、その美しいシーケンスを追ってみましょう。
[ Server (Actor) ] [ Switch (Partner) ]
| |
|--- LACPDU (Actor: Active, State: Default) ----->| お互いの存在と
|<-- LACPDU (Partner: Active, State: Default) ----| パラメータを交換
| |
|--- LACPDU (State: Expired/Default の更新) ----->| 同期（In_Sync）の
|<-- LACPDU (State: In_Sync, Collecting...) ------| 確認フェーズ
| |
[==================== 仮想的な1本の論理リンク確立 ====================]
| |
|--- 定期的な LACPDU 送信 (デフォルト 30秒毎) ---->| リンクの健全性を
|<-- 定期的な LACPDU 送信 ------------------------| 監視（Heartbeat）アクティブとパッシブの組み合わせ
- Active Mode: 自発的にLACPDUを送信し、ピアとのネゴシエーションを開始します。
- Passive Mode: ピアからLACPDUが送られてくるのを待ち、受信した場合のみ応答します（両者ともにPassiveだと、いつまで経ってもリンクが立ち上がりません！現場の罠の定番です）。
—
5. 実務設定例：Linux (Bonding/Team) と Cisco IOS
では、実際に現場でどのように設定されるのかを見てみましょう。ここでは、LinuxサーバーとCisco Catalystスイッチの間でLACP（802.3ad）を組む代表的な設定例を紹介します。
A. Cisco IOS スイッチ側の設定 (Port Channel / LACP)
Cisco環境では、LACPを有効にするために channel-group X mode active を指定します。
! 物理インターフェースのまとまり（Range）に対するLACP設定
interface range GigabitEthernet0/1 - 2
description *** Server Uplink for LACP ***
channel-group 1 mode active ! LACPアクティブモードでグループ1に参加
no shutdown
!
! 論理インターフェース（Port-channel）の設定
interface Port-channel1
description *** Production LAG to Linux Server ***
switchport mode trunk
switchport trunk allowed vlan 10,20,30
no shutdownB. Linux (Netplan / Ubuntu) の設定例
最近のUbuntu（Ubuntu 18.04以降など）で標準的なNetplanを使用したLACP（bonding）の設定ファイルです。
network:
version: 2
renderer: networkd
ethernets:
enp3s0:
dhcp4: no
enp4s0:
dhcp4: no
bonds:
bond0:
interfaces:
- enp3s0
- enp4s0
parameters:
mode: 802.3ad # LACPモードを指定
mii-mon: 100 # リンク状態の監視間隔（ミリ秒）
lacp-rate: fast # LACPの送信頻度を高速（1秒毎）に設定
hash-policy: layer2+3 # トラフィック分散のハッシュアルゴリズム
addresses:
- 192.168.10.100/24
gateway4: 192.168.10.1
nameservers:
addresses:
- 8.8.8.8ここで注目してほしいのが lacp-rate: fast というパラメータです。デフォルトの slow（30秒おき）に比べ、fast（1秒おき）にすることで、物理リンクの断線を検知してトラフィックをバイパスさせるまでのコンバージェンスタイムを劇的に短縮できます。ミッションクリティカルなAPIサーバーの足回りでは、原則として fast の採用を推奨します。
—
6. トラブルシューティングの現場から：ハッシュの罠
LACPを導入したエンジニアがよく直面する罠があります。それは、「4本の1Gbps回線を束ねて4Gbpsにしたはずなのに、特定のAPIサーバーへのファイル転送や単一のクライアントからのダウンロードが1Gbpsしか出ない」 という現象です。
リンクアグリゲーションは、1本の通信ストリーム（単一のTCPセッションなど）を複数の物理回線に「パケット単位」で分割して流すわけではありません。パケットが順序不同で到着するとTCPの再送制御やパケット順序逆転（Reordering）によるパフォーマンス低下を招くため、通常は フロー単位（送信元/宛先IPやポート番号のハッシュ値） で物理ポートを割り振ります。
もしバックエンドの通信相手が「1対1の単一セッション」であれば、どれだけLAGの帯域を束ねても、ハッシュ値が同一である限り常に「同じ1本の物理回線」しか使われません。
ハッシュアルゴリズムの確認（Linuxの場合）
現在の bonding の状態や統計情報は、以下のコマンドでリアルタイムに確認できます。
# bondingの状態詳細を確認
cat /proc/net/bonding/bond0出力結果の中に Transmit Hash Policy という項目があります。必要に応じて layer2+3 や layer3+4（ポート番号までハッシュ計算に含める）に変更し、トラフィックが綺麗に分散されるようチューニングすることが、シニアエンジニアの腕の見せ所です。
—
まとめ
IEEE 802.3ad / 802.1AX LACPは、単なる「ケーブルの束ね合わせ」ではありません。L2のレイヤーで緻密にネゴシエーションを行い、システムの信頼性と帯域の拡張性を両立させる、ネットワークエンジニアの知恵の結晶です。
APIのパフォーマンスチューニングやインフラの冗長化設計を行う際、パケットが物理ワイヤーから論理パスへどう流れているのか、その背景にあるプロトコルの息吹をぜひ想像してみてください。障害に強い、美しく堅牢なネットワークを築き上げることができるはずです。
コメント