ソフトウェア設定のトラブルシューティングに関する情報
スイッチのソフトウェア障害
スイッチ ソフトウェアがアップグレード中に破損する原因として、誤ったファイルがスイッチにダウンロードされた場合やイメージ ファイルが削除された場合があります。これらのどの場合も、スイッチは、電源投入時自己診断テスト(POST)に合格せず、接続はありません。ソフトウェア障害から回復するには、ソフトウェア障害からの回復の項で説明されている手順に従います。
のパスワードを紛失したか忘れた場合 デバイス
デバイスのデフォルト設定では、デバイスに物理的にアクセスしているエンドエンド ユーザは、スイッチの電源投入中に起動プロセスを中断して新しいパスワードを入力することにより、パスワードを紛失した状態から回復できます。ここで紹介する回復手順を実行するには、デバイスに物理的にアクセスする必要があります。
(注) |
これらのデバイスでは、システム管理者は、デフォルト設定に戻すことに同意した場合に限り、エンド ユーザによるパスワードのリセットを許可することによって、この機能の一部をディセーブルにできます。パスワード回復がディセーブルになっている場合に、エンド ユーザがパスワードをリセットしようとすると、ステータス メッセージで回復プロセスの間はデフォルトの設定に戻すように指示されます。 |
(注) |
Cisco WLC の設定を複数の Cisco WLC 間でコピーすると、暗号化パスワード キーを回復できなくなります(RMA の場合)。 |
パスワードを紛失または忘れた場合にそのパスワードを回復するには、パスワードを忘れた場合の回復の項で説明する手順に従います。
Ping
デバイスは IP の ping をサポートしており、これを使ってリモート ホストへの接続をテストできます。ping はアドレスにエコー要求パケットを送信し、応答を待ちます。ping は次のいずれかの応答を返します。
-
正常な応答:正常な応答(hostname が存在する)は、ネットワーク トラフィックにもよりますが、1 ~ 10 秒以内で発生します。
-
宛先の応答なし:ホストが応答しない場合、no-answer メッセージが返されます。
-
不明なホスト:ホストが存在しない場合、unknown host メッセージが返されます。
-
宛先到達不能:デフォルト ゲートウェイが指定されたネットワークに到達できない場合、destination-unreachable メッセージが返されます。
-
ネットワークまたはホストへの到達不能:ルート テーブルにホストまたはネットワークのエントリがない場合、network or host unreachable メッセージが返されます。
ping の動作を理解するには、ping の実行の項を参照してください。
レイヤ 2 Traceroute
レイヤ 2 traceroute 機能により、パケットが通過する、送信元デバイスから宛先デバイスへの物理パスを識別できます。レイヤ 2 traceroute は、ユニキャストの送信元および宛先 MAC アドレスだけをサポートします。transroute は、パス内にあるデバイスの MAC アドレス テーブルを使用してパスを識別します。デバイスがパス内でレイヤ 2 traceroute をサポートしていないデバイスを検知した場合、デバイスはレイヤ 2 trace クエリーを送信し続け、タイムアウトにします。
デバイスは、送信元デバイスから宛先デバイスへのパスのみを識別できます。パケットが通過する、送信元ホストから送信元デバイスまで、または宛先デバイスから宛先ホストまでのパスは識別できません。
レイヤ 2 の traceroute のガイドライン
-
ネットワーク内のすべてのデバイスで、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 を指定しないと、パスは識別されず、エラー メッセージが表示されます。
- 指定した送信元および宛先の 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 ではサポートされません。
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 ポート到達不能エラーを送信します。ポート到達不能エラーを除くすべてのエラーは中間ホップから送信されるため、ポート到達不能エラーを受信するということは、このメッセージが宛先ポートから送信されたことを意味します。
例:IP ホストに対する traceroute の実行に進み、IP traceroute プロセスの例を参照してください。
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 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 ファイル
デフォルトでは、生成されたシステム レポート ファイルは /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 使用率が高い場合に起こりうる症状
CPU 使用率が高すぎることで次の現象が発生する可能性がありますが、他の原因で発生する場合もあります。次にその一部を示します。
-
スパニングツリー トポロジの変更
-
通信が切断されたために EtherChannel リンクがダウンした
-
管理要求(ICMP ping、SNMP のタイムアウト、低速な Telnet または SSH セッション)に応答できない
-
UDLD フラッピング
-
SLA の応答が許容可能なしきい値を超えたことによる IP SLA の失敗
-
スイッチが要求を転送しない、または要求に応答しない場合の DHCP または IEEE 802.1x の処理の失敗