システム管理構成ガイド、Cisco IOS XE Release 3E(Cisco WLC 5700 シリーズ)
ソフトウェア設定のトラブルシューティング
ソフトウェア設定のトラブルシューティング

目次

ソフトウェア設定のトラブルシューティング

この章では、スイッチが稼働する Cisco IOS ソフトウェアに関連する問題を特定し、解決する方法について説明します。 問題の性質に応じて、コマンドライン インターフェイス(CLI)、デバイス マネージャ、または Network Assistant を使用して、問題を特定し解決できます。

LED の説明など、トラブルシューティングの詳細については、ハードウェア インストレーション ガイドを参照してください。

ソフトウェア設定のトラブルシューティングに関する情報

スイッチのソフトウェア障害

スイッチ ソフトウェアが破損する状況としては、アップグレードを行った場合、スイッチに不適切なファイルをダウンロードした場合、イメージ ファイルを削除した場合などが考えられます。 いずれの場合にも、スイッチは電源投入時セルフテスト(POST)に失敗し、接続できなくなります。

Controllerのパスワードを紛失した、または忘れた場合

controllerのデフォルト設定では、controllerに物理的にアクセスしているエンド ユーザは、スイッチの電源投入中に起動プロセスを中断して新しいパスワードを入力することにより、パスワードを紛失した状態から回復できます。 ここで紹介する回復手順を実行するには、controllerに物理的にアクセスする必要があります


(注)  


これらのcontrollersではシステム管理者は、デフォルト設定に戻すことに同意した場合に限り、エンド ユーザによるパスワードのリセットを許可することによって、この機能の一部をディセーブルにできます。 パスワード回復がディセーブルになっている場合に、エンド ユーザがパスワードをリセットしようとすると、回復プロセス中にデフォルト設定に戻ることをリマインドするステータス メッセージが表示されます。


Power over Ethernet(PoE)ポート

Power over Ethernet(PoE)スイッチ ポートでは、回路に電力が供給されていないことをスイッチが検出した場合、接続している次のデバイスに電力が自動的に供給されます。

  • シスコ先行標準受電装置(Cisco IP Phone および Cisco Aironet アクセス ポイントなど)

  • IEEE 802.3af 準拠の受電装置

  • IEEE 802.3at 準拠の受電装置

受電装置が PoE スイッチ ポートおよび AC 電源に接続されている場合、冗長電力として利用できます。 受電装置が PoE ポートにだけ接続されている場合、受電装置には冗長電力は供給されません。

受電装置を検出すると、スイッチは受電装置の電力要件を判断し、受電装置への電力供給を許可または拒否します。 また、スイッチは消費電力をモニタリングおよびポリシングすることで、装置の電力消費をリアルタイムに検知できます。

詳細については、Interface Configuration Guide(Cisco WLC 5700 Series)の「PoE の設定」の章を参照してください。

電力消失によるポートの障害

PoE スイッチ ポートに接続され、AC 電源から電力が供給されている受電装置(Cisco IP Phone 7910 など)に AC 電源から電力が供給されない場合、そのデバイスは errdisable ステートになることがあります。 errdisable ステートから回復するには、shutdown インターフェイス コンフィギュレーション コマンドを入力してから、no shutdown インターフェイス コマンドを入力します。 スイッチで自動回復を設定し、errdisable ステートから回復することもできます。

スイッチの場合、errdisable recovery cause loopback および errdisable recovery interval seconds グローバル コンフィギュレーション コマンドは、指定した期間が経過したあと自動的にインターフェイスを errdisable ステートから復帰させます。

偽のリンク アップによりポートが使用不可になる

シスコ受電装置をポートに接続し、power inline never インターフェイス コンフィギュレーション コマンドを使用してポートを設定した場合は、不正リンク アップが発生し、ポートが errdisable ステートになることがあります。 ポートを errdisable ステートから修正するには、shutdown および no shutdown インターフェイス コンフィギュレーション コマンドを入力します。

power inline never コマンドで設定したポートにシスコ受電装置を接続しないでください。

ping

スイッチは IP の ping をサポートしており、これを使ってリモート ホストへの接続をテストできます。 ping はアドレスにエコー要求パケットを送信し、応答を待ちます。 ping は次のいずれかの応答を返します。

  • 正常な応答:正常な応答(hostname が存在する)は、ネットワーク トラフィックにもよりますが、1 ~ 10 秒以内で発生します。

  • 宛先の応答なし:ホストが応答しない場合、no-answer メッセージが返ってきます。

  • ホスト不明:ホストが存在しない場合、unknown host メッセージが返ってきます。

  • 宛先に到達不能:デフォルト ゲートウェイが指定されたネットワークに到達できない場合、destination-unreachable メッセージが返ってきます。

  • ネットワークまたはホストに到達不能:ルート テーブルにホストまたはネットワークに関するエントリがない場合、network or host unreachable メッセージが返ってきます。

関連タスク

レイヤ 2 の traceroute

レイヤ 2 traceroute 機能により、パケットが通過する、送信元デバイスから宛先デバイスへの物理パスを識別できます。 レイヤ 2 Traceroute は、ユニキャストの送信元および宛先 MAC アドレスだけをサポートします。 パス内にあるスイッチの MAC アドレス テーブルを使用してパスを識別します。 スイッチがレイヤ 2 traceroute をサポートしないデバイスをパスで検出すると、スイッチはレイヤ 2 トレース キューを送信し続けてタイムアウトにしてしまいます。

スイッチは、送信元デバイスから宛先デバイスへのパスのみを識別できます。 パケットが通過する、送信元ホストから送信元デバイスまで、または宛先デバイスから宛先ホストまでのパスは識別できません。

レイヤ 2 の traceroute のガイドライン

  • Cisco Discovery Protocol(CDP)がネットワーク上のすべてのデバイスでイネーブルでなければなりません。 レイヤ 2 traceroute が適切に動作するために、CDP をディセーブルにしないでください。

    物理パス内のデバイスが CDP に対して透過的な場合、スイッチはこれらのデバイスを通過するパスを識別できません。

  • スイッチは、ping 特権 EXEC コマンドを使用して接続をテストする場合に他のスイッチから到達できます。 物理パス内のすべてのスイッチは、他のスイッチから到達可能でなければなりません。

  • パス内で識別可能な最大ホップ数は 10 です。

  • 送信元デバイスから宛先デバイスの物理パス内にないスイッチに、traceroute mac または traceroute mac ip 特権 EXEC コマンドを実行できます。 パス内のすべてのスイッチは、このスイッチから到達可能でなければなりません。

  • 指定した送信元および宛先 MAC アドレスが同一 VLAN に属する場合、traceroute mac コマンド出力はレイヤ 2 パスのみを表示します。 指定した送信元および宛先 MAC アドレスが、それぞれ異なる VLAN に属している場合は、レイヤ 2 パスは識別されず、エラー メッセージが表示されます。

  • マルチキャスト送信元または宛先 MAC アドレスを指定すると、パスは識別されず、エラー メッセージが表示されます。

  • 送信元または宛先 MAC アドレスが複数の VLAN に属する場合は、送信元および宛先 MAC アドレスの両方が属している VLAN を指定する必要があります。 VLAN を指定しないと、パスは識別されず、エラー メッセージが表示されます。

  • 指定した送信元および宛先 MAC アドレスが同一サブネットに属する場合、traceroute mac ip コマンド出力はレイヤ 2 パスを表示します。 IP アドレスを指定する場合、スイッチはアドレス解決プロトコル(ARP)を使用して、IP アドレスを対応する MAC アドレスおよび VLAN ID に関連付けます。
    • 指定の IP アドレスの ARP のエントリが存在している場合、スイッチは関連付けられた MAC アドレスを使用し、物理パスを識別します。

    • ARP のエントリが存在しない場合、スイッチは ARP クエリーを送信し、IP アドレスを解決しようと試みます。 IP アドレスが解決されない場合は、パスは識別されず、エラー メッセージが表示されます。

  • 複数のデバイスがハブを介して 1 つのポートに接続されている場合(たとえば複数の CDP ネイバーがポートで検出された場合)、レイヤ 2 traceroute 機能はサポートされません。 複数の CDP ネイバーが 1 つのポートで検出された場合、レイヤ 2 パスは特定されず、エラー メッセージが表示されます。

  • この機能は、トークン リング VLAN ではサポートされません。

