はじめに
スイッチ間やスイッチとサーバー間の接続で、帯域の不足やリンク障害への備えが課題になる場面は少なくありません。その解決策としてよく採用されるのがリンクアグリゲーションです。ただ、いざ設計・設定しようとすると「静的と LACP はどちらを選ぶべきか」「EtherChannel やボンディングとは何が違うのか」「自社の機器はどの方式に対応しているのか」といった疑問に直面します。用語の呼び方がメーカーごとに異なることも、混乱しやすい一因です。
この記事では、リンクアグリゲーションの仕組みと方式の違いを整理し、主要メーカーの対応状況を比較します。
- リンクアグリゲーションの基本的な仕組みと用語の整理
- 静的 LAG と LACP(IEEE 802.1AX)の違いと選び方
- PAgP(Cisco 独自プロトコル)の位置づけ
- ロードバランスの仕組みと「束ねても n 倍速にならない」理由
- Cisco、FortiGate、YAMAHA、NEC IX、Linux の対応状況比較
結論を先に述べると、静的 LAG と LACP の最大の違いは障害検出の仕組みにあり、対向機器が対応している場合は LACP の利用を推奨します。ただし、YAMAHA RTX や NEC IX のように静的 LAG のみ対応の機器も存在するため、機器選定の段階で対応方式を確認しておくことが重要です。
リンクアグリゲーションとは
リンクアグリゲーションは、ネットワーク機器間を接続する複数の物理リンクを束ねて、1 つの論理リンクとして扱う技術です。束ねられたリンクの集合はリンクアグリゲーショングループ(LAG)と呼ばれ、上位のプロトコルからは 1 本のリンクとして見えます。
現行の標準規格は IEEE 802.1AX です。もともとは 2000 年に IEEE 802.3ad として標準化されましたが、2008 年にイーサネット規格(802.3)から独立し、802.1 ワーキンググループへ移管されました。現在も「802.3ad」という旧称が機器の設定画面やドキュメントに残っているのはこの経緯によるものです。
参考: IEEE 802.1AX-2020 – Link Aggregation
“a MAC Client can treat the LAG as if it were a single link”
(MAC クライアントは LAG をあたかも 1 本のリンクであるかのように扱うことができます)
https://1.ieee802.org/tsn/802-1ax-rev/

