Cisco Catalyst 6500 シリーズ

この資料では、Cisco^® Catalyst^® 6500シリーズ スイッチのモジュール型Cisco IOS^®ソフトウェアの利点、特長、および機能について技術的な観点から説明します。

はじめに

音声、ビデオ、およびデータ アプリケーションなどのミッションクリティカルなトラフィックに対応するネットワークには、ネットワーキング デバイスのダウンタイムを縮小することが求められます。通常、コア レイヤやディストリビューション レイヤでは、システムの冗長化によってハイ アベイラビリティが実現されています。しかし、エンド デバイスのシングルポイント オブ フェイラーになりやすいワイヤリング クローゼット、データ センタ アクセス、およびWANエッジの耐障害性を高めることも非常に重要です。メトロ イーサネット アクセス ネットワークでも、お客様に対する厳しいサービス レベル アグリーメント（SLA）を満たすため、同様の要件が求められます。ビジネスにおけるネットワーク アプリケーションへの依存度はますます高まっているため、ネットワーク オペレータや管理者はアベイラビリティと信頼性を最も重視しています。

モジュール型Cisco IOSソフトウェアを搭載したCisco Catalyst 6500シリーズは、最先端のソフトウェア インフラストラクチャによって、運用の効率化とダウンタイムの最小化を実現します。モジュール化されたCisco IOSサブシステムが独立したプロセスとして稼働するため、自己回復プロセスにより予期しないダウンタイムが最小限に抑えられます。また、サブシステムIn-Service Software Upgrade（Subsystem ISSU）によってソフトウェアの変更が容易になり、さらにEmbedded Event Manager（EEM）の統合によってプロセスレベルのポリシー制御を自動化することができます。

Cisco Catalyst 6500シリーズのモジュール型Cisco IOSソフトウェア

Cisco IOSは、IPサービスへの対応や、ネットワークへの拡張に対応できるコントロール プレーンのスケーラビリティに対応できるように設計されています。Cisco IOSソフトウェアは、それぞれがテクノロジーの一部を担う数百のサブシステムで構成されており、これらはソフトウェアによるフォワーディング パフォーマンスを最大化するために共有メモリ領域で実行されます。

図1 Cisco Catalyst 6500シリーズのモジュール型Cisco IOSソフトウェア アーキテクチャ - コントロール プレーンとデータ プレーンがそれぞれ独立したプロセスになっている

Cisco Catalyst 6500シリーズは、Policy Feature Card（PFC;ポリシー フィーチャ カード）またはDistributed Forwarding Card（DFC）上のASICによってハードウェア ベースのフォワーディングを実装しています。Catalyst 6500シリーズのコントロール プレーン機能は、Multilayer Switch Forwarding Card（MSFC;マルチレイヤ スイッチ フィーチャ カード）上の専用CPUで実行されます。

• コントロール プレーン - ルーティング プロトコルや管理トラフィックなどの制御トラフィックを処理
• データ プレーン - ASICを使用して実際にトラフィックのフォワーディングを行う

データ プレーンが完全に分離されているため、コントロール プレーンに障害が発生しても、ハードウェアを動作させるのに必要なソフトウェア機能が維持されるかぎり、トラフィック フォワーディングは継続します。また、スーパーバイザ エンジンを冗長化した構成にすると、Catalyst 6500シリーズのNon-Stop Forwarding（NSF）やStateful Switch Over（SSO）機能により、アクティブ スーパーバイザ エンジンにハードウェア障害が発生した場合でもデータ プレーンの処理を継続することができます。障害分離やコントロール プレーンとデータ プレーンを分離する必要性は、OS（オペレーティング システム）レベルにまで影響を与えています。つまり、コントロール プレーン ソフトウェアに変更や問題が発生した場合でも、データ プレーンのフォワーディングに影響を与えないようにする必要があります。

モジュール型Cisco IOSソフトウェアでは、複数のサブシステムを組み合わせて個々のプロセスが構成され、メモリ アーキテクチャの強化が図られています。これは、プロセス レベルでの障害の分離を可能にし、サブシステムISSU機能を提供するためです。これらの拡張機能は、Catalyst 6500シリーズのSupervisor Engine 720とSupervisor Engine 32のCisco IOSソフトウェアで実現されており、ネットワーク オペレータがこれまで使用してきたCisco IOSソフトウェアの豊富な機能や動作環境はそのまま維持されています。モジュール型Cisco IOSソフトウェアは、Cisco IOSソフトウェア リリース12.2(18)SXFで最初に提供される予定です。