IP Traceroute

IP traceroute を使用すると、ネットワーク上でパケットが通過するパスをホップバイホップで識別できます。 このコマンドを実行すると、トラフィックが宛先に到達するまでに通過するルータなどのすべてのネットワーク層(レイヤ 3)デバイスが表示されます。

スイッチは、traceroute 特権 EXEC コマンドの送信元または宛先として指定できます。また、スイッチは traceroute コマンドの出力でホップとして表示される場合があります。 スイッチを traceroute の宛先とすると、スイッチは、traceroute の出力で最終の宛先として表示されます。 中間スイッチが同じ VLAN 内でポート間のパケットのブリッジングだけを行う場合、traceroute の出力に中間スイッチは表示されません。 ただし、中間スイッチが、特定のパケットをルーティングするマルチレイヤ スイッチの場合、中間スイッチは traceroute の出力にホップとして表示されます。

traceroute 特権 EXEC コマンドは、IP ヘッダーの存続可能時間(TTL)フィールドを使用して、ルータおよびサーバで特定のリターン メッセージが生成されるようにします。 traceroute の実行は、ユーザ データグラム プロトコル(UDP)データグラムを、TTL フィールドが 1 に設定されている宛先ホストへ送信することから始まります。 ルータで TTL 値が 1 または 0 であることを検出すると、データグラムをドロップし、インターネット制御メッセージ プロトコル(ICMP)time-to-live-exceeded メッセージを送信元に送信します。 traceroute は、ICMP time-to-live-exceeded メッセージの発信元アドレス フィールドを調べて、最初のホップのアドレスを判別します。

ネクスト ホップを識別するために、traceroute は TTL 値が 2 の UDP パケットを送信します。 1 番めのルータは、TTL フィールドの値から 1 を差し引いて次のルータにデータグラムを送信します。 2 番めのルータは、TTL 値が 1 であることを確認すると、このデータグラムを廃棄し、time-to-live-exceeded メッセージを送信元へ返します。 このように、データグラムが宛先ホストに到達するまで(または TTL の最大値に達するまで)TTL の値は増分され、処理が続けられます。

データグラムが宛先に到達したことを学習するために、traceroute は、データグラムの UDP 宛て先ポート番号を、宛先ホストが使用する可能性のない大きな値に設定します。 ホストが、ローカルで使用されない宛て先ポート番号を持つ自分自身宛てのデータグラムを受信すると、送信元に ICMP ポート到達不能エラーを送信します。 ポート到達不能エラーを除くすべてのエラーは中間ホップから送信されるため、ポート到達不能エラーを受信するということは、このメッセージが宛て先ポートから送信されたことを意味します。

関連タスク

Time Domain Reflector ガイドライン

Time Domain Reflector(TDR)機能を使用すると、ケーブル配線の問題を診断して解決できます。 TDR 稼働時、ローカル デバイスはケーブルを介して信号を送信して、最初に送信した信号と反射された信号を比べます。

TDR は 10/100/1000 の銅線イーサネット ポート上でだけサポートされます。 10 ギガビット イーサネット ポートまたは SFP モジュール ポートではサポートされません。

TDR は次のケーブル障害を検出します。

  • ツイストペア ケーブルの導線のオープン、損傷、切断:導線がリモート デバイスからの導線に接続されていない状態。

  • ツイストペア ケーブルの導線のショート:導線が互いに接触している状態、またはリモート デバイスからの導線に接触している状態。 たとえば、ツイスト ペア ケーブルの一方の導線が、もう一方の導線にはんだ付けされている場合、ツイストペア ケーブルのショートが発生します。

ツイストペアの導線の一方がオープンになっている場合、TDR はオープンになっている導線の長さを検出できます。

次の状況で TDR を使用して、ケーブル障害を診断および解決してください。

  • スイッチの交換

  • 配線クローゼットの設定

  • リンクが確立できない、または適切に動作していない場合における、2 つのデバイス間の接続のトラブルシューティング

TDR の実行時、次の場合にスイッチは正確な情報をレポートします。

  • ギガビット リンク用のケーブルが単線コア ケーブル

  • オープンエンド ケーブルが未終端

TDR の実行時、次の場合にスイッチは正確な情報をレポートしません。

  • ギガビット リンク用のケーブルがツイストペア ケーブルまたは連続接続された単線コア ケーブル

  • リンクが 10 Mb または 100 Mb

  • より線ケーブル

  • リンク パートナーが Cisco IP Phone

  • リンク パートナーが IEEE 802.3 に準拠していない

debug コマンド


注意    


デバッグ出力は CPU プロセスで高プライオリティが割り当てられているため、デバッグ出力を行うとシステムが使用できなくなることがあります。 したがって、debug コマンドを使用するのは、特定の問題のトラブルシューティング時、またはシスコのテクニカル サポート担当者とともにトラブルシューティングを行う場合に限定してください。 ネットワーク トラフィック量やユーザ数が少ない期間に debug コマンドを使用することをお勧めします。 デバッギングをこのような時間帯に行うと、debug コマンド処理のオーバーヘッドの増加によりシステムの使用に影響が及ぶ可能性が少なくなります。


debug コマンドはすべて特権 EXEC モードで実行します。ほとんどの debug コマンドは引数を取りません。

Crashinfo ファイル

crashinfo ファイルには、シスコのテクニカル サポート担当者が Cisco IOS イメージの障害(クラッシュ)が原因で起きた問題をデバッグするときに使用する情報が保存されています。 スイッチは障害発生時に 2 個のファイル(fullcore および crashinfo)を生成します。

この crashinfo ファイルに保存される情報は、障害が発生した Cisco IOS イメージの名前、バージョン、プロセッサ レジスタのリスト、およびスタック トレースです。 show tech-support 特権 EXEC コマンドを使用することによって、この情報をシスコのテクニカル サポート担当者に提供できます。

ファイル名は次の形式になります。
 [fullcore | crashinfo]_[process that crashed]_[date]-[timestamp]-UTC
IOS から、次のコマンドを使用して、各スイッチの crashinfo ファイルを確認できます。

Controller#  dir crashinfo?
crashinfo-1: crashinfo-2: crashinfo-3: crashinfo:
Controller#

たとえば、スイッチ 1 の crashinfo ディレクトリにアクセスするには、次のように入力します。
Controller dir crashinfo-1
ROMMON プロンプトで、dir コマンドを使用して crashinfo ファイルを確認できます。
Controller: dir sda1
次は crashinfo ファイルの出力例を示します。

