【Cisco】EtherChannel のロードバランスの仕組みと振分先インターフェースの確認方法

はじめに

帯域幅を増やし、冗長性を確保するために使われる Cisco の EtherChannel。 2本のリンクを束ねれば「通信がきれいに 50:50 に分散される」と思われがちですが、実際は必ずしもそうではありません。場合によっては「片方のリンクばかり混雑している」「特定の通信だけ遅い」といった偏り（Polarization）が発生することがあります。

トラブルシューティングの際、「このサーバーからあっちの PC への通信は、物理的にどのケーブルを通っているのか？」を特定することは、インターフェースのエラー切り分けやパフォーマンス分析において非常に重要です。

本記事では、ブラックボックスになりがちな EtherChannel の振り分けロジックと、意図通りに分散させるための確認手法を解説します。

EtherChannel ロードバランスの仕組み

EtherChannel を設定したのに「なぜか片方のケーブルばかりランプが激しく点滅している…」という経験はありませんか？ その謎を解く鍵は、スイッチ内部で行われている 「ハッシュ計算」 にあります。

誤解されがちなポイント（ラウンドロビンではない）

最もよくある誤解が、「パケットを 1つずつ順番に Link A、Link B、Link A… と振り分けている（ラウンドロビン方式）」というものです。 Cisco Catalyst スイッチのデフォルト動作はそうではありません。

EtherChannel はパケット単位ではなく、「フロー（通信の流れ）単位」 で振り分けを行います。つまり、「ある PC から あるサーバーへの通信」は、常に同じ物理ケーブルを通ります。 これは、パケットの到着順序が入れ替わる（Out of Order）のを防ぐための重要な仕様です。

ハッシュアルゴリズムの仕組み

では、どうやって「どのケーブルを通るか」を決めているのでしょうか？ スイッチは、パケットのヘッダ情報（IP アドレスや MAC　アドレス）の一部を取り出し、計算式（ハッシュ関数）に掛け合わせます。

• 入力: 送信元 IP、宛先 IP、MAC アドレス、ポート番号など（設定による）
• 計算: これらを数値化して計算（XOR 演算など）
• 出力: 計算結果（ハッシュ値）に基づいて、物理ポート（Link A または Link B）を決定

この計算結果は、入力情報が変わらない限り常に同じになります。そのため、同じ宛先への通信は常に同じリンクを通ることになります。

通信が偏る（Polarization）原因

上記の仕組み上、「計算に使う情報（ロードバランス方式）」 の選び方を間違えると、通信の偏りが発生します。

例えば、「宛先 MAC アドレス」 だけで振り分ける設定にしていたとします。 社内の PC がインターネットへ出る際、宛先 MAC アドレスはすべて「ルータ（デフォルトゲートウェイ）」の MAC アドレスになります。 すると、計算結果が全員同じになるため、数百台の PC があっても全員が「Link A」だけを使い、Link B はスカスカ という事態（Polarization）が起こります。

これを防ぐには、変動しやすい情報（送信元 IP や宛先 IP の組み合わせなど）を計算に使う設定にする必要があります。

現在の分散方式の確認と変更

ロードバランスの計算式（アルゴリズム）は、スイッチ全体で共通の設定となります。 まずは現状を確認し、ネットワーク構成に合わせて最適なものに変更する必要があります。

Switch# show etherchannel load-balance
EtherChannel Load-Balancing Configuration:
        src-dst-ip

(config)# port-channel load-balance src-dst-ip

通信経路のシミュレーション（test コマンド）

トラブルシューティングの現場では、「アルゴリズムが何か」よりも、「今、この重要な通信がどの物理ケーブルを通っているか」 を特定したい場面が多々あります。

実際に大量のパケットを流して確認するのは大変ですが、Cisco スイッチには 「もしこの IP アドレスから、あの IP アドレスへ通信したら、どのリンクを使うか？」 をシミュレーションして教えてくれる便利なコマンドが用意されています。