一貫した管理性
モジュール型ソフトウェアはCatalyst 6500シリーズ スイッチのCisco IOSソフトウェアにさまざまな拡張機能を提供しますが、運用面において必要な変更はありません。管理インターフェイスに関連するインターフェイス（SNMPやSyslogなど）およびCLI（コマンドライン インターフェイス）はこれまでと同じです。新しい機能をサポートするために、showコマンドの他にEXECモードやコンフィギュレーション モードにコマンドが新しく追加されています。ソフトウェア リリースおよびリビルドはこれまでと同じで、サブシステム パッチが新しくサポートされています。

保護されたメモリ領域
モジュール型ソフトウェアのメモリ アーキテクチャでは、プロセスは保護されたアドレス領域を使用できます。各プロセスと関連するサブシステムは、個別のメモリ領域を使用します。同一プロセスのサブシステムは相互に直接通信できますが、プロセス間での情報の通信には規定のInter Process Communication（IPC;プロセス間通信）を使用する必要があります。このパラダイムの導入により、複数のプロセスにまたがるメモリの破損は事実上発生しません。同一プロセス内のサブシステム間では直接通信できるため、コントロール プレーンは常に優れたパフォーマンスを発揮できます。

障害の封じ込め
プロセスごとに保護されたメモリ領域を使用することで、システム全体のアベイラビリティが向上します。これは、1つのプロセスに不具合が発生してもシステムの他の部分が影響を受けずに済むためです。たとえば、比較的クリティカルではないシステム プロセスに障害が発生したり、異常があることが判明した場合でも、パケット フォワーディングを維持するのに必要とされるクリティカルな機能が影響を受けることはありません。具体的には、UDPプロセスに障害が発生した場合、影響を受けるのはUDPを使用する機能に限られます。

プロセスのリスタート機能
メモリ領域の保護と障害の封じ込めによって、モジュール型プロセスは個別にリスタートできるようになっています。テストを行う場合やプロセスが応答しない場合に備えて、プロセスを手動でリスタートするCLIが用意されています。この機能を使用すると、フォワーディングを中断せずに一時的なエラーから迅速に復旧できます。

プロセスの手動リスタート機能は重要ですが、プロセスの状態を継続的にチェックすることも非常に重要です。統合型ハイ アベイラビリティ サブシステムは、プロセスの状態を常にチェックし、一定の期間内にプロセスがリスタートされた回数を記録します。このハイ アベイラビリティ サブシステムはプロセスのリスタート機能を提供して、さまざまな障害からの迅速な復旧を可能にします。プロセスをリスタートしてもシステムが復旧しない場合、ハイ アベイラビリティ サブシステムはスーパーバイザ エンジンのスイッチオーバーやシステムのリスタートといった処理を行います。

各プロセスはそれぞれ固有の保護環境を有しているため、必要に応じてステート情報のチェックポイント機能を利用できます。チェックポイント アーキテクチャを使用すると、プロセスのリスタートやフェールオーバーが行われている場合でもステート情報は維持されます。ハイ アベイラビリティ サブシステムは、プロセスのリスタート時にこの情報を利用してステートフルな復旧を可能にします。リスタートされるプロセスは、チェックポイント情報（IS-ISルーティング プロトコルの状態など）を使用して迅速な復旧を行います。チェックポイント情報が使用できるのは、指定されたインターバルで最初にプロセスがリスタートされる場合に限られます。これは、チェックポイントのステート情報そのものがエラーの原因になることを防ぐためです。

モジュール化されたプロセス
さまざまなコントロール プレーンの機能は、最も一般的な特徴を取り入れてモジュール化されています。モジュール型プロセスには、IPルーティング（RIP、EIGRP、OSPF、IS-IS、BGP）、TCP、UDP、CDP、EEM、およびインストーラなどがあります。

このアーキテクチャを使用するとCisco IOSソフトウェアのさらなるモジュール化が可能になるため、最新のモジュール型ソフトウェアでは、より多くの独立したモジュール型プロセスを使用できます。

サブシステムIn-Service Software Upgrades（Subsystem ISSU）
保護されたメモリ領域とプロセス リスタート機能の最大の利点は、システムの稼働中に変更を加えられることです。モジュール型Cisco IOSソフトウェアではCisco IOSインフラストラクチャの拡張により、個別のパッチを使用した選択的なシステム メンテナンスが可能です。パッチは単一の修正プログラムで、1つまたは複数のサブシステムに適用します。パッチは当初、Carrier Routing System（CRS-1）およびCisco XR 12000シリーズ ルータのCisco IOS XRソフトウェアにおけるSoftware Maintenance Update（SMU）と同様に、メンテナンス パックとして提供される予定です。メンテナンス パックには、稼働中に適用できる1つまたは複数のパッチが含まれます。モジュール型ソフトウェアの初期リリースでは、Product Security Incident Response Team（PSIRT）が発行するセキュリティ勧告に関わるパッチのみを提供する予定です。

