ソフトウェア設定のトラブルシューティングに関する情報
スイッチのソフトウェア障害
スイッチ ソフトウェアがアップグレード中に破損する原因として、誤ったファイルがスイッチにダウンロードされた場合やイメージ ファイルが削除された場合があります。いずれの場合にも、スイッチは電源投入時自己診断テスト(POST)に失敗し、接続できなくなります。ソフトウェア障害から回復するには、「ソフトウェア障害からの回復」セクションで説明されている手順を実行します。
デバイスのパスワードを紛失したか忘れた場合
デバイスのデフォルト設定では、デバイスを直接操作するエンドユーザが、スイッチの電源投入時に起動プロセスを中断して新しいパスワードを入力することにより、パスワードを紛失した状態から回復できます。ここで紹介する回復手順を実行するには、デバイスを直接操作してください。
![]() (注) |
これらのデバイスでは、システム管理者はデフォルト設定に戻す場合に限りエンドユーザーによるパスワードのリセットを許可することによって、この機能の一部をディセーブルにできます。パスワード回復がディセーブルになっている場合に、エンド ユーザーがパスワードをリセットしようとすると、ステータス メッセージで回復プロセスの間はデフォルトの設定に戻すように指示されます。 |
![]() (注) |
Cisco WLC の設定を複数の Cisco WLC 間でコピーすると、暗号化パスワード キーを回復できなくなります(RMA の場合)。 |
パスワードを紛失または忘れた場合にそのパスワードを回復するには、パスワードを忘れた場合の回復の項で説明する手順に従います。
Power over Ethernet(PoE)ポート
Power over Ethernet(PoE)スイッチ ポートでは、回路に電力が供給されていないことをスイッチが検知した場合、接続している次のデバイスに電力が自動的に供給されます。
-
シスコ先行標準受電デバイス(Cisco IP Phone や Cisco Aironet アクセス ポイントなど)
-
IEEE 802.3af 準拠の受電装置
-
IEEE 802.3at 準拠の受電装置
受電デバイスが 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 ステートになることがあります。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 メッセージが返されます。
ping の動作を理解するには、ping の実行の項を参照してください。
レイヤ 2 トレースルート
レイヤ 2 トレースルート機能により、パケットが通過する送信元デバイスから宛先デバイスまでの物理パスを識別できます。レイヤ 2 トレースルートは、ユニキャストの送信元および宛先 MAC アドレスだけをサポートします。トレースルートは、パス内にあるデバイスの MAC アドレステーブルを使用してパスを識別します。デバイスがパス内でレイヤ 2 トレースルートをサポートしていないデバイスを検知した場合、デバイスはレイヤ 2 トレースクエリを送信し続け、タイムアウトにします。
デバイスは、送信元デバイスから宛先デバイスへのパスのみを識別できます。パケットが通過する、送信元ホストから送信元デバイスまで、または宛先デバイスから宛先ホストまでのパスは識別できません。
レイヤ 2 の traceroute のガイドライン
-
ネットワーク内のすべてのデバイスで、Cisco Discovery Protocol(CDP)をイネーブルにする必要があります。レイヤ 2 traceroute が適切に動作するために、CDP を無効にしないでください。
物理パス内のデバイスが CDP に対して透過的な場合、スイッチはこれらのデバイスを通過するパスを識別できません。
-
ping 特権 EXEC コマンドを使用して接続をテストできれば、このデバイスは別のデバイスから到達可能であると定義できます。物理パス内のすべてのデバイスは、他のデバイスから相互に到達可能でなければなりません。
-
パス内で識別可能な最大ホップ数は 10 です。
-
送信元デバイスと宛先デバイスの間の物理パス内にないデバイスで、traceroute mac または traceroute mac ip の特権 EXEC コマンドを実行できます。パス内のすべてのデバイスは、このスイッチから到達可能でなければなりません。
-
指定された送信元および宛先アドレスが同じ VLAN にある場合、traceroute mac コマンド出力はレイヤ 2 パスを表示します。指定した送信元および宛先 MAC アドレスが、それぞれ異なる VLAN に属している場合は、レイヤ 2 パスは識別されず、エラー メッセージが表示されます。
-
マルチキャストの送信元または宛先 MAC アドレスを指定すると、パスは識別されず、エラー メッセージが表示されます。
-
送信元または宛先 MAC アドレスが複数の VLAN に属する場合は、送信元および宛先 MAC アドレスの両方が属している VLAN を指定する必要があります。VLAN を指定しないと、パスは識別されず、エラー メッセージが表示されます。
-
指定された送信元および宛先の IP アドレスが同一のサブネット内にある場合、traceroute mac ip コマンド出力はレイヤ 2 パスを表示します。IP アドレスを指定した場合、デバイスは Address Resolution Protocol(ARP)を使用し、IP アドレスとそれに対応する MAC アドレスおよび VLAN ID を対応させます。
-
指定の IP アドレスの ARP のエントリが存在している場合、デバイスは関連付けられた MAC アドレスを使用し、物理パスを識別します。
-
ARP のエントリが存在しない場合、デバイスは ARP クエリを送信し、IP アドレスを解決しようと試みます。IP アドレスが解決されない場合は、パスは識別されず、エラー メッセージが表示されます。
-
-
複数のデバイスがハブを介して 1 つのポートに接続されている場合(たとえば複数の CDP ネイバーがポートで検出された場合)、レイヤ 2 traceroute 機能はサポートされません。複数の CDP ネイバーが 1 つのポートで検出された場合、レイヤ 2 パスは特定されず、エラー メッセージが表示されます。
-
この機能は、トークンリング VLAN ではサポートされません。
-
レイヤ 2 トレースルートは、ユーザ データグラム プロトコル(UDP)ポート 2228 でリスニングソケットを開きます。このポートは、任意の IPv4 アドレスを使用してリモートからアクセスでき、認証は必要ありません。この UDP ソケットにより、VLAN 情報、リンク、特定の MAC アドレスの存在、および CDP ネイバー情報をデバイスから読み取ることができます。この情報を使用することにより、最終的にレイヤ 2 ネットワークトポロジの全体像を構築できます。
-
レイヤ 2 トレースルートはデフォルトで有効になっており、グローバル コンフィギュレーション モードで no l2 traceroute コマンドを実行することによって無効にできます。レイヤ 2 トレースルートを再度有効にするには、グローバル コンフィギュレーション モードで l2 traceroute コマンドを使用します。
IP トレースルート
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 ガイドライン
Time Domain Reflector(TDR)機能を使用すると、ケーブル配線の問題を診断して解決できます。TDR 稼働時、ローカル デバイスはケーブルを介して信号を送信して、最初に送信した信号と反射された信号を比べます。
-
ツイストペア ケーブルの導線のオープン、損傷、切断:導線がリモート デバイスからの導線に接続されていない状態。
-
ツイストペア ケーブルの導線のショート:導線が互いに接触している状態、またはリモート デバイスからの導線に接触している状態。たとえば、ツイスト ペア ケーブルの一方の導線が、もう一方の導線にはんだ付けされている場合、ツイストペア ケーブルのショートが発生します。
ツイストペアの導線の一方がオープンになっている場合、TDR はオープンになっている導線の長さを検出できます。
次の状況で TDR を使用して、ケーブル障害を診断および解決してください。
-
デバイスの交換
-
配線クローゼットの設定
-
リンクが確立できない、または適切に動作していない場合における、2 つのデバイス間の接続のトラブルシューティング
TDR の実行時、次の場合にデバイスは正確な情報をレポートします。
-
ギガビット リンク用のケーブルが単線コア ケーブル
-
オープンエンド ケーブルが未終端
TDR の実行時、次の場合にデバイスは正確な情報をレポートしません。
-
ギガビット リンク用のケーブルがツイストペア ケーブルまたは連続接続された単線コア ケーブル
-
リンクが 10 Mb または 100 Mb
-
より線ケーブル
-
リンク パートナーが Cisco IP Phone
-
リンク パートナーが IEEE 802.3 に準拠していない
TDR の実行および結果の表示に移動し、TDR のコマンドを確認します。
debug コマンド
![]() 注意 |
デバッグ出力は 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 switch active コマンドを使用します。
Device# request platform software process core fed switch active
SUCCESS: Core file generated.
Device# dir bootflash:/core
Directory of bootflash:/core/
16430 -rw- 10941657 Apr 6 2022 00:15:20 +00:00 Switch_1_RP_0_fed_18469_20220406-001511-UTC.core.gz
16812 -rw- 1 Apr 6 2022 00:01:48 +00:00 .callhome
16810 drwx 4096 Jan 18 2022 21:10:35 +00:00 modules
crashinfo ファイル
デフォルトでは、生成されたシステム レポート ファイルは /crashinfo ディレクトリに格納されます。Ifit は、領域不足のため crashinfo パーティションに保存できません。そのため、/flash ディレクトリに保存されます。
ファイルを表示するには、dir crashinfo: コマンドを入力します。次に crashinfo ディレクトリの出力例を示します。
Device# 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 などいくつかのオプションを使用して、さらにコピーできます。
Device# 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 サーバーにコピーするための一般的な構文は次のとおりです。
Device# 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 コマンドを発行することで収集できます。このコマンドには、時間帯オプションがあります。コマンド構文は次のとおりです。
Device# request platform software trace archive ?
last Archive trace files of last x days
target Location and name for the archive file
crashinfo: または flash: ディレクトリに格納されている過去 3650 日以内のトレースログが取得できます。
Device# 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)、およびシリアル番号。
-
メッセージ:スタンドアロンデバイスまたはスイッチスタックメンバにより生成されたハードウェア関連のシステムメッセージの記録。
-
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 の処理の失敗