test コマンドの使い方

特権モード（#）で以下のコマンドを使用します。これは設定変更ではなく、単なるテスト実行なので通信への影響はありません。

基本構文:

test etherchannel load-balance interface port-channel <番号> ip <送信元IP> <宛先IP>

※ MAC アドレスベースの場合は ip の部分を mac に変えて入力します。

具体的な実行例

例えば、「PC（192.168.1.10）から サーバー（10.0.0.5）への通信」 が、Port-channel 1 のメンバーポートのうち、どれを通るかを確認してみましょう。

Switch# test etherchannel load-balance interface port-channel 1 ip 192.168.1.10 10.0.0.5

Would select Gi1/0/1 of port-channel 1

結果の読み方:

Would select Gi1/0/1

「もしこの通信が発生したら、スイッチはハッシュ計算の結果、GigabitEthernet1/0/1 を選択します」という答えです。

これにより、実際のパケットをキャプチャしなくても、机上で通信パスを特定することができます。

トラブルシューティングでの活用シーン

このコマンドは、以下のような場面で活用できます。

スタック構成（Catalyst 3850/9300 等）での詳細確認

Catalyst 3850 や Catalyst 9000 シリーズなど、IOS-XE を搭載したモダンなスイッチをスタック構成で使用している場合、さらに踏み込んだ確認コマンドが存在します。

先ほどの test コマンドはあくまでソフトウェア的なシミュレーションですが、以下のコマンドを使用すると、スイッチの心臓部であるハードウェア（FED: Forwarding Engine Driver）が、実際にどのようにパケットを処理しようとしているかを確認できます。

ハードウェアレベルのロードバランス確認

以下のコマンドを使用します。これはスタックメンバーのスイッチ番号を指定して実行します。

show platform software fed switch <Stack番号> etherchannel <Po番号> load-balance ip <SrcIP> <DstIP>

※ <Stack番号> には active などのロールではなく、 1 や 2 などのメンバー番号が入ります。

実行例: スイッチ1（Stack 1）において、Port-channel 10 での振り分けを確認する場合

Switch# show platform software fed switch 1 etherchannel 10 load-balance ip 192.168.1.10 10.0.0.5

Dest Port: GigabitEthernet1/0/1

このコマンドのメリット: スタック構成では、複数のスイッチにまたがって EtherChannel（Cross-Stack EtherChannel）を組むことがよくあります。このコマンドを使うことで、「ハードウェア（ASIC）レベルで、どの物理ポートへ転送する決定が下されたか」という最終的な真実を知ることができます。

このコマンドは IOS-XE 搭載の Catalyst スイッチ（3650/3850/9000シリーズ等） に特有のものです。旧来の IOS スイッチ（Catalyst 2960/3750 等）や、Nexus シリーズでは構文が異なるためご注意ください。

まとめ

本記事では、Cisco EtherChannel のロードバランスの仕組みと、通信パスの確認方法について解説しました。

仕組みは「ハッシュ計算」

• パケットを均等に配る「ラウンドロビン」ではなく、計算結果に基づいた「固定的な振り分け」であることを理解しましょう。

アルゴリズム選びが重要

• デフォルトのまま運用せず、src-dst-ip （送信元/宛先 IP）などの変動要素が多い設定に変更することで、通信の偏り（Polarization）を防げます。

test コマンドで確認

• 「特定の通信がどのリンクを通るか」は、test etherchannel load-balance コマンドで簡単にシミュレーションできます。

以上、最後までお読みいただきありがとうございました。

---

シスコ技術者認定教科書 CCNA 完全合格テキスト＆問題集［対応試験］200-301 第2版 （EXAMPRESS） [ SAK University 東京イノベーションキャンパス 林口 裕志 ]

created by Rinker

¥4,620 (2026/03/19 21:09:09時点 楽天市場調べ-詳細)

• Amazon
• 楽天市場
• Yahooショッピング

おすすめ書籍