バージョニングおよびパッチ管理機能が用意されているため、システムをリスタートせずに、メンテナンス パックのダウンロード、検証、インストール、およびアクティブ化を行うことができます。多くのパッチはシステムをリスタートせずに適用できるため、パッチが必要なOSの部分に応じて、ネットワーク オペレータはソフトウェアをいつでも柔軟に変更できます。パッチはソフトウェアの特定の問題を修正するためのコンポーネントにのみ作用するため、コードの検証にかかる時間を大幅に削減できます。ネットワーク管理者は、ソフトウェアの修正に関係する部分を検証するだけで済みます。メンテナンス パックを適用することが決まったら、サブシステムISSUの機能を使用してネットワーク上の複数のCisco Catalyst 6500シリーズ スイッチを迅速にアップグレードすることができます。

モジュール型ソフトウェアとCisco Catalyst 6500シリーズ ハードウェア アーキテクチャの相互関係

Cisco Catalyst 6500シリーズ スイッチは、ASICを使用してハードウェアによるトラフィック フォワーディングを行います。ルーティング プロトコル、ターミナル セッション（TelnetやSecure Shell [SSH;セキュア シェル]プロトコルなど）、およびSNMPなどの制御タスクや管理タスクは、スイッチのCPUで実行する必要があります。そのため、「データ プレーン」と「コントロール プレーン」という言葉を使用して、システムを2つの部分に区別しています。データ プレーンはハードウェア フォワーディングを実行するためのエントリを正しく取得する必要があるため、ルーティング プロトコルを使用してこれらの情報を学習するコントロール プレーンとインターフェイスで接続します。これらのエントリがハードウェアに読み込まれると、コントロール プレーンからデータ プレーンに更新情報を送信するだけで済みます。

このようなアーキテクチャやEIGRP、OSPF、IS-IS、およびBGPなどのルーティング プロトコルのNSF機能にモジュール型ソフトウェアを組み合わせると、非常に優れた機能を実現できます。スーパーバイザ エンジンを1つだけ搭載したシステムでもNSF機能^*を使用できます。モジュール型ソフトウェアのリスタート機能を使用すると、システムの残りの部分を稼働したままIPルーティング プロセスなどのモジュール化されたプロセスをリスタートできます。次の手順は、システムが自動的に復旧する仕組みを示しています。

• 最初にすべてのルーティング プロトコル（コントロール プレーン）がコンバージェンスを行い、データ プレーンによってトラフィックが転送されます。
• IPルーティング プロセスに障害が発生します。
• プロセスがリスタートされます。この間、データ プレーンは現行のハードウェア エントリを維持しているため、トラフィック フォワーディングを継続します。
• IPルーティング プロセスが回復し、プロセス回復を知らせるNSFメッセージをネイバに送信します。
• NSF対応のネイバは、回復したシステムから学習したエントリをテーブル内に記録して、各ネイバの情報を回復したシステムに送り返します。
• コントロール プレーンがネイバから取得したすべてのルーティング アップデートを処理すると、変更内容をデータ プレーンに通知します。

注： 上記の手順が実行される際にも、データ プレーン上でのフォワーディング処理が常に実行されています。ただし、これによってスーパーバイザ エンジンのハードウェア障害が防止できるわけではありません。ハードウェア障害から復旧するには、セカンダリ スーパーバイザ エンジンが必要です。

^* Cisco Catalyst 6500シリーズのNSFの実行に関する詳細については、http://www.cisco.com/jp/product/hs/switches/cat6500/で製品の資料またはホワイト ペーパーを参照してください。

動作モード

モジュール型ソフトウェアに対応したCisco IOSソフトウェア イメージは、バイナリ イメージまたはインストール イメージの2つの異なるモードのいずれかで実行できます。バイナリ イメージを使用するシステムは多くのオペレータがこれまでに使用してきたシステムで、バイナリ形式の単一のCisco IOSソフトウェア イメージがスイッチ プロセッサとルート プロセッサで動作します。一方、インストール イメージを使用する場合、システムはディレクトリとファイル構造を備えたファイル システムから実行されます。サブシステムISSUが利用できるのはインストール モードのみであり、また、インストール モードではメモリの使用効率が向上するので、インストール イメージからシステムを実行することを推奨します。

相違点
表1に、2つの動作モードの相違を示します。

表1 動作モードの相違

再パッケージ機能を使用すると、ネットワーク管理者はベース イメージ、適用されたすべてのパッチ、およびタグを含むすべてのパッチ履歴を1つのバイナリ ファイルに圧縮できます。この再パッケージ機能については、後ほど詳しく説明します。

