帯域の魔術師「ポートチャネル」の深淵：ハッシュアルゴリズムが握るトラフィック分散の真実
ネットワークエンジニアの諸君、今日も元気にパケットを流しているか。
「ポートチャネル（EtherChannel）を設定すれば帯域が2倍になる」――そう教わった初心者の頃を懐かしく思う。だが、現場の現実はそんなに甘くない。物理リンクを束ねたところで、特定のフローが片方のリンクに偏り、もう片方がガラガラで泣いている…そんな「ロードバランスの偏り」に頭を抱えた経験は誰にでもあるはずだ。
今日は、スイッチがパケットをどう「仕分け」しているのか、その脳内（ハッシュアルゴリズム）を解剖していこう。
—
1. ポートチャネルの哲学：なぜ「完全な均等」は実現できないのか
まず大前提として理解してほしい。ポートチャネルにおけるロードバランスは、「パケット単位」ではなく「フロー単位」で行われる。
もしパケット単位で交互にリンクへ送り出せばどうなるか？ 到着順序が入れ替わり（パケットロスと同様の扱いを受ける）、TCPの再送制御が火を噴く。だからこそ、スイッチは「この送信元から宛先への通信は、このリンクを使う」というルールを固定する必要がある。そこで登場するのが「ハッシュ計算」だ。
ハッシュアルゴリズムの仕組み
スイッチは、フレームのヘッダー情報から数値を抽出し、それをハッシュ関数に通して特定のリンクを割り当てる。
- L2:
Source MAC+Destination MAC - L3:
Source IP+Destination IP - L4:
Source Port+Destination Port
情報源が細かければ細かいほど、フローの数が増え、結果としてトラフィックは分散しやすくなる。逆に、単一のクライアントと単一のサーバー間の通信であれば、どれだけリンクを束ねても、結局「1本のリンクしか使われない」のが運命なのだ。
—
2. 実践：ロードバランス設定の最適解
Cisco IOSを例に取ろう。スイッチ全体でのロードバランス設定は、そのネットワークの「性格」に合わせて選ぶ必要がある。
# 全体的なロードバランス戦略の設定（グローバルコンフィギュレーション）
# L3/L4のポート番号まで考慮に入れることで、分散効率を最大化する
Switch(config)# port-channel load-balance src-dst-mixed-ip-port
# 設定の確認コマンド
Switch# show etherchannel load-balance
# 現在どのフィールドを使ってハッシュ計算しているかを確認できるなぜ src-dst-mixed-ip-port を選ぶのか？
Web APIサーバーがバックエンドで通信している場合、同じIPアドレス間での通信が頻発する。src-dst-ip だけではハッシュ値が固定されてしまうが、そこに L4 Port（TCP/UDPのポート番号）を含めることで、リクエストごとに異なるポートが使われるAPI通信を、より細かくリンクへ分散させることが可能になる。
—
3. Web APIエンジニアへ：パケットがどう振り分けられるかを確認する
インフラの挙動を確かめるために、Pythonで簡単な検証スクリプトを書いてみよう。APIクライアントとして requests ライブラリを使い、宛先IPとポートを変えながらリクエストを投げるイメージだ。
import requests
# 複数のポートや宛先を想定したリクエスト
targets = [
{"ip": "192.168.1.10", "port": 8080},
{"ip": "192.168.1.10", "port": 8081}, # ポート番号を変えることでハッシュ値が変わる
{"ip": "192.168.1.11", "port": 8080}, # 宛先IPが変われば当然ハッシュ値も変わる
]
for target in targets:
url = f"http://{target['ip']}:{target['port']}/api/v1/resource"
try:
response = requests.get(url, timeout=2)
print(f"Request to {url}: Status {response.status_code}")
except requests.exceptions.RequestException as e:
print(f"Failed to connect to {url}: {e}")このスクリプトを回しながら、スイッチ側で show interface port-channel X を叩いてみてほしい。カウンターがどの程度均等に増えているか。それが君の設計の「答え合わせ」だ。
—
4. 現場の教訓：トラブルシューティングの勘所
もし、「特定のリンクだけが異常に混んでいる」という事態に直面したら、以下の順で疑うべきだ。
1. フローの数を確認せよ: 通信相手が1対1なら、それは仕様だ。諦めてNICを高速化（10G→40G等）するしかない。
2. ハッシュの偏りを確認せよ: 特殊なIPアドレス体系（例えば、全て同じサブネットで、なおかつ特定のMACアドレスに集中するような構成）では、ハッシュアルゴリズムが同じ値を弾き出し続ける「ハッシュ衝突」に近い現象が起きる。
3. リンクの物理状態を疑え: 片方のリンクでCRCエラーが多発していれば、スイッチは自動的にそのリンクの利用を避ける、あるいはトラフィックが再送で溢れ、見かけ上のトラフィック量がおかしくなることがある。show interface status でエラーカウンタを必ず見る癖をつけよう。
最後に：ネットワークは「生き物」である
ポートチャネルは魔法の杖ではない。物理的なリンクを束ねるための「糊（のり）」であり、その糊をどう使うかはエンジニアのセンス次第だ。
理論を知り、コードを書き、そして何よりCLIの向こう側にあるパケットの躍動を想像すること。それができれば、君はもう一段上のエンジニアになれるはずだ。
さあ、次のデプロイでは、ハッシュアルゴリズムの選択肢をもう一度見直してみてはどうだろうか。それでは、現場でまた会おう。
コメント