リンクアグリゲーションが組めない原因｜suspended と err-disabled の対処

はじめに

リンクアグリゲーション（LAG）を設定したのに組めない。物理リンクはアップしているのに、論理リンクだけが上がらない。この症状に直面したとき、闇雲に設定を見直し始める前に知っておきたいことがあります。機器は状態表示（フラグ）を通じて、原因をかなり具体的に教えてくれているという事実です。

Cisco の (s) や (I)、FortiGate の negotiating、err-disabled といった状態表示は、それぞれ異なる原因を指しています。読み方さえ知っていれば、原因の候補は最初の 1 コマンドで大きく絞り込めます。

この記事では、LAG が組めない症状を状態表示から逆引きし、suspended・err-disabled・stand-alone という代表的な 3 つの症状別に、原因の特定と対処の手順を解説します。

結論を先に述べると、LAG が組めない原因は状態表示から次の 4 系統に分類できます。設定不一致（suspended）、保護機能の発動（err-disabled）、LACPDU の不達（stand-alone・negotiating）、そして有効化忘れや物理障害です。本記事の早見表で症状を分類し、該当する章の手順に沿って切り分けることで、遠回りせずに原因へたどり着けます。

なお、LAG の基本的な仕組みは関連記事『リンクアグリゲーションの仕組みと方式の違い』を、各機器の設定手順はそれぞれの個別記事を参照してください。

切り分けの起点: 状態表示の逆引き早見表

切り分けの第一歩は、状態確認コマンドの実行です。ただしその前に 1 つだけ、メンバーポートの物理リンク状態を確認してください。物理リンクがダウンしている場合（Cisco のフラグ (D) 等）、それは LAG 以前の問題（ケーブル・SFP・対向ポートの障害）であり、本記事のスコープ外の一般的なリンク障害調査になります。物理リンクが上がっていることを確認した上で、以下の逆引きに進みます。

Cisco のフラグ（I・s・w・D）が示す原因

Cisco の show etherchannel summary のフラグと原因の対応です。

注意点が 1 つあります。Protocol 欄が -（on モード＝静的）の場合、自機器側でフラグが (P) でも、対向と正しく束ねられていることの保証にはなりません。静的 LAG には整合性を検証する仕組みがないためです。静的構成で通信が不安定な場合は、フラグが正常でも両端の設定の突き合わせ（症状 1 の手順）を行ってください。

FortiGate（ASAIEE）と YAMAHA SWX の状態表示

FortiGate と YAMAHA SWX についても、同じ発想で逆引きできます。

 FortiGate（diagnose netlink aggregate name <名前>）

 YAMAHA SWX

SWX の「論理インターフェースは初期状態がシャットダウン」という仕様は、他メーカーの感覚で作業すると高い確率で踏む落とし穴のため、症状 3 で改めて取り上げます。

症状 1: suspended になる（設定不一致の特定）

Cisco でメンバーポートに (s) が付く suspended は、故障ではなく保護動作です。「このポートを束ねると危険な不一致がある」と機器が判断し、意図的に停止させています。したがって、切り分けの本質は「何の不一致を検出したのか」を特定することに尽きます。

メンバーポートの一致条件を突き合わせる手順

最短ルートは、設定の突き合わせを始める前にログを見ることです。suspended への遷移時、Cisco は不一致の内容を具体的に記録しています。

Switch# show logging | include CANNOT_BUNDLE
%EC-5-CANNOT_BUNDLE2: Gi0/2 is not compatible with Gi0/1 and will be suspended (speed of Gi0/2 is 100Mb/s, Gi0/1 is 1000Mb/s)

注目すべきはメッセージ末尾のカッコ内です。不一致の理由がそのまま書かれています。実機で確認される代表的なパターンは次のとおりです。

メッセージ例は実機の syslog 出力に基づきます。記述の細部は機種・バージョンにより異なる場合があります。

このログが残っていれば、突き合わせ作業はほぼ不要で、指摘された項目を修正するだけです。ログが流れてしまっている場合は、show running-config interface で全メンバーポートとポートチャネルインターフェースの設定を並べ、速度・デュプレックス・スイッチポートモード・VLAN 関連（アクセス VLAN、ネイティブ VLAN、許可 VLAN）の差分を探します。一致条件の全体像は関連記事『Cisco EtherChannel の設定手順』の事前確認の節を参照してください。

修正時の注意点が 1 つあります。修正はポートチャネルインターフェースに対して行い、全メンバーへ一括反映させることです。suspended になったポートだけを個別に修正すると、その場は解消しても、別の差分が残って再発する原因になります。

なお、FortiGate で actor / partner state が Out of sync（4 文字目 O）のまま進まないケースも、多くは同種の設定不一致です。FortiGate は「参照が残っていると設定自体が投入できない」設計のため Cisco ほど不一致が起きにくいものの、VLAN サブインターフェースや対向スイッチ側のトランク設定との整合は同じ観点で確認します。

LACP ネゴシエーション不成立による suspended

メンバー間の設定は揃っているのに suspended になる場合、ログには別のメッセージが出ていることがあります。

%EC-5-L3DONTBNDL2: Gi1/0/2 suspended: LACP currently not enabled on the remote port.

これは「対向ポートで LACP が動いていない」という明確なサインです。原因はほぼ次の 3 つに絞られます。

1. 対向側の channel-group 設定漏れ（そもそも LAG 未設定）
2. 対向が on モード（静的）または PAgP で設定されている（方式の不一致）
3. 対向機器が LACP 非対応（YAMAHA RTX、NEC IX 等）

