リンクアグリゲーションのメーカー相互接続｜LAG がつながらない時の確認ポイント

はじめに

実際のネットワークが単一メーカーで完結することは、むしろ少数派です。ファイアウォールは FortiGate、コアスイッチは Cisco、拠点ルーターは YAMAHA や NEC IX という構成は、国内のインフラ現場ではごく一般的です。そして、こうした異メーカー機器の間でリンクアグリゲーション（LAG）を組もうとしたときに、「設定したのにつながらない」「片側だけリンクアップしている」という事象に遭遇しがちです。

この記事では、異メーカー間の LAG 接続で発生する問題を、原因の 3 階層（方式・モード・レート）で整理し、組み合わせ別の正しい設定パターンと切り分け手順をまとめます。

結論を先に述べると、異メーカー接続のトラブルは、方式（LACP か静的か）→ モード（アクティブ / パッシブ）→ レート等のパラメータ、という 3 階層を上から順に確認することで、ほとんどのケースを切り分けられます。特に、YAMAHA RTX や NEC IX のような静的 LAG のみ対応の機器が構成に含まれる場合は、対向側も静的に統一することが大前提になります。

なお、方式やモードの基礎（LACP の仕組み、静的 LAG との障害検出の違い）は、関連記事『リンクアグリゲーションの仕組みと方式の違い』で解説しています。本記事は組み合わせと切り分けに焦点を絞ります。

異メーカー接続で LAG が成立しない 3 つの原因

異メーカー間で LAG が組めない原因は、ほぼ次の 3 階層のいずれかに分類できます。上の階層ほど根本的な不一致であり、切り分けは必ず上から順に行います。

原因 1: 方式の不一致（LACP と静的 LAG の混在）

最も根本的な原因です。片側が LACP、もう片側が静的 LAG という組み合わせでは、LAG は決して成立しません。

• LACP 側は、対向からの LACPDU 応答を待ち続けます。応答がないため、ポートを束ねられません。
• 静的側は、LACPDU を送信せず、受信しても無視します。

このときの症状には特徴があります。物理リンクはアップしているのに、論理リンク（LAG）だけが上がらない、あるいは片側だけが「成立した」と誤認する状態です。Cisco であればメンバーポートが (I)（スタンドアロン）や (s)（サスペンド）と表示され、FortiGate であれば diagnose netlink aggregate の LACP state が negotiating のまま進みません。

さらに注意すべきは、静的側が「対向の合意なしに即座に転送を開始する」という点です。静的 LAG とネゴシエーション方式の混在は、単に不成立で済まず、構成によってはブリッジングループの引き金になります（この保護機能については、関連記事『Cisco EtherChannel の設定手順』の EtherChannel ミスコンフィグガードの節を参照してください）。

対処は、両側を同じ方式に統一することです。両方の機器が LACP に対応していれば LACP に、片方でも静的のみ対応の機器（YAMAHA RTX、NEC IX 等）が含まれるなら、全体を静的に統一します。

原因 2: モードの組み合わせ（受け身同士は不成立）

方式が LACP で揃っていても、モードの組み合わせによっては成立しません。LACP には「自分からネゴシエーションを開始する」モードと「対向からの開始を待つ」モードがあり、受け身同士の組み合わせでは、どちらもネゴシエーションを開始しないため LAG が成立しません。

紛らわしいのは、モードの呼称がメーカー間でおおむね共通している一方、微妙な差異がある点です。

組み合わせの成立条件は「少なくとも片側が active であること」です。実務では、両端とも active に設定しておくことを推奨します。どちらか一方の機器がリプレースや設定変更された場合でも、ネゴシエーション開始側が必ず残るためです。

なお、Cisco には PAgP（desirable / auto）という独自プロトコルもありますが、PAgP は Cisco 独自のため異メーカー接続では使用できません。異メーカー接続の文脈では「Cisco 側も LACP（active / passive）を使う」と覚えておけば十分です。

原因 3: レート・パラメータの不一致

方式もモードも合っているのに LAG が不安定、あるいは環境によっては成立しないケースで疑うのが、パラメータの不一致です。代表的なものは LACPDU の送信レート（slow / fast）です。

Cisco（IOS-XE）と FortiGate はいずれも既定が slow（30 秒間隔）ですが、メーカーによっては fast が既定のケースがあります。Fortinet の公式 Technical Tip（Juniper との接続例）でも、次のとおり注意喚起されています。

参考: Technical Tip: How to setup LACP between FortiGate and Juniper Switch（Fortinet 公式コミュニティ）
“These settings must match on both sides to ensure proper LACP negotiation.”
（適切な LACP ネゴシエーションのため、これらの設定は両側で一致させる必要があります）
https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-setup-LACP-between-FortiGate-and-Juniper/ta-p/337346