インストール イメージから実行されたシステムは、ライン カードの着脱に基づいてライン カードにメモリを割り当てます。この場合、必ずファイル システムが存在している必要があります。外部コンパクト フラッシュ メモリを使用する場合、システムの稼働中に外部コンパクト フラッシュを取り外してはなりません。バイナリ イメージから実行するシステムはブート時にすべてのコードを読み込みますが、インストール イメージから実行されるシステムでも実行時に設定される機能に応じて同様の処理を行うことができます。

イメージのインストール
イメージをインストールする作業は、ディレクトリ構造を作成して、そのディレクトリ構造にバイナリ ファイルを復元する作業と同じです。この処理はインストーラによって実行されます。インストーラは、モジュール型Cisco IOSソフトウェアに対応するイメージにコンポーネントとして追加されています。

モジュール型Cisco IOSソフトウェアに対応したイメージを実行する場合、新しいイメージはローカルまたはリモートのどちらに存在していてもかまいません。リモートからイメージをインストールする場合には、Trivial File Transfer Protocol（TFTP;簡易ファイル転送プロトコル）、FTP、またはRemote Copy Protocol（RCP）などを使用します。

このあと、システムは圧縮イメージのメモリへのコピー、コピーした圧縮イメージの復元、チェックサムの検証、および指定されたファイル システムへの書き込みを行います。インタラクティブなキーワードを使用すると、さらに詳細な出力を表示できます。

ファイル システムに十分な空き容量がある場合には、Cisco IOSソフトウェアの複数のバージョンを収容することができます。以前は、複数のバージョンを収容する場合、複数のファイルを1つのメディアにコピーしていました。インストール イメージは、複数のファイルを格納するディレクトリ構造で構成されるため、最上位ディレクトリ（上記の例の場合は/sysディレクトリ）で区別されます。システムでは、ファイル システムごとにイメージをインストールする3つの場所（/sys、/newsys、/oldsys）が用意されます。新しいリリースは/newsysにインストールしてテストできます。新しいリリースが検証できたら、古いソフトウェア ベースを/oldsysに移動して、新しいソフトウェア ベースを/newsysから/sysに移動します。

ブート変数の変更とイメージのバインディング
バイナリ イメージから実行するシステムでは、bootvar変数を使用してROMMONがブート時に読み込むバイナリ ファイルを指定します。通常、ファイルは1つしか存在しないため、この動作は単純です。ただし、ブート変数が正しく定義されていないと、電源停止やリロード後にシステムがROMMON状態のままになる可能性があります。また、ブート ストリングに誤りがあると、深刻な結果を招く場合があります。

インストール イメージからシステムを実行すると、ファイル構造が作成されます。ファイル構造はOSそのものによって管理されているため、ユーザはディレクトリやファイル構造に関する知識を必要としません。ただし、この方法には、bootvar変数を定義するために別の方法を使用する必要があるという問題点があります。

bootvar変数を定義する手順を簡素化すると同時に、安全性と信頼性を確保するために、「バインディング」という考え方が導入されています。イメージをインストールする場合には、disk0:/sysのようなインストール先を指定します。イメージのインストールが完了したら、システムを指定したインストール先とバインドする（ROMMONがシステムのブート元を識別できるようにする）必要があります。システムをある特定の場所とバインディングすると、適切なブート ストリングが自動的に定義されます。例を示します。

次のコンフィギュレーション コマンドは、OSを配置する場所を定義します。

注： 完全なブート ストリングが追加されています。バイナリ イメージから実行するシステムと比較すると、ブート ストリングは若干長くなりますが、ユーザはブート ストリングを入力する必要はなく、ディレクトリを指定するだけで済みます。

6500# show running-config | include disk0:
install bind disk0:/sys
boot system disk0:/sys/s72033/base/s72033-ipservicesk9-vm

ネットワーク管理者はシステムがバインドされている場所（つまり、OSが配置されている場所）をいつでも確認できます。

6500#show install bind

この例では、次のようにバインディングが定義されています（順序どおりあるいは優先順）:

Location Search Root
--------------------------- ------------------------------
Entire System disk0:/sys

すでに説明したように、1つのメディア上に複数の「インストール」リリースを配置することができます。この場合、各リリースをインストールまたは解凍するディレクトリを使用してリリースを区別します。システムをブートするディレクトリを変更するには、no install bind <location>コンフィギュレーション コマンドを使用して古いエントリを削除します。古いエントリを削除したら、上記の手順を使用してシステムをブートするディレクトリを新たに指定します。