用語の整理(LAG・EtherChannel・ポートチャネル・ボンディング)
リンクアグリゲーションを学ぶ際にまず戸惑うのが、メーカーや OS ごとに呼び方が異なる点です。指している技術は基本的に同じものなので、以下の対応関係を押さえておくと、各メーカーのドキュメントを読む際に迷いにくくなります。
| 呼称 | 主な使用元 | 補足 |
|---|---|---|
| リンクアグリゲーション / LAG | IEEE 標準、YAMAHA、NEC など | 規格上の正式な呼称 |
| EtherChannel(イーサチャネル) | Cisco | Catalyst シリーズでの機能名 |
| ポートチャネル(Port-channel) | Cisco ほか | EtherChannel で作成される論理インターフェース名 |
| アグリゲートインターフェース | FortiGate | インターフェースタイプ名として使用 |
| ボンディング(bonding) | Linux | カーネルのボンディングドライバーに由来 |
| チーミング(teaming) | Windows Server、Linux(teamd) | NIC チーミングとして呼ばれることが多い |
このほか、トランキングという呼称が使われる場合もありますが、VLAN のトランクポートと紛らわしいため、本ブログでは使用しません。VLAN トランクとの用語の混同については、関連記事『VLAN 設計の基礎|トランクと VLAN 間ルーティングの設計指針』も参考になります。
冗長化と帯域拡張という 2 つの目的
リンクアグリゲーションを導入する目的は、大きく次の 2 つに分けられます。
1. 冗長化(可用性の確保)
LAG 内の 1 本のリンクで障害が発生しても、残りのリンクで通信を継続できます。リンク単位の障害であれば通信断はごく短時間で済み、STP の再収束のようなトポロジー変更を伴わない点が利点です。実務では、この冗長化を主目的として導入されるケースが多く見られます。
2. 帯域拡張
複数のリンクにトラフィックを分散させることで、論理リンク全体として利用できる帯域を増やせます。ただし、注意点として、リンクを n 本束ねても単一の通信フローが n 倍速になるわけではありません。トラフィックはフロー単位でいずれか 1 本の物理リンクに割り当てられるためです。この動作原理は「ロードバランスの仕組み」の章で詳しく解説します。
なお、機器によっては帯域拡張の用途をサポートせず、冗長化専用と位置づけているものもあります(NEC IX シリーズなど)。詳細は「主要メーカーの対応状況比較」の章で整理します。
静的 LAG と LACP の違い
リンクアグリゲーションの構成方式は、ネゴシエーションを行わない静的 LAG と、制御プロトコルで対向機器と情報交換を行う LACP の 2 つに大別されます。どちらを選ぶかで障害時の挙動が変わるため、方式の違いを正しく理解しておくことが設計の第一歩になります。
静的 LAG(スタティック)の動作
静的 LAG は、制御プロトコルを使わず、両端の機器にあらかじめ設定を投入することでリンクを束ねる方式です。Cisco では on モードと呼ばれ、ネゴシエーションなしでポートを EtherChannel に参加させます。
参考: Catalyst 9600 Configuring EtherChannels(Cisco 公式)
“The on mode forces a port to join an EtherChannel without negotiations”
(on モードは、ネゴシエーションなしでポートを EtherChannel に強制的に参加させます)
https://www.cisco.com/c/dam/en/us/td/docs/switches/lan/catalyst9600/software/release/16-12/configuration_guide/lyr2/configuring_etherchannels.html
対向とのネゴシエーションが発生しないため動作はシンプルですが、その分、次のリスクを設計時に考慮しておく必要があります。
- 両端の設定が一致していることを機器が検証しないため、設定ミスや結線ミスがあってもポートはリンクアップしてしまう
- 片側だけ LAG 設定が入っている状態で結線すると、ブリッジングループやフレーム損失につながるおそれがある
- 物理リンクのアップ / ダウンだけで経路の正常性を判断するため、リンクダウンを伴わない障害を検出できない
YAMAHA RTX や NEC IX のように静的 LAG のみ対応の機器では、この特性を前提とした運用(結線前に両端の設定を完了させる等)が求められます。
LACP(IEEE 802.3ad / 802.1AX)の動作
LACP は、LACPDU と呼ばれる制御フレームを対向機器と交換し、双方の合意のもとでリンクを束ねる方式です。IEEE 802.1AX(旧 802.3ad)で標準化されており、メーカーをまたいだ相互接続が可能です。
LACP のポートには 2 つの動作モードがあります。
| モード | 動作 |
|---|---|
| アクティブ | 自分から LACPDU を送信し、ネゴシエーションを開始する |
| パッシブ | 自分からは送信せず、対向から LACPDU を受信した場合のみ応答する |
モードの組み合わせによって、LAG が成立するかどうかが決まります。
| 自機器 | 対向機器 | LAG 成立 |
|---|---|---|
| アクティブ | アクティブ | 成立 |
| アクティブ | パッシブ | 成立 |
| パッシブ | パッシブ | 不成立(双方が送信を開始しないため) |
パッシブ同士では LAG が成立しない点は、実際の障害事例でも比較的よく見られる設定ミスです。どちらのモードにすべきか迷う場合は、両端ともアクティブに設定しておくことを推奨します(片側の設定変更や機器リプレースがあっても成立条件を維持しやすいため)。
LACPDU の送信間隔には 2 つのレートがあり、タイムアウト値は送信間隔の 3 倍です。
| レート | LACPDU 送信間隔 | タイムアウト |
|---|---|---|
| slow(デフォルト) | 30 秒 | 90 秒 |
| fast | 1 秒 | 3 秒 |
参考: Command Reference, Cisco IOS XE Denali 16.2.x(Cisco 公式)
“The LACP timeout value on Cisco switch is three times the LACP rate”
(Cisco スイッチの LACP タイムアウト値は、LACP レートの 3 倍です)
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3850/software/release/16-2/command_reference/b_162_consolidated_3850_cr/b_162_consolidated_3850_cr_chapter_01000.html
レートの選択やメーカー間での不一致時の挙動には注意点があるため、詳細は別記事『LACP レート slow / fast の違いと不一致時の挙動』で解説します。
静的 LAG と LACP のどちらを選ぶべきかを判断する上で、最も重要な違いは障害検出の仕組みです。
静的 LAG は物理リンクの状態(リンクアップ / ダウン)だけを頼りに経路の正常性を判断します。一方、LACP は LACPDU の受信が途絶えたことをトリガーに、該当リンクを LAG から切り離せます。
この違いが顕著に表れるのが、リンクダウンを伴わない障害です。たとえば両機器の間にメディアコンバーターや中継機器が存在する構成では、対向側の区間で障害が発生しても、自機器側の物理リンクはアップしたままになるケースがあります。静的 LAG はこの状態を検出できず、障害リンクへフレームを送り続けてしまいますが、LACP であればタイムアウトによって障害リンクを LAG から除外できます。

