ネットワークの泥沼から生還せよ：LACPDUの深層と、リンクアグリゲーションを支配するパケットの掟
こんにちは。現場の最前線を渡り歩いてきたシニアネットワークエンジニアの私です。
Web系からインフラの世界に飛び込んできた若いエンジニアから、よくこんな相談を受けます。「APIのレスポンスが妙に遅い」「本番環境のデータベースクラスタ間でパケットドロップが起きる」。調査を進めると、物理インターフェースを束ねたはずのLACP（Link Aggregation Control Protocol：IEEE 802.3ad / 802.1AX）が、なぜか片側リンクしか使っていなかったり、ディストリビューションハッシュの偏りで特定の物理リンクが悲鳴を上げている……そんな現場の修羅場を、あなたも目撃したことがあるのではないでしょうか。
LACPは、ただの「回線の束ね役」ではありません。スイッチとサーバ（あるいはスイッチ間）が毎秒会話を交わし、お互いの生存確認とポートの同期をミリ秒単位で制御する、極めて洗練されたプロトコルです。
今回は、このLACPがワイヤー上でどのようなパケット（LACPDU）を飛ばし、いかにしてリンクの束を統率しているのか。そのヘッダー構造の深淵から、実務で使えるコンフィグやデバッグ手法まで、徹底的に解説していきましょう。
—
1. LACPDUの正体：イーサネットの海を泳ぐ「対話の切符」
LACPDU（Link Aggregation Control Protocol Data Unit）は、OSI参照モデルのデータリンク層（L2）で動作する制御フレームです。上位のIPやTCP/UDPの世話にはならず、イーサネットフレームの姿を借りて直接L2の海を駆け巡ります。
マルチキャストの宛先とEthertype
LACPDUが送信される際、宛先MACアドレスには特定のマルチキャストアドレスが使われます。
- 宛先MACアドレス:
01:80:c2:00:00:02（Slow Protocols用のマルチキャストアドレス） - Ethertype:
0x8809（IEEE 802.3 Slow Protocols） - Subtype:
0x01（LACP）
この 0x8809 というEthertypeを見た瞬間、ネットワーク機器のASIC（あるいはCPU）は「お、LACPの制御パケットだな」と認識し、通常のデータ転送パスから外してコントロールプレーンへCPU処理のために引き渡します。つまり、LACPDUはデータプレーンのトラフィックを妨げないよう、専用の裏口を通っているのです。
—
2. LACPDUヘッダー構造の解剖学：ActorとPartnerの心理戦
LACPDUのペイロードは、お互いの状態を伝え合う「名刺交換」の場です。パケット内部には、大きく分けて Actor（送信側） と Partner（受信側・認識している相手側） の情報が鏡写しのように格納されています。
実際のパケットアナライザ（Wireshark等）を覗いたとき、エンジニアが必ず確認すべき主要なフィールドを深掘りしていきましょう。
Actor / Partner System Information の中身
各システム情報は、以下の要素で構成されています。
1. System Priority (2オクテット):
- システム全体の優先度です。値が小さいほど（例:
32768より100）、アグリゲーションにおける「主導権（マスター）」を握りやすくなります。
2. System ID (6オクテット):
- 本体のMACアドレスです。System Priorityが同点の場合、このMACアドレスの数値が小さい方が優位に立ちます。
3. Key (2オクテット):
- 「オレはこのグループ（Channel-Group）に所属している！」という共通の合言葉です。送信側と受信側でこのKeyが一致しないと、LACPはリンクを束ねてくれません。現場での設定ミス（LACPのモードやグループ番号の不一致）は、大抵このKeyのミスマッチが原因です。
4. Port Priority (2オクテット):
- 個々の物理ポートの優先度です。リンクアグリゲーションの最大バンド幅（例えば8本までしか束ねられない制限など）を超えて物理ポートが接続された際、どのポートを生かすかを決める基準になります。
5. Port (2オクテット):
- 送信元/送信先の物理ポート番号（内部ID）です。
6. State (1オクテット):
- LACPのステートマシンを動かす最も重要なフラグ群です（後述）。
—
3. ステートマシンを支配する「Stateバイト」のフラグたち
LACPDUの State フィールド（1オクテット＝8ビット）は、パケット通信の成否を握る心臓部です。ここには、以下のフラグがビット単位で詰め込まれています。
- Bit 0 (LACP_Activity): アクティブモード（常にLACPDUを送出する）か、パッシブモード（相手から来るのを待つ）か。
- Bit 1 (LACP_Timeout): タイムアウトの周期。Fast（1秒ごと）か Slow（30秒ごと）か。
- Bit 2 (Aggregation): このリンクがアグリゲーション可能（集約可能）であるか。
- Bit 3 (Synchronization): ここが最重要！ 相手とパラメータ（Keyや速度など）が完全に一致し、束ねる準備が「同期（In-Sync）」しているかを示すフラグ。これが
1にならないと、トラフィックは流れ始めません。 - Bit 4 (Collecting): このポートが受信フレームの処理（収集）を行っているか。
- Bit 5 (Distributing): このポートが送信フレームの送出（分散）を行っているか。
- Bit 6 (Defaulted): パートナーからのLACPDUが途絶えたため、デフォルト値にフォールバックしているか。
- Bit 7 (Expired): タイムアウト期限を超過した状態。
実務の現場で「LACPがUpしない！」という障害に直面したとき、パケットキャプチャや機器のデバッグコマンドで確認すべきは、まさにこの Synchronization と Distributing が 1 に立っているか否か、ただそれだけです。
—
4. 現場で役立つ！実機設定とデバッグの作法
理論を理解したところで、実務へのアプローチを見ていきましょう。今回はLinux（bonding / team）と、Ciscoライクなスイッチでの設定例・トラブルシューティング手順を公開します。
A. Linux (Ubuntu / RHEL) におけるLACP (Mode 4) 設定例
現代のWebインフラでは、ベアメタルサーバやハイパーバイザー（KVM/Proxmox等）でLinuxのBonding（802.3ad）を使う機会が多々あります。以下は、Netplan（Ubuntu等）を用いた設定サンプルです。
# /etc/netplan/01-netcfg.yaml
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 # リンク監視間隔(ms)
lacp-rate: fast # LACPDUの送信頻度をFast(1秒)に設定 (デフォルトはslow)
transmit-hash-policy: layer3+4 # ハッシュアルゴリズムの指定（負荷分散の要）
addresses:
- 192.168.10.100/24
gateway4: 192.168.10.1
nameservers:
addresses:
- 8.8.8.8> シニアの現場Tips: lacp-rate: fast は、物理リンクの断線や障害発生時のフェイルオーバーを劇的に高速化（約3秒以内）させます。ただし、スイッチ側のCPU負荷がわずかに上がるため、大規模なポート数を持つ環境ではスイッチのスペックに注意してください。また、transmit-hash-policy は layer3+4（送信元/宛先IPおよびポート番号をハッシュ化）にすることで、複数セッションのトラフィックが綺麗に物理回線へ分散されます。
—
B. Ciscoスイッチ側（Cisco IOS）の対応コンフィグ
サーバ側を受け止めるCisco CatalystやNexusスイッチ側の設定は、Channel-Groupを active モードで作成するのが鉄則です。
! 物理インターフェースの定義 (GigabitEthernet 0/1 と 0/2 を束ねる)
interface GigabitEthernet0/1
description === Server-01 Port 1 ===
channel-group 1 mode active
no shutdown
interface GigabitEthernet0/2
description === Server-01 Port 2 ===
channel-group 1 mode active
no shutdown
! 論理ポートチャネル（Po1）の定義
interface Port-channel1
description === LACP Trunk to Server-01 ===
switchport mode trunk
switchport trunk allowed vlan 10,20,30—
C. トラブルシューティング：LACPが枯渇したときのデバッグ手順
もし「ポートチャネルがUpしない（Err-Disabledになる、あるいはBundledにならない）」という状況に陥ったら、以下の手順でパケットとステータスを追いかけます。
1. スイッチ側のLACPネイバー状態を確認する
Cisco IOSであれば、以下のコマンドでActorとPartnerの情報（KeyやState）が一致しているかを一目で確認できます。
# LACPのネイバー詳細とステートを確認するコマンド
show lacp neighbor*確認のポイント*: 相手側のSystem IDやKeyが意図した値になっているか、そしてステートに F（Fwd / Distributing）や S（Sync）の文字が点灯しているかを確認します。
2. パケットキャプチャでワイヤー上の現実を見る
スイッチのミラーポート、あるいはLinuxサーバ上で tcpdump を用いてLACPDUが生で流れているかを確認します。
# Linuxサーバ上でLACPDU（Ethertype 0x8809）をリアルタイムにキャプチャする
sudo tcpdump -i bond0 -nnvv "ether proto 0x8809"コンソールに LACP v1, length 110... といったログが流れてくれば、物理層とLACPのデーモンは正常に動作しています。逆にこれが一切流れていない場合は、物理ケーブルの断線、SFPモジュールの不具合、あるいはVLANやトランク設定のミスマッチ（ネイティブVLANの不一致など）を疑うべきです。
—
5. おわりに：プロトコルの行間に隠された真実
LACPDUというわずか数十バイトの小さなパケット。その中には、ネットワーク機器同士が「お前を相棒と認めた」「いや、まだ同期が終わっていない」と静かに語り合うドラマが詰まっています。
インフラやWeb APIの設計において、冗長性とスループットの確保は避けて通れない命題です。表面的なコマンドのコピペにとどまらず、「今、ワイヤーの上で何が交わされているのか」というパケットの息吹を感じ取れるエンジニアこそが、障害の迷宮から一瞬で生還できる真のプロフェッショナルです。
さあ、今日のログ確認とパケット解析の旅に出かけましょう。あなたのネットワークに、穏やかなパケットの奔流がありますように。
コメント