帯域の幻想とハッシュの残酷さ：EtherChannelロードバランシングの深層
ネットワークエンジニアという人種は、往々にして「帯域」という数字に魅了される。1Gbpsのリンクを4本束ねれば4Gbpsになる。この単純な算術は、L2スイッチングの世界では「EtherChannel（またはLAG）」という名の魔法によって実現される。しかし、パケットの深淵を覗く者ならば知っているはずだ。この魔法は、パケット単位のラウンドロビンという「愚行」を避ける代償として、特定の物理リンクにトラフィックを偏らせる「ハッシュの呪縛」を背負っていることを。
今日は、CCIEレベルの現場で語られることの少ない、ポートチャネルのハッシュアルゴリズムと、それがモダンなWeb通信（TLS/TCP）に与える不可避の影響について紐解いていこう。
—
ハッシュアルゴリズムの選択がもたらす「非対称」な現実
EtherChannelのロードバランスは、フレームのヘッダー情報をハッシュ関数に放り込み、その結果（0からN-1の値）を物理ポートにマッピングすることで行われる。問題は、何をハッシュの「種（シード）」にするかだ。
ハッシュ選択の優先順位とリスク
多くのエンジニアはデフォルト設定のまま運用しがちだが、ここに落とし穴がある。
- src-mac / dst-mac: レイヤ2隣接ノード間では有効だが、ルーターを跨いだ瞬間、送信元/宛先MACが「ルーターのMAC」で固定されるため、アップリンクでは全トラフィックが単一リンクに集中する。これは悲劇だ。
- src-ip / dst-ip: L3環境下で最もバランスが良い。しかし、特定のクライアント（NAT配下など）が大量のセッションを張る場合、結局は「偏り」が発生する。
- src-port / dst-port: L4ポートを含めることで、ようやく「同一IP間の複数セッション」を別リンクに分散させることが可能になる。
現場の知見: 現代のマイクロサービス環境や、大量のTLSコネクションを捌くロードバランサー配下では、必ず l4-port を含めたハッシュアルゴリズムを選択すべきだ。
# Cisco IOSでの設定例: L3/L4情報をハッシュに含める
Switch(config)# port-channel load-balance src-dst-mixed-ip-port
# ※この設定により、送信元/宛先IPとポート番号の双方がハッシュ計算に寄与し、
# 同一クライアント・同一サーバー間でもポート番号の差異でリンクが分散される。—
TLSハンドシェイクとTCPバッファ：マイクロバーストが引き起こす隠れた遅延
ロードバランシングの偏りは、単なる「リンク使用率の不均衡」では済まない。TLSのハンドシェイク中に発生する「マイクロバースト」が、特定の物理ポートのキューを瞬時に溢れさせれば、パケットロスが誘発される。
なぜTCPバッファチューニングだけでは不十分なのか
TCPの Initial Congestion Window (initcwnd) を広げ、高速な立ち上がりを目指しても、EtherChannelの物理ポートがハッシュの偏りで瞬時に詰まれば、再送制御（Retransmission）が発動する。これこそが、往復遅延時間（RTT）を不自然に増大させる原因だ。
もし貴方がLinuxサーバー側でTCPチューニングを行っているなら、NICのバッファとスイッチ側のポートバッファの整合性を意識してほしい。
# LinuxでのTCPバッファ設定（sysctl.conf）
# 広大なウィンドウサイズは、ポートチャネルのバースト耐性が低い環境では逆効果になることもある
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216—
脆弱性とパフォーマンスのトレードオフ：ハッシュの偏りを利用したDoS攻撃
セキュリティの観点からも、ハッシュアルゴリズムの固定は危険だ。特定のハッシュ値にトラフィックを集中させるような「悪意あるパケット」を継続的に送り込まれた場合、EtherChannelの特定の物理リンクだけを飽和させ、結果的にネットワーク全体の遅延を誘発する（いわゆる「リンク飽和攻撃」）ことが可能である。
このリスクを回避するために、一部のハイエンドスイッチでは「ハッシュの偏り（Polarization）」を動的に解消するアルゴリズムや、ポートごとのキュー制御を厳密に行う機能が実装されている。
アーキテクトとして取るべき次のステップ
1. モニタリングの深化: 単なる snmpwalk でのトラフィック監視ではなく、物理ポート単位の discard や output queue drops を監視せよ。
2. ハッシュの動的制御: 可能であれば、LACP（IEEE 802.3ad）を適切に設計し、必要に応じてリンクの増減を動的にコントロールする。
3. パケットの直交化: 物理リンクを論理的に分けることができない場合、アプリケーションレイヤーでの接続の「分散化（DNSラウンドロビンやAnycast）」を検討し、ネットワーク層への負荷を分散させる。
—
結びに代えて：教科書を閉じてCLIを開け
ネットワークプロトコルは生き物だ。EtherChannelのロードバランスアルゴリズム一つとっても、それがアプリケーションのハンドシェイクにどのような影響を与えるか、その挙動をパケットのタイムスタンプ一つ一つまで追跡する執念こそが、真のインフラアーキテクトの矜持である。
「なぜか遅い」という定性的な嘆きを、「ハッシュの衝突による特定リンクのキューイング遅延」という定量的な事実に落とし込めたとき、貴方はネットワークの深淵に一歩近づいている。
明日の朝、スイッチのコンソールを開くとき、貴方が見ている show etherchannel load-balance の表示が、ただの設定値ではなく、パケットの奔流を制御する重要なパラメータに見えることを願っている。
コメント