はじめに
1 Gbps のリンクを 2 本束ねたので 2 Gbps 出るはずが、速度を測ると 1 Gbps のまま。あるいは、リンク使用率のグラフを見ると片方のリンクばかりが高く、もう片方はほぼ使われていない。リンクアグリゲーション（LAG）を導入した現場で、この「期待した帯域が出ない」問題は最も頻繁に遭遇するトラブルの 1 つです。
厄介なのは、この症状の原因が「障害」ではなく「仕様と設定の組み合わせ」であることが多い点です。どこも壊れていないため、闇雲に調べても原因にたどり着きにくく、切り分けの順序が重要になります。
この記事では、「束ねたのに速くならない」「帯域が偏る」という症状を、期待値の確認 → 偏りの可視化 → ハッシュ設定の見直し → 設計での対応、という診断フローで整理します。
- 「速くならない」の原因を切り分ける診断フロー
- そもそも速くならないのが仕様であるケースの見分け方
- 帯域の偏りの確認手順と「送信側の設定を見る」という原則
- FortiGate・Linux・YAMAHA SWX のハッシュ設定の確認・変更方法
- ハッシュ変更でも改善しない場合の設計上の選択肢
結論を先に述べると、原因は次の 3 段階のいずれかに整理できます。第 1 段階は仕様の誤解（単一フローは 1 リンク分が上限、そもそも増速に対応しない機器がある）、第 2 段階はハッシュ設定と通信パターンの不整合（MAC ベースのハッシュでルーター越え通信が偏る等）、第 3 段階はフロー分布そのものの偏り（少数の巨大フローが支配的）です。この順に確認することで、無駄なく原因へたどり着けます。
なお、ハッシュ分散の原理（フロー単位で振り分けられる理由）は、関連記事『リンクアグリゲーションの仕組みと方式の違い』で解説しています。
「束ねたのに速くならない」原因の切り分けフロー
調査に入る前に、まず「その期待値は正しいか」を確認します。LAG の帯域拡張には原理上・仕様上の前提があり、症状に見えるものの一定割合は正常動作だからです。切り分けの全体像は次のとおりです。
| 段階 | 確認内容 | 該当する場合の結論 |
|---|---|---|
| 1 | 単一フローで速度を測っていないか | 正常動作（仕様） |
| 2 | 増速に対応しない機器（NEC IX 等）ではないか | 正常動作（機器仕様） |
| 3 | 複数フローでも特定リンクに偏っていないか | ハッシュ設定の見直しへ |
| 4 | ハッシュを変えても改善しないか | フロー分布の問題・設計対応へ |
まず期待値を確認する（単一フローは 1 リンク分が上限）
最初に確認すべきは、速度の測定方法です。1 本のファイル転送や 1 本の iperf セッションで速度を測っている場合、1 リンク分の速度しか出ないのは正常動作です。LAG はフロー（同じ送信元・宛先の組み合わせを持つ一連の通信）単位でリンクを割り当てるため、単一フローは常に 1 本の物理リンクだけを通ります。1 Gbps × 2 本の LAG で単一フローが 1 Gbps 止まりになるのは、期待値の側の誤りです。
したがって、LAG の帯域拡張効果を正しく測定するには、次の条件を満たす必要があります。
- 複数のクライアント（または複数の送信元・宛先の組み合わせ）から同時に通信を発生させる
- ハッシュの入力になる要素（IP アドレスやポート番号）にバリエーションを持たせる
複数フローの合計スループットが 1 リンク分を明確に超えるなら、LAG は帯域拡張として機能しています。複数フローでも合計が 1 リンク分から伸びない場合に、初めて「偏り」の調査（次章）へ進みます。
なお、「単一の大容量転送を高速化したい」が本来の要件だった場合、LAG はその解決策になりません。リンクの本数追加ではなく、10 G など上位速度への移行が正しい対処です。この判断は早い段階で下せるほど手戻りが少なくなります。
増速に対応しない機器（NEC IX）ではないか
もう 1 つ、調査の前に確認すべきが機器の仕様です。リンクアグリゲーション＝帯域拡張と冗長化、という一般論が通用しない機器が存在します。
代表例が NEC IX シリーズです。公式 FAQ・機能説明書に「リンクアグリゲーション機能を使用して回線の増速はできません」と明記されており、冗長化専用の機能と位置づけられています。この機器で「束ねたのに速くならない」のは、トラブルではなく仕様どおりの動作です。詳細は関連記事『NEC IX リンクアグリゲーションの設定』を参照してください。
同じ静的 LAG 専用のルーターでも、YAMAHA RTX は「出力ポートが分散していれば論理リンク全体の帯域が増加する」と公式に記載されており、機器によって位置づけが異なります。「この LAG は帯域拡張を仕様としてサポートしているか」を、調査より先に機器の公式ドキュメントで確認することが、無駄な切り分け作業を省く近道です。
帯域の偏りを確認する手順
複数フローでも合計スループットが伸びない場合、次のステップは偏りの可視化です。感覚ではなくメンバーポート単位の数字で確認します。
リンク使用率で偏りを可視化する
確認の鉄則は、LAG（論理インターフェース）単位ではなく、メンバー物理ポート単位で使用率を見ることです。論理インターフェースの合計値だけを見ていると、内部の偏りは見えません。
SNMP 監視やグラフツールを使っている場合は、メンバーポートごとの使用率グラフを並べて比較します。特定ポートだけが高止まりし、他がほぼゼロという形が典型的な偏りです。
その場で確認する場合は、各機器のインターフェースカウンタ（Cisco の show interfaces、FortiGate の diagnose netlink aggregate name のメンバー別カウンタ、YAMAHA SWX の show interface 等）で、メンバーポートごとの送受信量・レートを比較します。
このとき、送信（TX）と受信（RX）を分けて記録しておいてください。次の切り分けで、どちらの方向が偏っているかが重要になります。
偏りは送信側の設定で決まる（方向ごとに分けて考える）
ハッシュによるリンク選択は、フレームを送信する側の機器が、自分のハッシュ設定に基づいて行います。つまり、各機器のハッシュ設定は、その機器からの送信方向にのみ作用します。この原則から、見るべき設定がどちらの機器のものかを特定できます。
| 偏っている方向 | 確認・変更すべき設定 |
|---|---|
| 自機器からの送信（TX）が偏る | 自機器のハッシュ設定 |
| 自機器での受信（RX）が偏る | 対向機器のハッシュ設定 |
「スイッチ A で受信が偏っているから」とスイッチ A の設定をいくら変えても、受信の偏りは改善しません。受信の分散を決めているのは対向機器の送信ハッシュだからです。この取り違えは偏り調査で最も多い空振りのパターンであり、方向の特定を最初に行うだけで調査時間を大幅に短縮できます。
なお、行き（自機器→対向）と帰り（対向→自機器）の通信が別々のリンクを通ること自体は正常です。両方向が同じリンクを通る保証はどこにもありません。
ハッシュ設定の確認と変更（メーカー別）
偏っている方向の機器を特定したら、その機器のハッシュ設定を確認します。偏りの典型パターンは、MAC アドレスベースのハッシュ × ルーター（L3 ゲートウェイ）越えの通信です。宛先 MAC がすべてゲートウェイの MAC になり、ハッシュの入力が偏るためです。対処の方向性は「IP やポート番号など、より変動する要素をハッシュに含める」ことに尽きます。
FortiGate: algorithm の確認と変更
FortiGate の既定値は L4（IP アドレス＋ポート番号）で、最初から最も分散粒度の細かい設定です。偏りが疑われる場合は、まず既定から変更されていないかを確認します。
FGT # diagnose netlink aggregate list
1 name LAG-to-SW status up algorithm L2 lacp-mode active ← L2 になっていたら要注意L2 や L3 に変更されている場合、config system interface 配下で set algorithm L4 に戻すことで改善する可能性があります。設定の詳細は関連記事『FortiGate リンクアグリゲーションの設定手順』を参照してください。
Linux bonding: xmit_hash_policy の確認と変更
Linux bonding は注意が必要です。既定の xmit_hash_policy は layer2（MAC アドレスのみ）のため、ルーター越えの通信が大半を占めるサーバーでは、偏りが発生しやすい初期状態です。現在値は次のコマンドで確認できます。
$ cat /proc/net/bonding/bond0 | grep -i hash
Transmit Hash Policy: layer2 (0)変更先の選択肢は 2 つあり、性質が異なります。
| ポリシー | ハッシュ入力 | 802.3ad への準拠 |
|---|---|---|
| layer2+3 | MAC＋IP アドレス | 準拠 |
| layer3+4 | IP アドレス＋ポート番号 | 完全には準拠しない |
layer3+4 は最も分散が細かい一方、カーネル公式ドキュメントに準拠性の注意が明記されています。
参考: Linux Ethernet Bonding Driver HOWTO（kernel.org 公式）
“This algorithm is not fully 802.3ad compliant.”
（このアルゴリズムは、完全には 802.3ad に準拠していません）
https://www.kernel.org/doc/Documentation/networking/bonding.txt
具体的には、フラグメント化されたパケットと非フラグメントのパケットが混在する単一の TCP / UDP 会話が 2 つのインターフェースにまたがり、順序逆転が発生しうる、というものです。公式ドキュメントは同時に、TCP がフラグメントを起こすことはまれで、大半のトラフィックはこの条件に該当しないとも述べています。一般的な用途では layer3+4 で問題になるケースは少ないものの、準拠性を優先するなら layer2+3、分散を優先するなら layer3+4、という選択基準になります。
YAMAHA SWX: ロードバランスルールの確認と変更
YAMAHA SWX の既定値も MAC ベースです。公式技術資料に次のとおり記載されています。
参考: リンクアグリゲーション（SWX2220 技術資料、YAMAHA 公式）
「デフォルト設定値は、宛先/送信元MACアドレスです」
http://www.rtpro.yamaha.co.jp/SW/docs/swx2220/Rev_1_04_06/interface/interface_lag.html
現在値は show etherchannel（LACP）または show static-channel-group（静的）の「Load balancing:」行で確認できます。
Yamaha# show etherchannel
% Lacp Aggregator: po1
% Load balancing: src-dst-mac
% Member:
port1.1
port1.2ルールは、MAC・IP・L4 ポートそれぞれについて宛先 / 送信元 / 両方を選ぶ 9 種類（src-mac、dst-mac、src-dst-mac、src-ip、dst-ip、src-dst-ip、src-port、dst-port、src-dst-port）から選択でき、グローバル設定として全論理インターフェースに共通で適用されます。ルーター越えの通信で偏る場合は、IP ベースへの変更が定石です。
Yamaha(config)# port-channel load-balance src-dst-ipSWX の設定全般は関連記事『YAMAHA リンクアグリゲーションの設定手順』を参照してください。
Cisco: 既定 src-mac に注意
Cisco Catalyst（IOS-XE のボックス型）も、既定のロードバランス方式が src-mac（送信元 MAC のみ）であり、偏りやすい初期状態の代表例です。現在値は show etherchannel load-balance で確認でき、port-channel load-balance src-dst-ip 以上への変更が定石です。
Cisco については、振り分け先を実機でシミュレーションする test etherchannel load-balance コマンドや、スタック構成でハードウェアの転送先を確認する FED コマンドなど、偏り調査に使える強力なツールが揃っています。これらの詳細な使い方とアルゴリズムの選定基準は、関連記事『EtherChannel ロードバランスの仕組みと振り分け先の確認方法』で解説しています。
ハッシュを変えても改善しないケース
ハッシュ設定を見直しても偏りが解消しない場合、原因は設定ではなくトラフィックの分布そのものにあります。ここから先はハッシュの原理上の限界であり、設定変更ではなく設計での対応に切り替える判断が必要です。
フローが少ない・巨大フローが支配的な環境
ハッシュ分散が均等に近づくのは、「十分に多くの、サイズの偏りが小さいフローが流れている」ことが前提です。統計的に数が多ければ均されるという仕組みのため、前提が崩れる環境では原理的に偏ります。代表的なパターンは 3 つです。
- フロー数が少ない
-
たとえば 2 本のリンクに対してフローが 3 本しかない場合、ハッシュ結果が偶然同じリンクに寄る確率は無視できません。夜間バックアップのように少数のジョブだけが流れる時間帯は、偏って見えるのがむしろ自然です。フロー数がリンク本数と同程度しかない環境では、均等な分散は期待できません。
- 巨大フロー（エレファントフロー）が支配的
-
1 本のフローは分割されないため、リンク帯域に迫るような巨大フロー（大容量のバックアップ転送、ストレージレプリケーション等）が 1 本でも存在すると、そのフローが載ったリンクだけが飽和します。他のフローがもう片方のリンクへ分散されていても、「片方だけ使用率が高い」というグラフになります。これはハッシュ設定では解決できません。
- ハッシュ入力のバリエーションが足りない
-
同一のサーバーペア間で、同一ポートを使った通信が大半を占める場合（特定サーバー間の NFS 通信等）、L4 まで含めたハッシュでも入力が固定的になり、分散しません。ハッシュはあくまで「入力の多様性」を分散に変換する仕組みであり、入力が単調な環境では効果を発揮できないためです。
どのパターンに該当するかは、偏っているリンクに実際に載っているフローを特定すると判断できます。NetFlow / sFlow などのフロー可視化があれば確実ですが、なければ「その時間帯に動いている大口の通信（バックアップ、レプリケーション等）」から当たりをつけるだけでも十分に絞り込めます。Cisco 環境であれば、特定の通信がどのリンクを通るかを test etherchannel load-balance コマンドで机上確認できます（詳細は関連記事『EtherChannel ロードバランスの仕組みと振り分け先の確認方法』を参照してください）
改善策の選択肢（設計での対応）
トラフィック分布が原因と判明した場合の選択肢は、次の 4 つに整理できます。
1. 上位速度リンクへの移行
巨大フロー・少数フロー環境の正攻法です。1 G × 4 本の LAG で偏りに悩むより、10 G × 1 本（冗長化が必要なら 10 G × 2 本の LAG）へ移行する方が、構成もシンプルになります。単一フローの上限そのものが引き上がるため、ハッシュの原理的限界の影響を受けません。
2. アプリケーション側の並列化
プロトコルやアプリケーションによっては、単一の論理的な通信を複数の TCP セッションに分けて並列転送する仕組みが用意されている場合があります（ファイル共有プロトコルのマルチセッション機能等）。セッションが分かれればハッシュの入力が多様化し、複数リンクへの分散が期待できます。適用可否は使用しているソフトウェア・プロトコル側の仕様に依存するため、個別に確認が必要です。
3. フローの分離（経路設計での対応）
偏りの原因となっている大口フローを特定できているなら、その通信だけを LAG とは別の専用リンクへ逃がす、用途別に LAG を分割するといった経路設計での対応も選択肢です。ハッシュ任せにせず、大口フローだけ決定論的に経路を分ける発想です。
4. 「冗長化目的」と割り切る
帯域拡張が実質的に効かない環境であっても、リンク障害への耐性という LAG の価値は失われていません。増速はあきらめて冗長化目的の構成と位置づけ直し、帯域要件は別の手段（上記 1）で満たす、という整理も設計判断として十分に合理的です。
いずれを選ぶにしても、LAG の帯域拡張が最も効くのは「多数の均質なフローを集約する区間」であり、そこから外れる環境では設計側で補う、というのが本記事全体の結論です。
まとめ
「リンクアグリゲーションが速くならない」という症状は、仕様の誤解、ハッシュ設定と通信パターンの不整合、フロー分布そのものの偏り、という 3 つの層に分けて切り分けることで、効率的に原因へたどり着けます。特に「偏りは送信側の設定で決まる」という原則を押さえるだけで、調査の空振りを大きく減らせます。
- 単一フローの速度が 1 リンク分にとどまるのは正常動作（仕様）
- NEC IX など増速を仕様としてサポートしない機器の存在にも注意
- 偏りの確認は LAG 単位ではなくメンバー物理ポート単位で行う
- 送信の偏りは自機器、受信の偏りは対向機器のハッシュ設定を確認する
- Linux（layer2）・YAMAHA SWX（src-dst-mac）・Cisco（src-mac）は既定が MAC ベースで偏りやすい
- FortiGate の既定は L4 で、変更されていないかの確認が先
- ハッシュで解決しない偏りは上位速度への移行や経路設計で対応する
以上、最後までお読みいただきありがとうございました。