レートの仕様と不一致時の挙動の詳細は、別記事『LACP レート slow / fast の違いと不一致時の挙動』で深掘りします。

このほか、レート以外で確認すべきパラメータは次のとおりです。

 メンバーポートの速度・デュプレックス

LAG のメンバーは両端で速度を揃えることが前提です。SFP の種別違い（1G と 10G の混在等）は成立しない原因になります。

 ロードバランスのハッシュアルゴリズム

こちらは LAG の成立には影響しませんが、両側で方式が大きく異なると帯域の偏りの原因になります。成立後のパフォーマンス問題として切り分けます。

メーカー別の対応方式と既定値の早見表

異メーカー接続の設計・切り分けで最初に参照すべきは、「双方の機器が何に対応していて、既定値は何か」という情報です。この章では、国内の現場で組み合わせることの多い機器について、公式ドキュメントで確認した対応状況と既定値を一覧にまとめます。

対応方式・モード・既定値の一覧

（2026 年 7 月時点の情報です。導入時は対象機種・バージョンの公式ドキュメントをご確認ください）

この表から導かれる実務上の帰結はシンプルです。構成に YAMAHA RTX または NEC IX が含まれる場合、その LAG 区間は全体を静的に統一する以外の選択肢がありません。それ以外の組み合わせ（Cisco、FortiGate、YAMAHA SWX、Linux 相互）では LACP に統一できます。

なお、同じ YAMAHA でも RTX（ルーター）と SWX（スイッチ）で対応が異なる点は要注意です。「YAMAHA は静的のみ」と一括りに覚えてしまうと、SWX との接続で不必要に静的構成を選ぶことになります（静的構成は障害検出面で不利なため、LACP を使えるなら使うのが原則です）

静的 LAG のみ対応の機器が混ざる場合の考え方

静的に統一する構成では、LACP が担っていた保護機能（ネゴシエーションによる整合性検証、LACPDU タイムアウトによる障害検出）がすべて失われます。そのため、設定・運用の規律で補う必要があります。YAMAHA の公式コマンドリファレンスにも、次の注意が明記されています。

参考: スタティックリンクアグリゲーションの設定（YAMAHA 公式コマンドリファレンス）
「パケットのループを避けるため、リンク相手機器の設定も含め、先にリンクアグリゲーションの設定を済ませてから LAN ケーブルを結線することに注意する」
https://www.rtpro.yamaha.co.jp/RT/manual/rt-common/setup/lan_link-aggregation_static.html

静的統一構成での運用ルールは次の 3 点に集約されます。

1. 結線前に両端の設定を完了させる（上記公式注意のとおり。片側だけ設定済みの状態での結線がループの典型パターン）
2. Cisco 側では EtherChannel ミスコンフィグガードを有効化し、万一の不整合を err-disabled で止める（詳細は関連記事『Cisco EtherChannel の設定手順』を参照）
3. リンクダウンを伴わない障害は検出できない前提で、監視（ping 監視等）を別途設計する

組み合わせ別の設定パターン

この章では、実際の組み合わせごとに「両側で何を設定すれば成立するか」の最小構成を示します。各機器の設定手順の詳細（事前確認や確認コマンドを含む）は、それぞれの個別記事を参照してください。

Cisco と FortiGate を接続する場合（LACP 同士）

最も一般的な組み合わせです。両側とも LACP アクティブで統一します。

Cisco 側（Catalyst、Gi1/0/1-2 を Po1 に）

interface range gigabitEthernet 1/0/1 - 2
 switchport mode trunk
 channel-group 1 mode active

FortiGate 側（port3-4 を aggregate に）

config system interface
    edit "LAG-to-SW"
        set type aggregate
        set member "port3" "port4"
    next
end

FortiGate の lacp-mode は既定で active、lacp-speed は両者とも既定が slow のため、既定値のままで方式・モード・レートの 3 階層がすべて揃います。設定手順の詳細は、関連記事『Cisco EtherChannel の設定手順』および『FortiGate リンクアグリゲーションの設定手順』を参照してください。

この組み合わせで LAG 成立後に「VLAN 通信だけができない」場合は、LAG そのものではなく、トランク設計の不一致（Cisco 側のネイティブ VLAN・許可 VLAN と、FortiGate 側の VLAN サブインターフェースのタグ設計のずれ）を疑います。LAG の問題と VLAN の問題を切り分けて考えることが重要です。

Cisco・FortiGate と YAMAHA RTX・NEC IX を接続する場合（静的に統一）

静的のみ対応の機器が含まれるため、対向側を静的に合わせます。

Cisco 側

channel-group 1 mode on（active ではなく on。LACP モードとの混在は不成立＋ループリスク）

FortiGate 側

