ケーブルを挿し直しても、接続口がerr-disabledのまま。no shutdownで一度戻っても、すぐ止まる。この状態では、復旧の操作より先に「スイッチが何を検出したか」を知る必要があります。
err-disabledは、異常を検出した機器が接続口を停止した状態です。以下はCisco IOS／IOS XE系Catalystの説明例です。機種やOSで表示や対象の原因は変わります。ここでいうポートは、ケーブルをつなぐ接続口です。
まず、どんな理由で止まっているかを分ける
リンクが使えないとき、ケーブル抜けとerr-disabledでは出発点が違います。ケーブル抜けなら物理的な接続を調べます。err-disabledなら、止めた理由を探してから、その理由に合う場所を調べる流れになります。
たとえば端末用の接続口で、想定していないスイッチからBPDUを受け取ると、BPDU Guardが働いて停止する場合があります。配線はつながっていても、そのまま通信させないために止めています。
| 状態 | 意味 | 最初の確認 |
|---|---|---|
| notconnect / down | リンクが成立していない | 対向電源、ケーブル、モジュール |
| disabled / administratively down | 設定上で停止している | shutdownの設定と停止の理由 |
| err-disabled | 機器が異常検出で停止した | 発生ログとerrdisable reason |
表のdisabledは、設定で停止している場合の表示です。err-disabledと似て見えても、原因の確認方法は同じではありません。まず一覧で状態と対象ポートを特定すれば、違う状態に対して復旧コマンドを繰り返すのを避けられます。
保護機能を消して接続を通すと、停止した理由が残ってしまいます。今回の配線や機器が設計の想定どおりかを調べ、止めた原因を解消するところまでが復旧の準備です。
停止理由は、状態一覧とログを合わせて読む
対象がGi1/0/10なら、ログでも同じ名前を探します。発生時刻をそろえるため、show clockも一緒に記録します。別のポートの異常や、以前の停止を今回の原因と取り違えないためです。
下のログでは、BPDU受信の記録と、同じポートをbpduguardでerr-disableにした記録が対応しています。状態一覧で「止まっている」と分かり、ログで「何を検出して止めたか」が分かるわけです。
用語の補足：BPDU Guardは何を見ている？
BPDUは、スイッチなどがSTPの情報をやり取りする通信です。BPDU Guardは、その通信を受け取る想定のない接続口でBPDUを検出したときなどに、接続口を保護のため停止します。
show clock
show interfaces status err-disabled
show logging
show errdisable recovery
show running-config interface GigabitEthernet1/0/10説明用ログ抜粋：
%SPANTREE-2-BLOCK_BPDUGUARD: Received BPDU on port Gi1/0/10
%PM-4-ERR_DISABLE: bpduguard error detected on Gi1/0/10show running-configで、その口の役割や保護設定も読みます。PC用という前提なら、対向にスイッチやブリッジがいないかを配線図と現物で照合します。BPDUはSTPの情報をやり取りする通信なので、受信元が前提に合うかが次の手掛かりです。
show errdisable recoveryは、自動復旧の対象やタイマーを見るコマンドです。表示された原因一覧を、今回そのポートで起きた原因の一覧とは読めません。停止理由は発生時のログと対応させます。
原因を直した後で、接続口を戻す
BPDU Guardで止まったなら、想定外の機器や配線を解消します。ポートセキュリティなら、実際につながった端末のMACと許可条件を照合します。同じerr-disabledでも、直す対象は理由ごとに違います。
表で原因候補を整理したら、是正後に接続口を戻します。下のshutdown／no shutdownは、そのための説明例です。対象名が正しいか、停止と復旧の影響を受ける通信が何かを確かめたうえで行います。
用語の補足：shutdown／no shutdownって何？
shutdownは対象インターフェースを設定で停止し、no shutdownはその停止設定を解除します。err-disabledの手動復旧にも使われますが、先に停止原因を解消し、対象ポートと作業範囲を確認します。
| 理由の例 | 復旧前に確認すること |
|---|---|
| bpduguard | 端末用ポートにスイッチやブリッジが接続されていないか |
| psecure-violation | 許可MAC、学習方式、端末変更が承認されたものか |
| link-flap | ケーブル、SFP、対向電源、両端のリンクログ |
| udld | 光の片方向障害、配線、対向のUDLD状態 |
| channel-misconfig | EtherChannelの構成と両端の設定差 |
configure terminal
interface GigabitEthernet1/0/10
shutdown
no shutdown
endshutdownは設定で停止し、no shutdownはその停止設定を解除します。どちらも、断線したケーブルや想定外の配線を直す機能ではありません。原因が残れば、また保護が働いて止まります。
復旧後は状態を見て終わらず、同じ停止理由が再び記録されていないかを追います。一度戻ったことと、原因が取り除けたことは別です。直した配線や端末、実施した操作を残すと、再発したときも前回との違いを調べられます。
仕様の確認：Cisco：Errdisableの原因と復旧。
自動復旧を入れる前に、再発時の動きを考える
自動復旧を設定すると、指定した原因で停止した口を、一定時間後に戻せます。毎回手動で戻す手間は減りますが、原因を直す機能ではありません。
下の例ではlink-flapだけを対象にし、間隔を300秒にしています。link-flapは、リンクのup／downが繰り返されることです。実際に対象を選ぶ際は、なぜ止まるかと、戻った直後にどんな影響があるかを考えます。
設定例：link-flapだけを自動復旧対象にする
configure terminal
errdisable recovery cause link-flap
errdisable recovery interval 300
end
show errdisable recovery配線やモジュールに問題が残ったままなら、自動で戻しても再び停止するかもしれません。停止と復旧を繰り返しているログは、通信が安定した証拠にはなりません。再発を検出して調査する運用も必要になります。
すべての原因を一括で対象にするより、保護が何を防いでいるかを原因ごとに確認します。自動復旧を採用した理由、対象、間隔、再発時の連絡先まで残しておくと、次の担当が設定の意図を読めます。
connectedに戻ったら、再発と実際の通信を見る
connectedへ戻れば、リンクが成立した状態は確認できます。それでも、VLANや経路、FWの条件が違えば、目的のサービスは使えません。復旧した口の状態と、利用者が使いたい通信を続けて試します。
同じポートのログを追い、再停止や頻繁なリンク変化がないかも見ます。原因是正の結果を確かめるには、復旧前と後の時刻、対向機器、配線、状態を対応させる必要があります。
| 記録すること | 記入例 |
|---|---|
| 対象 | SW1 Gi1/0/10、対向機器と役割 |
| 原因と是正 | BPDU受信、想定外配線を是正 |
| 復旧操作 | 実施時刻、shutdown / no shutdown |
| 復旧後 | 状態、再発ログ、疎通、カウンター増分 |
記録は「復旧済み」だけより、「BPDU受信で停止。端末用ポートの想定外配線を是正し、手動復旧。再発ログと業務通信を確認」のように経過が分かる形にします。下の表は、その材料をそろえるための例です。
err-disabledで覚えておきたい順番は、状態を特定し、停止理由を読み、その原因を直してから戻すことです。復旧コマンドを知ることと、復旧してよい状態を判断することを、一緒に学んでいきましょう。
