束ねるという名の罠：スタティック・イーサチャネルが引き起こす「沈黙の破滅」
ネットワークエンジニアの諸君、LACP（IEEE 802.3ad）を毛嫌いして、あるいは「設定が楽だから」という理由で、スタティック・イーサチャネル（Mode On）に逃げてはいないだろうか？
確かに、PAGPやLACPといったネゴシエーションプロトコルを通さないスタティック設定は、スイッチ間の接続を即座に「論理的な1本」へ昇華させる魔法のように見える。しかし、その背後には、物理層の誤配線や対向機器の認識齟齬を検知できないという、致命的な盲点が存在する。今日は、現場の泥沼で幾度となく見てきた、この「スタティック構成」が引き起こす悪夢と、それを回避するためのアーキテクチャ設計について深掘りしよう。
1. なぜ「Mode On」はプロトコルの放棄なのか
LACPは、単にリンクを束ねるだけの機能ではない。対向との「合意形成」を行うための制御プレーンだ。LACPDU（LACP Data Unit）を毎秒交換することで、両端が同じバンドルグループに属しているか、リンクの物理的な特性が一致しているかを常に監視している。
一方で、スタティック構成（channel-group 1 mode on）は、いわば「盲目的な信頼」だ。対向のスイッチが意図せぬポートに接続されていようが、片側だけが物理的にリンクアップしていようが、スイッチは黙ってパケットを送り続ける。
スタティック設定で発生する「ブロードキャストストーム」のメカニズム
スタティック設定で最も恐ろしいのは、誤配線によるループだ。
対向機器の構成ミスや、パッチパネルの結線間違いにより、本来はポートチャネルの一部であるはずのリンクが、別のL2ドメインに接続されたとしよう。LACPが有効であれば、ネゴシエーション失敗により該当ポートは自動的に分離（ブロック）される。しかし、スタティック設定では、スイッチは「構成が正しい」と信じ込んでいるため、そのままパケットを転送し続ける。
結果として、論理的に分離されているはずのVLAN間にブリッジが形成され、ブロードキャストパケットが無限ループを描く。この瞬間にネットワークは物理的な限界を超え、スイッチのCPUは過負荷に陥り、管理プレーンすら応答不能になる。これが、現場で遭遇する「謎の全滅」の正体だ。
2. パケットレベルで見る「不一致」の末路
スタティックな設定ミスは、単なるループだけではない。MTUサイズやVLAN設定の不一致が組み合わさると、さらに厄介な挙動を見せる。
例えば、片側のスイッチでジャンボフレーム（9000 bytes）を有効にし、もう片方を標準（1500 bytes）のままスタティックに束ねた場合を考えてほしい。
- 1500 bytesを超えるパケットは、片側のスイッチからは送信されるが、対向では「巨大なパケット」として破棄される。
- これにより、TCPのセッション確立までは正常でも、TLSハンドシェイクの途中でデータが消滅し、接続がタイムアウトするという現象が発生する。
特に、TCP MSSのクランプ設定やバッファチューニングを怠っている環境では、この「特定のパケットだけが消える」という挙動が、調査を極限まで難しくする。
現場で推奨する設定のガードレール
もし、物理的制約や古いL2スイッチとの兼ね合いでスタティック設定をせざるを得ない場合でも、最低限の「防壁」を設けるべきだ。以下は、Cisco Catalystでの構成例だが、考え方は他ベンダーでも同じである。
# 物理インターフェースのガード設定
interface GigabitEthernet1/0/1
description UPLINK_TO_CORE_SW_P1
switchport mode trunk
# 誤ったVLANの混入を防ぐための許可VLAN制限
switchport trunk allowed vlan 10,20,100
# STPのガード機能を必ず有効化
spanning-tree guard root
# ポートチャネルの冗長性を補完するため、BPDUガードを考慮
spanning-tree bpduguard enable
channel-group 1 mode on
# ポートチャネル側の論理インターフェース設定
interface Port-channel1
description STATIC_LAG_TO_CORE
switchport mode trunk
# MTUの不一致を防ぐため、物理IFと論理IFのMTUを明示的に揃える
mtu 9000
# バッファチューニング（過負荷時のドロップ対策）
tx-queue limit 10003. 高度なインフラ設計へ：LACPこそが「セキュリティ」である
アーキテクトとして断言する。「LACPが使えない」という現場は、インフラの刷新タイミングである。
LACP（IEEE 802.3ad/802.1AX）は、単なる冗長プロトコルではない。それは、物理的なインフラに対する「状態確認（Health Check）」の仕組みそのものだ。最近のハイパフォーマンスなデータセンターやクラウド基盤では、LACP Fast Rate（1秒間隔のハートビート）を標準とし、リンクの障害検知をミリ秒単位まで短縮している。
TCPバッファとRTT最適化の観点から
高速なリンクアグリゲーションを構築しても、エンドツーエンドのRTT（Round Trip Time）が大きければ、スループットは向上しない。スタティックな束ね方で安心している間に、TCPウィンドウサイズが適切にスケーリングされず、TCP BDP（Bandwidth Delay Product）の計算が狂っているケースが多い。
# LinuxカーネルでのTCP最適化例（sysctl.conf）
# 広帯域・高RTTネットワークでのスループット低下を防ぐ
net.ipv4.tcp_window_scaling = 1
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216最後に：プロトコルを信じろ
ネットワークスペシャリストにとって、最も信頼すべきは「ベンダーの独自機能」ではなく「標準化されたRFC」だ。スタティック・イーサチャネルは、そのシンプルさゆえに、運用者の知識不足をカバーできない。
これから構築を行うのであれば、迷わずLACPを選択してほしい。そして、万が一スタティック設定が必要なレガシー環境に触れる際は、STPの挙動を熟知し、物理結線を地図のように頭に叩き込み、何が起きても即座に切り離せる「物理的な物理」を意識してほしい。
ネットワークとは、パケットという「電子の旅」をいかに安全に、そして高速に導くかという芸術である。その旅路を「設定ミス」という単純な過ちで汚してはならない。諸君のネットワークに、パケットの健やかなる巡回があらんことを。
コメント