aggregate インターフェースに set lacp-mode static を追加

YAMAHA RTX 側（RTX1300 で lan1 のポート 1・2 を束ねる例）

lan link-aggregation static 1 lan1:1 lan1:2

公式コマンドリファレンスによると、構文は lan link-aggregation static link_id interface:port interface:port ... で、RTX1300 では 1 つの論理リンクに最大 8 ポートを集約できます。フレキシブル LAN / WAN ポート対応機種では、集約対象ポートが同一 LAN インターフェースにマッピングされていることが前提となる点に注意してください（マッピング不一致でも入力エラーにならず、正常に機能しない挙動が公式に記載されています）

YAMAHA 側の設定詳細（SWX との違いを含む）は、公開予定の YAMAHA 個別記事で解説します。

NEC IX 側

静的リンクアグリゲーションを設定します（Ver.8.8 以降）。具体的なコマンド構文は本記事の執筆時点で公式 Web 上のリファレンスから確認できなかったため、お手元の機種の機能説明書・設定事例集をご参照ください。設定の詳細は、公開予定の NEC IX 個別記事で公式資料に基づいて解説します。

NEC IX を含む構成では、設定以前に次の制約を設計段階で確認しておくことが重要です。

参考: LAN（イーサネット）: FAQ: UNIVERGE IX シリーズ（NEC 公式）
「リンクアグリゲーション機能を使用して回線の増速（例えば1Gポートを2ポート使用して2Gbpsの通信を行う）はできません」
https://jpn.nec.com/univerge/ix/faq/ethernet.html

• 帯域の増速はできない（冗長化専用）。「2 本束ねて 2 Gbps」を期待した設計は成立しません
• モニタポート・ミラーポートとの併用不可
• ポート VLAN 併用時は、同一 LAG の全ポートを同一ポート VLAN グループに揃える必要がある

つながらない時の切り分け手順

ここまでの原因分析（方式・モード・レート）を踏まえ、実際に「LAG がつながらない」場面での切り分け手順をまとめます。基本方針は、両側の状態確認コマンドを見比べ、どちらが何を待っているのかを特定することです。

両側の状態確認コマンド早見表

各機器の LAG 状態確認コマンドと、正常時に表示される内容の対応です。

NEC IX の LAG 専用の状態確認コマンドは、本記事の執筆時点で公式 Web 上のリファレンスから確認できませんでした。お手元の機種の機能説明書・コマンドリファレンスをご参照ください。

切り分けの基本手順は次のとおりです。

LACPDU が届いているかを確認する

対向情報が表示されない場合、LACPDU そのものが届いているかを、パケットキャプチャで直接確認する方法があります。LACPDU は EtherType 0x8809 で識別できます。

Cisco 側（EtherType でフィルタしたスニファトレース取得）は、機種によりコマンド体系が異なるため、対象機種の公式ドキュメントを確認してください。

FortiGate 側は、次のコマンドで LACPDU のみを対象にキャプチャできます。

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

このキャプチャで自機からの送信（lacp_out_pkts 相当）はあるのに受信がない場合、対向側が LACPDU を送信していない（静的モードのまま等）か、経路上で破棄されている可能性が高くなります。逆に受信だけあって送信がない場合は、自機側の設定を再確認します。

なお、切り分けの過程で「方式は合っているのに、片方だけ静的、もう片方は LACP passive」のような中途半端な不一致が見つかることがあります。これは、過去にどちらかの機器だけがリプレースされ、既存の設定を新機種にそのまま踏襲しなかったケースで起こりがちです。機器更新の際は、対向側の設定も含めて LAG 全体を見直すことを推奨します。

まとめ

異メーカー間のリンクアグリゲーションが成立しない原因は、方式（LACP か静的か）、モード（アクティブ / パッシブ）、レート等のパラメータという 3 階層に整理できます。上の階層から順に確認することで、大半のケースは切り分けられます。YAMAHA RTX や NEC IX のように静的 LAG のみ対応の機器が含まれる構成では、対向側も静的に統一し、結線前の設定完了とミスコンフィグガードの活用で事故を防ぐことが重要です。

• 異メーカー接続の不成立は方式・モード・レートの 3 階層で切り分ける
• 方式の不一致（LACP と静的の混在）は最も根本的な原因
• YAMAHA RTX と NEC IX が含まれる構成は静的に統一する以外の選択肢がない
• YAMAHA は RTX（静的のみ）と SWX（LACP 対応）で仕様が異なる
• 静的統一構成は結線前の設定完了とミスコンフィグガードの活用が事故防止の鍵
• 両側の確認コマンドを見比べ、対向情報の有無で LACPDU 到達を判断する
• 機器リプレース時は対向側の設定も含めて LAG 全体を見直す

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