複数リンクを束ねるLACPの深層：IEEE 802.3adが支える帯域と冗長性の裏側
インフラエンジニアたるもの、サーバーとスイッチを繋ぐ物理リンクが1本だけでは夜も眠れない。夜中に「リンクダウンしました」というアラートでたたき起こされたトラウマを持つ人なら、誰もが冗長化の美しさに魅了されるはずだ。
リンクの冗長化や帯域拡張において、いまやデファクトスタンダードとなっているのが IEEE 802.3ad、そしてその制御プロトコルである LACP（Link Aggregation Control Protocol） だ。
しかし、現場で「とりあえずLACPを有効にしたらL2ループでネットワークが全滅した」「Active/Passiveの組み合わせをミスしてリンクが上がらない」といった悲劇に直面したことはないだろうか。
今回は、パケットのワイヤーフォーマットから、スイッチのコンフィグ、そしてトラブルシューティングの現場で使える知見まで、LACPの挙動を骨の髄まで解説しよう。
—
1. なぜLACPが必要なのか？Static Link Aggregationとの決定的な違い
複数の物理インタフェースを束ねて1本の論理リンク（Port Channel / EtherChannel）に見せかける技術は、何もLACPに限った話ではない。スイッチの設定だけで強制的に束ねる「Static（スタティック）リンクアグリゲーション」も存在する。
では、なぜわざわざLACPというプロトコルを走らせる必要があるのだろうか？
答えは「安全性」と「自動ネゴシエーション」にある。
Static構成の場合、対向装置（サーバーのNICチーミングや対向スイッチ）の設定ミスがあっても、片方が気づくすべがない。結果として、パケットがブラックホールに吸い込まれたり、意図せぬ片側のリンクだけで通信が強制されてパフォーマンスが劣化したり、最悪の場合はブロードキャストストーム（L2ループ）を引き起こす。
一方、LACPを有効にすると、お互いの装置が定期的に LACPDU（LACP Data Unit） と呼ばれる制御フレームを交わし、お互いの認識しているポート番号、システム優先度、アクター/パートナーの状態をリアルタイムで同期・検証する。これにより、結線のミスや設定の不整合をプロトコルレベルで検知し、安全にポートを切り離すことができるのだ。
—
2. LACPDUの構造とパケットの裏側
LACPは、IEEE 802.3のレイヤーで動作する。マルチキャストアドレス 01:80:C2:00:00:02 （Slow Protocols用の予約MACアドレス）宛てに送信され、VLANタグを越えてスイッチ間でやり取りされる。
LACPDUの中身を覗いてみると、次のような重要なパラメーター（Type-Length-Value構造）が詰め込まれている。
- Actor Information（送信側の情報）: システムID（MACアドレス＋システム優先度）、ポートID（ポート番号＋ポート優先度）、状態フラグ（LACP_state）
- Partner Information（受信側・認識している対向の情報）: 対向から受け取った情報を保持。最初は空、あるいは前回受信した内容が入る
- Collector Information: 最大受信フレームサイズなどのメタデータ
特に重要なのが、LACPDU内の LACP_state フラグ（8ビット）だ。ここには、以下の重要なステータスがリアルタイムで刻まれる。
1. LACP_Activity（ActiveかPassiveか）
2. LACP_Timeout（Periodicの送信間隔：Fast=1秒 / Slow=30秒）
3. Aggregation（個別リンクか、アグリゲーション可能か）
4. Synchronization（お互いにリンクが束ねられたことを認識・合意したか）
この Synchronization フラグが双方向で 1 になった瞬間初めて、その物理ポートはロジカルなアグリゲーション・グループの一員としてトラフィックを流し始める。
—
3. ActiveモードとPassiveモードの組み合わせの罠
LACPをコンフィグする際、必ず直面するのが Active と Passive（またはDisabled）の選択だ。ここを適当に設定すると、いつまで経ってもリンクが上がらずに泥沼にはまる。
- Activeモード: 自ら進んでLACPDUを送信し、対向に対してLACPのネゴシエーションを仕掛ける積極的な姿勢。
- Passiveモード: 自分からはLACPDUを積極的に送信せず、対向から送られてきたLACPDUに対してのみ応答する受動的な姿勢。
ここでインフラエンジニアがやりがちなミスが、「両端をPassiveにしてしまう」ことだ。
| 自装置の設定 | 対向装置の設定 | ネゴシエーション結果 | 備考 |
| :— | :— | :— | :— |
| Active | Active | 成功（リンクアップ） | 最も推奨される構成 |
| Active | Passive | 成功（リンクアップ） | 一般的なサーバー接続等でよく使われる |
| Passive | Active | 成功（リンクアップ） | 対向がActiveなら問題なし |
| Passive | Passive | 失敗（リンクダウン） | お見合い状態になり、永遠に通信できない |
【現場の教訓】
迷ったら、接続する両端（あるいはスイッチ側とサーバー側）の少なくとも片方を必ず Active にすること。実運用では、両端ともActiveで設定するのが最もトラブルが少なく安全である。
—
4. 実務で使える設定例とネットワーク構成
実際のCiscoスイッチ（IOS-XE）およびLinux（Ubuntu / Netplan）におけるLACP（EtherChannel / Bonding）の設定例を見てみよう。
Cisco Catalyst / Nexus スイッチ側の設定（LACP Active）
! 物理インターフェースをまとめ上げるポートチャネルグループを作成
interface Port-channel10
description === Server-A LACP Bond ===
switchport mode trunk
switchport trunk allowed vlan 10,20,30
! 物理ポート1と2をLACP（モード active）でポートチャネルに所属させる
interface GigabitEthernet1/0/1
description === to Server-A NIC1 ===
switchport mode trunk
switchport trunk allowed vlan 10,20,30
channel-group 10 mode active
!
interface GigabitEthernet1/0/2
description === to Server-A NIC2 ===
switchport mode trunk
switchport trunk allowed vlan 10,20,30
channel-group 10 mode activeLinux (Ubuntu Netplan) 側の設定例
サーバー側でも同様にLACP（IEEE 802.3ad）を構成する。
network:
version: 2
renderer: networkd
ethernets:
enp3s0:
dhcp4: no
enp4s0:
dhcp4: no
bonds:
bond0:
interfaces:
- enp3s0
- enp4s0
parameters:
mode: 802.3ad # LACPを指定
mii-mon: 100 # リンク監視間隔 (ms)
lacp-rate: fast # 高速LACPDU送信（1秒間隔：推奨）
addresses:
- 192.168.10.50/24
gateway4: 192.168.10.1
nameservers:
addresses:
- 8.8.8.8ここで lacp-rate: fast（Cisco側では channel-protocol lacp と lacp rate fast に相当）を指定している点に注目してほしい。デフォルトの slow（30秒おき）だと、万が一のリンク断検出に最大30秒かかってしまうが、fast（1秒おき）にすることで、障害発生時のフェイルオーバーを劇的に高速化できる。
—
5. トラブルシューティング：LACPが上がらないときのデバッグ手順
「設定は入れたはずなのに、ポートチャネルがダウンしている…」
そんな修羅場でシニアエンジニアが最初に叩くべきコマンドと、確認すべきポイントを伝授しよう。
① スイッチ側でステータスを確認する (Ciscoの場合)
# show etherchannel summary出力結果のなかに、各物理ポートのステータスフラグが表示される。
P: Port-channelに所属し、正常に束ねられている（Bundled）I: 独立してしまっている（Standalone / LACPネゴシエーション失敗）D: ダウンしている（Down）
もしポートが I になっている場合、対向装置との間でLACPDUが正しく交換できていないか、ネイバーの速度・デュプレックス・VLANネイティブ設定などがミスマッチを起こしている可能性が極めて高い。
② LACPのパケットが流れているか確認する (tcpdump / パケットキャプチャ)
Linuxサーバー側やスイッチのスパニッシュポートで、実際にLACPDUが流れているかを tcpdump でキャプチャしてみる。
# ネットワークインターフェース上でLACP（EtherType 0x8809 / Slow Protocols）をキャプチャする
sudo tcpdump -nnvvv -i enp3s0 ether proto 0x8809チェックポイント:
- 自装置からLACPDU（送信元MACが自NIC、宛先が
01:80:c2:00:00:02）が飛び出しているか？ - 対向装置からのLACPDUが返ってきているか？
- 返ってきていない場合、間にいるL2スイッチやプロバイダー網、あるいは仮想化基盤のセキュリティポリシー（MACスプーフィング対策など）でパケットがドロップされていないか？
—
6. まとめ
IEEE 802.3ad LACPは、単に「帯域を2倍にする魔法の杖」ではない。物理レイヤーの不確実性をプロトコルの力で担保し、システム全体の信頼性を底上げするための非常に洗練された仕組みだ。
- Active / Passiveの組み合わせミスによる「お見合い」に注意する
- リンク障害時の収束を早めるために
lacp-rate: fastを積極的に活用する - 困ったら
show etherchannel summaryとtcpdumpでパケットの往来を確認する
この基本原則さえ押さえておけば、どんな複雑なマルチベンダー環境のLACP構築であっても、恐れることは何もない。確かな理論と冷静なデバッグ力で、堅牢なネットワークインフラを構築してほしい。
コメント