動画と記事で学ぶ / Cisco・実機操作
Cisco show versionの出力をどこから読むかを解説。IOS／IOS XEの稼働版、uptime、前回再起動の手掛かり、起動イメージ、機種を表で整理し、show boot・show inventory・ログとの照合手順を示します。
ここからは、記事でゆっくり確かめましょう。図や操作の例を見ながら、気になるところから読み進めてください。
機器へログインして最初にshow versionを取る、と教わることがあります。バージョンだけなら一行で済みそうですが、このコマンドには機器の状態を調べる手掛かりがまとまっています。
稼働中のOS、起動したイメージ、稼働時間、前回の起動に関する情報などを見ます。表示項目はCiscoの製品や版で違うので、一つの画面例をすべての機器へ当てはめず、「何を確かめたいか」から読んでいきましょう。
最初に、対象機器と今動いているOSを確認する
SoftwareやVersionの行は、現在動いているOSの情報です。機器名、機種、取得時刻と一緒に保存すると、更新前後や障害時の状態を比較できます。
System image fileには起動に使ったイメージなどが表示されます。ただし、今起動したものと、次回起動に指定されているものは別に確認します。保存した設定が変わっていれば、次の再起動で違う版になることもあります。
| 出力の行 | 読む内容 | 照合先 |
|---|---|---|
| Software / Version | 稼働中のOSとリリース | 変更計画・既知不具合・セキュリティ情報 |
| uptime | 現在の連続稼働時間 | 監視アラート・作業時刻 |
| System returned to ROM / Last reload reason | 装置に残る再起動理由の手掛かり | syslog・クラッシュ情報・電源記録 |
| System image file | 今回起動したイメージ | show boot、保存済みイメージ |
| Model / Processor board ID | 機種・識別情報 | show inventoryと機器台帳 |
show versionでSoftware／VersionとSystem image fileを記録する。show boot（対応機種）で次回起動の指定を確認する。- リリースノートと対象PIDのEoX告知を、稼働版・機種の組で照合する。
IOS XEではinstallモードなど、製品によって起動方式が異なります。show bootや関連表示と照合し、対象製品の手順を使います。
uptimeと再起動理由は、ログと合わせて読む
uptimeは稼働を続けている時間です。昨日まで長く稼働していた機器の値が短くなっていれば、その間に再起動した可能性があります。
再起動の理由にはpower-on、reloadなどの表示があります。電源の入り直しや再起動操作を考える手掛かりですが、それだけで故障原因を確定しません。
| 表示 | 意味 | 次に見るところ |
|---|---|---|
| power-on | 電源が入り直した | 停電、電源ケーブル、UPS、PoE給電元 |
| reload | 人がreloadコマンドを実行した | 作業記録との照合。誰がいつ実施したか |
| reload command | 同上（表記は機種・バージョンで異なる） | 同上 |
| error / exception | ソフトウェア例外などで再起動した | クラッシュ情報の有無、既知不具合の該当 |
同じ時刻の装置ログ、作業記録、電源やUPSの記録、クラッシュ情報を照合します。電源が落ちたのか、予定したreloadなのか、異常終了なのかで、次に調べる場所が変わります。
時刻が合っていない機器ではログの比較も難しくなります。取得時刻と装置の時刻を分けて残しておくと、後から調査しやすくなります。
コンフィグレジスタは、適用される機種で読む
従来のIOSルーターでは、Configuration registerが起動時の動作を決めます。0x2102や0x2142という値は、その環境で設定を読み込むかなどを確認する材料です。
パスワードリカバリで設定を無視する状態にした場合、通常の起動へ戻したかを確認する必要があります。ただし、この値の説明をすべてのCatalystへ当てはめることはできません。
- 0x2102：startup-configを読み込んで通常起動する（標準）
- 0x2142：startup-configを読み飛ばす。パスワードリカバリの手順で使う値
Catalyst 9000のIOS XEでは、従来のconfig-registerではなく、対応する起動設定やROMMON変数を確認する場面があります。show versionに値が見えたことだけで、実際の起動動作を判断しないでください。
対象機種の起動・復旧ガイドで、何の値が有効かを調べます。機種を確かめず、理由の分からない数値変更を行う必要はありません。
本体とモジュールの情報を、inventoryで補う
保守や交換には、製品PIDとシリアルが必要です。PIDは製品型番、シリアルは個体を識別する番号です。show inventoryでは、本体だけでなくモジュールやSFPの情報を確認できる場合があります。
show versionに表示された本体の情報だけで、交換する部品まで特定できたとは限りません。対象部品の単位で取得します。
| コマンド | 取れるもの |
|---|---|
show inventory |
本体とモジュール、SFPそれぞれのPIDとシリアル |
show platform |
スタック構成やスロットの実装状況（機種により出力が異なる） |
show boot |
次回起動に使うイメージの指定（BOOT variable） |
dir flash: |
flash上のイメージファイルと空き容量 |
- 型番から保守期限を引く
show inventoryのPIDでEoX告知を検索し、LDoSを確認します。詳細はEOSとEOLの違いにまとめています。 - ソフトウェア側の期限も確認する
ハードがLDoS前でも、稼働中のリリースのEnd of SW Maintenanceが先に来ていることがあります。 - 該当する不具合がないか確認する
バージョンと機種を条件に、公開されている不具合情報とセキュリティアドバイザリを確認します。 - アップグレードの必要性を判断する
不具合の影響が自社の使い方に当てはまるかで決めます。バージョンが古いこと自体は理由になりません。
EOS・EOLの告知を調べるときは、そのPIDが対象一覧に入っているかを確認します。不具合調査ではOS版に加え、構成や発生条件が該当するかを照合します。
「同じシリーズだから同じ不具合」とせず、正式な型番と版をそろえることが、問い合わせや更改判断の出発点になります。
一回の出力を、後から比較できる記録にする
機器名、設置場所、PID、シリアル、稼働OS、起動方式、取得時刻を台帳へ整理します。長い出力の原本も残し、台帳の値へ戻って確かめられるようにします。
更新作業なら、前後を同じコマンドで取得します。版が変わったことだけでなく、意図したイメージで起動し、設定とサービスが戻ったことも別の確認で確かめます。
- 機器名、設置拠点、ラック位置
- 型番（PID）とシリアル（本体・モジュール・SFP）
- 稼働中のバージョンと、System image fileのファイル名
- コンフィグレジスタの値
- 取得日時と取得者
- 次回のアップグレード予定と、その判断理由
show versionは、版、稼働時間、起動の手掛かりを読む入口です。最初は一つの出力から、今のOS、いつ起動したか、何を追加で確認するかを拾ってみてください。
項目をすべて暗記するより、その行から言えることと言えないことを分けるほうが、実際の調査で使いやすくなります。
確認に使った公式資料