ファイル システム要件
必要なフラッシュのストレージ容量が増えることを除いて、モジュール型Cisco IOSソフトウェアにはファイル システムに関する特別な要件はありません。フラッシュの容量増加が必要であれば、コンパクト フラッシュ メディアを使用できます。シスコでは、内部フラッシュ（sup-bootflash:およびbootflash:のこと）と交換可能な内部コンパクト フラッシュ アダプタを提供しています。容量の大きな内部フラッシュを使用することで、外部コンパクト フラッシュが取り外されるリスクを回避できます。また、ファイル システムのパフォーマンスも強化されています。たとえば、多大な時間を必要としていたスクイーズ処理が不要になっています。サポートされているファイル システムは、コンパクト フラッシュ ベースのファイル システムのみです。

内部コンパクト フラッシュ アダプタ（製品番号はCF-ADAPTER=）の利点を生かすには、スイッチ プロセッサの場合でROMMONバージョン8.4(2)以降を、ルート プロセッサの場合は12.2(17r)S4以降を使用する必要があります。ファイル システムの表記は、sup-bootflash:からsup-bootdisk:、bootflash:からbootdisk:にそれぞれ変わります。Supervisor Engine 720では、ソフトウェアを使用してROMMONをアップグレードできます。これはリモートから実行でき、ハードウェアに変更を加える必要はありません。詳細については、Cisco.comでROMMONのリリース ノートを参照してください。

インストール イメージからシステムを実行する場合、ファイル システムが常に存在している必要があります。ライン カード コードはファイル システムから動的に読み込まれるため、ファイル システムが存在しないと深刻な不具合が生じる可能性があります。

インストール イメージから実行するシステムの最小ストレージ容量は256 MBです。推奨容量は512 MBです。

プロセス管理

モジュール型Cisco IOSソフトウェアでは、モジュールごとにプロセスをリスタートすることができます。ただし、ユーザは原則としてプロセスのリスタートを行う必要はありません。統合型ハイ アベイラビリティ サブシステムは、すべてのプロセスの状態を継続的にモニタし、必要に応じてプロセスを自動的にリスタートします。

プロセスの状態はいつでも確認できます。IPルーティング プロセスiprouting.iosprocの状態を表示する例を次に示します。

パッチの適用

プロセスのリスタート機能は、システムをリスタートせずに障害を回復できる重要なメカニズムですが、その本来の目的は稼働中のシステムに変更を加えることです。これらのサブシステム レベルのソフトウェア変更は、パッチの適用と呼ばれます。たとえば、単一の修正プログラムを使用してシステムを更新する場合や機能を微修正する場合にパッチが使用されます。モジュール型Cisco IOSソフトウェアの最初のリリースでは、一般公開されるセキュリティ上の脆弱性（PSIRTアラート）に関する場合に限り、メンテナンス パックでパッチが提供される予定です。将来のリリースでは、あらゆるタイプの修正および新機能に対応するパッチを導入する予定です。

パッチをインストールしたら、そのサブシステム コードが属するすべてのプロセスをリスタートして、システムに変更を適用する必要があります。チェックポイント情報が利用できる場合、それを使用して障害の影響を最小限に抑えることができます。ルーティング プロトコルは、NSF機能を使って、障害から復旧しているシステムを通じて学習したルートをネイバが削除しないようにします。

システムにパッチを適用する手順を次に示します。この手順が適用されるのは、インストール イメージから実行されるシステムだけであることに注意してください。

1. 最初に、show install runningコマンドを使用して、システムで稼働しているベース イメージとパッチの種類を確認します。

2. メンテナンス パックはCisco.comからダウンロードする必要があります。^***特定のイメージに対して適用されるメンテナンス パックやパッチは容易に見つけることができます。Cisco.comのサイトで、Technical SupportからToolsを選択し「Patch Navigator」を表示します（図2）。下記のスクリーンショットは、Patch Navigatorとパッチを検索するオプションを示しています。

図2 Software Modularity Patch Navigator

3. メンテナンス パックまたはパッチはシステムにコピーして、ファイル システムに取り込む必要があります。この処理は、インストーラによって実行されます。インストーラはシステムにファイルをコピーして、パッチの適合性を検証し、ファイル システム構造に合わせてファイルを書き込みます。ファイル システムの管理はインストーラによって行われるため、ユーザはファイル システムに関する知識を必要としません。メンテナンス パックまたはパッチは、システム上の任意のファイル システムに手動でコピーできます。また、TFTP、FTP、またはRCPを使用してメンテナンス パックやパッチにアクセスすることもできます。以下に例を示します。

^*** Cisco.comにログインする必要があります。

