ソフトウェア設定のトラブルシューティングに関する情報
スイッチのソフトウェア障害
スイッチ ソフトウェアがアップグレード中に破損する原因として、誤ったファイルがスイッチにダウンロードされた場合やイメージ ファイルが削除された場合があります。これらのどの場合も、接続はありません。ソフトウェア障害から回復するには、ソフトウェア障害からの回復の項で説明されている手順に従います。
デバイスのパスワードを紛失したか忘れた場合
デバイスのデフォルト設定では、デバイスを直接操作するエンドユーザが、スイッチの電源投入時に起動プロセスを中断して新しいパスワードを入力することにより、パスワードを紛失した状態から回復できます。ここで紹介する回復手順を実行するには、デバイスを直接操作してください。
(注) |
これらのデバイスでは、システム管理者はデフォルト設定に戻す場合に限りエンドユーザによるパスワードのリセットを許可することによって、この機能の一部をディセーブルにできます。パスワード回復がディセーブルになっている場合に、エンド ユーザがパスワードをリセットしようとすると、ステータス メッセージで回復プロセスの間はデフォルトの設定に戻すように指示されます。 |
(注) |
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 トレースルート
レイヤ 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 プロセスの例を参照してください。
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 ディレクトリの出力例を示します。
システムレポートは、次の形式で 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 ディレクトリからクリアし、トレースログやその他の目的に使用できる領域を確保することが重要です。 |
複雑なネットワークでは、システムレポートファイルの送信元を追跡することは困難です。システムレポートファイルが一意に識別できる場合、この作業は簡単になります。Cisco IOS XE Amsterdam 17.3.x リリース以降、システムレポートファイル名の前にホスト名が追加され、レポートが一意に識別できるようになります。
次の例では、ホスト名が先頭に追加されたシステムレポートファイルを表示します。
HOSTNAME#dir flash:/core | grep HOSTNAME
40486 -rw- 108268293 Oct 21 2019 16:07:50 -04:00 HOSTNAME-system-report_20191021-200748-UTC.tar.gz
40487 -rw- 17523 Oct 21 2019 16:07:56 -04:00 HOSTNAME-system-report_20191021-200748-UTC-info.txt
40484 -rw- 48360998 Oct 21 2019 16:55:24 -04:00 HOSTNAME-system-report_20191021-205523-UTC.tar.gz
40488 -rw- 14073 Oct 21 2019 16:55:26 -04:00 HOSTNAME-system-report_20191021-205523-UTC-info.txt
スイッチのオンボード障害ロギング
オンボード障害ロギング(OBFL)機能を使用すれば、デバイスに関する情報を収集できます。この情報には稼働時間、温度、電圧などの情報が含まれており、シスコのテクニカルサポート担当者がデバイスの問題をトラブルシューティングする際に役立ちます。OBFL はイネーブルにしておき、フラッシュ メモリに保存されたデータは消さないようにすることを推奨します。
OBFL は、デフォルトでイネーブルになっています。デバイスおよび Small Form-Factor Pluggable(SFP)モジュールに関する情報が収集されます。デバイスは、次の情報をフラッシュメモリに保存します。
-
CLI コマンド:スタンドアロンデバイスに入力された OBFL CLI コマンドの記録。
-
メッセージ:スタンドアロンデバイスにより生成されたハードウェア関連のシステムメッセージの記録。
-
Power over Ethernet(PoE):スタンドアロンデバイスの PoE ポートの消費電力の記録。
-
温度:スタンドアロンデバイスの温度。
-
稼働時間:スタンドアロンデバイスが起動された際の時刻、デバイスが再起動された理由、およびデバイスが最後に再起動されて以来の稼働時間。
-
電圧:スタンドアロンデバイスのシステム電圧。
システム時計は、手動で時刻を設定するか、またはネットワーク タイム プロトコル(NTP)を使用するように設定します。
デバイスの稼働中には、show logging onboard 特権 EXEC コマンドを使用することにより、OBFL データを取得できます。デバイスに障害が発生した場合のデータの取得方法については、お客様担当のシスコテクニカルサポート担当者にお問い合わせください。
OBFL がイネーブルになっているデバイスが再起動された場合、新しいデータの記録が開始するまでに 10 分間の遅延があります。
ファン障害
デフォルトでは、この機能はディセーブルです。現場交換可能ユニット(FRU)または電源装置の複数のファンが故障した場合、デバイスはシャットダウンせず、次のようなエラー メッセージが表示されます。
デバイスが過熱状態となり、シャットダウンすることもあります。
デバイスを再起動するには、電源をオフにしてから再度オンにする必要があります。
CPU 使用率が高い場合に起こりうる症状
CPU 使用率が高すぎることで次の現象が発生する可能性がありますが、他の原因で発生する場合もあります。次にその一部を示します。
-
スパニングツリー トポロジの変更
-
通信が切断されたために EtherChannel リンクがダウンした
-
管理要求(ICMP ping、SNMP のタイムアウト、低速な Telnet または SSH セッション)に応答できない
-
UDLD フラッピング
-
SLA の応答が許容可能なしきい値を超えたことによる IP SLA の失敗
-
スイッチが要求を転送しない、または要求に応答しない場合の DHCP または IEEE 802.1x の処理の失敗