Cisco Catalyst Center SWIM（旧DNA Center）とは｜ソフトウェアイメージ管理とアップグレード手順

SWIM（Software Image Management）は、Cisco Catalyst Center が備えるネットワーク機器のソフトウェアイメージを一元管理する機能です。イメージの取り込みからゴールデンイメージの指定、配布・有効化、アップグレードの事前チェックまでを画面操作で回せるため、多数のCatalyst機器のIOS XEバージョンを手作業で更新する運用から抜け出せます。

検索で「cisco dna swim」と「catalyst center swim」が混在するのは、製品名が2023年に Cisco DNA Center から Cisco Catalyst Center へ改名されたためで、指しているのは同一のSWIMです。この記事では改名後の名称と最新リリース（3.x系）を前提に、SWIMの構成要素と実務手順、無停止アップグレード（ISSU）の使い分けまでを整理します。

まとめ：SWIM運用の要点

• SWIM = Catalyst Center（旧DNA Center）のイメージ管理機能。イメージリポジトリ・ゴールデンイメージ・配布/有効化の3要素で成り立つ。
• イメージ取り込みは Cisco.com連携（CCO）／ローカルアップロード／URL指定の3経路。取り込み時にKGV（既知の正常値）と照合して整合性を検証する。
• ゴールデンイメージをデバイスファミリ・ロール単位で指定すると、各機器の稼働イメージと差分（Outdated）が自動判定される。
• アップグレードは 配布（Distribute）と有効化（Activate）を分離し、配布は業務時間中・有効化はメンテナンス枠に回すのが定石。実行前に Readiness Precheck（管理状態・ディスク容量など）が走り、失敗すると更新は止まる。
• ISSU（無停止アップグレード）は対応機種・対応リリースが限られる。要件を満たさない環境では通常アップグレード（リブート）を選ぶ。
• SWIMはイメージ管理が対象で、設定（コンフィグ）のバックアップやインベントリ復元とは別機能。混同しない。

SWIM（Software Image Management）の役割と全体像

「Cisco DNA Center」と「Catalyst Center」は同一製品（2023年改名）

Ciscoは2023年、ネットワーク管理・自動化プラットフォームの名称を Cisco DNA Center から Cisco Catalyst Center へ変更しました。Catalystというハードウェア製品群と名称を揃える改名で、ライセンス体系や中身の機能は引き継がれています。したがって「cisco dna swim」「dnac swim」「catalyst center swim」はすべて同じSWIM機能を指します。旧ドキュメントやCLIには DNAC 表記が残るため、社内資料を更新する際は名称の対応関係を押さえておくと混乱を避けられます。

リリースは3.x系が現行で、2026年7月時点で 3.2.2（2026年5月）や 3.1.6（2026年7月）が提供されています。2.3.7.x系は先行して使われてきた長期リリースで、Cisco.com連携（CCO）によるイメージ自動取得は 2.3.7.6 以降で利用できます。バージョンごとに対応機能が変わるため、導入時は稼働バージョンのリリースノートを確認してください。

SWIMを構成する3つの要素

SWIMは次の要素で機器のソフトウェア状態を管理します。字面の機能説明ではなく「何を制御するか」で捉えると運用設計しやすくなります。

• イメージリポジトリ：Catalyst Center内にIOS XEイメージやSMU（パッチ）を集約する保管庫。取り込んだイメージがここに一覧化される。
• ゴールデンイメージ：機種・ロールごとに「これを標準とする」と指定する検証済みイメージ。準拠判定の基準になる。
• 配布と有効化：ゴールデンイメージを対象機器へコピー（配布）し、稼働イメージに切り替える（有効化）実行部分。

ソフトウェアイメージの取り込み（インポート）

3つのインポート経路

リポジトリへのイメージ取り込みには次の3経路があります。運用規模とインターネット接続の可否で選びます。

受け付けるファイル拡張子は bin・img・tar・smu・pie・aes・iso・ova・tar.gz・qcow2 など。大規模環境では機器へのコピー負荷を分散するため、イメージ配布サーバー（Image Distribution Server）を別途構成して配布処理をオフロードします。

取り込み時の整合性検証（Integrity Verification）

取り込み時、Catalyst Centerは Integrity Verification により、イメージのソフトウェア／ハードウェアプラットフォームのチェックサムを KGV（Known Good Values：既知の正常値） ファイルと照合します。値が一致しないイメージは改ざんや破損の疑いがあるものとして検知でき、素性の不明なイメージを本番機に流し込む事故を防げます。閉域網でCCO連携を使わない場合は、KGVファイルを別途取り込んで最新化しておくのが安全です。

ゴールデンイメージの指定とコンプライアンス確認

ゴールデンイメージの指定手順

Design → Image Repository でイメージ一覧を開き、対象イメージを デバイスファミリ・ロール単位でゴールデン指定します。同じCatalyst 9300でもコア用とアクセス用で標準イメージを分けたい場合は、ロールを分けて別々にゴールデンを割り当てられます。指定すると、その機種群の「あるべきバージョン」が定義されます。

Outdated判定の見方と是正

ゴールデン指定後、Catalyst Centerは各機器の稼働イメージをゴールデンと比較し、差がある機器を Outdated（非準拠）として表示します。これにより「どの機器がどのバージョンで止まっているか」が一覧で分かり、更新対象の棚卸しが不要になります。是正は、Outdated機器に対して後述の配布・有効化を実行し、準拠状態へ揃える流れです。準拠状況はコンプライアンスとして継続監視されるため、新規機器を追加した際も基準からのズレをすぐ検知できます。

