ネットワークエンジニアになろう! > 四方山話 > ErrDisable - 不具合を検知したポートを閉塞する

この記事は、改訂&リニューアルして『P はプロトコルのP - ErrDisable - 不具合を検知したポートを閉塞する』へ移転しました。

ErrDisable - 不具合を検知したポートを閉塞する

Cisco のCatalyst は、不具合を検知したポートを、ErrDisable(エラーディセイブル) という状態にすることで、不具合箇所を局所化する機能を持っています。

ErrDisable となったポートは、shutdown (CatOS の場合はdisable) と同様の扱いとなります。

ポートをErrDisable にする条件(不具合の種類)は、機種やOS の種類(IOS/CatOS)、Version によって異なります。
以下に、代表的な条件をリストします。

UDLD (Unidirectional Link Detection)
BPDU-Guard (STP)
RootーGuard (STP)
Channel Config Mismatch
Link Flap
Loopback Detection
Broadcast Supression

どの条件がサポートされているか確認するには、次のshow コマンドを使います。

IOS
show errdisable detact cause

CatOS
show errdisable-timeout

ErrDisable は、不具合を回避するための措置であって、それ自体は不具合ではありません。
問題を解決するには、ポートをno shutdown (CatOS の場合はset port enable) とする前に、ErrDisable となった原因を追及する必要があります。

※IOS において、ErrDisable となったインターフェイスを復旧させるには、一度手動でshutdown をした上で、no shutdown する必要があります。

「shutdown と同等」と書きましたが、ErrDisable がshutdown と異なる点は、自動的に復旧させる手段があることです。

次のコマンドで秒数を設定すると、ErrDisable となったポートは、一定秒数が経過すると自動的に復旧します。

IOS
errdisable recovery interval

CatOS
set errdisable-timeout interval

IOS の場合、errdisable detect cause コマンドで、ErrDisable とする条件を、個別にenable/disable することができます。


Cisco.com (CCO) レビューについて

■ レビュー対象

CatOS プラットフォームでの errDisable ポート状態からの復旧 (ライター翻訳)


Recovering From errDisable Port State on the CatOS Platforms (英文)



ErrDisable となったポートを復旧せさせる方法を説明した技術資料です。
CatOS で動作しているCatalyst が対象となっています。

エラー ディセーブル状態になっているポートは、根本原因が検出されて解決される限り、それ自体がアラームの原因にはならないことを覚えておいてください。 エラー ディセーブル状態のポートは、解決する必要があるもっと深刻な問題があることを示しています。

ErrDisable 自体が不具合では無いことを説明しています。
ポートをErrDisable から復旧できたとしても、根本原因を取り除かない限り、問題は解決されません。

set option errport という新しいコマンドが CatOS に追加されました。このコマンドを使うと、このような特殊なコリジョン エラーが起きているポートの検出でスイッチが実行するアクションを管理者が決定できます。

CatOS version 6.x で確認したところ、set option errport コマンドはすでになくなっているようですので、本レビューでは触れません。

上記メッセージでは、errDisable またはエラー ディセーブル状態であることが明確には示されていません。しかし、これらのメッセージでは、スイッチによってポートがディセーブルにされたことが確かに示されています。

ErrDisable となった時に表示されるメッセージは、ErrDisable と明記してない場合があります。show interface status (IOS)、show port (CatOS) などのコマンドを使って確認する必要があります。

これらの状況を修正するには、根本にある問題に対処してからポートを再度イネーブルにする必要があります。 これは接続が正しくないポートであるため(PortFast がイネーブルで別のスイッチに接続されている)、PortFast 機能をオフにします。 繰り返しますが、PortFast は端末に接続されたポートでだけ使用することを想定しています。

この対策は根本的に間違っています。
BPDU-Guard は、Spanning Tree を理解する機器(= BPDU をしゃべる機器・・・スイッチやブリッジ)がそのポートの配下に存在することを禁止する機能で、PortFast を設定したポートでのみ使用可能です。

このポートがErrDisable となったのは、BPDU を受信したからです。
そもそも禁止していたことを行ったためにErrDisable となったわけですから(管理ポリシー違反)、ここですべき対策は、「ポリシーを変えること = PortFast を辞める」ではなく、BPDU を送信する機器を特定して取り除くことです。


あるスイッチを EtherChannel に設定して別のスイッチを EtherChannel に設定しないと、スパニング ツリー プロセスを引き起こして EtherChannel に設定した側のチャネル ポートをシャットダウンします。

Channel Config Mismatch 発生時の状況を説明しています。
Channel Config Mismatch については、以下のリンクで詳しく説明しています。

EtherChannel - 複数のリンクを束ねる


EtherChannel を ON モードにしても、チャネリングの前にもう一方のサイドとネゴシエートするための PAgP パケットは送信されません。

「ON モードにしても」ではなく「ON モードにすると」です。

Channel Config Mismatch の検出は、BPDU を利用して行います。
Spanning Tree をDisable にしているCatalyst では、Channel Config Mismatch が発生しても検出されず、ポートもErrDisable にはならない点に注意してください。


ネットワークエンジニアになろう!のトップページへ戻る
サイト内検索
無料メールマガジン「英語でネットワークエンジニア」
マニュアルやRFCを読むのに必要なのは、高度な文法知識ではなく語彙力です。毎回一単語、例文と解説に技術情報を併せてお届けします. (マガジンID:0000181633)
メールアドレス:
Powered by
This website is powered by Movable Type 3.2 Smartnetworks.jp.