このため、両端の機器が LACP に対応している場合は、静的 LAG ではなく LACP の利用を推奨します。静的 LAG を選択するのは、対向機器が LACP に対応していない場合(YAMAHA RTX、NEC IX との接続等)に限定するのが実務上の目安です。
PAgP とは(Cisco 独自プロトコル)
PAgP(Port Aggregation Protocol)は、LACP と同様にネゴシエーションによってリンクを束ねる Cisco 独自のプロトコルです。IEEE 標準化以前から存在しており、Cisco 機器および Cisco がライセンス供与したベンダーの機器でのみ動作します。
PAgP にも LACP と対になる 2 つのモードがあります。LACP との対応関係は以下のとおりです。
| 役割 | LACP | PAgP |
|---|---|---|
| 自分からネゴシエーションを開始する | アクティブ | desirable |
| 対向からの開始を待つ | パッシブ | auto |
| ネゴシエーションなし(静的) | —(on モード) | —(on モード) |
auto 同士で LAG が成立しない点も LACP のパッシブ同士と同様です。なお、PAgP と LACP はプロトコルとして互換性がなく、両端で同じプロトコルを使用する必要があります。
LACP との違いと現在の位置づけ
PAgP と LACP は機能的に近いプロトコルですが、現在の実務では次の理由から LACP が標準的な選択肢となっています。
- PAgP は Cisco 独自プロトコルのため、他メーカー機器との相互接続には使用できない
- Cisco 製品の中でも、NX-OS(Nexus シリーズ)は PAgP をサポートしていない
参考: Cisco Nexus 3400-S NX-OS Interfaces Configuration Guide(Cisco 公式)
“The device does not support Port Aggregation Protocol (PAgP) for port channels.”
(本機器は、ポートチャネルにおいて PAgP をサポートしていません)
https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus3400s/sw/93x/interfaces/configuration/guide/cisco-nexus-3400s-nx-os-interfaces-configuration-guide-93x/m_3400s_configuring_port_channels.pdf
Catalyst シリーズでは現在も PAgP を設定できますが、新規設計であえて PAgP を選択する理由はほぼなく、既存環境の維持や機器リプレース時に遭遇するプロトコルという位置づけです。既存の PAgP 環境を LACP へ移行する際の手順は、別記事『Cisco Catalyst EtherChannel の設定』で扱います。
ロードバランスの仕組み
リンクアグリゲーションの帯域拡張効果を正しく見積もるには、トラフィックがどのように各リンクへ分散されるかを理解しておく必要があります。この仕組みを知らないまま導入すると、「束ねたのに速くならない」という期待外れにつながりがちです。
ハッシュアルゴリズムの基本(1 フローは 1 リンク)
LAG では、送信するフレームごとにどの物理リンクを使うかをハッシュ計算で決定します。ハッシュの入力に使われるのは、フレームやパケットのヘッダー情報です。代表的な組み合わせは以下のとおりです。
| ハッシュポリシー | 入力に使う情報 |
|---|---|
| L2(MAC ベース) | 送信元 / 宛先 MAC アドレス |
| L2+L3 | MAC アドレス+送信元 / 宛先 IP アドレス |
| L3+L4 | IP アドレス+送信元 / 宛先ポート番号 |
重要なのは、同じヘッダー情報を持つ一連の通信(フロー)は、常に同じ物理リンクに割り当てられるという点です。これはフレームの順序逆転(リオーダリング)を防ぐための設計であり、TCP 通信の性能劣化を避ける上で合理的な動作です。
参考: Red Hat Enterprise Linux 7 Networking Guide(Red Hat 公式)
“a single connection will not span multiple ports”
(単一のコネクションが複数のポートにまたがることはありません)
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/networking_guide/sec-using_channel_bonding

