LACP(Link Aggregation Control Protocol)は、複数の物理リンクを束ね、1本の論理リンクとして扱うための制御プロトコルです。リンクアグリゲーションをLACPで構成すると、一部のリンクに障害が発生しても通信を継続しやすくなり、複数フローが流れる環境では帯域を有効に使いやすくなります。
ただし、LACPは「物理リンクを足した分だけ単一通信が必ず速くなる」仕組みではありません。多くの実装では、送信元・宛先のMACアドレス、IPアドレス、TCP/UDPポート番号などを使ったハッシュにより、フロー単位で使用するリンクを決めます。そのため、LACPの効果を正しく理解するには、冗長化、帯域活用、分散方式、設定条件を分けて確認する必要があります。
LACPは、リンクアグリゲーションを構成する両端機器が、どの物理ポートを同じグループとして束ねるか、束ねた状態が正常かを相互に確認するための制御プロトコルです。スイッチ、サーバーNIC、ネットワーク機器などの間でLACPフレームを交換し、リンクの参加状態を管理します。
ここで区別したいのは、LAG(Link Aggregation Group)が複数の物理リンクを束ねた論理リンクそのものを指すのに対し、LACPはそのLAGを両端でネゴシエーションし、状態を確認するためのプロトコルである点です。LAGを構成しても、静的リンクアグリゲーションのようにLACPを使わない方式もあります。
1本のケーブルや1ポートだけに依存する構成では、そのリンクに障害が発生した時点で通信が途切れます。LACPを使ったリンクアグリゲーションでは、複数リンクのうち一部が利用できなくなっても、残りのリンクで通信を継続しやすくなります。
また、複数の物理リンクを束ねることで、複数端末や複数セッションが同時に通信する環境では、全体として利用できる帯域を増やせます。サーバー集約スイッチ、仮想化基盤、ストレージ接続、上位スイッチ間接続など、通信が集中しやすい場所で利用されることが多い構成です。
LACPを理解するには、物理ポートと論理ポートの関係、トラフィック分散の方法、リンク障害時の動きを分けて確認します。
物理ポートは、ネットワーク機器に実在するLANポートを指します。LACPを使うと、複数の物理ポートを1つの論理インターフェース(LAG:Link Aggregation Group)としてまとめられます。
OSや上位のネットワーク機能からは、LAGは1本の論理リンクとして扱われます。そのため、VLAN、ルーティング、STPなどの設定を、物理ポートごとではなく論理インターフェース側で管理しやすくなります。ただし、物理ポート間で速度、デュプレックス、VLAN、MTUなどの条件がそろっていないと、LACPが成立しない、または一部のリンクがメンバーから外れる原因になります。
リンクアグリゲーションでは、通信を複数の物理リンクへ分散します。ただし、分散は常に均等になるわけではありません。一般的には、送信元や宛先のMACアドレス、IPアドレス、TCP/UDPポート番号などを使ったハッシュ方式で、使用するリンクが決まります。
そのため、単一の大きな通信、つまり1つのフローの速度は、基本的に1本の物理リンクの速度が上限になります。一方で、複数端末や複数セッションが同時に通信する環境では、フローが複数リンクへ分散され、全体として混雑を抑えやすくなります。
メンバーリンクの一部に障害が発生した場合、LACPはそのリンクをLAGから外し、残りのリンクで通信を継続します。その結果、利用できる帯域は減少しますが、通信断を避けやすくなります。
ただし、実際の挙動は、機器の実装、タイマー設定、STPやL3冗長構成、上位アプリケーションの通信特性によって変わります。LACPを設定しただけで、すべての障害を無停止で吸収できるわけではありません。
LACPは、リンクアグリゲーションの標準仕様の一部として定義されています。歴史的にはIEEE 802.3adとして知られていますが、現在はIEEE 802.1AXとして扱われるのが一般的です。標準規格に基づくため、異なるベンダー機器間でも構成を組みやすい点が特徴です。
ただし、実装差や推奨設定の違いは残ります。たとえば、対応するハッシュ方式、タイマー、最大メンバー数、スタック構成やMLAG構成での扱いは機器によって異なります。異なるベンダー機器を組み合わせる場合は、事前検証と監視項目の確認が必要です。
LACPの価値は、単純に通信速度を上げることではありません。リンク断に備えた冗長性を確保しつつ、並行する通信が多い環境では複数リンクを活用して混雑を抑えることにあります。
たとえば、1Gbpsのリンクを4本束ねても、1つのTCPセッションが4Gbpsで流れるとは限りません。複数の端末、複数の仮想マシン、複数の通信セッションが同時に利用する場合に、合計として複数リンクを活用しやすくなります。
具体的なコマンドやGUI操作は、機器ベンダーやOSによって異なります。ここでは、LACPを構成する際に共通して確認したい動作モードと設定条件を整理します。
LACPには、主に次の2つの動作モードがあります。
一般に、少なくとも片側がActiveであればLACPネゴシエーションが始まります。両側がPassiveの場合は、どちらもLACPフレームを送信しないため、LACPは成立しません。運用では、両側Active、または片側Active・片側Passiveの構成を採用します。
設定前に確認しておきたい代表的なポイントは次の通りです。
基本的な設定手順の流れは次の通りです。
静的リンクアグリゲーションは、両端の機器で手動設定によりリンクを束ねる方式です。LACPのように制御フレームを交換して相手状態を確認するわけではありません。そのため、設定が一致していればシンプルに使える一方、片側だけ設定が異なる場合や、想定外の接続になった場合に検知しにくいことがあります。
両端で状態を確認しながら安全に束ねたい場合は、LACPを使う構成が基本です。片側をLACP、片側を静的リンクアグリゲーションにすると、リンクがUpに見えても意図どおりに束ねられず、不安定な動作につながる場合があります。
LACPを設定した後は、LAGがUpになっているか、各物理ポートが正しくメンバーとして参加しているかを確認します。機器によって表示項目は異なりますが、LACPの同期状態、メンバーリンク数、タイムアウト状態、スタンバイ状態などを確認します。
あわせて、インターフェースのエラーカウンタ、ログ、STP状態、VLAN設定、MTU不一致の有無も確認します。LAGがUpでも、一部メンバーが外れていると、想定より帯域が出ない原因になります。
LACP構成で「帯域が出ない」と感じる場合、まず単一フローの上限に達していないかを確認します。1つの通信だけを測定している場合、複数リンクを束ねていても、1本分の帯域しか使えないことがあります。
次に、分散方式の偏りを確認します。送信元・宛先の組み合わせが偏っている環境では、特定リンクに通信が集中する場合があります。必要に応じて、ハッシュキーの選択、通信経路、LAGの設計を見直します。
LACPを導入したら、平常時だけでなく障害時の挙動も確認します。メンバーリンクを1本停止したときに、通信が継続するか、ログに記録されるか、監視通知が発報されるかを確認します。
また、利用できる帯域が減少した状態で、重要な通信に影響が出ないかも確認します。冗長化は通信継続のための手段ですが、縮退時の性能要件を満たせるかは別途確認が必要です。
LACPは、複数の物理リンクを束ね、1本の論理リンクとして扱うための制御プロトコルです。リンクアグリゲーションにより、一部リンク断への備えと、複数フローがある環境での帯域活用を両立しやすくなります。
一方で、LACPを使えば単一通信が必ず複数リンク分速くなるわけではありません。多くの構成ではフロー単位のハッシュで使用リンクが決まり、単一フローの速度は1本の物理リンクに制約されます。設計時は、Active/Passiveの組み合わせ、速度・デュプレックス・VLAN・MTUの整合、分散方式、障害時の縮退動作を確認する必要があります。
A.LAGは複数の物理リンクを束ねて1本の論理リンクとして扱う仕組みで、LACPはそのLAGを両端機器でネゴシエーションし、状態を管理するための制御プロトコルです。
A.必ず倍にはなりません。一般にフロー単位で分散されるため、単一フローの最大速度は1本の物理リンク相当が上限になります。
A.少なくとも片側をActiveに設定します。両側PassiveではLACPネゴシエーションが始まらないため、両側Activeまたは片側Active・片側Passiveで構成します。
A.機器や設定によってはリンクUpに見える場合もありますが、不安定な動作になることがあります。基本的には両端で同じ方式にそろえます。
A.メンバーリンクの一部断であれば、残りリンクに切り替わり通信断を避けられる場合があります。ただし、設計や障害箇所によって挙動は変わります。
A.MACアドレス、IPアドレス、TCP/UDPポート番号などを基にしたハッシュ方式で、使用するメンバーリンクが選ばれるのが一般的です。
A.速度、デュプレックス、VLAN設定、MTUなど、機器が求める条件をそろえる必要があります。
A.LAGの状態、メンバーリンクの参加状況、LACPネゴシエーションの状態を確認します。ログやエラーカウンタの確認も有効です。
A.LACPはIEEE標準規格に基づく方式で、PAgPはCisco独自方式として知られています。相互運用性の前提が異なるため、混在可否は事前に確認します。
A.LACPの成立状態、メンバーリンクの状態、エラー有無、分散方式の偏り、単一フローが物理リンク上限に達していないかを確認します。