ネットワークの深淵へようこそ。シニアネットワークエンジニアの私だ。
Web APIの設計やモダンなクラウドインフラの構築に日々奔走する君たちにとって、L2/L3スイッチの物理ポートやリンクアグリゲーション（LACP/EtherChannel）の設定は、普段は黒衣として隠れている「地味な下回り」に見えるかもしれない。しかし、アプリケーションがどれほど美しく非同期処理をさばき、APIエンドポイントがミリ秒単位の応答速度を誇っていこうとも、その土台を支えるスイッチド・ネットワークの足元がすくわれれば、システム全体が一瞬で沈黙する。
今回は、プロトコルによる動的なネゴシエーションを一切行わず、人間の手で強引に帯域を束ねる「スタティック・イーサチャネル（マニュアル・イーサチャネル）」に焦点を当てよう。
LACP（IEEE 802.3ad / 802.1AX）やPAgP（Cisco Proprietary）という安全装置を投げ捨て、シニアの「俺を信じろ」という勘と手動設定だけに頼ったとき、データセンターのフロアで何が起きるのか。その恐るべきリスクと、実務で絶対に踏み抜いてはならない地雷の正体を、パケットの挙動とともに徹底的に解説しよう。
—
1. スタティック・イーサチャネルとは何か？ なぜLACPを使わないのか
イーサチャネル（Cisco用語。ベンダーによってはリンクアグリゲーションやポートチャネルと呼ばれる）は、複数の物理リンクを論理的に1本の太いパイプとして束ね、帯域幅の拡大と冗長性を同時に手に入れるための技術だ。
通常、これを行うにはLACPなどのネゴシエーションプロトコルを使用する。LACPは、対向機器間で定期的にLACPDU（LACP Data Unit）という制御パケットを交わし、「お互いのポートが正しく結ばれているか」「同じアグリゲーション・グループに属しているか」を常に監視し合っている。
しかし、歴史的背景や、他ベンダーのレガシー機器との相互接続性、あるいは「プロトコルオーバヘッドを削ぎ落として極限までシンプルな構成にしたい」という現場の判断から、プロトコルを一切使わない「スタティック（静的）設定」が選択されることがある。
Cisco IOSであれば channel-group 1 mode on、Linuxのbondingであれば mode=0 (balance-rr) や mode=1 (active-backup) の一部設定などがこれに該当する。
プロトコルレスの代償：ネゴシエーションの欠如
スタティック設定の最大にして唯一の特徴は、「対向機器と一切会話をしない」ことだ。
スイッチA側で「ポート1と2を束ねろ」と命令されれば、スイッチAは対向のスイッチBがどう思っていよう関係なく、黙々とトラフィックを両方のポートに分散して送り出す。スイッチB側がそれを単体の独立したポートとして認識していようが、間違ったポートの組み合わせで束ねていようが、スイッチAは知ったことではない。ここに、ヒューマンエラーや構成ミスが入り込む余地が生まれた瞬間、大惨事へのカウントダウンが始まる。
—
2. 破滅へのシナリオ：スタティック設定が生む致命的なミスと挙動
実務において、スタティック・イーサチャネルを構成する際によくあるミス、そしてそれがネットワークに何をもたらすのかを順に見ていこう。
2.1 片側のみのチャネル設定（Mismatched Channel Configuration）
最も古典的かつ破壊的なミスは、「ローカル側は mode on でイーサチャネルとして設定したのに、対向側（ピア）の設定を忘れた、あるいは単体ポートのまま放置した」というケースだ。
このとき、ネットワーク内部では次のようなパケットの迷走が発生する。
1. トラフィックの送信: ローカルスイッチは、イーサチャネルのアルゴリズム（送信元/宛先MACアドレスのハッシュ値など）に従い、フレームを物理ポート1とポート2の両方に分散して送り出す。
2. 対向での受信: 対向スイッチはポート1とポート2を「通常の独立したアクセスポートまたはトランクポート」として扱っている。
3. スパニングツリー（STP）の誤認: 通常、イーサチャネルを構成すると、対向からは「1本の論理ポート」に見えるためSTPの計算上も1リンクとして扱われる。しかし、対向がこれを独立した2つのポートと認識している場合、STPのBPDUのやり取りやポート状態の解釈が狂い始める。
4. 最悪の事態（ループの発生）: 対向スイッチがこれらを別々のポートとして認識した結果、同一VLAN内で意図しないブリッジループが形成されることがある。LACPであれば、対向からのLACPDUが途絶えるためポートは自動的にフォールバックするかエラーディセーブル（Err-disabled）になるが、スタティック設定には慈悲深い安全装置がないため、ループを検知する前にブロードキャストストームが爆誕する。
2.2 ポートの入れ替がい（Cabling Mismatch）
物理配線のミスも致命的だ。
スイッチA側の GigabitEthernet 0/1 と 0/2 をポートチャネル1に割り当てたとする。しかし、ラック内の配線作業で、スイッチB側の対向ポートに挿す際、うっかりケーブルを逆（0/2 と 0/1）に挿してしまったとしよう。
LACP環境であれば、LACPDUに含まれるアクター/パートナーのシステムIDやポートID、アグリゲーションの情報を相互に検証するため、「おい、お前のポート番号が逆だぞ」とネゴシエーションが失敗し、リンクは立ち上がらない。
しかし、スタティック設定ではお構いなしだ。
スイッチAは「俺たちは一心同体だ」と信じ込み、ハッシュ計算に基づいてパケットをばら撒く。結果として、受信側でパケットの順序逆転や、フレームの断片化のような奇妙なL2レイヤーの破損が起き、TCPの再送が嵐のように発生する。アプリケーション層から見れば、「なぜかAPIのレスポンスが異常に遅い、あるいはランダムにパケットがドロップする」という、原因究明が極めて困難な幽霊障害（ゴースト・トラブル）に発展する。
—
3. 実務で役立つ設定例とインフラ構築のベストプラクティス
では、どうしてもスタティックな構成を取らざるを得ないレガシー環境や、検証環境において、どのように安全に、かつ確実設定を行うべきか。実務的な設定ファイルと、トラブルシューティングの作法を共有しよう。
Cisco IOSにおけるスタティック・イーサチャネル設定例
以下の例は、Cisco Catalystスイッチにおいて、ポート GigabitEthernet 1/0/1 と 1/0/2 をスタティックなポートチャネル（Po1）としてトランクポートで対向接続する際の設定だ。
! --- ローカルスイッチ側の設定 ---
! 1. 物理インターフェースをまとめて選択
interface range GigabitEthernet 1/0/1 - 2
description *** Static EtherChannel Link to Core-SW-02 ***
no ip address
! 冗長プロトコルを使用せず、強制的にチャネル化（mode on）
channel-group 1 mode on
storm-control broadcast level pps 1k
no shutdown
! 2. 論理ポート（ポートチャネル）側の設定
interface Port-channel 1
description *** Logical Trunk to Core-SW-02 ***
switchport trunk encapsulation dot1q
switchport mode trunk
switchport nonegotiate
spanning-tree portfast trunk
no shutdown> 実務のTips:
> スタティック設定を行う場合、物理インターフェース側（interface range）には switchport mode やVLAN設定を直接書かず、必ず論理インターフェース（Port-channel）側に集約して記述すること。物理ポート側に個別設定が残っていると、パケットの処理挙動に矛盾が生じ、思わぬフレーム破棄の原因になる。
—
4. 障害発生時のデバッグ手順：パケットとログの読み解き方
もし君が運用するネットワークで、スタティック・イーサチャネルの設定ミスによるブロードキャストストームやリンク障害に直面したとき、どのようにしてその原因を特定すべきか。現場のシニアが使う実践的なデバッグコマンドの流れを伝授しよう。
ステップ1: ポートチャネルの状態確認
まず、論理インターフェースが本当に「Up」しているか、そしてメンバーポートが正しく組み込まれているかを確認する。
Router# show etherchannel summary
Flags: D - down P - bundled in port-channel
I - stand-alone s - suspended
H - Hot-standby (LACP only)
R - L3 protocol S - L2 protocol
U - in use-f - trp - optional
--------------------------------------------------------------------------------
Group Port-channel Protocol Ports
--------------------------------------------------------------------------------
1 Po1(SU) - Gi1/0/1(P) Gi1/0/2(P)チェックポイント:
Protocolの欄が-（なし、すなわちスタティック）になっていること。Portsの欄の各物理ポートに(P)（Bundled in port-channel）がついていること。もしここがI（Stand-alone）やDになっている場合、対向との設定不整合（スピード、デュプレックス、VLANネイティブの不一致など）が起きている。
ステップ2: 物理レイヤーとエラーカウンターの監視
次に、インターフェースのエラーカウンタを覗き見る。ストームが発生している、あるいは配線ミスによるフレーム化エラーが起きている場合、ここが跳ね上がっているはずだ。
Router# show interfaces GigabitEthernet 1/0/1
GigabitEthernet1/0/1 is up, line protocol is up (connected)
...
5 minute input rate 10485760 bits/sec, 15200 packets/sec
5 minute output rate 10485760 bits/sec, 15200 packets/sec
12543000 packets input, 1850230000 bytes, 0 no buffer
Received 45210 broadcasts (0 IP multicasts)
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored> 実務のTips:
> input errors や CRC、frame エラーが秒単位で増加している場合、物理層のケーブル不良、あるいは対向とのデュプレックス（全二重/半二重）ミスマッチが疑われる。スタティック・イーサチャネルでは、片側のポートがダウンしたときにそれを対向が検知できず、死んだポートに延々とトラフィックを流し続ける「ブラックホール現象」が起きやすいため、このカウンターの監視は命綱となる。
—
5. まとめ：モダンインフラにおける教訓
スタティック・イーサチャネルは、設定がシンプルであるがゆえに、「正しく動いているときは最高に美しいが、一度狂い始めるとシステム全体を地獄に引きずり込む劇薬」である。
現代のネットワークインフラストラクチャにおいて、特別な理由（レガシー機器の制限など）がない限り、リンクアグリゲーションには必ずLACP（mode active または passive）を採用すべきだ。機械同士に対話をさせ、人間が気づけないミスをプロトコルに検知させることこそが、モダンでレジリエントなシステムを維持する鉄則である。
コードを書くときも、インフラを組むときも、手動の思い込みを排し、プロトコルという名の信頼できる相棒に仕事をさせる――これこそが、数々の修羅場をくぐり抜けてきたエンジニアの流儀なのだ。
コメント