4. パッチをアクティブ化する前に、パッチがインストール待ち状態になっていることを確認するには、show install runningコマンドを使用します。install activate <systemlocation>コマンドを使用すると、パッチをアクティブ化できます。リスタートの必要なプロセスがシステムによって示されます。さらに確認メッセージが表示されたあとに、プロセスがリスタートされ、サブシステムに対する変更がアクティブになります。

メンテナンス パックのリリース構造
パッチは、メンテナンス パックとして提供される予定です。メンテナンス パックには1つまたは複数のパッチが含まれます。パッチはベース イメージに依存しているため、Cisco IOSソフトウェアの各リリースが公開されると、Patch Integration Branch（PAIB）が発足します。図3の一番上にある矢印は、ソフトウェアの不具合が発見されたタイミングを示しています。新たに不具合が発見された場合には、追ってそれに対応したメンテナンス パックがCisco.comからダウンロード可能になります。メンテナンス パックには、PAIBで提供された過去のメンテナンス パックのパッチがすべて含まれます。

図3 メンテナンス パックのリリース構造

不具合が解決されて、メンテナンス パックがリリースされると、ベース ソフトウェア トレインにもただちに修正が反映されるので（これは、従来のCisco IOSリリースと同じです）、既知の不具合すべてに迅速な対応が行われ、次回のメンテナンス リリースに自動的に統合されます。

ソフトウェア リリース（12.2(18)SXFなど）に対するメンテナンス サポートが終了すると、PAIBはこのサポート終了後最低1か月間継続しますが、その後新たにメンテナンス パックがリリースされることはありません。モジュール型Cisco IOSソフトウェアの拡張機能を備えた新しいリリース（12.2(18)SXGなど）がリリースされると、新たにPAIBが発足します。旧PAIBの既存パッチはすべて新リリースに統合されます。通常のリリース プロセスやメンテナンス リビルド プロセスの変更はなく、PAIBのサポートがシスコの標準的なソフトウェア サポート ポリシーに追加されるに過ぎません。メンテナンス リリースでは、よりきめ細かな対応が可能になります。

インストーラ

パッチを管理する機能として、Cisco IOSソフトウェア インフラストラクチャにインストーラという新しいコンポーネントが追加されています。インストーラはメンテナンス パックの追加と削除だけでなく、タグの設定とイメージの再パッケージを行う機能を備えています。インストーラはシステムのパッチ履歴をすべて記録します。これは、実行中のシステム（この場合、システムはバインドされている）か、または同一メディア上でインストールされている別のシステムかに関係なく実行されます。

チェック
メンテナンス パックがシステムに追加される際に、システムは下記のような複数のチェックを実行します。

• メンテナンス パックのすべての部分がシステム上のベース イメージと適合するか
• メンテナンス パックがすでにシステム上にインストールされていないか
• 過去にメンテナンス パックがインストールされてプルーニング（Pruning）されたことはないか（プルーニングを行うと、容量を節約するために過去に定義されたタグと以前のパッチにロールバックするのに必要なファイルが削除される）
• ファイル システムにメンテナンス パックを追加できるだけの空き容量があるか
• チェックサムがメンテナンス パックに格納されているチェックサムと一致するか

システムは、システムおよびメンテナンス パックのすべてのシンボルを解決するための詳細なチェックを行います。

これらの手順を実行すると、適切なメンテナンス パックだけをインストールできます。ダウンロードまたはインストール中にメンテナンス パックが破損した場合、インストーラはメンテナンス パックをシステムに適用しないようにします。

タグ
タグはパッチ履歴における特定のポイントを表すラベルと考えることができます。ネットワーク管理者はタグをいつでも定義できます。タグを定義すると、パッチがさらに追加されアクティブ化されたあとでも、1つのコマンドを使用してパッチ履歴のタグで定義されたポイントに戻れるため、ネットワーク管理者はパッチを1つずつロールバックする必要はありません。操作を容易にするために、次の3つのタグが事前に定義されています。これらのタグは削除できません（表2）。

表2 事前に定義されたタグと対応するアクション

システムの現在の状態を確認するには、show install runningコマンドを使用します（前述の項を参照）。新しいタグを設定する場合は、install commitコマンドを使用します。そうすると、現在の情報が保存され、所定の名前がその情報に付与されます。

ロールバック
システムにパッチを追加する機能はそれだけで有用ですが、完全なパッチ処理には、稼働中にパッチを削除する機能も必要です。このプロセスはロールバックと呼ばれます。パッチを適用しても期待通りの結果が得られなかった場合に、この削除機能を使用するとシステムを前の状態に戻すことができます。

