【テクニカル・上級編】 IEEE 802.3ad / LACP（Link Aggregation Control Protocol）の束縛動作 – インフラ・物理＆L2/L3ネットワーク基礎実践ガイド

LACPの深淵：なぜあなたの「束ねたリンク」は期待通りの性能を出せないのか

ネットワークエンジニア諸君。現場で「リンクアグリゲーション（LAG）を組めば帯域は2倍になる」と安易に設計し、後になって「なぜかパケットロスが発生する」「特定のフローだけ遅延が大きい」といった現実に直面したことはないだろうか。

IEEE 802.3ad（現在はIEEE 802.1AXに統合）で定義されたLACPは、単なる「物理線の束ね」ではない。これは、制御プレーンが物理層の揺らぎを監視し、論理的な整合性を保つための高度な対話プロトコルだ。今回は、パケットレベルの挙動からカーネルのバッファチューニングまで、LACPの「本当の姿」を掘り下げていく。

1. LACPDUが語る「対話」の正体

LACPの心臓部は LACPDU（LACP Data Unit）にある。これは 01:80:c2:00:00:02 というマルチキャストMACアドレス宛に、30秒（Fastモードなら1秒）間隔で投げられる小さなパケットだ。

このフレーム内には Actor（送信側）と Partner（受信側）のシステム優先度、MACアドレス、キー、そしてポート状態が格納されている。注目すべきは State フィールドだ。ここで Active か Passive かが決定される。

Activeモード: 自発的にLACPDUを送信し、対向とのネゴシエーションを開始する。
Passiveモード: 受動的。相手からLACPDUが来るまで待機し、来た場合にのみ応答する。

現場の教訓: 双方を Passive に設定してはいけない。当然だが、ネゴシエーションは永遠に成立せず、リンクはフォールバックして単一の物理ポートとして振る舞うか、最悪の場合、ブラックホール化する。大規模環境では、すべて Active で統一するのが「事故を防ぐ」唯一の正解だ。

2. ハッシュアルゴリズムと「マイクロバースト」の罠

LACPがトラフィックを分散させる際、基本となるのは Flow-based Hashing だ。L2ならMAC、L3ならIPとポートの組み合わせをハッシュ化し、特定の物理ポートへマッピングする。

しかし、現代のデータセンターにおいて、単一のフロー（例えば大容量のバックアップ転送）がハッシュの偏りにより特定のリンクを占有し、他のリンクがスカスカになる状況は珍しくない。さらに、この偏りが「マイクロバースト」を引き起こし、スイッチのバッファを瞬時に枯渇させる。

バッファチューニングの極意（Linuxにおける設定例）

Linuxのボンディングドライバを利用する場合、xmit_hash_policy の選択が運命を分ける。単純な layer2 では不十分だ。レイヤー4のポート番号まで含めた layer3+4 を選択し、エントロピーを最大化させる必要がある。

# モジュールロード時にハッシュポリシーをlayer3+4に設定
modprobe bonding mode=4 miimon=100 lacp_rate=1 xmit_hash_policy=layer3+4

# 実行中の設定確認
cat /proc/net/bonding/bond0

ここで重要なのは、lacp_rate=1（Fastモード）の設定だ。1秒間隔のハートビートにより、リンク障害の検知と収束を劇的に高速化できる。高可用性が求められるシステムでは必須のチューニングである。

3. TCP/TLSハンドシェイクとRTTの最適化

LACPはL2/L3の物理的な冗長化を提供するが、それより上位のトランスポート層で何が起きているかも意識しなければならない。特にTLS 1.3のような低遅延ハンドシェイクを行う場合、リンクの切り替わり（再ハッシュ）で発生する数ミリ秒の順序逆転（Out-of-order）が、TCP再送を誘発する。

これが起きると、TCPの Congestion Window が縮小し、スループットがガタ落ちする。これを防ぐには、システム側のTCPバッファを最適化する必要がある。

# カーネルパラメータの最適化（sysctl.conf）
# TCPの輻輳制御アルゴリズムをBBRに変更（パケットロスに強い）
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_congestion_control = bbr

BBR（Bottleneck Bandwidth and RTT）は、パケットロスを「輻輳」と誤認せず、帯域幅とRTTを直接測定する。LACPの切り替え時や微妙なリンク品質劣化が発生した際にも、スループットの急落を最小限に抑えることができる。

4. セキュリティの観点：LACPは「信頼」の上に成り立つ

LACPそのものは認証を持たない。つまり、対向が信頼できる機器であるという前提が必要だ。もしネットワーク上に悪意あるデバイスが接続され、LACPDUを偽装して送りつけられた場合、論理インターフェースを乗っ取られる（LACPハイジャック）リスクが存在する。

物理ポートレベルで Port Security を設定し、信頼できないデバイスからのLACPパケットをドロップするようにスイッチ側のACLやインターフェース設定を固めることは、もはや「インフラの基本」である。

! Ciscoスイッチ等の設定例
interface GigabitEthernet0/1
 switchport mode trunk
 switchport trunk allowed vlan 10,20
 channel-group 1 mode active
 ! LACPDUの異常を検知するための設定
 lacp rate fast

最後に：プロトコルと対話せよ

LACPは単なる帯域拡張のツールではない。制御パケットを飛ばし、自身の状態を絶えず相手と同期し続ける、非常に「生き物に近い」プロトコルだ。

「なぜつながらないのか」をログやパケットキャプチャで追うとき、我々はプロトコルの設計者が何を考え、どのようなエラーケースを想定してこの仕様を作ったのかを想像する必要がある。パケットのヘッダーの一つひとつに、先人たちの「ネットワークを止めない」という執念が詰まっているのだ。

諸君、まずは tcpdump を握り、流れる LACPDU を眺めることから始めよう。そこには、教科書には載っていない「ネットワークの鼓動」が確かに聞こえるはずだ。