LACPを設定したのに帯域が増えない、なぜかスパニングツリーで片系がブロックされる、障害時の挙動が読めず不安になる──そんな経験はありませんか。
LACPは「束ねる」だけでなく、性能と冗長性を両立させるための重要な仕組みです。
本記事では、LACPの基本から設定の勘どころ、よくあるミスの切り分け、スパニングツリーとの関係まで、現場目線でわかりやすく整理します。
この記事は以下のような人におすすめ!
- LACPとは何か知りたい人
- LACPの具体的な仕組みが理解したい
- アクティブ/パッシブの組み合わせや負荷分散の考え方がわからない
LACPとは何か
LACPは、複数の物理リンク(LANケーブルやポート)を「1本の太い回線」のようにまとめて使うための仕組みです。つまり、帯域(通信できる量)を増やしたり、1本が切れても通信を続けたりする目的で使われます。
ただし、単に束ねれば良いわけではありません。そこで登場するのが LACP(Link Aggregation Control Protocol) です。LACPを使うことで、接続相手と自動的にやり取りしながら「束ねてよいリンクか」を確認し、安定してリンクアグリゲーションを成立させられます。
1-1. LACPの正式な定義と役割
LACPは、リンクアグリゲーション(ポートチャネル、EtherChannelなどと呼ばれることもあります)を 自動的に交渉して成立させる制御プロトコル です。
したがって、LACPの役割は「通信データを運ぶこと」ではなく、「束ねるためのルールを確認し、正しく束ね続けること」にあります。
1-1-1. LACPが解決する典型的な悩み
ネットワーク運用でよくある悩みは次のようなものです。
- 帯域が足りず、ピーク時に遅くなる
- ケーブルやポート障害で通信が止まる
- 手動で束ねたつもりが、設定ミスで片側だけ束ねていて不安定になる
そこでLACPを使うと、相手装置と「束ね方」をネゴシエーション(交渉)し、ミスマッチを起こしにくくなります。つまり、速さと安定性を両立しやすくなるわけです。
1-1-2. LACPで実現できること
LACPが提供する価値は大きく分けて3つです。
- 自動交渉:両端の設定が噛み合うか確認し、適切に束ねる
- 障害時の切り離し:リンク不良が起きた回線を束から外し、通信を継続しやすくする
- 運用性の向上:追加・交換時のヒューマンエラーを減らしやすい
1-2. LACPとリンクアグリゲーションの関係
リンクアグリゲーションは「複数リンクを束ねる技術」そのものを指します。一方でLACPは、そのリンクアグリゲーションを 自動で成立させるための方式(制御の仕組み) です。
つまり、関係性を一言でまとめるなら次の通りです。
- リンクアグリゲーション:やりたいこと(束ねて使う)
- LACP:それを安全に成立させる方法(自動交渉)
1-2-1. 静的(手動)とLACP(動的)の違い
リンクアグリゲーションには大きく2種類あります。
| 種類 | 呼び方 | 特徴 | 向いているケース |
|---|---|---|---|
| 手動 | 静的リンクアグリゲーション | 交渉なしで束ねる。設定ミスがあると不安定になりやすい | 小規模・構成が固定で変更が少ない |
| 自動 | LACP(動的) | 相手と交渉して束ねる。ミス検知や運用性が高い | 企業ネットワーク、データセンター、変更が多い環境 |
だからこそ、多くの現場で「LACPを使ったリンクアグリゲーション」が標準的に選ばれます。
1-2-2. 「LACPを入れたら回線が2倍速くなる?」への答え
ここは検索ユーザーがつまずきやすいポイントです。LACPで回線を束ねても、1つの通信(1フロー)が常に2倍速になるとは限りません。
なぜなら、一般的なリンクアグリゲーションは「負荷分散(ロードバランシング)」で複数リンクを使い分ける仕組みだからです。
- 通信が多数あるほど、複数リンクに分散されて効果が出やすい
- 1本の大きな転送だけだと、特定のリンクに偏ることがある
したがって、LACPは「単発の速度アップ」よりも、全体の混雑緩和と冗長化で効くケースが多いと理解すると運用で失敗しにくくなります。
1-3. LACPの歴史と標準規格
LACPが重視される理由の1つは、メーカー独自仕様ではなく IEEEの標準規格 として整備されてきた点です。
歴史的には、リンクアグリゲーションの標準として IEEE 802.3ad が広まり、その後、仕様は IEEE 802.1AX に整理・発展していきました。
1-3-1. なぜ標準化が重要なのか
ネットワーク機器は、スイッチ、サーバ、NIC(ネットワークカード)など複数の製品が組み合わさって動きます。
その結果、ベンダーが混在する環境では「同じ考え方・同じルールで束ねられる」ことが重要になります。
標準化のメリットは次の通りです。
- 相互接続性が高い:異なるメーカー間でもLACPを合わせやすい
- 運用ノウハウが蓄積しやすい:一般的な設計・障害対応の情報が見つかりやすい
- 将来の拡張に強い:機器更新でも設計思想を引き継ぎやすい
つまり、LACPは「便利だから使う」だけでなく、長期運用で破綻しにくいから選ばれる側面が大きいのです。
1-3-2. 規格名で混乱しない覚え方
規格名はややこしく見えますが、覚え方はシンプルです。
- 802.3ad:リンクアグリゲーションが広まった代表的な標準
- 802.1AX:リンクアグリゲーション(LACP含む)を整理して発展した標準
したがって、記事や機器設定の資料で両方を見かけても「同じ系統の標準」と捉えればOKです。
なぜLACPが必要なのか
ネットワークを設計していると、「回線を増やして速くしたい」「障害に強くしたい」という要望が必ず出てきます。ただし、ケーブルを複数本つないだだけでは、ループ(経路の輪)が発生して通信が破綻することがあります。そこで重要になるのが スパニングツリー と LACP の役割分担です。
スパニングツリーは、ループを防ぐために冗長リンクの一部をブロックして安定稼働させる仕組みです。一方で、LACPは複数リンクを束ねて「1本の論理リンク」として扱い、帯域拡張と冗長化を両立しやすくします。つまり、スパニングツリーだけでは得られない“帯域の有効活用”を、LACPが補う構図になります。
2-1. 帯域幅の拡張とネットワーク性能向上
トラフィックが増えると、1本のリンクでは混雑して遅延が増えます。だから回線を増やしたくなりますが、ここでスパニングツリーを思い出してください。冗長リンクをそのまま増やすとループが起きるため、スパニングツリーは安全のために一部リンクをブロックします。
その結果、せっかく増やした回線が「待機」に回って、帯域が有効活用されないことがあります。したがって、帯域拡張を目的にするなら、LACPで束ねて論理的に1本として扱う方が効率的です。
2-1-1. スパニングツリーとLACPの違いを一言で
- スパニングツリー:ループ防止のために“余った道を止める”
- LACP:複数リンクを“束ねて1本にする”ので止めずに使える
つまり、スパニングツリーが「安全運転」、LACPが「車線増設」のイメージです。
2-1-2. 速度が上がる仕組みで誤解しやすい点
LACPで帯域が増えるといっても、1つの通信が常に倍速になるとは限りません。多くの場合、通信の組み合わせ(送信元/宛先MAC、IP、TCP/UDPポートなど)を元に負荷分散されます。
その結果、次の傾向になります。
- 多数の通信が同時に流れる環境ほど、LACPの効果が出やすい
- 1本の大容量転送だけだと、特定リンクに偏って体感が変わりにくい場合がある
2-2. 耐障害性(冗長化)と信頼性の向上
ネットワーク障害で多いのは、ケーブル断線、ポート故障、SFP不良など「物理リンクの問題」です。ここで冗長化を組むと安心ですが、冗長リンクを普通に張るだけだと、先ほどの通りスパニングツリーがループ防止で片側をブロックします。
一方、LACPで束ねた場合、束の中の1本が切れても、残りのリンクで通信を継続しやすくなります。つまり、フェイルオーバー(迂回)というより「束の中で自動的に縮退して動き続ける」イメージです。
2-2-1. スパニングツリーの復旧とLACPの復旧の違い
スパニングツリーは障害時に経路再計算が走るため、環境によっては収束(落ち着くまで)に時間がかかることがあります。
対してLACPは、束のメンバーリンクが1本減るだけで論理リンク自体は維持されるため、影響が小さくなることが多いです。
| 観点 | スパニングツリー | LACP |
|---|---|---|
| 目的 | ループ防止 | 帯域拡張+冗長化 |
| 障害時の挙動 | ブロック解除や再計算で経路切替 | 束のメンバーが減って継続 |
| 体感影響 | 環境により一時停止が出ることがある | 比較的小さいことが多い |
したがって、「止まりにくいネットワーク」を目指すなら、スパニングツリーに任せる範囲とLACPで束ねる範囲を整理するのがコツです。
2-3. LACPが構成ミスを防ぐ理由
リンクアグリゲーションを手動(静的)で組むと、設定ミスが起きたときに厄介です。片側だけ束ねていて、もう片側は束ねていない、といった状態になると、予期せぬループや通信断、片方向通信などが起きることがあります。
だからこそLACPの「ネゴシエーション」が効きます。相手と制御フレームを交換して、束ねてよい条件かどうかを確認しながら成立するため、ミスに気づきやすいのです。
2-3-1. スパニングツリーがあるのに、なぜミスが問題になるのか
スパニングツリーは“スイッチ間のループ”を抑えるのが得意ですが、LACPの設定ミスは「意図しないリンクの扱い」や「片側だけの論理化」など、別の種類の不整合を生むことがあります。
その結果、スパニングツリーがいても、次のような事故が起こりえます。
- 期待した帯域が出ない(実は束になっていない)
- 片系だけに流量が集中して輻輳する
- 特定VLANだけ不安定になる
つまり、スパニングツリーは万能な安全装置ではないため、LACPで“束として成立しているか”を機械的に確認できる価値が高いわけです。
2-3-2. 現場で多いミスと、チェック観点
LACP導入時に起きやすいミスを、点検表としてまとめます。
- 速度/デュプレックスが一致していない
- VLANやトランク設定が一致していない
- LACPモード(アクティブ/パッシブ)の組み合わせが不適切
- 片側のポートだけ別のグループに入っている
したがって、LACPを使うなら「束の状態(メンバーが揃っているか)」と「スパニングツリー上での扱い(トポロジが意図通りか)」をセットで確認すると、トラブルを大幅に減らせます。
LACPの仕組みと動作
LACPを理解するうえで大事なのは、「複数リンクを束ねて1本に見せる」だけでなく、その裏側で 相手装置と状態を確認し続けている 点です。つまり、LACPは“束ねる瞬間”だけ働くのではなく、運用中もリンクの健康状態を見張ります。
そして、ここで一緒に押さえておきたいのが スパニングツリー との関係です。スパニングツリーはループを防ぐ仕組みですが、LACPで束ねたリンクは多くの場合「1本の論理リンク」として扱われます。
したがって、束ね方が正しければ、スパニングツリーが余計なリンクをブロックして帯域を無駄にする状況を避けやすくなります。
3-1. LACPがリンクを束ねる仕組み
LACPは、LACPDU(LACP Data Unit)という制御フレームを使って、接続相手と「このポート同士を同じ束にしてよいか」を確認します。
言い換えると、LACPDUは“束ねるための名刺交換”です。
3-1-1. LACPDUでやり取りしている情報(ざっくり理解)
初心者が混乱しやすいので、重要ポイントだけに絞ると次のイメージです。
- 相手がLACP対応か(LACPで束ねる意思があるか)
- 同じグループとして束ねる条件が合っているか
- 束の中のどのポートが有効メンバーか
したがって、片側だけ設定が違う、ポート条件がズレている、といった場合に「束が成立しない」「一部ポートだけ外れる」などの形で問題が表面化します。
3-1-2. LACPのネゴシエーションがスパニングツリーに与える影響
LACPが正しく束を作れないと、物理的には複数リンクが存在してしまいます。その結果、スパニングツリーが「ループの可能性あり」と判断してブロックに回し、意図した帯域拡張ができないことがあります。
つまり、現場でよくある流れはこうです。
- LACPが不成立(または一部不成立)
- 束ではなく“冗長リンク”として見える
- スパニングツリーが片側リンクをブロック
- 期待した帯域や冗長性が出ない
だから、LACPDUによるネゴシエーションの理解は、スパニングツリーの挙動を読み解くうえでも役立ちます。
3-2. LACPのモード
LACPには代表的に アクティブ と パッシブ の2つのモードがあります。難しく見えますが、要するに「自分から交渉を始めるかどうか」です。
3-2-1. アクティブとパッシブの違い
- アクティブ:自分からLACPDUを送って交渉を開始する
- パッシブ:相手から来たら応答するが、自分からは積極的に始めない
この違いを表にすると、判断しやすくなります。
| 組み合わせ | LACPは成立しやすいか | 現場での推奨 |
|---|---|---|
| アクティブ × アクティブ | 成立しやすい | よく使う |
| アクティブ × パッシブ | 成立する | よく使う |
| パッシブ × パッシブ | 成立しないことが多い | 避ける |
したがって、迷ったら「少なくとも片側はアクティブ」にするのが定番です。
3-2-2. スパニングツリーとの運用上の注意点
LACPが成立すると、スパニングツリーは束(論理リンク)単位で扱うことが多く、トポロジがシンプルに見える傾向があります。
しかし、モード設定ミスでLACPが成立しないと、スパニングツリーがリンクをブロックしたり、予期しない経路に切り替えたりします。
だから、スパニングツリーの状態を見て「ブロックされてるから悪い」と決めつけず、まずLACPのモード組み合わせを疑うのがトラブル対応の近道です。
3-3. LACPがリンク状態を監視するしくみ
LACPは束を作って終わりではありません。運用中もLACPDUの送受信を通じて「相手が生きているか」「このリンクはまだ束の一員として正常か」を監視します。ここが、静的なリンクアグリゲーションとの大きな違いです。
3-3-1. 監視が効くと何が嬉しいのか
リンクが不安定なとき、LACPがなければ「リンクは物理的にUPだけど実際は怪しい」状態に気づきにくいことがあります。
一方でLACPなら、束の中の異常なリンクを自動的に外し、結果として通信影響を小さくできる場合があります。
つまり、LACPの監視は次を支えます。
- 障害の早期検知
- 束の健全性維持(怪しいリンクの切り離し)
- 運用の安心感(状態が見える)
3-3-2. スパニングツリーと合わせて見るべき運用チェック
LACPとスパニングツリーは役割が違うため、どちらか片方だけ見ていると原因を見誤ります。したがって、運用では次のセット確認が有効です。
- LACP側:束が成立しているか、メンバーリンクが全て有効か
- スパニングツリー側:束(論理リンク)が想定通りの経路になっているか、意図しないブロックがないか
3-3-3. 現場で効く「切り分けの順番」
トラブル時におすすめの順番は次の通りです。
- まずLACPの束が成立しているか(メンバー数が期待通りか)
- 次にスパニングツリーでブロックや迂回が起きていないか
- 最後にVLANやトランク、速度などの整合性を見る
この順で見ると、「スパニングツリーが悪いのか、LACPが不成立なのか」を早く切り分けられます。
LACPの設定と運用のポイント
LACPは「束ねれば終わり」ではなく、設定の整合性と運用監視がすべてです。とくに現場では、LACPの不成立や部分不成立が原因で、意図せず スパニングツリー がリンクをブロックし、帯域が出ない・経路が変わるといったトラブルが起きがちです。
したがって、LACP設定は「LACPの視点」と「スパニングツリーの視点」をセットで押さえると失敗しにくくなります。
4-1. LACPを設定する際の基本ルール
LACPは、複数ポートを“同じ束のメンバー”として扱うため、メンバー同士の条件が揃っていないと成立しません。つまり、LACPの基本ルールは「束の中身を同一仕様にそろえること」です。
4-1-1. まず揃えるべき代表項目
以下は、LACPが成立しない・一部だけ外れる原因になりやすいポイントです。
- 速度(Speed):例)1Gと10Gが混ざっていないか
- デュプレックス(Duplex):全二重/半二重が混在していないか
- VLAN設定:アクセスポートのVLAN番号、またはトランク許可VLANが一致しているか
- ポート種別:アクセス/トランクが揃っているか
- MTU:ジャンボフレーム有無などが揃っているか(環境次第で重要)
ここがズレると、束として成立しないだけでなく、スイッチから見ると「ただの冗長リンク」に見える場合があります。するとスパニングツリーが動作して片側をブロックし、結果として「LACPを組んだのに帯域が増えない」という状況になりやすいのです。
4-1-2. スパニングツリー観点での基本チェック
LACPを組むと、多くの環境でスパニングツリーは束(論理リンク)単位で扱います。したがって、確認したいのは次の2点です。
- スパニングツリー上で、束が 1本のリンクとして 見えているか
- ブロック状態が出ているなら、LACP不成立が原因ではないか
4-2. 実際の機器でのLACP設定手順の考え方
メーカーやOSでコマンドは違いますが、考え方は共通です。つまり「設計を決める → 束を作る → ポートを参加させる → 整合性を確認する」という順番が安定します。
4-2-1. スイッチ側の一般的な流れ
スイッチ間でも、スイッチとサーバ間でも基本は同じです。
- 束(Port-Channel / LAG)を作る
- 参加させる物理ポートを選ぶ
- LACPモードを決める(例:アクティブ推奨が多い)
- 束(論理IF)側にVLANやトランク等の設定を入れる
- 状態確認(メンバー全員が有効か)
ポイントは「物理ポート個別ではなく、束(論理IF)に設定を寄せる」ことです。なぜなら、物理ポート側にバラバラの設定が残ると、LACPが部分不成立になったり、スパニングツリーで予期しないブロックが起きたりするからです。
4-2-2. サーバ側(NICチーミング/ボンディング)の一般的な流れ
サーバ側は用語が揺れますが、やることはシンプルです。
- LACP対応のチーミング/ボンディング方式を選ぶ
- 参加NICを指定する
- ハッシュ方式(負荷分散の基準)を選ぶ
- スイッチ側のLACPと整合するか確認する
したがって、スイッチ側だけ正しくても、サーバ側が静的だったり別方式だったりするとLACPが噛み合いません。その結果、スパニングツリーがブロックしたり、通信が片寄ったりします。
4-2-3. 設計時に決めておくと楽になる項目
運用で揉めやすいので、事前に決めると良いポイントをまとめます。
| 項目 | 決める理由 |
|---|---|
| LACPモード(アクティブ/パッシブ) | 不成立の典型原因を潰せる |
| 負荷分散方式(ハッシュ) | 偏りやすさが変わる |
| トランク許可VLAN | VLAN不一致による部分障害を防ぐ |
| スパニングツリーの扱い(設計方針) | 予期しないブロックや経路変化を減らす |
4-3. よくある設定ミスとトラブルシューティング
「LACPが動かない」と感じるとき、実際は次のどれかが多いです。
- LACPが 不成立(束になっていない)
- LACPが 部分不成立(一部ポートだけ束から外れている)
- 束は成立しているが、設計期待(帯域や経路)が違う
そして、これらはスパニングツリーの状態にも現れます。つまり、スパニングツリーのブロックが“原因”ではなく“結果”になっているケースが多いです。
4-3-1. ありがちなミス一覧(まずここを見る)
- パッシブ × パッシブになっていて交渉が始まらない
- 速度/デュプレックス不一致
- トランク/アクセスの混在
- トランク許可VLANの不一致
- 片側だけ別のLAGグループ番号に入っている
- 物理ポート側に古い設定が残っている(論理IFに集約できていない)
4-3-2. 切り分けの順番(スパニングツリーを活用する)
トラブル対応は、次の順番が効率的です。
- LACPの状態確認:束が成立しているか、メンバーが全員有効か
- スパニングツリー確認:束が1本として見えているか、意図しないブロックがないか
- VLAN/トランク整合性:許可VLAN・ネイティブVLAN・タグ有無の一致
- 物理層確認:エラーカウンタ、リンクフラップ、SFP、ケーブル
この順で見れば、「スパニングツリーがブロックしているから遅い」のか、「LACP不成立で冗長リンク扱いになりブロックされている」のかを短時間で判断できます。
4-3-3. 症状から原因を当てる早見表
| 症状 | ありがちな原因 | まず見る場所 |
|---|---|---|
| 帯域が増えない | LACP不成立、スパニングツリーが片系ブロック | LACPメンバー状態、STPポート状態 |
| 片方のリンクだけ使われる | 部分不成立、設定不一致 | VLAN/トランク、速度/デュプレックス |
| ときどき切れる | リンクフラップ、エラー多発、LACP監視で外れている | エラーカウンタ、ログ、LACP状態遷移 |
| VLANによって通信できない | トランク許可VLAN不一致 | トランク設定、論理IF設定 |
LACPのメリットとデメリット
LACPは、複数の物理リンクを束ねて「1本の論理リンク」として使える仕組みです。その結果、帯域を増やしながら冗長化もでき、設計の自由度が上がります。
一方で、万能ではありません。とくにネットワーク全体では スパニングツリー がループ防止を担っているため、LACPの設計や設定が甘いと、スパニングツリーが想定外にブロックして「結局、帯域が増えない」「経路が変わって遅い」といった問題につながります。したがって、メリットだけでなく注意点もセットで理解することが重要です。
5-1. LACPの利点まとめ(パフォーマンス・冗長性)
LACPの利点は大きく分けると「性能」と「可用性」、そして「運用性」です。つまり、導入する価値は“速くて落ちにくい”だけでなく、“管理しやすい”ことにもあります。
5-1-1. パフォーマンス面のメリット
- 帯域拡張:複数リンクを束ねて総量を増やせる
- 混雑の緩和:複数の通信を分散でき、ピーク時に強い
- スパニングツリーで寝てしまう回線を減らせる:冗長リンクをブロックせず、束として活用しやすい
ここで重要なのは、スパニングツリー単体だと「ループ防止のために余剰リンクを止める」方向に働く点です。だから、帯域を有効活用したいなら、LACPで論理的に1本化してスパニングツリーの“ブロック対象”になりにくくするのが定石です。
5-1-2. 冗長性(可用性)面のメリット
- リンク障害に強い:束の中の1本が切れても残りで継続しやすい
- 復旧が速いケースが多い:スパニングツリーの再計算待ちより影響が小さくなることがある
- 保守作業がしやすい:1本ずつ抜き差ししても束が生きていればサービス影響を抑えられる
つまり、スパニングツリーの「切替」で冗長化するのではなく、LACPの「束の縮退」で冗長化する設計ができるのが強みです。
5-1-3. 運用性のメリット
- 自動交渉でミスに気づきやすい
- 状態が見える:メンバーが有効か無効かを把握しやすい
- 拡張が容易:条件が揃えばメンバー追加で帯域を増やしやすい
5-2. LACPの注意点
メリットが大きい一方、LACPには注意点もあります。ここを理解していないと、「スパニングツリーは正常なのに通信が不安定」「束ねたのに速くならない」といった悩みが発生します。
5-2-1. 互換性・機器仕様の注意
- すべての機器やNICが同じ方式・同じ機能に対応しているとは限らない
- ベンダー差で、推奨のハッシュ方式や制限が異なることがある
- 一部の機能(マルチシャーシ系など)は“LACPだけ”では完結しない場合がある
したがって、設計段階で「どの機器同士で束ねるか」「対応範囲はどこまでか」を決めておくことが重要です。
5-2-2. 負荷分散の制限(思ったほど速くならない問題)
LACPは多くの場合、通信を“分散”しますが、“1つの通信を分割して同時に流す”わけではありません。だから、次のような状況では体感が変わりにくいことがあります。
- 大容量転送が1本だけ(バックアップ1本流すだけ、など)
- 特定の通信だけが偏るハッシュ条件になっている
- サーバ側のチーミング設定とスイッチ側の意図がズレている
5-2-3. パケット再順序(順番が入れ替わる)への配慮
LACP自体が“再順序を起こす”というより、負荷分散設計がまずいと、通信の経路が変わりやすくなり、結果として順番の乱れが問題になるケースがあります。
とくに遅延差が大きいリンクを混在させたり、分散条件を頻繁に変えたりすると、アプリケーションによっては性能低下につながる場合があります。
したがって、次のような運用が安全です。
- 束のメンバーは同一条件(速度・遅延・設定)でそろえる
- 分散条件(ハッシュ方式)を必要以上に頻繁に変更しない
- 重要系では検証環境で挙動を確認してから本番導入する
5-2-4. スパニングツリーとの“勘違い”に注意
LACPが部分不成立になると、スイッチはリンクを束として扱えず、冗長リンクとして扱うことがあります。するとスパニングツリーがブロックを始めます。
その結果、「スパニングツリーのせいで遅い」と見えて、実は原因がLACPの不成立だった、というパターンが非常に多いです。
5-3. 静的リンクアグリゲーションとの比較
リンクアグリゲーションには、LACP(動的)と静的(手動)があります。違いを一言で言うなら、交渉があるかないかです。
5-3-1. LACPと静的の比較表
| 観点 | LACP(動的) | 静的(手動) |
|---|---|---|
| 交渉 | あり(相手と確認) | なし(強制的に束ねる) |
| 設定ミス耐性 | 高め(不一致が表面化しやすい) | 低め(気づきにくい) |
| 運用監視 | 状態が見えやすい | 見えにくいことがある |
| トラブル時 | 切り分けしやすい傾向 | 原因特定が長引くことがある |
| スパニングツリーとの関係 | 束として扱われやすい | 失敗時に冗長リンク化しやすい |
5-3-2. どちらを選ぶべきか(実務的な結論)
- 変更が多い、機器が混在する、止められない:LACPが向きやすい
- 小規模で固定、運用者が限定される:静的でも成立することはある
ただし、スパニングツリーが動く環境では、静的での“思い込み設定”が事故につながりやすいのも事実です。だから、多くの現場では「基本はLACP、理由があるときだけ静的」という運用方針が採られがちです。
LACPの実践例と応用
LACPは仕組みを理解するだけではなく、「どこに使うと効くのか」を具体例で掴むと一気に腹落ちします。
とくに設計の現場では、冗長化を入れた結果として スパニングツリー がリンクをブロックし、帯域が眠ってしまう問題がよく起きます。
したがって、LACPを使った設計では「スパニングツリーで止める冗長」と「LACPで束ねて活かす冗長」を分けて考えるのがポイントです。
6-1. LACPを使ったネットワーク構成例
ここでは、導入頻度が高い2パターンを紹介します。どちらも「速さ」と「落ちにくさ」を両立しやすく、さらにスパニングツリーのブロックを減らして帯域を活かしやすい構成です。
6-1-1. スイッチ間でLACPを使う例(上位・下位の接続を太くする)
目的はシンプルで、スイッチ間の幹線を太くしつつ、1本切れても通信を継続できるようにすることです。
- 下位スイッチ ↔ 上位スイッチの間に複数リンクを用意
- それらをLACPで束ね、論理的に1本として運用
- スパニングツリーから見ても、束は1リンクとして扱われやすい
つまり、スパニングツリーが「冗長リンクだから止める」と判断する状況を減らし、幹線帯域を有効活用できます。
6-1-1-1. イメージ構成(概念図)
- 下位SWのポート1・2 → 上位SWのポート1・2
- 2本をLACPで1つのLAG(束)にする
- VLANやトランク設定は束(論理IF)側に集約する
6-1-1-2. この構成でスパニングツリーがどう楽になるか
LACPが成立していれば、スパニングツリーの設計は次のように単純化しやすくなります。
- ブロック対象が「束単位」になりやすい
- 物理リンクごとのブロック/解除で揺れにくい
- 障害時は束の縮退で吸収でき、STP再計算の影響が小さくなることがある
6-1-2. サーバ間(スイッチ—サーバ)でLACPを使う例(NIC冗長+帯域)
サーバ側はNICが2枚あることが多く、ここをLACPで束ねると効果が大きいです。
- サーバNICを2本、スイッチの2ポートへ接続
- スイッチ側でLACPのLAGを作成
- サーバ側でもLACP対応のボンディング(チーミング)を設定
その結果、1本のNICやケーブル障害が起きても通信継続しやすく、複数通信が並走する環境では帯域も活かせます。
6-1-2-1. スパニングツリーとの関係(ここが落とし穴)
サーバを2台のスイッチにまたがって冗長接続したくなる場面があります。しかし、ここで通常のLACPだけで組もうとすると、構成次第でスパニングツリーが介入し、片系がブロックされてしまうことがあります。
だから、サーバの“二重化の仕方”は、次の判断が重要です。
- 同一スイッチに2本で完結できるなら、LACPがシンプル
- 2台のスイッチに分散するなら、次の「MC-LAG」などの仕組みが候補になる
6-2. LACPの応用(MC-LAGや拡張機能)
LACPの応用として最も現場で話題になりやすいのが MC-LAG(Multi-Chassis LAG) 系です。これは「別々のスイッチ2台を、サーバからは1つの論理接続に見せる」ための考え方です。
6-2-1. なぜMC-LAGが必要になるのか
通常のLACPは、原則として同一装置(同一スイッチ)内のポートを束ねる想定です。
しかし現場では、次の要望がよく出ます。
- スイッチ自体の故障にも備えたい(片方のスイッチが落ちても止めたくない)
- サーバは2本のNICで冗長化したい
- しかも片系をスパニングツリーで寝かせたくない(帯域も活かしたい)
つまり、「スイッチ二重化」と「帯域活用」を両立するためにMC-LAGが選ばれることがあります。
6-2-2. スパニングツリーとMC-LAGの位置づけ
MC-LAGの大きな狙いは、冗長リンクを“束”として扱える範囲を広げることです。
その結果、スパニングツリーが冗長リンクをブロックしてしまう状況を減らせる可能性があります。
ただし、ここは重要ですが、MC-LAGは各社で実装や前提条件が異なり、設計を誤ると逆にトラブルが複雑化します。したがって、次の観点で設計の筋を通すことが大切です。
- どこまでをLACP(束)で扱い、どこからをスパニングツリーで守るのか
- 障害時に「どの経路がアクティブになるべきか」を明確にする
- 監視・切り分け手順を運用設計に落とす
6-2-3. 応用導入時のチェックリスト(実務で効く)
最後に、応用構成で事故を減らすためのチェック項目をまとめます。
- LACPが全ポートで成立しているか(部分不成立がないか)
- スパニングツリー上で想定外のブロックが出ていないか
- VLAN/トランク設定が束(論理IF)に集約されているか
- 障害試験(ケーブル断、ポート断、装置断)を実施したか
- 監視項目(LAGメンバー数、STP状態変化、エラー増加)を決めたか

IT資格を取りたいけど、何から始めたらいいか分からない方へ
「この講座を使えば、合格に一気に近づけます。」
- 出題傾向に絞ったカリキュラム
- 講師に質問できて、挫折しない
- 学びながら就職サポートも受けられる
独学よりも、確実で早い。
まずは無料で相談してみませんか?