Controller# dir crashinfo:

Directory of crashinfo:/

   12  -rwx        2768  Dec 31 1969 16:00:15 -08:00  koops.dat
   15  -rwx           0  Jan 12 2000 22:53:40 -08:00  deleted_crash_files
   16  -rwx     4246576  Jan 12 2000 22:53:40 -08:00  crashinfo_stack-mgr_20000113-065250-UTC
   17  -rwx          50   Oct 2 2012 03:18:42 -08:00  last_crashinfo
   26  -rwx          39  Jan 22 2013 14:14:14 -08:00  last_systemreport
   18  -rwx     2866565  Jan 12 2000 22:53:41 -08:00  fullcore_stack-mgr_20000113-065250-UTC
   20  -rwx     4391796   Feb 1 2000 17:50:44 -08:00  crashinfo_stack-mgr_20000202-014954-UTC
   21  -rwx     2920325   Feb 1 2000 17:50:45 -08:00  fullcore_stack-mgr_20000202-014954-UTC
34817  -rw-     1050209  Jan 10 2013 20:26:23 -08:00  system-report_1_20130111-042535-UTC.gz
18434  -rw-     1016913  Jan 11 2013 10:35:28 -08:00  system-report_1_20130111-183440-UTC.gz
18435  -rw-     1136167  Jan 22 2013 14:14:11 -08:00  system-report_1_20130122-221322-UTC.gz
34821  -rw-     1094631   Jan 2 2013 17:59:23 -08:00  system-report_1_20130103-015835-UTC.gz
 6147  -rw-      967429   Jan 3 2013 10:32:44 -08:00  system-report_1_20130103-183156-UTC.gz
34824  -rwx          50  Jan 22 2013 14:14:14 -08:00  deleted_sysreport_files
6155  -rwx         373  Jan 22 2013 14:14:13 -08:00  last_systemreport_log

145898496 bytes total (18569216 bytes free)
stack3#

The file name of the most recent crashinfo file is stored in last_crashinfo.
The file name of the most recent system report is stored in last_systemreport.

 
Controller#  
 

システム レポート

コントローラのクラッシュが発生すると、スイッチ スタックの各スイッチについて、システム レポートが自動的に生成されます。 システム レポート ファイルは、すべてのトレース バッファ、およびスイッチ上にあるその他のシステム全体のログをキャプチャします。 システム レポートは、次の形式で crashinfo ディレクトリにあります。
system-report_[switch number]_[date]-[timestamp]-UTC.gz

スイッチのクラッシュの後には、システム レポート ファイルが生成されているかどうか確認する必要があります。 最後に生成されたシステム レポート ファイルは crashinfo ディレクトリの下に last_systemreport というファイル名で保存されます。 問題のトラブルシューティングを行う場合には、システム レポートおよび crashinfo ファイルが TAC の役に立ちます。

スイッチのオンボード障害ロギング

オンボード障害ロギング(OBFL)機能を使用すれば、スイッチに関する情報を収集できます。 この情報には稼働時間、温度、電圧などの情報が含まれており、シスコのテクニカル サポート担当者がスイッチの問題をトラブルシューティングする際に役立ちます。 OBFL はイネーブルにしておき、フラッシュ メモリに保存されたデータは消さないようにすることを推奨します。

OBFL は、デフォルトでイネーブルになっています。 スイッチおよび Small Form-Factor Pluggable(SFP)モジュールに関する情報が収集されます。 スイッチは、次の情報をフラッシュ メモリに保存します。

  • CLI コマンド:スタンドアロン スイッチまたはスイッチ スタック メンバに入力された OBFL CLI コマンドの記録。

  • 環境データ:スタンドアロン スイッチまたはスタックメンバおよび接続されているすべての FRU デバイスの Unique Device Identifier(UDI)情報、製品 ID(PID)、バージョン ID(VID)、およびシリアル番号。

  • メッセージ:スタンドアロン スイッチまたはスタック メンバにより生成されたハードウェア関連のシステム メッセージの記録。

  • Power over Ethernet(PoE):スタンドアロン スイッチまたはスタック メンバの PoE ポートの電力消費の記録。

  • 温度:スタンドアロン スイッチまたはスタック メンバの温度。

  • 稼働時間:スタンドアロン スイッチまたはスタック メンバが起動されたときの時刻、スイッチが再起動された理由、およびスイッチが最後に再起動されて以来の稼働時間。

  • 電圧:スタンドアロン スイッチまたはスタック メンバのシステム電圧。

システム時計は、手動で時刻を設定するか、またはネットワーク タイム プロトコル(NTP)を使用するように設定します。

スイッチの稼働中には、show logging onboard 特権 EXEC コマンドを使用することにより、OBFL データを取得できます。 スイッチに障害が発生した場合のデータの取得方法については、お客様担当のシスコ テクニカル サポート担当者にお問い合わせください。

OBFL がイネーブルになっているスイッチが再起動された場合、新しいデータの記録が開始するまでに 10 分間の遅延があります。

関連タスク
関連資料

ファン障害

デフォルトでは、この機能はディセーブルです。 現場交換可能ユニット(FRU)または電源装置の複数のファンが故障した場合、スイッチはシャットダウンせず、次のようなエラー メッセージが表示されます。

Multiple fan(FRU/PS) failure detected. System may get overheated. Change fan quickly.

スイッチが過熱状態となり、シャットダウンすることもあります。

ファン障害管理機能をイネーブルにするには、system env fan-fail-action shut 特権 EXEC コマンドを入力します。 スイッチ内の複数のファンに障害が発生した場合、スイッチは自動的にシャットダウンし、次のようなエラー メッセージが表示されます。

Faulty (FRU/PS) fans detected, shutting down system! 

最初のファンの停止後、スイッチが 2 つめのファンの障害を検知した場合、スイッチは 20 秒待機してからシャットダウンします。

スイッチを再起動するには、電源をオフにしてから再度オンにする必要があります。

CPU 使用率が高い場合に起こりうる症状

CPU 使用率が高すぎることで次の症状が発生する可能性がありますが、他の原因で発生する場合もあります。

  • スパニングツリー トポロジの変更

  • 通信が切断されたために EtherChannel リンクがダウンした

  • 管理要求(ICMP ping、SNMP のタイムアウト、低速な Telnet または SSH セッション)に応答できない

  • UDLD フラッピング

  • SLA の応答が許容可能なしきい値を超えたことによる IP SLA の失敗

  • スイッチが要求を転送しない、または要求に応答しない場合の DHCP または IEEE 802.1x の処理の失敗

ソフトウェア設定のトラブルシューティング方法

ソフトウェアで障害が発生した場合の回復

はじめる前に

ここで紹介する回復手順を実行するには、スイッチを直接操作する必要があります。

