LACPのハッシュアルゴリズム：その「偏り」を制する者がネットワークを制す
ネットワークエンジニアとして現場を渡り歩いていると、避けては通れないのが「LACP（Link Aggregation Control Protocol）のロードバランシング」という名の黒魔術だ。
「LAG（Link Aggregation Group）を組めば帯域が2倍になる」――これは教科書的な正解に過ぎない。現実のトラフィックは、そんなに都合よく均等に分散してくれない。なぜなら、LACPのハッシュアルゴリズムは、単なる「ラウンドロビン」ではなく、パケットヘッダーの特定のフィールドをシード値として算出される「決定論的な偏り」を宿命づけられているからだ。
ハッシュ計算の内部挙動を解剖する
LACPの分散アルゴリズムは、通常、送信元/宛先のMACアドレス、IPアドレス、そしてL4ポート番号（TCP/UDP）の組み合わせによって決定される。スイッチのASIC内部では、これらのフィールドをキーとして、XOR演算やCRC32といったハッシュ関数を通し、その結果の下位数ビット（リンク数に応じて変化）を物理ポートのインデックスにマッピングしている。
ここで最も陥りやすい罠が、「フローの偏り」だ。
例えば、バックアップサーバーからストレージへの大容量転送が1対1で行われている場合、いくらリンクを束ねても、その通信は常に「単一の物理リンク」を流れる。ハッシュ値が変わらないからだ。このとき、ネットワークインターフェース（NIC）の統計を確認すると、あるリンクは90%使用率なのに、別のリンクはアイドリングという悲劇が起きる。
偏りを解消するためのトポロジ最適化とチューニング
この偏りを物理レベルで解消するには、ハッシュのキー（入力データ）を動的に変えるしかない。最近のスイッチOSでは、enhanced-hashingやsymmetric-hashingといったオプションが提供されている。
1. 送受信対称性の確保
symmetric-hashingを有効にすることで、双方向のトラフィックが同一の物理リンクを通過するよう制御できる。これは、特にステートフルなファイアウォールやIDS/IPSがLACPの先に介在している場合に極めて重要だ。非対称経路をとると、セッションの片方向だけがフィルタをすり抜けたり、TCPリセットが発生したりする脆弱性を招く。
# Cisco Nexusにおけるハッシュアルゴリズムの調整例
# L3/L4ポート情報をキーに含めることで、フロー単位の粒度を細かくする
port-channel load-balance ethernet destination-ip source-ip l4port2. Linuxカーネル側のチューニング
サーバーサイドでLACP（Bonding mode 4）を組む場合、xmit_hash_policyの設定が極めて重要だ。デフォルトではレイヤー2ベースのハッシュになっていることが多いが、これをlayer3+4に変更し、カーネルスタックがポート番号まで考慮するように強制する。
# /etc/modprobe.d/bonding.conf の設定例
alias bond0 bonding
options bonding mode=4 miimon=100 lacp_rate=fast xmit_hash_policy=layer3+4※ lacp_rate=fast（1秒間隔の送信）に設定することで、リンク障害時のコンバージェンスを高速化する。デフォルトのslow（30秒間隔）では、高可用性を担保するインフラとしては心もとない。
パフォーマンスとセキュリティの境界線
LACPの設計において、もう一つ見落とされがちなのが、TCPバッファとウィンドウサイズの影響だ。
リンク間でパケットの到着順序が入れ替わる（Out-of-order）と、TCPは再送制御（Retransmission）を頻発させ、スループットが劇的に低下する。これを防ぐためには、単一のフローが物理リンクを跨がないようなLACP設計が必須であり、それが「ハッシュアルゴリズムの選定」に直結する。
また、TLSハンドシェイクの観点では、RTT（Round Trip Time）の削減がボトルネックになる。LACPによるリンクの過負荷はジッターを増大させ、TCPの「スロースタート」フェーズにおいてパケットロスを誘発する。これを防ぐには、単なる負荷分散だけでなく、以下のチューニングを併用すべきだ。
- TCP BBR (Bottleneck Bandwidth and Round-trip propagation time) の採用:
パケットロスを「混雑」と誤認せず、帯域の実効値を測定するBBRアルゴリズムは、LACPによる微細なジッターの影響を緩和する。
# sysctlによるBBRの有効化
sysctl -w net.core.default_qdisc=fq
sysctl -w net.ipv4.tcp_congestion_control=bbr結論：プロトコルの美学は「予測可能性」にある
LACPの設計において、「とりあえず全部盛り」のハッシュ設定にするのは素人のやることだ。プロは、そのネットワークを流れるトラフィックの「フローの多様性」を見極める。
- 多数の小規模なHTTPリクエストが流れる環境なら、L4ポートまで含めたハッシュが有効。
- 特定のサーバー間での巨大な転送が支配的なら、物理的にリンクを分離するか、アプリケーション層での分散を検討する。
パケットは嘘をつかない。LACPの統計カウンターを眺め、偏りを見つけ、アルゴリズムを微調整する。この泥臭い試行錯誤こそが、安定したネットワークを構築する唯一の道である。次回の構築時、ぜひ一度、show port-channel load-balanceの結果と、実トラフィックのバランスを照らし合わせてみてほしい。そこには、設計の意図と現実の乖離という、最も知的なパズルが待っているはずだ。
コメント