3.2EtherChannelのトラブルシュート

EtherChannelは帯域を束ねると同時に、スパニングツリーから見て1本の論理リンクに見せることで冗長リンクをブロッキングさせずに使い切る技術です。しかし現場で最も多いトラブルは「ケーブルは全部挿さっているのに1本しか束に入っていない」「ポートがsuspendedになる」というもので、原因はほぼ例外なく両端の設定の食い違いです。この節では、束が成立するための条件を「プロトコルの交渉」と「物理/論理パラメータの一致」の2軸に分けて整理し、show etherchannel summary のフラグからどちらの軸で失敗したかを即断できるようにします。

3.2.1LACP・PAgP・on のモード組み合わせ

• LACP（Link Aggregation Control Protocol）はIEEE 802.3adの標準プロトコルで、他社機器とも束ねられる。モードは channel-group 1 mode active（積極的に交渉を開始）と mode passive（応答するだけ）。DTPと同じ原理でpassive＋passiveは束にならない。異ベンダ混在環境では実質LACP一択である。
• PAgP（Port Aggregation Protocol）はCisco独自で、モードは mode desirable（積極）と mode auto（受動）。やはりauto＋autoは束にならない。LACPとPAgPは互換性がないため、片側LACP・片側PAgPの組み合わせは交渉が成立せず束ができない。
• mode on は静的（交渉なし）で、相手も on のときだけ正しく束ねられる。危険なのは片側 on・片側 active/desirable の組み合わせで、on 側は交渉なしに即座に転送を始める一方で相手は束を認めないため、STPが1本の論理リンクと認識できず物理ループやMACフラッピングを招く。「とりあえず on にすれば確実」という発想が最も事故を起こす。

3.2.2束ねる条件（パラメータ一致）

• 交渉が成立しても、束ねるメンバポートのパラメータが揃っていなければそのポートは束から外れる。一致が必要なのは速度・duplex・スイッチポートモード（アクセス／トランク）・トランクの許可VLANリスト・ネイティブVLAN・アクセスVLAN・STPのポートコスト/優先度など。1本だけ100Mbpsでオートネゴした、といった些細な差でも束から弾かれる。
• 設定順序も事故のもとで、先にメンバポートの設定を揃えてから channel-group を投入するのが定石。interface port-channel 1 に後から設定を入れると、メンバポートへ継承されるものとされないものがあるため、show running-config interface でメンバ側を必ず確認する。
• show etherchannel summary のフラグで状態を読む：P＝束に参加（bundled）、I＝独立（stand-alone・交渉相手なし）、s＝suspended（LACPは受信しているがパラメータ不一致等で保留）、D＝down、H＝hot-standby（LACPは同時アクティブ最大8本で、9本目以降は待機になる）。Port-channel自体は SU（L2・in use） が正常。

3.2.3ロードバランシングの偏り

• EtherChannelはフロー単位でメンバリンクを選ぶハッシュで分散し、1つのフローが複数リンクに分割されることはない（パケット順序逆転を防ぐため）。したがって「10Gbpsを4本束ねたので単一フローが40Gbps出る」は誤りで、単一フローの上限は物理1本分である。
• ハッシュの入力は port-channel load-balance で選ぶ（src-mac/dst-mac/src-dst-mac/src-ip/dst-ip/src-dst-ip/src-dst-port 等）。入力に選んだフィールドの値が偏っていると分散も偏る——例えばサーバ群が1台のルータ（1つのMAC）越しに通信する環境で dst-mac を選ぶと、全トラフィックが同じリンクに集中する。

あなたはコアスイッチCSW1とディストリビューションスイッチDSW1の間に4本のギガビットリンクでEtherChannelを構成しましたが、期待した4Gbpsの帯域が出ず、監視上は1本分しか使われていません。CSW1で show etherchannel summary を実行すると、Po1が SU で Gi1/0/1 が (P)、Gi1/0/2 と Gi1/0/3 が (s)、Gi1/0/4 が (I) と表示されました。フラグごとに原因が違うので、ここを一括りに「設定ミス」と片付けると解決しません。まず (I)＝stand-alone の Gi1/0/4 は、LACPのネゴシエーションパケットを一度も受け取っていないことを意味します。つまり相手側のGi1/0/4に channel-group が入っていないか、そもそもケーブルが別ポートに刺さっているか、相手が on（交渉しない）になっている可能性が高く、対向側の show running-config interface と show cdp neighbors で物理接続の対応づけから確認します。次に (s)＝suspended の2本は、LACPは受信できている（＝相手も交渉モードで設定済み）が、束ねる条件が揃っていない状態です。ここで疑うのは速度/duplexの不一致、片方だけアクセスポートでもう片方がトランク、あるいはトランクの許可VLANリストやネイティブVLANの差異です。実際に確認すると、Gi1/0/2とGi1/0/3では switchport trunk allowed vlan がGi1/0/1と異なっており、後から追加したVLANを2本にしか反映していなかったことが判明しました。ここで「suspendedだから mode on にすれば強制的に束ねられる」と考えるのは最悪の対処で、パラメータ不一致を残したまま強制的に転送を始めるため、STPが論理リンクとして扱えずMACフラッピングやループを誘発します。正しい手順は、メンバ4本のパラメータを完全に揃えてから、必要なら channel-group を入れ直すことです。パラメータを揃えた後は再度 show etherchannel summary で全メンバが (P) になったことを確認し、さらに show etherchannel load-balance でハッシュ入力を点検します。仮に全メンバが (P) なのに帯域が偏るなら、それはもう束の問題ではなくハッシュ入力の選択（フローの多様性）の問題であり、src-dst-ip など分散しやすい入力への変更を検討します。

3.2.4この節のまとめ

• LACP（active/passive・標準）とPAgP（desirable/auto・Cisco独自）は非互換で、受動同士では束にならない。on は交渉せず、片側だけ on はループの危険
• 交渉が成立してもメンバの速度/duplex/トランクモード/許可VLAN/ネイティブVLANが不一致なら束から外れる＝(s) suspended
• (I)＝交渉相手なし、(s)＝条件不一致、(P)＝正常。分散はフロー単位ハッシュで単一フローは物理1本分が上限