パッチ処理を簡素化するために、パッチは適用時と逆の順番で削除しなければなりません。つまり、パッチA、B、Cをこの順番でシステムに適用した場合、ロールバックではC、B、Aの順番でパッチを削除する必要があります。ただし、複数のパッチを一度に削除することは可能です。そうすれば、パッチ同士の依存関係を損なう可能性がなくなります。パッチは必ずメンテナンス パックとして提供されるため、ロールバックでは前のメンテナンス パック レベルに戻すことしかできません。

パッチの追加と同様に、ロールバックは2つの手順から成り、最初に、ロールバックする1つまたは複数のパッチを選択する必要があります。この操作は、install rollback <system location> <tag>コマンドでタグを使って行います。タグ フィールドには、ユーザ定義のタグまたは事前に定義されているタグを使用します。次に、install activateコマンドを使用してこれらの変更をアクティブ化する必要があります。ここでもリスタートの必要なプロセスが一覧表示されて、再確認メッセージが表示されます。

アクティブ化する前に複数のパッチを追加および削除することもできます。あるパッチを削除して別のパッチをインストールする場合（どちらのパッチも同じサブシステムに作用する）、最初に、すでにアクティブなパッチをロールバックして新しいパッチをインストールします。次に、これらの変更をすべて一度にアクティブ化します。そのため、プロセスを1回リスタートするだけで、ロールバックと新しいパッチのインストールを行うことができます。

再パッケージ機能
時間とともに、多くのパッチがベース イメージに追加されます。この場合、タグを設定してシステムの特定のステージを定義することができます。再パッケージ機能は、数多くのデバイスでモジュール型Cisco IOSソフトウェアに対応するイメージを使用する場合に役立ちます。再パッケージを行うと、次の情報が1つのバイナリ ファイルに圧縮されます。

• ベース イメージ
• システム上でインストール（またはインストールおよびアクティブ化）されたすべてのメンテナンス パック
• すべてのタグ

ファイルだけでなくパッチ履歴もすべて1つのファイルに変換されます。

使用例としては、ラボ環境やテスト環境でベース イメージに必要なパッチを追加する場合が考えられます。そのリリースが実際のネットワークのニーズを満たすことが確認されれば、このシステムの再パッケージを実行できます。再パッケージ化されたイメージを内部TFTPサーバで公開して、新規システムはすべて中央の「マスター」イメージからイメージを取得します。取得できるパッチ情報はすべて「オリジナル」のイメージとまったく同じです。システムをこのインストール イメージから実行すると、このシステムでベース イメージが最初から使用されていた場合と同じようにパッチの追加やロールバックを行うことができます。再パッケージ化されたイメージはシステム上にインストールする必要があるため、最初のフェーズではバイナリ ファイルとして使用することはできません。

プルーニング（Pruning）
すべての履歴とロールバックの可能性を維持しながらシステムにいくつものパッチを追加すると、ファイル システムのサイズが大きくなることがあります。ファイル システムのサイズを最適化するために、インストーラには「プルーニング」オプションが用意されています。プルーニングは、新しいパッチによって不要になったパッチに対してのみ実行できます。プルーニングを行うと、過去に定義されたタグとロールバックに必要なファイルが削除されます。プルーニングを行うとファイル システムの容量は節約できますが、パッチ履歴の前の段階にロールバックできなくなるので注意が必要です。

使用例としては、ベース イメージにいくつかのパッチを適用した結果、企業ネットワークの「新しいベース」として機能している場合が考えられます。この例ではロールバックする必要がないため、システムをプルーニングしてから再パッケージ化してネットワークに配布することができます。プルーニングを行うと、個々のCisco Catalyst 6500シリーズ スイッチの内部ファイル システムの容量を節約できます。

Embedded Event Manager（EEM）

EEMは、Cisco IOSインフラストラクチャの強力な拡張機能です。EEMを使用すると、Catalyst 6500スイッチ上でコマンド実行等のアクションのカスタマイズを行い、指定されたイベントをトリガーにして、このカスタム アクションを実行させることができます。このアクションのトリガーや個別の手順を定義するには、Tool Command Language（TCL）スクリプトを使用します。TCLスクリプトを使用すると、個別のニーズに応じてトリガーや実行するアクションを自在にカスタマイズできます。

EEMはCisco IOSインフラストラクチャの一部であるため、中央管理ステーションとの接続が一時的に利用できなくなっても独立して動作します。EEMのアーキテクチャは、次の3つのコンポーネントに分割できます。

• イベント ディテクタ
• ポリシー エンジン
• EEMサーバ