「束ねても n 倍速にはならない」理由
前述の動作原理から、次の 2 つの実務上の帰結が導かれます。
1. 単一フローの通信は 1 本分の帯域が上限になる
1 Gbps のリンクを 4 本束ねても、1 つのフロー(たとえば単一の TCP セッションによるファイル転送)が使えるのは最大 1 Gbps です。LAG の帯域拡張は「多数のフローを収容する合計帯域が増える」効果であり、単一通信の高速化ではありません。バックアップ転送の高速化などを目的とする場合は、この特性を踏まえた設計が求められます。
2. フローの偏りによって特定リンクに負荷が集中することがある
ハッシュ計算の入力が偏っていると、トラフィックが特定のリンクに集中します。典型例は、L2 ハッシュ(MAC ベース)の環境でルーター越しの通信が大半を占めるケースです。宛先 MAC アドレスがすべてルーターの MAC アドレスになるため、ハッシュ結果が偏り、実質的に 1 本のリンクしか使われないことがあります。この場合、ハッシュポリシーを L3 や L4 ベースに変更することで分散が改善する可能性があります。
なお、ハッシュポリシーは送信側の機器ごとに独立して動作します。行き(自機器→対向)と帰り(対向→自機器)で異なるリンクを通ることは正常な動作であり、障害切り分けの際に混乱しやすいポイントです。帯域の偏りに関する詳しい切り分け手順は、別記事『LAG の帯域が偏る・増速されない問題』で解説します。
主要メーカーの対応状況比較
リンクアグリゲーションの方式選定は、接続する両端の機器が何に対応しているかで決まります。この章では、国内のインフラ現場で採用されることの多い機器について、対応状況を整理します。
対応マトリクス(Cisco / FortiGate / YAMAHA RTX・SWX / NEC IX / Linux)
各メーカーの公式ドキュメントで確認した対応状況は以下のとおりです。(2026 年 7 月時点の情報です。導入時は必ず対象機種・対象バージョンの公式ドキュメントをご確認ください)
| 機器 | 静的 LAG | LACP | PAgP | 備考 |
|---|---|---|---|---|
| Cisco Catalyst | ○(on モード) | ○ | ○ | |
| Cisco Nexus | ○(on モード) | ○ | × | NX-OS は PAgP 非サポート |
| FortiGate | ○(lacp-mode static) | ○(active / passive) | × | インターフェースタイプ aggregate として設定 |
| YAMAHA RTX | ○ | × | × | 対応機種は限られるため公式コマンドリファレンスで要確認 |
| YAMAHA SWX | ○ | ○ | × | LACP はアクティブモードの指定が推奨されている |
| NEC IX | ○(Ver.8.8 以降) | × | × | 帯域の増速は不可(冗長化専用) |
| Linux(bonding) | ○(balance-xor 等) | ○(802.3ad モード) | × | 全 7 モードから選択 |
設定手順の詳細は、各機器の個別記事で解説します。(cisco-etherchannel、fortigate-link-aggregation、yamaha-link-aggregation、nec-ix-link-aggregation)
国産ルーター系は静的のみ対応という注意点
上記マトリクスで注目すべきは、YAMAHA RTX と NEC IX という国内拠点ルーターの定番 2 シリーズが、いずれも LACP 非対応(静的 LAG のみ)である点です。
NEC IX シリーズについては、公式 FAQ に次のとおり明記されています。
参考: LAN(イーサネット): FAQ: UNIVERGE IX シリーズ(NEC 公式)
「静的設定のみ対応しています。LACP等の動的設定には対応しておりません」
https://jpn.nec.com/univerge/ix/faq/ethernet.html
さらに NEC IX シリーズは、リンクアグリゲーションを使用した回線の増速(1G ポート 2 本で 2 Gbps 化等)はできないと公式 FAQ に記載されており、冗長化専用の機能という位置づけです。
この事実が実務に与える影響は 2 つあります。
- これらの機器と Cisco や FortiGate を接続して LAG を組む場合、Cisco・FortiGate 側も静的モード(on / lacp-mode static)に合わせる必要があります。片側だけ LACP を有効にすると LAG は成立しません。
- 静的 LAG はリンクダウンを伴わない障害を検出できないため、これらの構成では障害検出の限界を設計時に織り込んでおくことが重要です。
異メーカー間の接続で注意すべきポイントの詳細は、別記事『LAG のメーカー相互接続の注意点』で解説します。
使いどころと設計のポイント
方式の違いとメーカーの対応状況を踏まえ、この章ではリンクアグリゲーションをどのような構成で使うべきか、設計時に何を考慮すべきかを整理します。
適する構成と適さない構成
リンクアグリゲーションの効果を発揮しやすいのは、多数のフローが流れる区間の冗長化と帯域確保です。
適する構成の例
- スイッチ間のアップリンク: 多数の端末やサーバーのフローが集約される区間であり、フロー単位の分散が有効に機能する
- 仮想化ホストとスイッチ間: 多数の VM のトラフィックが分散対象となり、NIC 障害時も通信を継続できる
- ファイアウォール・ルーターとスイッチ間: 冗長化を主目的とした構成で、リンク・ポート・モジュール単位の障害に備えられる
LAG は 1 本のメンバーリンクが生きていれば論理リンクとして動作し続けるため、ケーブル抜けや SFP モジュール故障といったリンク単位の障害に対して有効です。
参考: Cisco Nexus 9000 Series NX-OS Interfaces Configuration Guide(Cisco 公式)
“operationally up when at least one of the member ports is up”
(メンバーポートが 1 つでもアップしていれば、ポートチャネルは運用上アップ状態となります)
https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/6-x/interfaces/configuration/guide/b_Cisco_Nexus_9000_Series_NX-OS_Interfaces_Configuration_Guide/configuring_port_channels.pdf
適さない構成・注意が必要な構成
- 単一の大容量フローを高速化したい場合: 単一フローは 1 リンク分が上限のため、リンクの本数追加ではなく上位速度(10 G / 25 G 等)への移行を検討する方が目的に合う
- 機器筐体そのものの冗長化: LAG は同一機器のポート障害には備えられるが、筐体障害には対応できない。筐体をまたいだ冗長化にはスタック構成や MC-LAG(Cisco では vPC 等)といった別の技術が必要になる
- 帯域拡張を期待できない機器: NEC IX のように冗長化専用と位置づけられている機器では、増速目的の設計はできない
また、LAG のメンバーポートは両端で速度・デュプレックスを揃えることが前提です。速度の混在は LAG が成立しない、または一部ポートがスタンバイ扱いになる原因となります。デュプレックスの不一致が引き起こす問題については、関連記事『デュプレックスミスマッチの症状と対処|全二重と半二重の違いから解説』も参考になります。
STP との関係
リンクアグリゲーションと STP は、どちらも L2 の冗長化に関わる技術ですが、役割が異なります。
STP から見ると、LAG は 1 本の論理リンクとして扱われます。このため、LAG のメンバーリンク同士が STP によってブロックされることはなく、束ねたすべてのリンクを同時に活用できます。同じ 2 台のスイッチを LAG なしで複数本接続した場合、STP がループを防ぐために 1 本を残して他をブロックしてしまうのと対照的です。並行リンクの帯域を無駄なく使いたい場合、LAG 化は STP ブロッキングの回避策としても機能します。
一方で、LAG を導入しても STP を無効化しないことを推奨します。理由は次の 2 つです。
- LAG の設定ミス(片側だけ静的 LAG が設定されている、束ねるべきポートの指定漏れ等)が発生した場合、ブリッジングループに発展するおそれがある。STP はこの際の最後の防御線として機能する
- LAG を組んだ区間以外のトポロジーにループが存在する場合、その検出とブロックには引き続き STP が必要になる
STP の動作原理やブロッキングの仕組みについては、関連記事『スパニングツリー(STP)とは|仕組みと RSTP・MSTP の違い』を参照してください。
まとめ
リンクアグリゲーションは、複数の物理リンクを 1 つの論理リンクとして扱い、冗長化と帯域拡張を実現する技術です。方式選定では静的 LAG と LACP の障害検出の違いを理解することが出発点となり、あわせて接続する機器の対応状況(特に国産ルーター系の制約)を確認しておくことが、確実な設計につながります。
- リンクアグリゲーションは複数の物理リンクを束ねて 1 つの論理リンクとして扱う技術
- 静的 LAG と LACP の最大の違いはリンクダウンを伴わない障害を検出できるかどうか
- 両端の機器が対応していれば LACP を両端アクティブモードで使う構成を推奨
- LACPDU の送信レートは slow(30 秒)と fast(1 秒)の 2 種類でタイムアウトは 3 倍
- PAgP は Cisco 独自プロトコルで Nexus では非対応のため新規採用の理由は乏しい
- 帯域はフロー単位で分散されるため単一フローの速度は 1 リンク分が上限
- YAMAHA RTX と NEC IX は静的 LAG のみ対応のため異メーカー接続時は方式を合わせる
以上、最後までお読みいただきありがとうございました。