ここで紹介する手順では、破損したイメージ ファイルまたは不適切なイメージ ファイルの回復に boot loader コマンドおよび TFTP を使用します。


    ステップ 1   PC 上で、Cisco.com からソフトウェア イメージ ファイル(image.bin)をダウンロードします。
    ステップ 2   TFTP サーバにソフトウェア イメージをロードします。
    ステップ 3   PC をスイッチのイーサネット管理ポートに接続します。
    ステップ 4   スイッチの電源コードを外します。
    ステップ 5   Mode ボタンを押しながら、電源コードをスイッチに再接続します。
    ステップ 6   ブートローダ(ROMMON)プロンプトで、TFTP サーバに ping を実行できることを確認します。
    1. 次のコマンドを実行して、IP アドレス を設定します。switch: set IP_ADDR ip_address subnet_mask

      例:
      switch: set IP_ADDR 192.0.2.123/255.255.255.0
      
      
    2. 次のコマンドを実行して、デフォルト ルータの IP アドレスを設定します。 switch: set DEFAULT_ROUTER ip_address

      例:
      switch: set DEFAULT_ROUTER 192.0.2.1
      
      
    3. 次のコマンドを実行して、TFTP サーバに ping を実行できることを確認します。 switch: ping ip_address_of_TFTP_server


    例:
    switch: ping 192.0.2.15 
    ping 192.0.2.1 with 32 bytes of data...
    Host 192.0.2.1 is alive.
    switch:
    
    
    ステップ 7   リカバリ パーティション(sda9:)に回復イメージが存在することを確認します。

    この回復イメージは、emergency-install 機能を使用して回復を実施する場合に必要となります。



    例:
    switch: dir sda9:
    Directory of sda9:/
    
        2  drwx  1024       .
        2  drwx  1024       ..
       11  -rw-  18923068   c3850-recovery.bin
    
    36939776 bytes available (20830208 bytes used)
    switch:
    
    
    ステップ 8   ブートローダ(ROMMON)プロンプトで、emergency-install 機能を開始します。この機能を使用すると、スイッチでソフトウェア イメージを容易に回復できます。

    警告:emergency-install コマンドを実行すると、ブート ブラッシュ全体が消去されます。



    例:

    パスワードを忘れた場合の回復

    スイッチのデフォルト設定では、スイッチを直接操作するエンド ユーザが、スイッチの電源投入時に起動プロセスを中断して新しいパスワードを入力することにより、パスワードを紛失した状態から回復できます。 ここで紹介する回復手順を実行するには、スイッチを直接操作してください。


    (注)  


    これらのスイッチでは、システム管理者はデフォルト設定に戻す場合に限りエンド ユーザによるパスワードのリセットを許可することによって、この機能の一部をディセーブルにできます。 パスワード回復がディセーブルになっている場合に、エンド ユーザがパスワードをリセットしようとすると、回復プロセスの間、ステータス メッセージにその旨が表示されます。


    手順の概要

      1.    端末または PC をスイッチに接続します。

      2.    エミュレーション ソフトウェアの回線速度を 9600 ボーに設定します。

      3.    スタンドアロン スイッチまたはスイッチ スタック全体の電源を切断します。

      4.    またはに電源コードを再接続します。 15 秒以内に Mode ボタンを押します。このときシステム LED はグリーンに点滅しています。 すべてのシステム LED が点灯した状態になるまで、MODE ボタンを押し続けます。その後、MODE ボタンを放します。

      5.    パスワードの回復後、スイッチまたはをリロードします。

      6.    スタック内の残りのスイッチに電源を投入します。


    手順の詳細
      ステップ 1   端末または PC をスイッチに接続します。
      • 端末または端末エミュレーション ソフトウェアが稼働している PC をスイッチのコンソール ポートに接続します。 スイッチ スタックのパスワードを回復する場合は、またはのコンソール ポートに接続します。

      • PC をイーサネット管理ポートに接続します。 スイッチ スタックのパスワードを回復する場合は、スタック メンバのイーサネット管理ポートに接続します。

      ステップ 2   エミュレーション ソフトウェアの回線速度を 9600 ボーに設定します。
      ステップ 3   スタンドアロン スイッチまたはスイッチ スタック全体の電源を切断します。
      ステップ 4   またはに電源コードを再接続します。 15 秒以内に Mode ボタンを押します。このときシステム LED はグリーンに点滅しています。 すべてのシステム LED が点灯した状態になるまで、MODE ボタンを押し続けます。その後、MODE ボタンを放します。
      • 
        Switch:
        Xmodem file system is available.
        Base ethernet MAC Address: 20:37:06:4d:e9:80
        Verifying bootloader digital signature.
        
        
        The system has been interrupted prior to loading the operating
        system software, console will be reset to 9600 baud rate.
        
        
        

        パスワード回復がイネーブルになっている場合の手順」セクションに記載されている手順を実行します。

      ステップ 5   パスワードの回復後、スイッチまたはをリロードします。

      スイッチ

      Switch> reload
      Proceed with reload? [confirm] y
      
      

      アクティブ スイッチの場合

      Switch> reload slot <stack-active-member-number>
      Proceed with reload? [confirm] y
      
      
      ステップ 6   スタック内の残りのスイッチに電源を投入します。

      パスワード回復がイネーブルになっている場合の手順

      パスワード回復操作がイネーブルになっている場合は、次のメッセージが表示されます。


        ステップ 1   次のコマンドでスタートアップ コンフィギュレーションを無視します。
        Controller: SWITCH_IGNORE_STARTUP_CFG=1
        
        
        ステップ 2   フラッシュからの packages.conf ファイルのスイッチを起動します。
        Controller: boot flash:packages.conf
        
        
        ステップ 3   No と応答して初期設定ダイアログを終了します。
        Would you like to enter the initial configuration dialog? [yes/no]: No
        
        
        ステップ 4   スイッチ プロンプトで、特権 EXEC モードを開始します。
        Controller> enable      
        Switch#  
        
        
        ステップ 5   スタートアップ コンフィギュレーションを実行コンフィギュレーションにコピーします。
        Controller# copy startup-config running-config Destination filename [running-config]?
        
        

        確認を求めるプロンプトに、Return を押して応答します。 これで、コンフィギュレーション ファイルがリロードされ、パスワードを変更できます。

        ステップ 6   グローバル コンフィギュレーション モードを開始して、イネーブル パスワードを変更する。
        Controller# configure terminal
        Controller(config)# 
        
        
        ステップ 7   実行コンフィギュレーションをスタートアップ コンフィギュレーション ファイルに書き込みます。
        Controller# copy running-config startup-config     
        
        
        ステップ 8   手動ブート モードがイネーブルになっていることを確認します。
        Controller# show boot
         
         BOOT variable = flash:packages.conf;
         Manual Boot = yes
         Enable Break = yes
        
        
        ステップ 9   controllerをリロードします。
        Controller# reload
        
        
        ステップ 10   (ステップ 2 と 3 で変更した)ブートローダ パラメータを元の値に戻します。
          
        Controller: switch: SWITCH_IGNORE_STARTUP_CFG=0
        
        
        ステップ 11   フラッシュからの packages.conf ファイルのcontrollerを起動します。
        Controller: boot flash:packages.conf
        
        
        ステップ 12   controllerのブート後に、controller手動ブートをディセーブルにします。
        Controller(config)# no boot manual
        
        

        パスワード回復がディセーブルになっている場合の手順

        パスワード回復メカニズムがディセーブルの場合、次のメッセージが表示されます。

        The password-recovery mechanism has been triggered, but
        is currently disabled.  Access to the boot loader prompt
        through the password-recovery mechanism is disallowed at
        this point.  However, if you agree to let the system be
        reset back to the default system configuration, access
        to the boot loader prompt can still be allowed.
        
        Would you like to reset the system back to the default configuration (y/n)?
        
        

        注意    


        スイッチをデフォルト設定に戻すと、既存の設定がすべて失われます。 システム管理者に問い合わせて、バックアップ スイッチと VLAN(仮想 LAN)コンフィギュレーション ファイルがあるかどうかを確認してください。


        • n(no)を入力すると、Mode ボタンを押さなかった場合と同様に、通常の起動プロセスが継続されます。ブート ローダ プロンプトにはアクセスできません。したがって、新しいパスワードを入力できません。 次のメッセージが表示されます。

          Press Enter to continue........
          
          
        • y(yes)を入力すると、フラッシュ メモリ内のコンフィギュレーション ファイルおよび VLAN データベース ファイルが削除されます。 デフォルト設定がロードされるときに、パスワードをリセットできます。


          ステップ 1   パスワード回復手順の継続を選択すると、既存の設定が失われます。
          Would you like to reset the system back to the default configuration (y/n)? Y 
          
          
          ステップ 2   フラッシュ メモリの内容を表示します。
          Controller: dir flash:
          
          
          

          スイッチのファイル システムが表示されます。

          ステップ 3   システムを起動します。
          Controller: boot
          
          

          セットアップ プログラムを起動するように求められます。 パスワード回復手順を継続するには、プロンプトに N を入力します。

          Continue with the configuration dialog? [yes/no]: N
          
          
          ステップ 4   スイッチ プロンプトで、特権 EXEC モードを開始します。
          Controller> enable
          
          
          ステップ 5   グローバル コンフィギュレーション モードを開始します。
          Controller# configure terminal
          
          
          ステップ 6   パスワードを変更します。
          Controller(config)# enable secret password
          
          

          シークレット パスワードは 1 ~ 25 文字の英数字です。数字で始めることができます。大文字と小文字が区別され、スペースを使用できますが、先行スペースは無視されます。

          ステップ 7   特権 EXEC モードに戻ります。
          Controller(config)# exit
          Controller# 
          
          
          (注)     

          ステップ 9 に進む前に、接続されているすべてのスタック メンバの電源を入れ、それらが完全に初期化されるまで待ちます。

          ステップ 8   実行コンフィギュレーションをスタートアップ コンフィギュレーション ファイルに書き込みます。
          Controller# copy running-config startup-config
          
          

          新しいパスワードがスタートアップ コンフィギュレーションに組み込まれました。

          ステップ 9   ここでスイッチを再設定する必要があります。 システム管理者によって、バックアップ スイッチと VLAN コンフィギュレーション ファイルが使用可能に設定されている場合は、これらを使用します。

          スイッチ スタックの問題の防止

          スイッチ スタックの問題を回避するには、次を実行する必要があります。
          • スイッチ スタックにスイッチを追加したりそこから取り外したりする場合には、必ずスイッチの電源を切ってください。 スイッチ スタックでの電源関連のあらゆる考慮事項については、ハードウェア インストレーション ガイドの「Switch Installation(スイッチのインストール)」の章を参照してください。
          • スタック モード LED が点灯するまで、スタック メンバの Mode ボタンを押します。 スイッチの最後の 2 つのポート LED がグリーンになります。 スイッチ モデルに応じて、最後の 2 つのポートは 10/100/1000 ポートまたは Small Form-Factor Pluggable(SFP)モジュールになります。 最後の 2 つのポート LED の片方または両方がグリーンになっていない場合は、スタックが全帯域幅で稼働していません。
          • スイッチ スタックを管理する場合は、1 つの CLI セッションだけを使用することを推奨します。 に複数の CLI セッションを使用する場合は注意が必要です。 1 つのセッションで入力したコマンドは、別のセッションには表示されません。 そのため、コマンドを入力したセッションを識別できなくなることがあります。
          • スタック内での位置に従ってスタック メンバ番号を手動で割り当てると、リモートから行うスイッチ スタックのトラブルシューティングが容易になります。 ただし、後からスイッチを追加したり、削除したり、場所を入れ替えたりする際に、スイッチに手動で番号を割り当てたことを覚えておく必要があります。 スタック メンバ番号を手動で割り当てるには、switch current-stack-member-number renumber new-stack-member-number グローバル コンフィギュレーション コマンドを使用します。

          スタック メンバをまったく同じモデルで置き換えると、新しいスイッチは、置き換えられたスイッチとまったく同じ設定で稼働します。 この場合、新しいスイッチは置き換えられたスイッチと同じメンバ番号を使用するものと想定されます。

          電源が入った状態のスタック メンバを取り外すと、スイッチ スタックが、それぞれ同じ設定を持つ 2 つ以上のスイッチ スタックに分割(パーティション化)されます。 スイッチ スタックを分離されたままにしておきたい場合は、新しく作成されたスイッチ スタックの IP アドレス(複数の場合あり)を変更してください。 パーティション化されたスイッチ スタックを回復するには、次の手順に従います。

          1. 新しく作成されたスイッチ スタックの電源を切ります。

          2. 新しいスイッチ スタックを、StackWise Plus ポートを介して元のスイッチ スタックに再度接続します。

          3. スイッチの電源を入れます。

          自動ネゴシエーションの不一致の防止

          IEEE 802.3ab 自動ネゴシエーション プロトコルは速度(10 Mbps、100 Mbps、および SFP モジュール ポート以外の 1000 Mbps)およびデュプレックス(半二重または全二重)に関するスイッチの設定を管理します。 このプロトコルは設定を適切に調整しないことがあり、その場合はパフォーマンスが低下します。 不一致は次の条件で発生します。

          • 手動で設定した速度またはデュプレックスのパラメータが、接続ポート上で手動で設定された速度またはデュプレックスのパラメータと異なっている場合。

          • ポートを自動ネゴシエーションに設定したが、接続先ポートは自動ネゴシエーションを使用しない全二重に設定されている場合。

          スイッチのパフォーマンスを最大限に引き出してリンクを確保するには、次のいずれかの注意事項に従って、デュプレックスおよび速度の設定を変更してください。

          • 速度とデュプレックスの両方について、両方のポートで自動ネゴシエーションを実行させます。

          • 接続の両側でポートの速度とデュプレックスのパラメータを手動で設定します。


          (注)  


          接続先装置が自動ネゴシエーションを実行しない場合は、2 つのポートのデュプレックス設定を一致させます。 速度パラメータは、接続先のポートが自動ネゴシエーションを実行しない場合でも自動調整が可能です。


          SFP モジュールのセキュリティと識別に関するトラブルシューティング

          シスコの Small Form-Factor Pluggable(SFP)モジュールは、モジュールのシリアル番号、ベンダー名とベンダー ID、一意のセキュリティ コード、および巡回冗長検査(CRC)が格納されたシリアル EEPROM(電気的に消去可能でプログラミング可能な ROM)を備えています。 スイッチに SFP モジュールを装着すると、スイッチ ソフトウェアは、EEPROM を読み取ってシリアル番号、ベンダー名、およびベンダー ID を確認し、セキュリティ コードおよび CRC を再計算します。 シリアル番号、ベンダー名、ベンダー ID、セキュリティ コード、または CRC が無効な場合、ソフトウェアは、セキュリティ エラー メッセージを生成し、インターフェイスを errdisable ステートにします。


          (注)  


          セキュリティ エラー メッセージは、GBIC_SECURITY 機能を参照します。 スイッチは、SFP モジュールをサポートしていますが、GBIC(ギガビット インターフェイス コンバータ)モジュールはサポートしていません。 エラー メッセージ テキストは、GBIC インターフェイスおよびモジュールを参照しますが、セキュリティ メッセージは、実際は SFP モジュールおよびモジュール インターフェイスを参照します。


          他社の SFP モジュールを使用している場合、スイッチから SFP モジュールを取り外し、シスコのモジュールに交換します。 シスコの SFP モジュールを装着したら、errdisable recovery cause gbic-invalid グローバル コンフィギュレーション コマンドを使用してポート ステータスを確認し、errdisable ステートから回復する時間間隔を入力します。 この時間間隔が経過すると、スイッチは errdisable ステートからインターフェイスを復帰させ、操作を再試行します。

          モジュールがシスコ製 SFP モジュールとして識別されたにもかかわらず、システムがベンダー データ情報を読み取ってその情報が正確かどうかを確認できないと、SFP モジュール エラー メッセージが生成されます。 この場合、SFP モジュールを取り外して再び装着してください。 それでも障害が発生する場合は、SFP モジュールが不良品である可能性があります。

          SFP モジュール ステータスのモニタリング

          show interfaces transceiver 特権 EXEC コマンドを使用すると、SFP モジュールの物理または動作ステータスを確認できます。 このコマンドは、温度や特定のインターフェイス上の SFP モジュールの現状などの動作ステータスと、アラーム ステータスを表示します。 また、このコマンドを使用して SFP モジュールの速度およびデュプレックス設定も確認できます。

          ping の実行

          別の IP サブネットワーク内のホストに ping を実行する場合は、ネットワークへのスタティック ルートを定義するか、またはこれらのサブネット間でルーティングされるように IP ルーティングを設定する必要があります。

          IP ルーティングは、デフォルトではすべてのスイッチでディセーブルになります。


          (注)  


          ping コマンドでは、他のプロトコル キーワードも使用可能ですが、このリリースではサポートされていません。


          このコマンドは、スイッチからネットワーク上の他のデバイスに ping を実行する目的で使用します。

          コマンド

          目的

          ping ip host | address

          Controller# ping 172.20.52.3
          
          

          IP またはホスト名やネットワーク アドレスを指定してリモート ホストに ping を実行します。

          関連コンセプト

          温度のモニタ

          スイッチは温度条件をモニタし、温度情報を使用してファンを制御します。

          温度の値、状態、しきい値を表示するには、show env temperature status 特権 EXEC コマンドを使用します。 温度の値は、スイッチ内の温度であり、外部の温度ではありません。system env temperature threshold yellow value グローバル コンフィギュレーション コマンドを使用して、黄色のしきい値レベル(摂氏)のみを設定し、黄色のしきい値および赤のしきい値の差を設定できます。 グリーンまたはレッドのしきい値は設定できません。

          物理パスのモニタリング

          次のいずれかの特権 EXEC コマンドを使用して、パケットが通過する、送信元デバイスから宛先デバイスへの物理パスをモニタできます。

          表 1 物理パスのモニタリング
          コマンド 目的

          tracetroute mac [interface interface-id] {source-mac-address} [interface interface-id] {destination-mac-address} [vlan vlan-id] [detail]

          指定の送信元 MAC アドレスから、指定の宛先 MAC アドレスまでをパケットが通過するレイヤ 2 パスを表示します。

          tracetroute mac ip {source-ip-address | source-hostname}{destination-ip-address | destination-hostname} [detail]

          指定の送信元 IP アドレスまたはホスト名から、指定の宛先 IP アドレスまたはホスト名を通過するパケットのレイヤ 2 パスを表示します。

          IP traceroute の実行


          (注)  


          traceroute 特権 EXEC コマンドでは、他のプロトコル キーワードも使用可能ですが、このリリースではサポートされていません。


          コマンド

          目的

          traceroute ip host

          Controller# traceroute ip 192.51.100.1
          
          

          ネットワーク上でパケットが通過するパスを追跡します。

          関連コンセプト

          TDR の実行および結果の表示

          TDR を実行する場合、test cable-diagnostics tdr interface interface-id 特権 EXEC コマンドを実行します。

          TDR の結果を表示するには、show cable-diagnostics tdr interface interface-id 特権 EXEC コマンドを実行します。

          デバッグおよびエラー メッセージ出力のリダイレクト

          ネットワーク サーバはデフォルトで、debug コマンドおよびシステム エラー メッセージの出力をコンソールに送信します。 このデフォルトの設定を使用する場合は、コンソール ポートまたはイーサネット管理ポートに接続する代わりに、仮想端末接続によってデバッグ出力をモニタできます。

          指定できる宛先として、コンソール、仮想端末、内部バッファ、および syslog サーバを実行している UNIX ホストがあります。 Syslog フォーマットは、4.3 Berkeley Standard Distribution(BSD)UNIX およびそのバリエーションと互換性があります。


          (注)  


          デバッグの出力先がシステムのオーバーヘッドに影響を与えることがないように注意してください。 コンソールにメッセージを記録する場合は、かなり大きなオーバーヘッドが発生します。 仮想端末にメッセージを記録する場合は、発生するオーバーヘッドは少ないです。 Syslog サーバでメッセージ ロギングを行うと、オーバーヘッドはさらに小さくなり、内部バッファであれば最小限ですみます。


          関連コンセプト

          show platform forward コマンドの使用

          show platform forward 特権 EXEC コマンドの出力からは、インターフェイスに入るパケットがシステムを介して送信された場合、転送結果に関して、有意義な情報がいくつか得られます。 パケットに関して入力されたパラメータに応じて、ルックアップ テーブル結果、転送宛先の計算に使用されるポート マップ、ビットマップ、および出力側の情報が表示されます。

          このコマンドで出力される情報のほとんどは、主に、スイッチの特定用途向け集積回路(ASIC)に関する詳細情報を使用するテクニカル サポート担当者に役立つものです。 ただし、パケット転送情報はトラブルシューティングにも役立ちます。

          OBFL の設定


          注意    


          OBFL はディセーブルにせず、フラッシュ メモリに保存されたデータは削除しないことを推奨します。


          • OBFL をイネーブルにするには、hw-switch switch [switch-number] logging onboard [message level level] グローバル コンフィギュレーション コマンドを使用します。 スイッチの場合、switch-number に指定できる範囲は 1 ~ 9 です。 スイッチが生成してフラッシュ メモリに保存するハードウェア関連のメッセージの重大度を指定するには、message level level パラメータを使用します。

          • OBFL データをローカル ネットワークまたは指定したファイル システムにコピーするには、copy onboard switch switch-number url url-destination 特権 EXEC コマンドを使用します。

          • OBFL をディセーブルにするには、no hw-switch switch [switch-number] logging onboard [message level] グローバル コンフィギュレーション コマンドを使用します。

          • フラッシュ メモリ内の稼働時間と CLI コマンド情報以外のすべての OBFL データをクリアするには、clear onboard switch switch-number 特権 EXEC コマンドを使用します。

          • スイッチ スタックでは、hw-switch switch [switch-number] logging onboard [message level level] グローバル コンフィギュレーション コマンドを使用することにより、スタンドアロン スイッチまたはすべてのスタック メンバの OBFL をイネーブルにできます。

          • のメンバ スイッチの OBFL をイネーブルまたはディセーブルにできます。

          関連資料

          ソフトウェア設定のトラブルシューティングの確認

          OBFL 情報の表示

          表 2 OBFL 情報を表示するためのコマンド

          コマンド

          目的

          show onboard switch switch-number clilog

          Controller# show onboard switch 1 clilog
          
          

          スタンドアロン スイッチまたは指定されたスタック メンバで入力された OBFL CLI コマンドを表示します。

          show onboard switch switch-number environment

          Controller# show onboard switch 1 environment
          
          

          スタンドアロン スイッチまたは指定されたスタック メンバおよび接続されているすべての FRU デバイスの UDI 情報、PID、VID、およびシリアル番号を表示します。

          show onboard switch switch-number message

          Controller# show onboard switch 1 message
          
          

          スタンドアロン スイッチまたは指定されたスタック メンバによって生成されたハードウェア関連のメッセージを表示します。

          show onboard switch switch-number counter

          Controller# show onboard switch 1 counter
          
          

          スタンドアロン スイッチまたは指定したスタック メンバのカウンタ情報を表示します。

          show onboard switch switch-number temperature

          Controller# show onboard switch 1 temperature
          
          

          スタンドアロン スイッチまたは指定されたスイッチ スタック メンバの温度を表示します。

          show onboard switch switch-number uptime

          Controller# show onboard switch 1 uptime
          
          

          スタンドアロン スイッチまたは指定されたスタック メンバが起動した時刻、スタンドアロン スイッチまたは指定されたスタック メンバが再起動された理由、およびスタンドアロン スイッチまたは指定されたスタック メンバが最後に再起動されて以来の稼働時間を表示します。

          show onboard switch switch-number voltage

          Controller# show onboard switch 1 voltage
          
          

          スタンドアロン スイッチまたは指定されたスタック メンバのシステム電圧を表示します。

          show onboard switch switch-number status

          Controller# show onboard switch 1 status
          
          

          スタンドアロン スイッチまたは指定されたスタック メンバの状態を表示します。

          関連タスク

          例:高い CPU 使用率に関する問題と原因の確認

          CPU 使用率が高いことが問題となっているかどうか判別するには、show processes cpu sorted 特権 EXEC コマンドを入力します。 出力例の 1 行目にある下線が付いた部分に注目してください。

          Controller# show processes cpu sorted
          CPU utilization for five seconds: 8%/0%; one minute: 7%; five minutes: 8%
          PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 
          309 42289103 752750 56180 1.75% 1.20% 1.22% 0 RIP Timers 
          140 8820183 4942081 1784 0.63% 0.37% 0.30% 0 HRPC qos request 
          100 3427318 16150534 212 0.47% 0.14% 0.11% 0 HRPC pm-counters 
          192 3093252 14081112 219 0.31% 0.14% 0.11% 0 Spanning Tree 
          143 8 37 216 0.15% 0.01% 0.00% 0 Exec 
          ...
          <output truncated>
          
          

          この例は、正常な CPU 使用率を示しています。 この出力によると、最後の 5 秒間の使用率が 8%/0% となっていますが、この意味は次のとおりです。

          • Cisco IOS の処理時間と割り込みの処理にかかった時間を合わせた CPU の合計の使用率は全体の 8%

          • 割り込みの処理にかかった時間は全体の 0%

          表 3 CPU 使用率に関する問題のトラブルシューティング

          問題のタイプ

          原因

          改善処置

          割り込みのパーセント値が合計の CPU 使用率の値とほぼ同程度に高い

          CPU がネットワークから受信するパケット数が多すぎる。

          ネットワーク パケットのソースを判別する。 データの流れを遮断するか、スイッチの設定を変更します。 「Analyzing Network Traffic(ネットワーク トラフィックの解析)」の項を参照してください。

          割り込みの所要時間は最小限であったにもかかわらず CPU の合計使用率が 50% を超える

          CPU 時間を過度に消費する Cisco IOS 処理が 1 つ以上存在する。 これは通常、処理をアクティブ化するイベントによって始動されます。

          異常なイベントを特定して根本的な原因を解消する。 「Debugging Active Processes(アクティブなプロセスのデバッグ)」のセクションを参照してください。

          ソフトウェア設定のトラブルシューティングのシナリオ

          Power over Ethernet(PoE)に関するトラブルシューティングのシナリオ

          表 4 PoE に関するトラブルシューティングのシナリオ

          症状または問題

          考えられる原因と解決法

          1 つのポートだけに PoE がない。

          1 つのスイッチ ポートに限り問題が発生する。 このポートでは PoE 装置と PoE 非対応の装置のいずれも動作しないが、他のポートでは動作する。

          この受電装置が他の PoE ポートで動作するかを確認します。

          ポートがシャットダウンまたは errdisable になっていないかを確認するために、ユーザ EXEC コマンドの show run または show interface status を使用します。

          (注)     

          ほとんどのスイッチはポートがシャットダウンしているときはポートの電力供給をオフにします。これは、IEEE 仕様でこれがオプションに指定されている場合も同様です。

          受電装置からスイッチ ポートまでのイーサネット ケーブルの動作が正常であることを確認します。具体的には、既知の正常な PoE 非対応のイーサネット装置とイーサネット ケーブルを接続して、受電装置がリンクを確立し他のホストとトラフィックを交換することを確認します。

          スイッチのフロント パネルから受電装置までのケーブル長の合計が 100 メートル以下であることを確認します。

          スイッチ ポートからイーサネット ケーブルを外します。 短いイーサネット ケーブルを使用して、既知の正常なイーサネット装置を、スイッチのフロント パネルの(パッチ パネルではない)このポートに直接接続します。 これによってイーサネット リンクが確立され他のホストとトラフィックを交換できることを確認します。あるいは、ポートの VLAN SVI で ping を実行してください。 次に、受電装置をこのポートに接続し、電源がオンになることを確認します。

          パッチ コードをスイッチ ポートに接続しても受電装置の電源がオンにならない場合、接続する受電装置の合計数とスイッチの電力バジェット(使用可能な PoE)とを比較してください。 使用可能な電力量を確認するには、show power inline コマンドを使用します。

          すべてのポートまたは 1 つのポート グループで PoE が機能しない。

          すべてのスイッチ ポートで問題が発生する。 電力が供給されていないイーサネット装置がどのポートでもイーサネット リンクを確立できず、PoE 装置の電源がオンになりません。

          電力に関するアラームが継続的に発生する、断続的に発生する、または再発する場合は、可能であれば電源モジュールを交換します(現場交換可能ユニットです)。 そうでない場合はスイッチを交換してください。

          連続する複数のポートで問題があるものの、すべてのポートで問題が発生するわけではない場合、電源の故障ではないと考えられ、スイッチの PoE レギュレータに関連した異常の可能性があります。

          PoE の状況やステータスの変更について過去に報告されているアラームまたはシステム メッセージがないか、show log 特権 EXEC コマンドを使用して調べます。

          アラームがない場合は、show interface status コマンドを使用して、ポートがシャットダウンしていないか errdisable になっていないかを確認します。 ポートが errdisable の場合、shut および no shut インターフェイス コンフィギュレーション コマンドを使用してポートを再びイネーブルにします。

          特権 EXEC コマンドの show env power および show power inline を使用して、PoE のステータスおよび電力バジェット(使用可能な PoE)を調べます。

          実行コンフィギュレーションを調べて power inline never がこのポートに設定されていないことを確認します。

          受電していないイーサネット装置をスイッチ ポートに直接接続します。 接続には短いパッチ コードだけを使用します。 既存の配線ケーブルは使用しないでください。 shut および no shut インターフェイス コンフィギュレーション コマンドを入力し、イーサネット リンクが確立されていることを確認します。 正しく接続している場合、短いパッチ コードを使用して受電装置をこのポートに接続し、電源がオンになることを確認します。 装置の電源がオンになったら、すべての中間パッチ パネルが正しく接続されているか確認してください。

          1 本を除くすべてのイーサネット ケーブルをスイッチ ポートから抜きます。 短いパッチ コードを使用して、1 つの PoE ポートにだけ受電装置を接続します。 スイッチ ポートからの受電に比較して、受電装置が多くの電力を必要としないことを確認してください。

          show power inline 特権 EXEC コマンドを使用して、ポートがシャットダウンしていない場合に、受電装置に電力が供給されることを確認します。 あるいは、受電装置を観察して電源がオンになることを確認してください。

          1 台の受電装置だけがスイッチに接続しているときに電力が供給される場合、残りのポートで shut および no shut インターフェイス コンフィギュレーション コマンドを入力してから、イーサネット ケーブルをスイッチの PoE ポートに 1 本ずつ再び接続してください。 show interface status および show power inline 特権 EXEC コマンドを使用して、インライン電力統計およびポート ステータスをモニタします。

          すべてのポートで、まだ PoE が機能しない場合は、電源装置の PoE セクションでヒューズを開くことができる場合があります。 この場合、アラームが生成されるのが一般的です。 過去にシステム メッセージでアラームが報告されていないか、ログをもう一度チェックしてください。

          Cisco IP Phone が切断またはリセットされる。

          正常に動作した後で、Cisco phone またはワイヤレス アクセス ポイントが断続的にリロードしたり、PoE から切断されたりします。

          スイッチから受電装置までのすべての電気系統を確認してください。 信頼性の低い接続は、電力供給の中断や受電装置の機能が不安定になる原因となり、受電装置の断続的な切断やリロードなどが発生します。

          スイッチ ポートから受電装置までのケーブル長が 100 メートル以下であることを確認してください。

          スイッチが配置されている場所で電気環境にどのような変化があるか、切断時に、受電装置に何が起きるかについて注意してください。

          切断と同時にエラー メッセージが表示されたか注意します。 show log 特権 EXEC コマンドを使用してエラー メッセージを確認します。

          リロードの発生直前に IP Phone から Call Manager へのアクセスが失われていないか確認してください (PoE の障害ではなくネットワークに問題が発生している場合があります)。

          受電装置を PoE 非対応の装置に交換し、装置が正しく動作することを確認します。 PoE 非対応の装置にリンク障害または高いエラー率がある場合、スイッチ ポートと受電装置を接続する信頼性の低いケーブル接続が問題の可能性があります。

          シスコ以外の受電装置がシスコ PoE スイッチで動作しない。

          シスコ PoE スイッチに接続するシスコ以外の受電装置に電源が供給されないか、電源投入後すぐに電源が切れます。 PoE 非対応装置は正常に動作します。

          show power inline コマンドを使用して、受電装置の接続前後に、スイッチの電力バジェット(使用可能な PoE)が使い果たされていないか確認してください。 受電装置を接続する前に、このタイプの装置に十分な電力が使用可能であることを確認します。

          show interface status コマンドを使用して、接続されている受電装置をスイッチが検出することを確認します。

          show log コマンドを使用して、ポートの過電流状態を報告したシステム メッセージがないか確認します。 症状を正確に特定してください。最初に電力が受電装置に供給され、その後、切断される状態ですか。 その場合は、問題は最初のサージ電流(突入電流)が原因で、ポートの電流上限しきい値が超過した可能性があります。

          ソフトウェアのトラブルシューティングの設定例

          例:IP ホストを ping する

          次に、IP ホストに ping を実行する例を示します。

          Controller# ping 172.20.52.3
          
          Type escape sequence to abort.
          Sending 5, 100-byte ICMP Echoes to 172.20.52.3, timeout is 2 seconds:
          !!!!!
          Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
          Controller#
          
          表 5 ping の出力表示文字

          文字

          説明

          !

          感嘆符 1 個につき 1 回の応答を受信したことを示します。

          .

          ピリオド 1 個につき応答待ちの間にネットワーク サーバのタイムアウトが 1 回発生したことを示します。

          U

          宛先到達不能エラーを表す PDU を受信したことを意味します。

          C

          輻輳に遭遇したパケットを受信したことを示します。

          I

          ユーザによりテストが中断されたことを示します。

          ?

          パケット タイプが不明です。

          &

          パケットの存続時間を超過したことを示します。

          ping セッションを終了するには、エスケープ シーケンス(デフォルトでは Ctrl+^ X)を入力してください。 Ctrl キー、Shift キー、および 6 キーを同時に押してから放し、その後 X キーを押します。

          関連コンセプト
          関連タスク

          例:IP ホストに対する traceroute の実行

          次に、IP ホストに traceroute を実行する例を示します。

          Controller# traceroute ip 192.0.2.10
          
          Type escape sequence to abort.
          Tracing the route to 192.0.2.10
          
            1 192.0.2.1 0 msec 0 msec 4 msec
            2 192.0.2.203 12 msec 8 msec 0 msec
            3 192.0.2.100 4 msec 0 msec 0 msec
            4 192.0.2.10 0 msec 4 msec 0 msec
             
          
          

          ディスプレイには、送信される 3 つのプローブごとに、ホップ カウント、ルータの IP アドレス、およびラウンドトリップ時間(ミリ秒単位)が表示されます。

          表 6 traceroute の出力表示文字

          文字

          説明

          *

          プローブがタイムアウトになりました。

          ?

          パケット タイプが不明です。

          A

          管理上、到達不能です。 通常、この出力は、アクセス リストがトラフィックをブロックしていることを表しています。

          H

          ホストが到達不能です。

          N

          ネットワークが到達不能です。

          P

          プロトコルが到達不能です。

          Q

          発信元。

          U

          ポートが到達不能です。

          実行中の追跡を終了するには、エスケープ シーケンス(デフォルトでは Ctrl+^ X)を入力してください。 Ctrl キー、Shift キー、および 6 キーを同時に押してから放し、その後 X キーを押します。

          関連コンセプト
          関連タスク

          例:すべてのシステム診断のイネーブル化


          注意    


          デバッグ出力は他のネットワーク トラフィックより優先され、debug all 特権 EXEC コマンドは他の debug コマンドより出力が大量になるので、スイッチのパフォーマンスが極度に低下したり、場合によっては使用不能になったりすることがあります。 状況にかかわらず、特定性の高い debug コマンドを使用するのが原則です。


          このコマンドは、すべてのシステム診断をディセーブルにします。

          Controller# debug all
          
          

          no debug all 特権 EXEC コマンドを使用すると、すべての診断出力がディセーブルになります。 いずれかの debug コマンドが誤ってイネーブルのままにならないようにするには、no debug all コマンドを使用すると便利です。

          関連コンセプト

          ソフトウェア設定のトラブルシューティングの機能履歴と情報

          リリース

          変更

          Cisco IOS XE 3.2SE

          この機能が導入されました。