イベント ディテクタは、OSのさまざまな部分におけるセンサとみなすことができます。イベント ディテクタは、カスタム アクションが記述されたスクリプトを実行するトリガーとなります。イベント ディテクタは、CLI入力、カウンタ、リソースのスレッシュホールド、タイマー ベースのサービス、SNMPやSyslogのメッセージ、およびルーティング プロトコル イベントなどに基づいて、イベントを発行^*****します。イベント ディテクタの完全な一覧については、EEMのマニュアルを参照してください。

ポリシー エンジンは、ユーザ定義のポリシーをシステムにバインドします。ポリシー エンジンには、システムをバインドするため、次の2つのインターフェイスが用意されています。

• TCLスクリプト
• CLIアプレット

TCLスクリプトに対応したポリシー エンジンは、TCLインターフェイスを備えています。システムには事前に定義されたスクリプトがいくつか用意されていますが、ネットワーク オペレータはTCLスクリプト インターフェイスを利用して独自のスクリプトをシステムに追加し、個別のニーズに基づくアクションを実行することもできます。コマンド出力の収集からスイッチの完全なパッチ管理に至るさまざまなアクションを実行できます。

^***** 「発行する」という表現は、イベントが発生したことをEEMマネージャに通知することを意味します。

EEMサーバはイベント ディテクタおよびポリシー エンジンと連携して処理を行います。イベント ディテクタはEEMサーバにイベント出力を行い、EEMサーバはポリシー エンジンを使用して処理を行います。

簡単な例として、Syslogイベント ディテクタを使用するケースが考えられます。この場合、OSPF隣接関係の変更を示すSyslogメッセージ「%OSPF-5-ADJCHG」がシステムから発行されるとすぐに、show ip ospf neighbor detailコマンドの出力をローカル ファイル システムに保管することができます。

モジュール型ソフトウェアとEEMを組み合わせて使用すると、さらに優れた機能を実現できます。EEMはそれ自体がモジュール化されたプロセスなので、プロセスの動作に基づいてアクションを実行できます。たとえば、プロセスがクラッシュした場合のトラブルシューティングを容易にするために、クラッシュ ダンプやメモリ割り当てなどの関連情報をローカルまたは中央のサーバに保管することができます。EEMによるアクションが実行されると、スイッチからネットワーク管理者に情報が通知され、管理者は原因の詳細な分析やTechnical Assistance Center（TAC）への問い合わせなどを行うことができます。

ユーザ定義のスクリプトを使用して特定のシステム動作に対応することにより、中堅・中小企業のネットワークから大規模ネットワークに至るさまざまな場所でCisco Catalyst 6500シリーズを有効に活用できます。

付録

モジュール型ソフトウェア対応リリースへの移行
システムを移行する前に、リリース ノートを参照してハードウェアとソフトウェアの互換性（ROMMONバージョンを含む）を確認してください。Cisco IOSソフトウェアのネイティブ モード^*で稼働しているシステムを移行するには、次の手順を実行する必要があります。

Cisco.comのSoftware Center^**から適切なイメージをダウンロードします。イメージは1つのバイナリ ファイルとして提供されます。

1. bootdisk:、disk0:、またはdisk1:のいずれかに十分な空き容量があることを確認して、システムにイメージをコピーします。イメージをインストールする場合、バイナリ ファイル サイズの約2.5倍の空き容量が必要です。^***

2. boot system flash...コマンドを使用し、新しいイメージに合わせてブート変数を変更します。

3. 設定を保存し、show bootvarコマンドでブート変数がモジュール型ソフトウェアに対応したイメージに適合していることを確認して、システムをリロードします。

4. show versionコマンドを使用して、新しいイメージがロードされていることを確認します。

「インストール イメージ」を使用してシステムを実行する場合は、この資料の「動作モード」の「イメージのインストール」の項に記載されている手順に従ってください。

参考資料および連絡先

• Catalyst 6500のモジュール型Cisco IOSソフトウェアに関する製品情報（ハードウェア サポートに関する詳細情報を含む）：http://www.cisco.com/jp/product/hs/switches/cat6500/ism6500.shtml
• Cisco Catalyst 6500のリリース ノート（英語）：http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/relnotes/index.htm
• Cisco Catalyst 6500のマニュアル：http://www.cisco.com/jp/service/manual_j/index_sw_cat6500.shtml
• LAN Switching Softwareのダウンロード：http://www.cisco.com/public/sw-center/lan/cat6000.shtml

^* スイッチ プロセッサとルート プロセッサで1つのバイナリ ファイルを実行するシステム（モジュール型Cisco IOSソフトウェアには対応していません）。
^** Cisco.comにログインする必要があります。
^*** 2種類のイメージと複数のパッチをインストールできるだけの空き容量を確保する場合を想定しています。