イメージの配布（Distribute）と有効化（Activate）

配布と有効化を分離してダウンタイムを抑える

アップグレードのUpdate Imageワークフローは Distribute（配布）→ Activate（有効化）の2段で構成されます。要点は両者を切り離せることです。

• Distribute：新イメージを機器のフラッシュへコピーするだけの工程。稼働に影響しないため 業務時間中に先行実施できる。
• Activate：コピー済みイメージを稼働イメージに切り替える工程。リブートを伴うため メンテナンス枠にスケジュールする。「配布完了後に有効化」を予約すれば自動で連結できる。

この分離により、深夜メンテナンスで実際に止まる時間を有効化の分だけに短縮できます。数十台規模のロールアウトほど効果が大きい設計です。

アップグレード前のReadiness Precheck

イメージを機器へ流す前に、Catalyst Centerは アップグレードReadiness Precheck（事前チェック）を自動実行します。チェック対象は機器の管理状態（Managedか）、フラッシュのディスク空き容量、到達性・認証などです。いずれかが失敗すると、その機器のアップグレードは実行できません。ディスク不足は古いイメージの削除、管理状態の不整合はインベントリの再同期、といったように、失敗項目を先に潰してから再実行するのが正攻法です。事前チェックを軽視して当日にまとめて弾かれる、というのがSWIM運用でよくあるつまずきです。

ISSU（無停止アップグレード）の対応範囲と使い分け

ここは競合記事が「メリットが多い機能」として一括りにしがちな論点ですが、実務では 「使える環境かどうか」を先に判定するのが正解です。ISSUは要件が厳しく、満たさない環境で無理に狙うと計画が破綻します。

ISSU対応デバイスとリリース制約

ISSU（In-Service Software Upgrade）はリブートを回避し、サービス断を最小化してイメージを更新する方式です。ただし対応は限定的です。

• 対応機種：StackWise Virtual構成のCatalyst 3850／Catalyst 9000シリーズ、デュアルスーパーバイザ構成のCatalyst 9400／9600、HA SSO構成のCatalyst 9800ワイヤレスコントローラ（IOS XE 17.3.x以降）など。単体・単一スーパーバイザ構成は対象外のことが多い。
• リリース制約：ISSUは長期リリース内・長期リリース間でのみサポート（例：17.3.x→17.3.y、17.3.x→17.6.y）。短命リリースをまたぐアップグレードには使えない。

ISSUの内部処理は add → activate → commit の3段で、有効化後にコミットしなければ自動ロールバックのタイマーが働きます。問題がなければ install commit でコミットし、様子見を続けたいときは自動アボートタイマーを止めます。

! 有効化後、確定する場合
install commit

! ロールバックタイマーを止めて様子見する場合
install auto-abort-timer stop

通常アップグレードとISSUの選択基準

判断はシンプルです。対応機種・対応リリース・冗長構成の3条件をすべて満たすときだけISSUを選び、1つでも欠ければ通常アップグレード（リブート）に倒す。断時間を惜しんでISSUに固執するより、確実にリブートで切り替えてメンテナンス枠を確保するほうが、ロールバックの読みやすさでも運用が安定します。SD-Accessファブリックの一部構成のようにISSU非対応が明示されている領域では、そもそも選択肢に入れないのが安全です。

よくあるトラブルと対処

SWIMで詰まりやすいポイントは事前チェックとリポジトリまわりに集中します。

よくある質問（FAQ）

Cisco DNA CenterとCatalyst Centerは何が違いますか？

名称が違うだけで同一製品です。2023年にCisco DNA CenterがCatalyst Centerへ改名されました。SWIMを含む機能は引き継がれており、「cisco dna swim」も「catalyst center swim」も同じ機能を指します。

SWIMでコンフィグ（設定）のバックアップはできますか？

SWIMが管理するのはソフトウェアイメージです。設定のバックアップやインベントリの保護は、Catalyst Center本体のバックアップ・復元機能やConfiguration Archiveが担う別機能です。「catalyst center backup」を目的にする場合はSWIMとは別の手順になります。

対応しているCatalyst Centerのバージョンは？

SWIMはCatalyst Center（旧DNA Center）の標準機能で、2.3.7.x系や現行の3.x系（2026年7月時点で3.2.2・3.1.6など）で利用できます。Cisco.com連携によるイメージ自動取得は2.3.7.6以降です。詳細な対応範囲は稼働バージョンのリリースノートで確認してください。

アップグレード後にロールバックはできますか？

ISSUの場合、有効化後にコミットするまではロールバックタイマーが働き、コミットしなければ元のバージョンへ戻せます。通常アップグレードでは、旧イメージをフラッシュに残しておけば手動で切り戻せます。いずれもメンテナンス枠内で切り戻し手順を用意しておくのが安全です。

ゴールデンイメージの指定は必須ですか？

アップグレード自体はゴールデン指定なしでも実行できますが、指定すると各機器の準拠（Outdated）判定が自動化され、バージョン管理の抜け漏れを防げます。多数の機器を運用するなら指定を前提にした方が棚卸しの手間が大きく減ります。

関連記事

• IOS-XRとは？Cisco IOS・IOS-XEとの違いと特徴・対応機器を解説【2026年最新】：SWIMが配布するイメージのOS種別（IOS XE／IOS-XR）の違いを整理したい方へ。
• Batfishとは？ネットワーク構成を検証するOSSツールの仕組みと使い方【2026年版】：イメージ更新前後のネットワーク構成変更を検証したい場合の補完ツール。