この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
この章では、スイッチが稼働する Cisco IOS ソフトウェアに関連する問題を特定し、解決する方法について説明します。問題の性質に応じて、コマンドライン インターフェイス(CLI)、デバイス マネージャ、または Network Assistant を使用して、問題を特定し解決できます。
LED の説明など、トラブルシューティングの詳細については、ハードウェア インストレーション ガイドを参照してください。
スイッチ ソフトウェアがアップグレード中に破損する原因として、誤ったファイルがスイッチにダウンロードされた場合やイメージ ファイルが削除された場合があります。これらのどの場合も、スイッチは、電源投入時自己診断テスト(POST)に合格せず、接続はありません。ソフトウェア障害から回復するには、ソフトウェア障害からの回復の項で説明されている手順に従います。
デバイスのデフォルト設定では、デバイスに物理的にアクセスしているエンドエンド ユーザは、スイッチの電源投入中に起動プロセスを中断して新しいパスワードを入力することにより、パスワードを紛失した状態から回復できます。ここで紹介する回復手順を実行するには、デバイスに物理的にアクセスする必要があります。
(注) | これらのデバイスでは、システム管理者は、デフォルト設定に戻すことに同意した場合に限り、エンド ユーザによるパスワードのリセットを許可することによって、この機能の一部をディセーブルにできます。パスワード回復がディセーブルになっている場合に、エンド ユーザがパスワードをリセットしようとすると、ステータス メッセージで回復プロセスの間はデフォルトの設定に戻すように指示されます。 |
(注) | Cisco WLC の設定を複数の Cisco WLC 間でコピーすると、暗号化パスワード キーを回復できなくなります(RMA の場合)。 |
パスワードを紛失または忘れた場合にそのパスワードを回復するには、パスワードを忘れた場合の回復の項で説明する手順に従います。
Power over Ethernet(PoE)スイッチ ポートでは、回路に電力が供給されていないことをスイッチが検知した場合、接続している次のデバイスに電力が自動的に供給されます。
受電デバイスが PoE スイッチ ポートおよび AC 電源に接続されている場合、冗長電力として利用できます。受電装置が PoE ポートにだけ接続されている場合、受電装置には冗長電力は供給されません。
受電デバイスを検出すると、スイッチは受電デバイスの電力要件を判断し、受電デバイスへの電力供給を許可または拒否します。また、スイッチは消費電力をモニタリングおよびポリシングすることで、装置の電力の消費をリアルタイムに検知できます。
詳細については、『Interface and Hardware Component Configuration Guide (Catalyst 9300 Switches)』の「Configuring PoE」の章を参照してください。
PoE のさまざまなトラブルシューティング シナリオについては、Power over Ethernet(PoE)に関するトラブルシューティングのシナリオの項を参照してください。
PoE デバイス ポートに接続され、AC 電源から電力が供給されている受電デバイス(Cisco IP Phone 7910 など)に AC 電源から電力が供給されない場合、そのデバイスは errdisable ステートになることがあります。error-disabled ステートから回復するには、shutdown インターフェイス コンフィギュレーション コマンドを入力してから、no shutdown インターフェイス コマンドを入力します。デバイスで自動回復を設定し、error-disabled ステートから回復することもできます。
デバイスの場合、errdisable recovery cause loopback および errdisable recovery interval seconds グローバル コンフィギュレーション コマンドは、指定した期間が経過したあと自動的にインターフェイスを error-disabled ステートから復帰させます。
シスコ受電デバイスをポートに接続し、power inline never インターフェイス コンフィギュレーション コマンドを使用してポートを設定した場合は、不正リンク アップが発生し、ポートが error-disabled ステートになることがあります。ポートを error-disabled ステートから回復するには、shutdown および no shutdown インターフェイス コンフィギュレーション コマンドを入力します。
power inline never コマンドで設定したポートにシスコ受電デバイスを接続しないでください。
デバイスは IP の ping をサポートしており、これを使ってリモート ホストへの接続をテストできます。ping はアドレスにエコー要求パケットを送信し、応答を待ちます。ping は次のいずれかの応答を返します。
正常な応答:正常な応答(hostname が存在する)は、ネットワーク トラフィックにもよりますが、1 ~ 10 秒以内で発生します。
宛先の応答なし:ホストが応答しない場合、no-answer メッセージが返されます。
不明なホスト:ホストが存在しない場合、unknown host メッセージが返されます。
宛先到達不能:デフォルト ゲートウェイが指定されたネットワークに到達できない場合、destination-unreachable メッセージが返されます。
ネットワークまたはホストへの到達不能:ルート テーブルにホストまたはネットワークのエントリがない場合、network or host unreachable メッセージが返されます。
ping の動作を理解するには、ping の実行の項を参照してください。
レイヤ 2 traceroute 機能により、パケットが通過する、送信元デバイスから宛先デバイスへの物理パスを識別できます。レイヤ 2 traceroute は、ユニキャストの送信元および宛先 MAC アドレスだけをサポートします。transroute は、パス内にあるデバイスの MAC アドレス テーブルを使用してパスを識別します。デバイスがパス内でレイヤ 2 traceroute をサポートしていないデバイスを検知した場合、デバイスはレイヤ 2 trace クエリーを送信し続け、タイムアウトにします。
デバイスは、送信元デバイスから宛先デバイスへのパスのみを識別できます。パケットが通過する、送信元ホストから送信元デバイスまで、または宛先デバイスから宛先ホストまでのパスは識別できません。
ネットワーク内のすべてのデバイスで、Cisco Discovery Protocol(CDP)をイネーブルにする必要があります。レイヤ 2 traceroute が適切に動作するために、CDP をディセーブルにしないでください。
物理パス内のデバイスが CDP に対して透過的な場合、スイッチはこれらのデバイスを通過するパスを識別できません。
ping 特権 EXEC コマンドを使用して接続をテストできれば、このデバイスは別のデバイスから到達可能といえます。物理パス内のすべてのデバイスは、他のスイッチから相互に到達可能でなければなりません。
パス内で識別可能な最大ホップ数は 10 です。
送信元デバイスと宛先デバイスの間の物理パス内にないデバイスで、traceroute mac または traceroute mac ip の特権 EXEC コマンドを実行できます。パス内のすべてのデバイスは、このスイッチから到達可能でなければなりません。
traceroute mac コマンドの出力結果としてレイヤ 2 パスが表示されるのは、指定の送信元および宛先 MAC アドレスが、同一の VLAN に属している場合だけです。指定した送信元および宛先 MAC アドレスが、それぞれ異なる VLAN に属している場合は、レイヤ 2 パスは識別されず、エラー メッセージが表示されます。
マルチキャストの送信元または宛先 MAC アドレスを指定すると、パスは識別されず、エラー メッセージが表示されます。
送信元または宛先 MAC アドレスが複数の VLAN に属する場合は、送信元および宛先 MAC アドレスの両方が属している VLAN を指定する必要があります。VLAN を指定しないと、パスは識別されず、エラー メッセージが表示されます。
複数のデバイスがハブを介して 1 つのポートに接続されている場合(たとえば複数の CDP ネイバーがポートで検出された場合)、レイヤ 2 traceroute 機能はサポートされません。複数の CDP ネイバーが 1 つのポートで検出された場合、レイヤ 2 パスは特定されず、エラー メッセージが表示されます。
この機能は、トークンリング VLAN ではサポートされません。
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 ポート到達不能エラーを送信します。ポート到達不能エラーを除くすべてのエラーは中間ホップから送信されるため、ポート到達不能エラーを受信するということは、このメッセージが宛先ポートから送信されたことを意味します。
例:IP ホストに対する traceroute の実行に進み、IP traceroute プロセスの例を参照してください。
Time Domain Reflector(TDR)機能を使用すると、ケーブル配線の問題を診断して解決できます。TDR 稼働時、ローカル デバイスはケーブルを介して信号を送信して、最初に送信した信号と反射された信号を比べます。
次の状況で TDR を使用して、ケーブル障害を診断および解決してください。
TDR の実行時、次の場合にデバイスは正確な情報をレポートします。
TDR の実行時、次の場合にデバイスは正確な情報をレポートしません。
ギガビット リンク用のケーブルがツイストペア ケーブルまたは連続接続された単線コア ケーブル
リンクが 10 Mb または 100 Mb
より線ケーブル
リンク パートナーが Cisco IP Phone
リンク パートナーが IEEE 802.3 に準拠していない
TDR の実行および結果の表示に移動し、TDR のコマンドを確認します。
注意 | デバッグ出力は CPU プロセスで高プライオリティが割り当てられているため、デバッグ出力を行うとシステムが使用できなくなることがあります。したがって、debug コマンドを使用するのは、特定の問題のトラブルシューティング時、またはシスコのテクニカル サポート担当者とともにトラブルシューティングを行う場合に限定してください。ネットワーク トラフィック量やユーザ数が少ない期間に debug コマンドを使用することをお勧めします。デバッグをこのような時間帯に行うと、debug コマンド処理のオーバーヘッドの増加によりシステムの使用に影響が及ぶ可能性が少なくなります。 |
debug コマンドはすべて特権 EXEC モードで実行します。ほとんどの debug コマンドは引数を取りません。
システム レポートまたは crashinfo ファイルには、シスコのテクニカル サポート担当者が Cisco IOS イメージの障害(クラッシュ)が原因で起きた問題をデバッグするときに使用する情報が保存されています。明瞭度と整合性の高い重要なクラッシュ情報を迅速かつ確実に収集することが必要です。さらに、この情報の収集とバンドルが、特定のクラッシュの発生に対し関連付けか特定ができるような方法で行われることが必要です。
システム レポートは次の状況で生成されます。
スイッチ障害の場合:システム レポートは障害が発生したメンバーで生成されます。スタック内の他のメンバーではレポートは生成されません。
スイッチオーバーの場合:システム レポートはハイ アベイラビリティ(HA)のメンバー スイッチでのみ生成されます。非 HA メンバーについてはレポートは生成されません。
リロード時はレポートは生成されません。
クラッシュ プロセス時は、次の情報がスイッチからローカルに収集されます。
完全なプロセス core
トレースログ
IOS の syslog(非アクティブなクラッシュの場合には保証されません)
システム プロセス情報
ブートアップ ログ
リロード ログ
特定のタイプの /proc 情報
この情報は個別のファイルに格納されてから、アーカイブされて 1 つのバンドルに圧縮されます。これにより、クラッシュのスナップショットを 1 つの場所で取得して、分析のためにボックス外に移動できるようになります。このレポートは、スイッチが ROMmon/ブートローダにダウンする前に生成されます。
完全な core およびトレースログ以外はテキスト ファイルです。
request platform software process core fed active コマンドを使用してコア ダンプを生成します。
h2-macallan1# request platform software process core fed active Process : fed main event (28155) encountered fatal signal 6 Process : fed main event stack : SUCCESS: Core file generated. h2-macallan1#dir bootflash:core Directory of bootflash:/core/ 178483 -rw- 1 May 23 2017 06:05:17 +00:00 .callhome 194710 drwx 4096 Aug 16 2017 19:42:33 +00:00 modules 178494 -rw- 10829893 Aug 23 2017 09:46:23 +00:00 h2-macallan1_RP_0_fed_28155_20170823-094616-UTC.core.gz
デフォルトでは、生成されたシステム レポート ファイルは /crashinfo ディレクトリに格納されます。Ifit は、領域不足のため crashinfo パーティションに保存できません。そのため、/flash ディレクトリに保存されます。
ファイルを表示するには、dir crashinfo: コマンドを入力します。次に crashinfo ディレクトリの出力例を示します。
Switch#dir crashinfo: Directory of crashinfo:/ 23665 drwx 86016 Jun 9 2017 07:47:51 -07:00 tracelogs 11 -rw- 0 May 26 2017 15:32:44 -07:00 koops.dat 12 -rw- 4782675 May 29 2017 15:47:16 -07:00 system-report_1_20170529-154715-PDT.tar.gz 1651507200 bytes total (1519386624 bytes free)
システム レポートは、次の形式で crashinfo ディレクトリにあります。
system-report_[switch number]_[date]-[timestamp]-UTC.gz
スイッチがクラッシュしたら、システム レポート ファイルを確認します。最後に生成されたシステム レポート ファイルは crashinfo ディレクトリの下に last_systemreport というファイル名で保存されます。問題のトラブルシューティングを行う際、システム レポートおよび crashinfo ファイルが TAC の役に立ちます。
生成されたシステム レポートは、TFTP や HTTP などいくつかのオプションを使用して、さらにコピーできます。
Switch#copy crashinfo: ? crashinfo: Copy to crashinfo: file system flash: Copy to flash: file system ftp: Copy to ftp: file system http: Copy to http: file system https: Copy to https: file system null: Copy to null: file system nvram: Copy to nvram: file system rcp: Copy to rcp: file system running-config Update (merge with) current system configuration scp: Copy to scp: file system startup-config Copy to startup configuration syslog: Copy to syslog: file system system: Copy to system: file system tftp: Copy to tftp: file system tmpsys: Copy to tmpsys: file system
TFTP サーバにコピーするための一般的な構文は次のとおりです。
Switch#copy crashinfo: tftp: Source filename [system-report_1_20150909-092728-UTC.gz]? Address or name of remote host []? 1.1.1.1 Destination filename [system-report_1_20150909-092728-UTC.gz]?
スタックの全メンバーからのトレースログは、trace archive コマンドを発行することで収集できます。このコマンドには、時間帯オプションがあります。コマンド構文は次のとおりです。
Switch#request platform software trace archive ? last Archive trace files of last x days target Location and name for the archive file
crashinfo: または flash: ディレクトリに格納されている過去 3650 日以内のトレースログが取得できます。
Switch# request platform software trace archive last ? <1-3650> Number of days (1-3650) Switch#request platform software trace archive last 3650 days target ? crashinfo: Archive file name and location flash: Archive file name and location
(注) | 一度コピーされたら、システム レポートやトレースのアーカイブを flash ディレクトリまたは crashinfo ディレクトリからクリアし、トレースログやその他の目的に使用できる領域を確保することが重要です。 |
オンボード障害ロギング(OBFL)機能を使用すれば、デバイスに関する情報を収集できます。この情報には稼働時間、温度、電圧などの情報が含まれており、シスコのテクニカル サポート担当者がデバイスの問題をトラブルシューティングする際に役立ちます。OBFL はイネーブルにしておき、フラッシュ メモリに保存されたデータは消さないようにすることを推奨します。
OBFL は、デフォルトでイネーブルになっています。デバイスおよび Small Form-Factor Pluggable(SFP)モジュールに関する情報が収集されます。デバイスは、次の情報をフラッシュ メモリに保存します。
CLI コマンド:スタンドアロン デバイスまたはスイッチ スタック メンバに入力された OBFL CLI コマンドの記録
環境データ:スタンドアロン デバイスまたはスタックメンバおよび接続されているすべての FRU デバイスの一意のデバイス ID(UDI)情報、製品 ID(PID)、バージョン ID(VID)、およびシリアル番号
メッセージ:スタンドアロン デバイスまたはスタック メンバにより生成されたハードウェア関連のシステム メッセージの記録
イーサネット経由の電源供給(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 秒待機してからシャットダウンします。
デバイスを再起動するには、電源をオフにしてから再度オンにする必要があります。
ファンの障害の詳細については、『Cisco Catalyst 9400 Series Switches Hardware Installaion Guide』を参照してください。
CPU 使用率が高すぎることで次の現象が発生する可能性がありますが、他の原因で発生する場合もあります。次にその一部を示します。
ここで紹介する回復手順を実行するには、スイッチを直接操作する必要があります。
ここで紹介する手順では、破損したイメージ ファイルまたは不適切なイメージ ファイルの回復に boot loader コマンドおよび TFTP を使用します。
あるいは、Telnet または管理ポートを通じて TFTP からローカル フラッシュにイメージをコピーした後、ローカル フラッシュからデバイスをブートします。
スイッチのデフォルト設定では、スイッチを直接操作するエンド ユーザが、スイッチの電源投入時に起動プロセスを中断して新しいパスワードを入力することにより、パスワードを紛失した状態から回復できます。ここで紹介する回復手順を実行するには、スイッチを直接操作してください。
(注) | これらのスイッチでは、システム管理者はデフォルト設定に戻す場合に限りエンド ユーザによるパスワードのリセットを許可することによって、この機能の一部をディセーブルにできます。パスワード回復がディセーブルになっている場合に、エンド ユーザがパスワードをリセットしようとすると、回復プロセスの間、ステータス メッセージにその旨が表示されます。 |
パスワード回復メカニズムがディセーブルの場合、次のメッセージが表示されます。
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)コンフィギュレーション ファイルがあるかどうかを確認してください。 |
スタック メンバをまったく同じモデルで置き換えると、新しいデバイスは、置き換えられたデバイスとまったく同じ設定で稼働します。この場合、新しいデバイスは置き換えられたデバイスと同じメンバ番号を使用するものと想定されます。
電源が入った状態のスタック メンバを取り外すと、スイッチ スタックが、それぞれ同じ設定を持つ 2 つ以上のスイッチ スタックに分割(パーティション化)されます。スイッチ スタックを分離されたままにしておきたい場合は、新しく作成されたスイッチ スタックの IP アドレス(複数の場合あり)を変更してください。パーティション化されたスイッチ スタックを元に戻すには、次の手順を実行します。
スイッチ スタックおよびそのメンバのモニタリングに使用できるコマンドについては、「Displaying Switch Stack Information」の項を参照してください。
IEEE 802.3ab 自動ネゴシエーション プロトコルは速度(10 Mbps、100 Mbps、および SFP モジュール ポート以外の 1000 Mbps)およびデュプレックス(半二重または全二重)に関するデバイスの設定を管理します。このプロトコルは設定を適切に調整しないことがあり、その場合はパフォーマンスが低下します。不一致は次の条件で発生します。
手動で設定した速度またはデュプレックスのパラメータが、接続ポート上で手動で設定された速度またはデュプレックスのパラメータと異なっている場合。
ポートを自動ネゴシエーションに設定したが、接続先ポートは自動ネゴシエーションを使用しない全二重に設定されている場合。
デバイスのパフォーマンスを最大限に引き出してリンクを確保するには、次のいずれかの注意事項に従って、デュプレックスおよび速度の設定を変更してください。
(注) | 接続先装置が自動ネゴシエーションを実行しない場合は、2 つのポートのデュプレックス設定を一致させます。速度パラメータは、接続先のポートが自動ネゴシエーションを実行しない場合でも自動調整が可能です。 |
シスコの 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 グローバル コンフィギュレーション コマンドを使用してポート ステータスを確認し、error-disabled ステートから回復する時間間隔を入力します。この時間間隔が経過すると、デバイスは error-disabled ステートからインターフェイスを復帰させ、操作を再試行します。errdisable recovery コマンドの詳細については、このリリースに対応するコマンド リファレンスを参照してください。
モジュールがシスコ製 SFP モジュールとして識別されたにもかかわらず、システムがベンダー データ情報を読み取ってその情報が正確かどうかを確認できないと、SFP モジュール エラー メッセージが生成されます。この場合、SFP モジュールを取り外して再び装着してください。それでも障害が発生する場合は、SFP モジュールが不良品である可能性があります。
show interfaces transceiver 特権 EXEC コマンドを使用すると、SFP モジュールの物理または動作ステータスを確認できます。このコマンドは、温度や特定のインターフェイス上の SFP モジュールの現状などの動作ステータスと、アラーム ステータスを表示します。また、このコマンドを使用して SFP モジュールの速度およびデュプレックス設定も確認できます。詳細については、このリリースのコマンド リファレンスに記載された show interfaces transceiver コマンドの説明を参照してください。
別の IP サブネットワーク内のホストに ping を実行する場合は、ネットワークへのスタティック ルートを定義するか、またはこれらのサブネット間でルーティングされるように IP ルーティングを設定する必要があります。
IP ルーティングは、デフォルトではすべてのデバイスでディセーブルになります。
(注) | ping コマンドでは、他のプロトコル キーワードも使用可能ですが、このリリースではサポートされていません。 |
このコマンドは、デバイスからネットワーク上の他のデバイスに ping を実行する目的で使用します。
コマンド(Command) |
目的 |
---|---|
ping ip host | address
Device# ping 172.20.52.3
|
IP またはホスト名やネットワーク アドレスを指定してリモート ホストに ping を実行します。 |
デバイスは温度条件をモニタし、温度情報を使用してファンを制御します。
温度の値、状態、しきい値を表示するには、show env temperature status 特権 EXEC コマンドを使用します。温度の値は、デバイス内の温度であり、外部の温度ではありません。system env temperature threshold yellow value グローバル コンフィギュレーション コマンドを使用してイエローのしきい値レベル(摂氏)だけを設定し、イエローのしきい値およびレッドのしきい値の差を設定できます。グリーンまたはレッドのしきい値は設定できません。詳細については、このリリースのコマンド リファレンスを参照してください。
次のいずれかの特権 EXEC コマンドを使用して、パケットが通過する、送信元デバイスから宛先デバイスへの物理パスをモニタできます。
コマンド(Command) | 目的 |
---|---|
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 パスを表示します。 |
(注) | traceroute 特権 EXEC コマンドでは、他のプロトコル キーワードも使用可能ですが、このリリースではサポートされていません。 |
コマンド(Command) |
目的 |
---|---|
traceroute ip ホスト Device# traceroute ip 192.51.100.1
|
ネットワーク上でパケットが通過するパスを追跡します。 |
TDR を実行する場合、test cable-diagnostics tdr interface interface-id 特権 EXEC コマンドを入力します。
TDR の結果を表示するには、show cable-diagnostics tdr interface interface-id 特権 EXEC コマンドを実行します。
ネットワーク サーバはデフォルトで、debug コマンドおよびシステム エラー メッセージの出力をコンソールに送信します。このデフォルトの設定を使用する場合は、コンソール ポートまたはイーサネット管理ポートに接続する代わりに、仮想端末接続によってデバッグ出力をモニタできます。
指定できる宛先として、コンソール、仮想端末、内部バッファ、および syslog サーバを実行している UNIX ホストがあります。Syslog フォーマットは、4.3 BSD UNIX およびそのバリエーションと互換性があります。
(注) | デバッグの出力先がシステムのオーバーヘッドに影響を与えることがないように注意してください。メッセージをコンソールに記録すると、非常に高いオーバーヘッドが発生します。仮想端末にメッセージを記録すると、発生するオーバーヘッドは低くなります。Syslog サーバでメッセージ ロギングを行うと、オーバーヘッドはさらに小さくなり、内部バッファであれば最小限ですみます。 システム メッセージのロギングに関する詳細については、「システム メッセージ ロギングの設定」を参照してください。 |
show platform forward 特権 EXEC コマンドの出力から、インターフェイスに入るパケットがシステムを介して送信された場合、転送結果に関して有意義な情報がいくつか得られます。パケットに関して入力されたパラメータに応じて、参照テーブル結果、転送宛先の計算に使用されるポート マップ、ビットマップ、および出力側の情報が表示されます。
このコマンドで出力される情報のほとんどは、主に、デバイスの用途別集積回路(ASIC)に関する詳細情報を使用するテクニカル サポート担当者に役立つものです。ただし、パケット転送情報はトラブルシューティングにも役立ちます。
show debug コマンドは、特権 EXEC モードで入力します。このコマンドは、スイッチで使用可能なすべてのデバッグ オプションを表示します。
すべての条件付きデバッグ オプションを表示するには、コマンド show debug condition を実行します。コマンドは、条件 ID <1-1000>または all 条件を選択することで一覧表示できます。
デバッグを無効にするには、no debug all コマンドを使用します。
注意 | デバッグ出力は CPU プロセスで高プライオリティが割り当てられているため、デバッグ出力を行うとシステムが使用できなくなることがあります。したがって、debug コマンドを使用するのは、特定の問題のトラブルシューティング時、またはシスコのテクニカル サポート担当者とともにトラブルシューティングを行う場合に限定してください。さらに、debug コマンドは、ネットワーク トラフィックが少なく、ユーザも少ないときに使用することを推奨します。デバッグをこのような時間帯に行うと、debug コマンド処理のオーバーヘッドの増加によりシステムの使用に影響が及ぶ可能性が少なくなります。 |
注意 | 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 をイネーブルまたはディセーブルにできます。
ここで説明した各コマンドの詳細については、このリリースのコマンド リファレンスを参照してください。
コマンド |
目的 |
---|---|
show onboard switch switch-numberclilog Device# show onboard switch 1 clilog
|
スタンドアロン スイッチまたは指定されたスタック メンバで入力された OBFL CLI コマンドを表示します。 |
show onboard switch switch-numberenvironment Device# show onboard switch 1 environment
|
スタンドアロン スイッチまたは指定されたスタック メンバおよび接続されているすべての FRU デバイスの UDI 情報、PID、VID、およびシリアル番号を表示します。 |
show onboard switch switch-numbermessage Device# show onboard switch 1 message
|
スタンドアロン スイッチまたは指定されたスタック メンバによって生成されたハードウェア関連のメッセージを表示します。 |
show onboard switch switch-numbercounter Device# show onboard switch 1 counter
|
スタンドアロン スイッチまたは指定したスタック メンバのカウンタ情報を表示します。 |
show onboard switch switch-numbertemperature Device# show onboard switch 1 temperature
|
スタンドアロン スイッチまたは指定されたスイッチ スタック メンバの温度を表示します。 |
show onboard switch switch-numberuptime Device# show onboard switch 1 uptime
|
スタンドアロン スイッチまたは指定されたスタック メンバが起動した時刻、スタンドアロン スイッチまたは指定されたスタック メンバが再起動された理由、およびスタンドアロン スイッチまたは指定されたスタック メンバが最後に再起動されて以来の稼働時間を表示します。 |
show onboard switch switch-numbervoltage Device# show onboard switch 1 voltage
|
スタンドアロン スイッチまたは指定されたスタック メンバのシステム電圧を表示します。 |
show onboard switch switch-numberstatus Device# show onboard switch 1 status
|
スタンドアロン スイッチまたは指定されたスタック メンバの状態を表示します。 |
CPU 使用率が高いことが問題となっているかどうか判別するには、show processes cpu sorted 特権 EXEC コマンドを入力します。出力例の 1 行目にある下線が付いた部分に注目してください。
Device# 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% となっていますが、この意味は次のとおりです。
問題のタイプ |
原因 |
修正処置 |
---|---|---|
割り込みのパーセント値が合計の CPU 使用率の値とほぼ同程度に高い |
CPU がネットワークから受信するパケット数が多すぎる。 |
ネットワーク パケットのソースを判別する。データの流れを遮断するか、スイッチの設定を変更します。「Analyzing Network Traffic(ネットワーク トラフィックの解析)」の項を参照してください。 |
割り込みの所要時間は最小限であったにもかかわらず CPU の合計使用率が 50% を超える |
CPU 時間を過度に消費する Cisco IOS 処理が 1 つ以上存在する。これは通常、処理をアクティブ化するイベントによって始動されます。 |
異常なイベントを特定して根本的な原因を解消する。 「Debugging Active Processes(アクティブなプロセスのデバッグ)」のセクションを参照してください。 |
症状または問題 |
考えられる原因と解決法 |
||||
---|---|---|---|---|---|
PoE がないポートは 1 つに限りません。 1 つのスイッチ ポートに限り問題が発生する。このポートでは PoE 装置と PoE 非対応の装置のいずれも動作しないが、他のポートでは動作します。 |
この受電デバイスが他の PoE ポートで動作するかを確認する。 show run、または show interface status ユーザ EXEC コマンドを使用して、ポートがシャットダウンしていないか、または error-disabled になっていないかを確認します。
power inline never がそのインターフェイスまたはポートで設定されていないことを確認します。 受電デバイスからスイッチ ポートまでのイーサネット ケーブルの動作が正常であることを確認します。具体的には、既知の正常な PoE 非対応のイーサネット装置とイーサネット ケーブルを接続して、受電デバイスがリンクを確立し他のホストとトラフィックを交換することを確認します。
スイッチのフロント パネルから受電デバイスまでのケーブル長の合計が 100 メートル以下であることを確認します。 スイッチ ポートからイーサネット ケーブルを外します。短いイーサネット ケーブルを使用して、既知の正常なイーサネット装置を、スイッチのフロント パネルの(パッチ パネルではない)このポートに直接接続します。これによってイーサネット リンクが確立され他のホストとトラフィックを交換できることを確認します。あるいは、ポートの VLAN SVI で ping を実行してください。次に、受電デバイスをこのポートに接続し、電源がオンになることを確認します。 パッチ コードをスイッチ ポートに接続しても受電デバイスの電源がオンにならない場合、接続する受電デバイスの合計数とスイッチの電力バジェット(使用可能な PoE)とを比較してください。show inline power コマンドを使用して、利用可能な電源の量を確認します。 |
||||
すべてのポートまたは 1 つのポート グループで PoE が機能しない。 すべてのスイッチ ポートで問題が発生する。電力が供給されていないイーサネット装置がどのポートでもイーサネット リンクを確立できず、PoE 装置の電源がオンになりません。 |
電力に関するアラームが継続的に発生する、断続的に発生する、または再発する場合は、可能であれば電源モジュールを交換します(現場交換可能ユニットです)。そうでない場合はスイッチを交換してください。 連続する複数のポートで問題があるものの、すべてのポートで問題が発生するわけではない場合、電源の故障ではないと考えられ、スイッチの PoE レギュレータに関連した異常の可能性があります。 PoE の状況やステータスの変更について過去に報告されているアラームまたはシステム メッセージを確認するには、show log 特権 EXEC コマンドを使用します。 アラームがない場合は、show interface status コマンドを使用して、ポートがシャットダウンしていないか errdisable になっていないかを確認します。ポートが error-disabled の場合、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 phone またはワイヤレス アクセス ポイントが断続的にリロードしたり、PoE から切断されたりします。 |
スイッチから受電デバイスまでのすべての電気系統を確認してください。信頼性の低い接続は、電力供給の中断や受電デバイスの機能が不安定になる原因となり、受電デバイスの断続的な切断やリロードなどが発生します。 スイッチ ポートから受電デバイスまでのケーブル長が 100 メートル以下であることを確認してください。 スイッチが配置されている場所で電気環境にどのような変化があるか、切断時に、受電デバイスに何が起きるかについて注意してください。 切断と同時にエラー メッセージが表示されたか注意します。show log 特権 EXEC コマンドを使用してエラー メッセージを確認します。 リロードの発生直前に IP Phone から Call Manager へのアクセスが失われていないか確認してください(PoE の障害ではなくネットワークに問題が発生している場合があります)。 受電デバイスを PoE 非対応の装置に交換し、装置が正しく動作することを確認します。PoE 非対応の装置にリンク障害または高いエラー率がある場合、スイッチ ポートと受電デバイスを接続する信頼性の低いケーブル接続が問題の可能性があります。 |
||||
IEEE 802.3af 準拠または IEEE 802.3at 準拠の受電装置は、Cisco PoE スイッチでは機能しません。 シスコ PoE スイッチに接続するシスコ以外の受電デバイスに電源が供給されないか、電源投入後すぐに電源が切れます。PoE 非対応装置は正常に動作します。 |
show power inline コマンドを使用して、受電デバイスの接続前後に、スイッチの電力バジェット(使用可能な PoE)が使い果たされていないか確認してください。受電デバイスを接続する前に、このタイプの装置に十分な電力が使用可能であることを確認します。 show interface status コマンドを使用して、接続されている受電デバイスをスイッチが検出することを確認します。 show log コマンドを使用して、ポートの過電流状態を報告したシステム メッセージがないか確認します。症状を正確に特定してください。最初に電力が受電デバイスに供給され、その後、切断される状態ですか。その場合は、問題は最初のサージ電流(突入電流)が原因で、ポートの電流上限しきい値が超過した可能性があります。 |
次に、IP ホストに ping を実行する例を示します。
Device# 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 Device#
文字 |
説明 |
---|---|
! |
感嘆符 1 個につき 1 回の応答を受信したことを示します。 |
. |
ピリオド 1 個につき応答待ちの間にネットワーク サーバのタイムアウトが 1 回発生したことを示します。 |
U |
宛先到達不能エラー PDU を受信したことを示します。 |
C |
輻輳に遭遇したパケットを受信したことを示します。 |
I |
ユーザによりテストが中断されたことを示します。 |
? |
パケット タイプが不明です。 |
& |
パケットの存続時間を超過したことを示します。 |
ping セッションを終了するには、エスケープ シーケンス(デフォルトでは Ctrl+^ X)を入力してください。Ctrl キー、Shift キー、および 6 キーを同時に押してから放し、その後 X キーを押します。
次に、IP ホストに traceroute を実行する例を示します。
Device# 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 アドレス、およびラウンドトリップ タイム(ミリ秒単位)が表示されます。
文字 |
説明 |
---|---|
* |
プローブがタイムアウトになりました。 |
? |
パケット タイプが不明です。 |
A |
管理上、到達不能です。通常、この出力は、アクセス リストがトラフィックをブロックしていることを表しています。 |
H |
ホストが到達不能です。 |
N |
ネットワークが到達不能です。 |
P |
プロトコルが到達不能です。 |
Q |
発信元。 |
U |
ポートが到達不能です。 |
実行中の追跡を終了するには、エスケープ シーケンス(デフォルトでは Ctrl+^ X)を入力してください。Ctrl キー、Shift キー、および 6 キーを同時に押してから放し、その後 X キーを押します。
リリース |
変更箇所 |
---|---|
Cisco IOS XE Everest 16.5.1a |
この機能が導入されました。 |