EtherChannel ロードバランスの仕組みと振り分け先の確認方法

はじめに

帯域の拡張と冗長性の確保に使われる Cisco の EtherChannel ですが、2 本のリンクを束ねれば通信が常に 50:50 に分散される、というわけではありません。場合によっては片方のリンクに通信が偏る（Polarization）こともあります。

トラブルシューティングでは、「ある通信が物理的にどのケーブルを通っているのか」を特定できると、インターフェースのエラー切り分けやパフォーマンス分析が進めやすくなります。本記事では、EtherChannel の振り分けロジックと、意図どおりに分散させるための確認手法を整理します。

結論を先に整理すると、EtherChannel はパケット単位ではなくフロー単位で、ヘッダ情報のハッシュ計算によって通る物理リンクを決定します。計算に使う要素の選び方を誤ると偏りが生じるため、現行の IOS-XE 機でも既定となっている src-mac から、src-dst-ip 以上への変更を検討するのが無難です。特定の通信がどのリンクを通るかは、通信に影響を与えずに test etherchannel load-balance コマンドで確認できます。

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

片方のケーブルだけリンク使用率が高い、という状況の背景には、スイッチ内部で行われるハッシュ計算があります。

フロー単位の振り分け（ラウンドロビンではない）

よくある誤解が、パケットを 1 つずつ Link A、Link B と順番に振り分ける（ラウンドロビン方式）というものです。Cisco Catalyst スイッチの既定動作はこれとは異なります。

EtherChannel はパケット単位ではなく、フロー（通信の流れ）単位で振り分けます。同じホストからのパケットは、チャネル内の同じポートを使用します。これは、パケットの到着順序が入れ替わる（Out of Order）のを防ぐための仕様です。

参考: Configuring EtherChannels (Catalyst 9500, IOS XE 17.13.x)
“packets from the same host use the same port in the channel”
（同じホストからのパケットは、チャネル内の同じポートを使用します）
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9500/software/release/17-13/configuration_guide/lyr2/b_1713_lyr2_9500_cg/configuring_etherchannels.html

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

スイッチは、パケットのヘッダ情報（IP アドレスや MAC アドレスなど）の一部を取り出し、ハッシュ関数に通して物理ポートを選択します。

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

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

偏り（Polarization）の原因

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

たとえば宛先 MAC アドレスだけで振り分ける設定の場合、社内の PC がインターネットへ出る通信では、宛先 MAC アドレスがすべてデフォルトゲートウェイ（ルータ）のものになります。すると計算結果が同じになり、多数の PC があっても全員が同じリンクに集中し、もう一方のリンクが使われない状態（Polarization）になります。

これを避けるには、変動しやすい情報（送信元 IP と宛先 IP の組み合わせなど）を計算に使う設定にします。

分散方式（アルゴリズム）の確認と選定

ロードバランスの計算式（アルゴリズム）は、スイッチ全体で共通の設定です。まず現状を確認し、ネットワーク構成に合わせて選定します。

現在の設定の確認

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

表示された文字列（この例では src-dst-ip）が、現在ハッシュ計算に使われている要素です。

アルゴリズムの種類と選定基準

設定可能なアルゴリズムは機種により異なりますが、代表的なものは次のとおりです。

選定の基本は、ネットワーク上の位置と通信の多様性に方式を合わせることです。アクセス層のように送信元が多様な箇所では送信元ベース、ルータ側のように単一 MAC へ集まる箇所では送信元/宛先や IP ベースが有効です。要素が多く変動しやすい方式ほど、偏りを抑えやすくなります。

なお、Catalyst 9000 系では src-dst-mixed-ip-port のように L4 ポートを含む方式や、複数要素を組み合わせる port-channel load-balance extended も選択できます。Catalyst 9600 系では VLAN ID を加味した方式（vlan-dst-ip など）も利用できます。

設定変更

現行の Catalyst 9000 系（IOS-XE）でも、既定のロードバランス方式は src-mac です。L2 情報（MAC）だけだと、ルータ越えの通信で宛先 MAC が一点に集まり偏りやすいため、基本的には src-dst-ip（またはそれ以上）への変更を推奨します。

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

参考: Layer 2/3 Commands, port-channel load-balance (Catalyst 9400)
“The default value is src-mac”
（既定値は src-mac です）
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9400/software/release/17-5/command_reference/b_175_9400_cr/layer_2_3_commands.html

通信経路の確認（test コマンド）

トラブルシューティングでは、アルゴリズムの種類よりも、対象の通信が今どの物理ケーブルを通っているかを特定したい場面が多くあります。Cisco スイッチには、実際にトラフィックを流さずに振り分け先をシミュレーションするコマンドが用意されています。

基本構文と実行例

特権モード（#）で実行します。設定変更ではなくテスト実行のため、通信への影響はありません。

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 を選択する」という意味です。これにより、実際のパケットをキャプチャしなくても通信パスを特定できます。

なお、IOS のバージョンによっては、インターフェース名ではなく RBH 値（Result Bundle Hash）のみが返る場合があります。その際は、RBH 値に対応する物理ポートを別途確認します。また、Catalyst 6500/6800 系や Nexus 系では構文が異なるため注意してください。

参考: Understand EtherChannel Load Balance and Redundancy on Catalyst Switches
“Would select Gi6/1 of Po1”
（この通信では Po1 の Gi6/1 が選択される、という出力例）
https://www.cisco.com/c/en/us/support/docs/lan-switching/etherchannel/12023-4.html

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

パケットキャプチャ（SPAN）の対象絞り込み

対象通信が Gi1/0/1 を通ると分かれば、その物理ポートだけを SPAN すればよく、キャプチャ量を抑えられます。

通信品質劣化（CRC エラー）の影響範囲特定

片方のポートで CRC エラーが増えている場合、重要な通信の IP を入力し、結果が該当ポートなら影響範囲を切り分けられます。

帯域の偏りの確認

帯域を多く使っている疑いのある端末（Elephant Flow）の IP を入力し、混雑しているリンクと一致するかを確認できます。

スタック構成での詳細確認（FED コマンド）

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 で 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 スイッチに特有のもので、旧来の IOS スイッチや Nexus 系では構文が異なります。

複数のスイッチを 1 台の論理スイッチとして扱い、その上で MEC（Multi-Chassis EtherChannel）を構成する技術については、関連記事『Catalyst 9000 StackWise Virtual 設定の手順｜SVL と DAD のポイント』で扱っています。従来機での同等構成は、関連記事『Catalyst 4500-X VSS 設定の手順と Dual Active 対策のポイント』を参照してください。これらの MEC でも、リンクの選択には本記事と同じハッシュ計算が用いられます。

まとめ

本記事では、EtherChannel のロードバランスの仕組みと、通信パスの確認方法を整理しました。振り分けがハッシュ計算による固定的なものであることを押さえると、偏りの原因究明やトラブルシューティングが進めやすくなります。

• EtherChannel はパケット単位ではなくフロー単位で振り分ける方式
• 振り分け先はヘッダ情報のハッシュ計算で決まり、同じフローは同じリンク
• 計算要素の選び方を誤ると偏り（Polarization）が発生
• 現行 IOS-XE の既定は src-mac で、src-dst-ip 以上への変更が無難
• アルゴリズムはスイッチ全体で共通、位置と通信特性に応じて選定
• test etherchannel load-balance で通信パスを無影響で確認可能
• スタック構成では FED コマンドでハードウェアの転送先を確認

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