1 であれば対向に設定を入れるだけです。2・3 の場合は機器の組み合わせの問題であり、どちらの方式に統一すべきかの判断を含めて、関連記事『リンクアグリゲーションのメーカー相互接続』の手順に進んでください。

suspended に該当しない場合は、症状 2（err-disabled）または症状 3（stand-alone）へ進みます。

症状 2: err-disabled になる（発動条件と復旧手順）

err-disabled は suspended よりさらに強い保護動作で、ポート自体が強制的に無効化された状態です。リンクランプも消灯するため一見リンク障害に見えますが、原因は設定側にあります。

ミスコンフィグガードの発動を確認する

まず、err-disabled の発生と原因種別を確認します。

Switch# show interfaces status err-disabled

Port      Name               Status       Reason
Gi1/0/1                      err-disabled channel-misconfig

Reason 欄が channel-misconfig であれば、EtherChannel ミスコンフィグガードの発動です。このガードは、STP の BPDU を利用して EtherChannel の設定不整合を検出します。典型的な発動パターンは、片側が on モード（静的）で転送を開始しているのに、対向がネゴシエーションモード（または LAG 未設定）のままになっている構成です。この状態を放置するとブリッジングループに発展しうるため、ガードがポートを止めて事故を未然に防いだ、という状況です。

つまり err-disabled は「困った状態」ではなく「守られた状態」です。ガードが働かなければ、より深刻なループ障害になっていた可能性があります。

復旧手順と再発防止

復旧は必ず 2 段階で行います。

Switch(config)# interface GigabitEthernet1/0/1
Switch(config-if)# shutdown
Switch(config-if)# no shutdown

Switch(config)# errdisable recovery cause channel-misconfig

症状 3: stand-alone・negotiating のまま進まない

Cisco の (I)（stand-alone）や FortiGate の negotiating 継続は、いずれも「LACP のネゴシエーション相手が見つからない」状態です。suspended が「不一致を検出した」という積極的な判定であるのに対し、こちらは対向からの LACPDU がそもそも届いていないことを示します。したがって、確認すべきは設定の細部ではなく、まず LACPDU の到達性です。

LACPDU の到達を確認する

手順は 3 段階です。

FGT # diagnose sniffer packet any "ether proto 0x8809" 6 0 a

見落としがちな原因（論理インターフェースの有効化忘れ等）

LACPDU の切り分けと並行して、単純だが気づきにくい原因を潰します。経験上、この 4 つで大半がカバーできます。

YAMAHA SWX の論理インターフェースの有効化忘れ

SWX は論理インターフェース（po / sa）が作成時点でシャットダウン状態です。ポートの所属設定を終えても、interface po<番号> → no shutdown を投入するまでリンクアップしません。SWX が絡む構成で「設定は合っているのに上がらない」場合、最初に確認すべきポイントです。

passive 同士（受け身同士）の組み合わせ

両端が passive では、どちらもネゴシエーションを開始しません。少なくとも片側、推奨は両側を active にします。

FortiGate 側で設定自体が入っていない

FortiGate はポリシー等から参照中のインターフェースをメンバーにできず、設定投入時にエラーで弾かれます。投入したつもりの設定が実は保存されていなかった、というケースがあるため、show system interface で設定の実在を確認します。

チャネルグループ番号の不一致を疑って時間を使ってしまう

チャネルグループ番号（Po1 と Po5 等）は両端で一致している必要はありません。ここは原因にならないため、疑うだけ時間の無駄になります（運用上の分かりやすさのために揃えること自体は推奨します）。

機器の組み合わせに起因する場合（別記事への誘導）

ここまでの手順（設定不一致・保護機能・LACPDU 到達・有効化忘れ）で解決しない場合、特に異メーカー機器間の構成では、機器の組み合わせそのものに原因がある可能性が高くなります。

判断の入口はシンプルです。構成に YAMAHA RTX、NEC IX、または静的のみ対応のスイッチが含まれていないかを確認してください。これらが含まれる場合、対向側が LACP のままでは決して成立せず、区間全体を静的に統一する必要があります。組み合わせ別の正解パターンと切り分け手順は、関連記事『リンクアグリゲーションのメーカー相互接続』で解説しています。

また、「LAG は成立しているが、障害時の切り離しタイミングが両側でずれる」という症状は、LACP レート（slow / fast）の不一致が原因です。レートの不一致は成立可否には影響しないため本記事の症状には現れませんが、障害対応の中で発見されることがあります。仕組みと対処は関連記事『LACP レート slow と fast の違い』を参照してください。

まとめ

LAG が組めないとき、機器の状態表示は原因の系統をすでに教えてくれています。suspended なら設定不一致（ログのカッコ内が答え）、err-disabled なら保護機能の発動（原因修正が復旧より先）、stand-alone・negotiating なら LACPDU の不達（到達確認から分岐）という対応を押さえれば、切り分けは最短ルートで進みます。

• 切り分けの第一歩は状態確認コマンドで症状を分類すること
• suspended は保護動作であり CANNOT_BUNDLE2 ログのカッコ内に不一致理由が明記される
• 設定修正はポートチャネル側に投入して全メンバーへ一括反映する
• err-disabled は原因修正が先で復旧操作（shutdown / no shutdown）は後
• stand-alone は LACPDU 不達のサインでキャプチャによる送信有無の分岐が有効
• YAMAHA SWX の論理インターフェース有効化忘れは見落としの筆頭
• 静的のみ対応の機器が含まれる構成は方式の統一から見直す

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