帯域の幻想と現実：LACPが隠蔽するパケットシーケンスの深淵
ネットワーク設計において、リンクアグリゲーション（IEEE 802.3ad / 802.1AX）は「魔法の杖」のように扱われがちだ。2本の10Gbps回線を束ねれば20Gbpsになる――。教科書的には正しいが、現場のインフラアーキテクトであれば知っているはずだ。これは帯域の総和を増やすものではなく、「フローの並列化」に過ぎないということを。
本稿では、LACP（Link Aggregation Control Protocol）の泥臭い仕様と、それが現代の高速通信（TCP/TLS）に与える影響、そして我々がチューニングすべき「見えない境界線」について深掘りする。
—
LACPの制御プレーン：ActiveとPassiveの政治学
LACPには Active と Passive という二つのモードがある。多くのエンジニアは「とりあえず対向もActiveにしておけば動く」と考えがちだが、ここには明確な意図が必要だ。
- Activeモード: 自発的にLACPDUを送信し、対向とのネゴシエーションを開始する。
- Passiveモード: 送信されてきたLACPDUに応答するだけで、自発的には開始しない。
現場で「なぜかリンクが上がらない」「片側が疎通不能になる」といったトラブルの多くは、このモードの組み合わせミスや、誤ったエッジポート設定によるLACPDUのブラックホール化に起因する。特に、スタック構成のスイッチにおいて、LAG（Link Aggregation Group）をまたいだLACP設定ミスは、一瞬でループを引き起こし、STP（Spanning Tree Protocol）を悶絶させるトリガーとなる。
—
ロードバランスの解像度：ハッシュアルゴリズムの罠
LACPがトラフィックを分散させる際、物理レイヤでは「どこに流すか」を決定するためのハッシュ計算が行われる。一般的に、以下の要素をキーとしてハッシュ値が算出される。
src-ip,dst-ipsrc-port,dst-portprotocol
ここで重要なのは、「フローのハッシュ値が同じであれば、常に同じ物理リンクを通る」という原則だ。単一の巨大なTCP転送（大容量ファイルの転送など）を行っている場合、どれほどLAGの物理本数を増やしても、その通信は1本のリンクの帯域制限を受ける。
パフォーマンス最適化のためのチューニングポイント
TLSハンドシェイクやTCPセッションにおいて、ハッシュの偏り（Polarization）を防ぐには、コンテナや仮想マシンのNIC割り当てにおいて、フローの多様性を意識した設計が不可欠だ。
# Linuxでのハッシュポリシー設定例 (bondingドライバー)
# xmit_hash_policy: layer3+4 を選択することで、
# IPだけでなくポート番号を含めたハッシュ計算を行い、分散効率を向上させる
echo layer3+4 > /sys/class/net/bond0/bonding/xmit_hash_policy—
高速通信におけるパケット順序とTCP再送の相関
ネットワークスペシャリストとして最も警戒すべきは、「パケットの順序逆転（Out-of-order Delivery）」である。
もしハッシュアルゴリズムや物理リンクのレイテンシ差によって、パケットが到着順序を違えて届いた場合、TCPスタックはこれを「パケットロス」と誤認する。結果として、TCPの DupACK が発生し、輻輳制御アルゴリズム（CUBICやBBR）が「ネットワークが混雑している」と判断してウィンドウサイズを絞ってしまう。
RTT削減とTCPバッファの最適化
高速なTLS通信を維持するためには、以下のカーネルパラメータを調整し、パケット逆転やバーストへの耐性を高めるのが定石だ。
# TCPバッファの自動チューニング上限を拡張 (高帯域・長距離回線向け)
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"
# パケット順序逆転に寛容な設定（推奨値は環境依存だが、過度な調整は注意）
# tcp_reorderingの値を適切に調整することで、多少の順序逆転での再送を抑制できる
sysctl -w net.ipv4.tcp_reordering=3—
セキュリティと可観測性：見えないパケットを追う
LACPで束ねられたリンクをミラーリング（SPAN/RSPAN）する際、すべての物理リンクからキャプチャを採らないと、パケットの断片しか見えない。これはセキュリティモニタリングにおける最大の盲点だ。IDS/IPSを設計する際は、必ずLAG全体を一つの論理ポートとして認識できる構成を採用すべきである。
また、現代のインフラでは、VXLAN や GENEVE といったオーバーレイ技術がLACPの上で動作することも多い。この場合、インナーパケットのハッシュ計算にまで踏み込まないと、物理リンクの偏りは解消できない。
最後に：プロトコルの深淵へ
ネットワークプロトコルは、パケット一つ一つの背景に「なぜそうなっているのか」という歴史と哲学がある。LACPを単なる束ねる機能として見るのではなく、L2レイヤがL3以上の通信品質をいかに担保しようとあがいているか――その苦悩に思いを馳せることが、真のトラブルシューターへの第一歩だ。
次は、NICの RSS（Receive Side Scaling）とLACPのハッシュ計算が、どのようにCPUの softirq を消費し、レイテンシを削り取っているのかを解説しよう。ネットワークの真実は、常にカーネルの奥深くにある。
コメント