はじめに
このドキュメントでは、コントロール接続とデータプレーン接続に影響を与え、サービス停止を引き起こす可能性がある、期限切れの証明書を使用したvEdgeを特定する方法について説明します。
背景説明
この問題は、vEdge 100M、vEdge 100WM、vEdge 100B、vEdge 1000、およびvEdge 2000プラットフォームに影響を与えます。 これは、2023年5月9日の午前6:57(UTC)に期限切れになった公開ルート証明書が原因です。
注:このインシデントは、次のプラットフォームには影響しません。
1. Viptela OSを実行するvEdge Cloud、vEdge 5000、およびISR 1100
2. XE SD-WANソフトウェアを実行するシスコのルーティングプラットフォーム(物理および仮想)
vEdge# show control local-properties
personality vedge
sp-organization-name CALO - 100589
organization-name CALO - 100589
root-ca-chain-status Installed
certificate-status Installed
certificate-validity Not Valid - certificate has expired <<<<<<<<<<<<<<<<<<<<
certificate-not-valid-before May 12 17:11:21 2013 GMT
certificate-not-valid-after Jan 19 03:14:07 2038 GMT
「hour X」(2023年5月9日午前6時57分(UTC)AM)の後にデバイスがリロードされた場合、さらに次のように表示されます。
serial-num BOARD-ID-NOT-INITIALISED
注意:この問題は、ハードウェアWANエッジの証明書許可がvManageでエンタープライズ証明書またはオンボックス証明書のいずれかに設定されている場合に該当します。
次の条件が原因で、vEdgeに影響が及ぶ可能性があります。
- vSmartへの接続が失われる
- vManageへの接続が失われる
- ポートホップ
- ネットワークのトポロジ変更などのポリシー変更を制御する
- コントロール接続のクリア
- インターフェイスフラップ
- デバイスのリロード
注:コントロール接続の確立中は、すべての場合においてオンボックス証明書がコントローラによって検証されます。エンタープライズ証明書を使用すると、オンボックス証明書とエンタープライズ証明書の両方が検証されます。
注:この動作の詳細については、Cisco Bug ID CSCwf28118を参照してください。
サービスの中断を回避するための注意事項
サービスが完全に停止しないようにするには、このセクションの次のアクションを回避します。
- デバイスをリロードする
- ポリシーの更新
- テンプレートプッシュ
注意:デバイスをリロードすると、グレースフルリスタートのタイマーがリセットされ、ルータはファブリックに再接続できません。リロードを行わないと、データプレーン(BFD)セッションはアップしたままになり、コントロール接続がダウンしている間でも、グレースフルリスタートのタイマーが切れるまでトラフィックは通過できます。
修復プロセス
シスコでは、この問題を永続的に解決するために、ソフトウェアのアップグレードバージョンを公開しています。何らかの行動を起こす前に、プロセス全体を注意深く読んでください。
この問題を解決するための大まかなプロセスは次のとおりです。
- プレチェックを実行して、コントローラのアップグレードの準備をします。
- SD-WANコントローラを修正済みバージョンにアップグレードする
- vEdgeとコントローラ間の制御およびBFD接続の復元
- 事前チェックを実行して、vEdgeソフトウェアをアップグレードする準備をします。
- vEdgeソフトウェアを修正済みバージョンにアップグレード
- アップグレード後の考慮事項
ここでは、3つのシナリオを参照します。修復の手順は、ネットワーク内の各vEdgeにどのシナリオが適用されるかによって異なります。
シナリオ1:vEdge Control Connectionが起動しており、vEdgeがリブートされていない。
シナリオ2:vEdge Control Connectionがダウンし、vEdgeがリブートされていない。
シナリオ3:vEdge Control Connectionがダウンし、vEdgeがリブートされた。
修正済みソフトウェアバージョン
シスコは、修正済みソフトウェアバージョンをできるだけ迅速に構築および検証するための作業を継続します。このページは、新しいバージョンが検証され、Cisco.comに投稿されると更新されます。
ヒント:Cisco.comのソフトウェアダウンロードページにある「My Notifications」機能を使用すると、対象のシスコ製品で新しいソフトウェアが使用可能になったときに通知を受けることができます。
次の表を参照して、現在のバージョンに基づいてアップグレードできるバージョンを確認してください。複数のアップグレードパスがサポートされている可能性があります。
利用可能なバージョンが増えるにつれて、さらにバージョンが追加されます。ご使用のバージョンがCurrent Version列に表示されていない場合、現時点で利用可能なアップグレードパスはありません。
ヒント:スケジュールされたメンテナンスウィンドウの前に、ソフトウェアイメージをステージングすることをお勧めします。 Installを使用して、ウィンドウの前にイメージをステージングします。 このプロセスの実行中は、Activate and Rebootボックスにはチェックマークを付けないでください。チェックマークを付けないと、デバイスはインストールの完了直後にアップグレードを完了します。 これにより、メンテナンスウィンドウが短縮されます。
アップグレード推奨マトリックス
期限切れの証明書の問題に対する修正に基づいて、次の表に示すソフトウェアバージョンが推奨されます。この問題の範囲外であるアップグレードは、アップグレード先のバージョンに基づいて、製品ドキュメントおよび『Cisco SD-WANのリリースノート』の手順を実行する必要があります。
注:認定の期限切れの問題による実稼働への影響を緩和するために、現在のリリーストレイン内に留まることを強く推奨します。たとえば、現在20.3.2を使用している場合は、20.3.7.1にアップグレードします。
Cisco Bug ID CSCwf28118により、vEdge 5000、vEdge Cloud、およびISR 1100は影響を受けないため、現在これらのアップグレードは必要ありません。
注:バージョンが混在する環境では、デバイスが現在実行しているイメージに基づいて、表に示されている推奨事項に従ってソフトウェアのアップグレードを実行します。
互換性マトリクスを確認して、考えられるコントローラとエッジの互換性の問題を特定し、問題が発生した場合はTAC SRを開いてサポートを受けてください。
注:Engineering Special(ES)イメージを使用しているお客様で、修正が適用されたイメージにまだアップグレードされていないお客様は、詳細なガイダンスを得るためにTAC SRを開く必要があります。
vEdge-2000の互換性
vEdge-2000でサポートされる最後のソフトウェアイメージトレインは20.9.xです。
vEdge-100B、vEdge-100M、vEdge-1000の互換性
vEdge-100B、vEdge-100M、およびvEdge-1000でサポートされる最後のソフトウェアイメージトレインは20.6.xです。推奨されるターゲットリリースを特定するには、現在のバージョンとのソフトウェアイメージを使用します。
vEdge-100B、vEdge-100M、およびvEdge-1000がすでに20.7.x以降にある場合は、TAC SRに連絡してください。
注意:実稼働に影響を与える可能性があるため、お客様にはメンテナンスの時間帯にのみアップグレードを実行することをお勧めします。実稼働に追加の変更を加える前に、ネットワークの安定性を確認します。
SD-WANコントローラとvEdgeソフトウェアの互換性マトリクス
注:認定の期限切れの問題による実稼働への影響を緩和するために、現在のリリーストレイン内に留まることを強く推奨します。
たとえば、現在20.3.2を使用している場合は、20.3.7.1にアップグレードします。
証明書修正のアップグレード後、あるリリーストレインから別のメジャーリリーストレインにアップグレードする場合は、そのリリーストレインの優先リリースにアップグレードすることを推奨します。
たとえば、認定後の修正の場合:現在20.3.7.1を使用していて、20.6リリーストレインへのアップグレードを計画している場合は、推奨バージョンの20.6.5.2リリースにアップグレードすることを推奨します。
SD-WANコントローラ |
vEdge 100M、vEdge 100B、vEdge 1000 |
vEdge 2000 |
20.3.3.21 |
20.3.3.21 |
20.3.3.21 |
20.3.4.31 |
20.3.3.21, 20.3.4.31 |
20.3.3.21, 20.3.4.31 |
20.3.5.11 |
20.3.3.21, 20.3.4.31, 20.3.5.11 |
20.3.3.21, 20.3.4.31, 20.3.5.11 |
20.3.7.12 |
20.3.3.21、20.3.4.31、20.3.5.11、20.3.7.12 |
20.3.3.21、20.3.4.31、20.3.5.11、20.3.7.12 |
20.4.2.3 |
20.3.3.21, 20.3.7.12, 20.4.2.3 |
20.3.3.21, 20.3.7.12, 20.4.2.3 |
20.6.1.2 |
20.6.1.2 |
20.6.1.2 |
20.6.3.2 |
20.3.3.21、20.3.4.31、20.3.5.11、20.3.7.12、20.4.2.3、20.6.1.2、20.6.3.2 |
20.3.3.21、20.3.4.31、20.3.5.11、20.3.7.12、20.4.2.3、20.6.1.2、20.6.3.2 |
20.6.4.1 |
20.3.3.21、20.3.4.31、20.3.5.11、20.4.2.3、20.6.1.2、20.6.3.2、20.6.4.1 |
20.3.3.21、20.3.4.31、20.3.5.11、20.4.2.3、20.6.1.2、20.6.3.2、20.6.4.1 |
20.6.5.22 |
20.3.3.21、20.3.4.31、20.3.5.11、20.3.7.12、20.4.2.3、20.6.1.2、20.6.3.2、20.6.4.1、20.6.5.22 |
20.3.3.21、20.3.4.31、20.3.5.11、20.3.7.12、20.4.2.3、20.6.1.2、20.6.3.2、20.6.4.1、20.6.5.22 |
20.9.3.12 |
20.3.3.21、20.3.4.31、20.3.5.11、20.3.7.12、20.4.2.3、20.6.1.2、20.6.3.2、20.6.4.1、20.6.5.22 |
20.3.3.21、20.3.4.31、20.3.5.11、20.3.7.12、20.4.2.3、20.6.1.2、20.6.3.2、20.6.4.1、20.6.5.22、20.9.3.12 |
20.10.1.1 |
20.6.1.2, 20.6.3.2, 20.6.4.1 |
20.6.1.2, 20.6.3.2, 20.6.4.1 |
20.11.1.1 |
20.6.1.2、20.6.3.2、20.6.4.1、20.6.5.22 |
20.6.1.2、20.6.3.2、20.6.4.1、20.6.5.22、20.9.3.12 |
1このイメージはダウンロードできなくなりました。導入済みのお客様向けに文書化されています。
2は、証明書の修正を含む推奨リリースを示します。
コントローラのアップグレード前に実行する事前チェック
コントローラのバックアップ
- クラウドホスト型の場合は、最新のバックアップが完了したことを確認するか、次の手順で説明するconfig dbのバックアップを開始します。
- SSPポータルから、現在のバックアップを表示したり、オンデマンドスナップショットをトリガーしたりできます。 詳細については、こちらを参照してください。
- オンプレミスの場合は、コントローラのconfig-dbバックアップとVMスナップショットを作成します。
vManage# request nms configuration-db backup path /home/admin/db_backup
successfully saved the database to /home/admin/db_backup.tar.gz
- オンプレミスの場合は、show running-configを収集し、これをローカルに保存します。
- オンプレミスの場合は、neo4jパスワードを確認し、現在の正確なバージョンに通知します。
AURAチェックの実行
コントローラへの送信/vBondへの送信が完了していることを確認します。
vManage統計収集間隔の確認
Administration > SettingsのStatistics Collection Intervalは、デフォルトのタイマーである30分に設定することをお勧めします。
注:シスコでは、アップグレードの前にvSmartsとvBondをvManageテンプレートに添付することを推奨しています。
vSmartおよびvBondのディスク領域の確認
df -khコマンドを使用します。 | vshellからgrep bootを実行して、ディスクのサイズを確認します。
controller:~$ df -kh | grep boot
/dev/sda1 2.5G 232M 2.3G 10% /boot
controller:~$
サイズが200 MBを超える場合は、コントローラのアップグレードに進みます。
サイズが200 MB未満の場合は、次の手順を実行します。
1.現在のバージョンがshow softwareコマンドの下にリストされている唯一のものであることを確認します。
VERSION ACTIVE DEFAULT PREVIOUS CONFIRMED TIMESTAMP
------------------------------------------------------------------------------
20.11.1 true true false auto 2023-05-02T16:48:45-00:00
20.9.1 false false true user 2023-05-02T19:16:09-00:00
20.8.1 false false false user 2023-05-10T10:57:31-00:00
2.現在のバージョンがshow software versionコマンドでデフォルトとして設定されていることを確認します。
controller# request software set-default 20.11.1
status mkdefault 20.11.1: successful
controller#
3.その他のバージョンが表示された場合は、request software remove <version>コマンドを使用して、アクティブでないバージョンをすべて削除します。これにより、アップグレードを続行するための空き領域が増えます。
controller# request software remove 20.9.1
status remove 20.9.1: successful
vedge-1# show software
VERSION ACTIVE DEFAULT PREVIOUS CONFIRMED TIMESTAMP
------------------------------------------------------------------------------
20.11.1 true true false auto 2023-05-02T16:48:45-00:00
controller#
4.ディスク領域をチェックして、200 MBを超えていることを確認します。200 MBを超えていない場合は、TAC SRを開きます。
コントローラのアップグレード
これらのお客様に対して実行される次のステップの概要を示します。
注意:前のセクションの説明に従って、すべての事前確認が完了し、バックアップが作成されていることを確認してください。
- 新しいソフトウェアバージョンをアップグレードリポジトリにアップロードします。
- この問題の修正を含むコントローライメージが選択されていることを確認します。
- 次の順序でイメージ修正を使用してコントローラをアップグレードします。
1. vManage
(2)vBond
3. vSmart
注:CLIでコントローラのアップグレードを続行する場合は、「request software upgrade-confirm」を必ず実行してください。
vManageスタンドアロンアップグレード
スタンドアロンvManageの場合は、次の手順を実行する必要があります。
- イメージをvManage Maintenance> Software repositoryにコピーします。
- vManage Maintenance>Software upgradeによるアップグレード
- Upgradeをクリックし、アップグレードが完了するまで待ちます
- 同じページに戻り、vManageをクリックしてから、Activateをクリックします
注:vManageのアップグレードは、データネットワークには影響しません。
vManageクラスタアップグレード
クラスタアップグレードの場合は、『Cisco SD-WAN Getting Started Guide - Cluster Management [Cisco SD-WAN] - Cisco』ガイドに記載されている手順を実行する必要があります。
注:vManageクラスタのアップグレードは、データネットワークには影響しません。
注意:クラスタをアップグレードする際に質問や問題が発生した場合は、先に進む前にTACにお問い合わせください。
vBondアップグレード
vBondのアップグレードは、vManageのアップグレードと同じプロセスを使用します。
警告: vBondは順次アップグレードする必要があります。次に進む前に、各vBondでアップグレードが完了していることを確認します。
- イメージをvManage Maintenance > Software repositoryにコピーします。
- vManage Maintenance > Software upgradeによるアップグレード
- Upgradeをクリックし、アップグレードが完了するまで待ちます
- 同じページに戻り、[vManage]、[Activate]の順にクリックします
- vBondでshow orchestrator connectionsコマンドを使用して確認します
- vManageでshow control connectionsコマンドを使用して確認します
vSmartアップグレード
vSmartアップグレードは、vManageアップグレードと同じプロセスを使用します。
警告:vSmartsは順次アップグレードする必要があります。次に進む前に、各vSmartでアップグレードが完了していることを確認します。
- イメージをvManage Maintenance > Software repositoryにコピーします。
- vManage UI Maintenance > Software upgradeからvSmartをアップグレードします。
- Upgradeをクリックし、アップグレードが完了するまで待ちます
- 同じページに戻ります。vSmartを選択し、Activateをクリックします。
- アップグレード後にvSmartでshow control connectionsコマンドを使用して、セッションが復元されたことを確認します
注:ソフトウェアのアップグレード中にvSmartがリブートすると、ネットワークに影響を与えることなく、デバイスはグレースフルリスタートで実行されます。
すべてのコントローラのアップグレード後に制御接続が確立されていることの確認
コントローラをアップグレードした後のシナリオ1およびシナリオ2のすべてのvEdgeでは、コントロール接続とBFD接続の両方を復元する必要があります。
vEdgeのアップグレード
注:vEdgeのアップグレードは、シナリオ3で説明されているように、vEdgeルータの電源のオフ/オンを完全に防止するための手順の最後のステップです。
注:スケジュールされたメンテナンス時間帯の前にvEdgeソフトウェアイメージをステージングすることをお勧めします。 Installを使用して、ウィンドウの前にイメージをステージングします。 このプロセスの実行中は、Activate and Rebootボックスにはチェックマークを付けないでください。チェックマークを付けないと、デバイスはインストールの完了直後にアップグレードを完了します。 これにより、メンテナンスウィンドウが短縮されます。
次の方法でvManageから複数のvEdgeに一度にイメージをロードできます。
1. vManage UIに移動します。Maintenance > Software Repositoryの順に移動します。vEdgeイメージをロードします。その後、Maintenance > Software Upgradeの順に移動し、アップグレードが必要なデバイスを選択してからUpgradeをクリックします。
2. vManage UIに移動します。Maintenance > Software Repositoryの順に移動します。Add new softwareをクリックします。Remote serverをクリックします。コントローラのバージョン、vEdgeのバージョン、およびイメージが保存されているFTP/HTTP URLへの完全なパスを入力します。たとえば、ftp://<username>:<password>@<FTP server>/<path>/<image name>のようになります。次に、Maintenance > Software Upgradeの順に移動し、Remote serverオプションを使用してアップグレードが必要なデバイスを選択した後、Upgradeをクリックします。
注:イメージをプッシュするには、帯域幅に基づいてvEdgeをバッチで選択します。
vEdgeアップグレード前の事前チェック
注意:これらの事前チェックをスキップすると、ディスク領域が不足しているためにvEdgeのアップグレードが失敗する可能性があります。
1.現在のバージョンがshow softwareコマンドの下にリストされている唯一のものであることを確認します。
VERSION ACTIVE DEFAULT PREVIOUS CONFIRMED TIMESTAMP
------------------------------------------------------------------------------
20.11.1 true true false auto 2023-05-02T16:48:45-00:00
20.9.1 false false true user 2023-05-02T19:16:09-00:00
20.8.1 false false false user 2023-05-10T10:57:31-00:00
2.現在のバージョンがshow software versionコマンドでデフォルトとして設定されていることを確認します。
vedge-1# request software set-default 20.11.1
status mkdefault 20.11.1: successful
vedge-1#
3.その他のバージョンが表示された場合は、request software remove <version>コマンドを使用して、アクティブでないバージョンをすべて削除します。これにより、アップグレードを続行するための空き領域が増えます。
vedge-1# request software remove 20.9.1
status remove 20.9.1: successful
vedge-1# show software
VERSION ACTIVE DEFAULT PREVIOUS CONFIRMED TIMESTAMP
------------------------------------------------------------------------------
20.11.1 true true false auto 2023-05-02T16:48:45-00:00
vedge-1#
4. vShellとコマンドdf -hを使用して、アップグレードを実行するための十分な空きディスク領域があることを確認します。
VEDGE-1000-AC-K9# vshel
VEDGE-1000-AC-K9:~$ df -h
Filesystem Size Used Avail Use% Mounted on
none 1.4G 8.0K 1.4G 1% /dev
/dev/sda1 1013M 518M 445M 54% /boot
/dev/loop0 78M 78M 0 100% /rootfs.ro
/dev/sda2 6.0G 178M 5.5G 4% /rootfs.rw
aufs 6.0G 178M 5.5G 4% /
tmpfs 1.4G 300K 1.4G 1% /run
shm 1.4G 48K 1.4G 1% /dev/shm
tmp 600M 84K 600M 1% /tmp
tmplog 120M 37M 84M 31% /var/volatile/log/tmplog
svtmp 1.0M 312K 712K 31% /etc/sv
5. /tmpがいっぱいの場合は、TAC SRを開いて、アップグレードの前に/tmp/tmpディレクトリの領域をクリアするためのサポートを受けてください。
vEdgeのアップグレードシナリオ1:コントロール接続がアップ状態で、vEdgeがリブートされていない
修正を含むバージョンにコントローラをアップグレードした後、リブートされていないvEdgeデバイスは自動的に接続を再確立します。
重要:この状態のvEdgeデバイスではアップグレードが必要です。優先順位を付け、できるだけ早く計画する必要があります。必要に応じて、営業時間外に可能な限り迅速に実行します。 デバイスのリブートまたは電源の再投入によるコントロールプレーンとデータプレーンへの影響を避けるために、デバイスのアップグレードを計画します。アップグレードの前にデバイスをリブートしないでください。
vEdgeをアップグレードするには、次の手順を実行します。
- Maintenance > Software repositoryを使用して、新しいvEdgeソフトウェアをvManageにコピーします。
- vManage Maintenance > Software upgradeからvEdgeをアップグレードします。
- [アップグレード]をクリックし、アップグレードが完了するまで待ちます
- 同じページに戻ります。vEdgeを選択し、Activateをクリックします
アップグレード後の検証
- コントロール接続とBFDセッションを確認します。
- OMPルートとサービスVPNルートを確認する:vEdgeとハブ/他のノード間のすべてのサービスVPNセグメントでエンドツーエンドpingをテストします。
- アップグレード後の考慮事項の確認
vEdgeのアップグレードシナリオ2:コントロール接続がダウンし、vEdgeがリブートしない
修正を含むバージョンにコントローラをアップグレードした後、リブートされていないvEdgeデバイスは自動的に接続を再確立します。
重要:この状態のvEdgeデバイスではアップグレードが必要です。優先順位を付け、できるだけ早く計画する必要があります。必要に応じて、営業時間外に可能な限り迅速に実行します。 デバイスのリブートまたは電源の再投入によるコントロールプレーンとデータプレーンへの影響を避けるために、デバイスのアップグレードを計画します。アップグレードの前にデバイスをリブートしないでください。
vEdgeをアップグレードするには、次の手順を実行します。
- Maintenance > Software repositoryを使用して、新しいvEdgeソフトウェアをvManageにコピーします。
- vManage Maintenance > Software upgradeからvEdgeをアップグレードします。
- [アップグレード]をクリックし、アップグレードが完了するまで待ちます
- 同じページに戻ります。vEdgeを選択し、Activateをクリックします
アップグレード後の検証
- コントロール接続とBFDセッションを確認します。
- OMPルートとサービスVPNルートを確認する:vEdgeとハブ/他のノード間のすべてのサービスVPNセグメントでエンドツーエンドpingをテストします。
- アップグレード後の考慮事項の確認
シナリオ3:vEdge、コントロール接続がダウン、デバイスのリブートまたは電源の再投入
注意:これらのデバイスを回復するには、アウトオブバンドアクセスが必要です。
この出力は、証明書の期限が切れた後にリブートされたvEdgeデバイスを示しています。show control local-propertiesコマンドを使用します。 | inc serialコマンドを発行し、出力にBOARD-ID-NOT-INITIALIZEDと表示されていることを確認します。
vedge# show control local-properties | inc serial
serial-num BOARD-ID-NOT-INITIALISED
subject-serial-num N/A
enterprise-serial-num No certificate installed
vedge#
制御接続を復元するためのvEdgeの日付/時刻の変更
これらの手順では、コンソールや直接SSHなどのvEdgeデバイスへのアウトオブバンドアクセスが必要です。
コントロール接続がDOWNになっているvEdgeで、クロックを2023年5月5日(#clock set date 2023-05-05 time 15:49:00.000など)にロールバックします。
vedge# clock set date 2023-05-05 time 10:23:00
vedge# show clock
Mon May 5 10:23:37 UTC 2023
vedge#
board-idが初期化されるまで2~3分待ちます。show control local-propertiesをチェックして、出力に示されている番号がデバイスに設定されていることを確認します。
vedge# show control local-properties | inc serial
serial-num 10024640
subject-serial-num N/A
enterprise-serial-num No certificate installed
vedge#
(オプション)board-idの初期化が2 ~ 3分以内に発生しない場合は、vEdgeをリロードし、show control local-propertiesの出力をチェックして、出力にデバイスのシリアル番号が表示されていることを確認します
ボードIDが初期化されたら、show certificate validityコマンドで証明書を検証します
vedge# show certificate validity
The certificate issued by c33d2cf4-e586-4df4-ac72-298422644ba3 is valid from Sep 7 02:50:16 2021 GMT (Current date is Mon May 1 10:25:03 GMT 2023) & valid until Sep 5 02:50:16 2031 GMT
vedge#
コントロール接続が正常に復旧したら、日時をYYYY-MM-DDおよびHH:MM::SSの形式で現在の時刻に修正します。
この例は説明のみを目的としています。日付と時刻は常に現在の時刻に設定してください。
vedge# clock set date YYYY-MM-DD time HH:MM::SS
vedge# show clock
Wed May 10 10:23:37 UTC 2023
vedge#
show control connectionsコマンドを使用して、コントロール接続が有効であることを確認します。
vedge# show control connections
PEER PEER CONTROLLER
PEER PEER PEER SITE DOMAIN PEER PRIV PEER PUB GROUP
TYPE PROT SYSTEM IP ID ID PRIVATE IP PORT PUBLIC IP PORT LOCAL COLOR PROXY STATE UPTIME ID
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
vsmart dtls 10.3.3.1 10 1 192.168.24.112 12346 192.168.24.112 12346 private1 No up 0:14:33:46 0
vsmart dtls 10.3.3.1 10 1 192.168.24.112 12346 192.168.24.112 12346 private2 No up 0:14:33:46 0
vbond dtls 0.0.0.0 0 0 192.168.28.122 12346 192.168.28.122 12346 private1 - up 0:14:33:47 0
vbond dtls 0.0.0.0 0 0 192.168.28.122 12346 192.168.28.122 12346 private2 - up 0:14:33:47 0
vmanage dtls 10.1.1.1 10 0 192.168.25.209 12346 192.168.25.209 12346 private1 No up 0:14:33:46 0
注:この状態のvEdgeデバイスではアップグレードが必要です。優先順位を付け、できるだけ早く計画する必要があります。必要に応じて、営業時間外のメンテナンス時間帯に実施してください。 デバイスのリブートや電源の再投入による影響を避けるために、デバイスのアップグレードを計画します。アップグレードの前にデバイスをリブートしないでください。
vEdgeをアップグレードするには、次の手順を使用します。
- Maintenance > Software repositoryを使用して、vEdgeイメージ修正をvManageにコピーします。
- vManage UI Maintenance > Software upgradeからvEdgeをアップグレードします。
- Upgradeをクリックし、アップグレードが完了するまで待ちます
- 同じページに戻ります。vEdgeを選択し、Activateをクリックします
・コントロール接続とBFDセッションがアップしていることを確認します。
・ OMPルートとサービスVPNルートの確認:vEdgeとハブ/他のノード間のすべてのサービスVPNセグメントでエンドツーエンドのpingをテストします。
- アップグレード後の考慮事項の確認
18.4、19.x、および20.1からのアップグレード手順(2000年5月13日改訂UTC)
バージョン18.4、19.x、および20.1.xからのすべてのアップグレードは、バージョン20.3.7.1にアップグレードする必要があります。
このセクションでは、2.5Gより小さいブートディスクを使用するvManageを、20.1.3ではなく20.1.3.1にアップグレードする手順を修正しました。
新しい20.1.3.1 vManageソフトウェアには更新された証明書が含まれており、20.3.7.1への2回目のアップグレードの実行中にデバイスの接続が可能になります。
注意:先に進む前に、このセクションを注意深く読んでください。複数のアップグレードが必要になる場合があります。
アップグレード前のチェック
アップグレードを開始する前に、アップグレードが成功することを確認するためにすべての事前チェックを完了する必要があります。
これらのアップグレード前チェックでは、データベースのサイズ、コンピューティングリソース、およびブートディスクサイズが検証されます。
CLIによるデータベースサイズの確認
request nms configuration-db diagnosticコマンドを使用します | i TotalStoreSizeを使用して、データベースのサイズをバイト単位で取得します。
vshellからコマンドexpr <number of bytes> / 1024 / 1024 / 1024 を実行して、この出力をGBの整数値に変換します。
vmanage# request nms configuration-db diagnostics | i TotalStoreSize
| "StoreSizes" | "TotalStoreSize" | 3488298345 |
vmanage1# vshell
vmanage1:~$ expr 348829834 / 1024 / 1024 / 1024
3
この例では、データベースサイズが3 GBであることを示しています。
停止:データベースサイズが5 GB以上の場合は、TAC SRを開いて、このアップグレードに関するサポートを受けてください。
データベースサイズが5 GB未満の場合は、アップグレードを続行します。
コンピューティングリソースの確認
コンピューティングリソースが『20.3コンピューティングリソースガイド』に従っていることを確認します。
- lscpuコマンドを使用してvCPUを確認します。 | grep CPU\ MHz
vmanage1:~$ lscpu | grep CPU\ MHz
CPU MHz: 2999.658
vmanage1:~$
- free -gコマンドを使用してメモリを確認します。 | grep Memおよびfree —giga | grepメモリ
vmanage1:~$ free -g | grep Mem
Mem: 31 21 7 0 2 9
vmanage1:~$ free --giga | grep Mem
Mem: 33 23 7 0 2 9
vmanage1:~$
- コマンドdf -khを使用して、3番目のパーティション(/opt/data)のサイズを確認します。
vmanage1:~$ df -kh | grep "/opt/data"
/dev/sdb 108G 24G 79G 23% /opt/data
vmanage1:~$
コンピューティングリソースが20.3に適合していない場合は、アップグレード前にコンピューティングリソースを増やします。
CLIによるブートディスク領域の確認
df -khコマンドを使用します。 | grep bootコマンドをvShellから実行して、ディスクのサイズを確認します。
vmanage# vshell
vmanage:~$ df -kh | grep boot
/dev/sda1 5.0G 4.7G 343M 94% /boot
vmanage:~$
この例では、/boot diskが5.0Gであることを示しています。
警告:vManageブートディスクが2.5G未満の場合は、バージョン20.1へのアップグレードを実行する必要があります
バージョン18.4および19.xでのvManageのアップグレード
アップグレードの実行:vManage Standalone
ブートディスクのサイズが2.5G未満の場合は、続行する前にvManageをバージョン20.1にアップグレードする必要があります。
ディスクサイズが2.5G以上の場合は、20.3.7.1に直接アップグレードできます。
アップグレードの実行:vManageクラスタ
ディスクのサイズが2.5G未満の場合は、続行する前にvManageをバージョン20.1.3.1にアップグレードする必要があります。
ディスクサイズが2.5G以上の場合は、20.3.7.1に直接アップグレードできます。
vManage 20.1.xのアップグレード
アップグレードの実行:vManageスタンドアロンまたはクラスタ
vSmartおよびvBondを18.4、19.x、または20.1から20.3.7.1にアップグレード
vSmartsおよびvBondは、すべてのバージョンから20.3.7.1に直接アップグレードできます。
vEdgeを18.4、19.x、または20.1から20.3.7.1にアップグレード
vSmarts、vBond、vEdgeデバイスは、すべてのバージョンから20.3.7.1に直接アップグレードできます。
アップグレード後の考慮事項
アップグレード前にグレースフルリスタートのタイマーとIPSecキー再生成のタイマーを増やすように設定を変更した場合は、不必要な影響を避けるために、アップグレード前の設定に設定をロールバックすることを推奨します。
特別勧告
コントローラを20.3.7.1よりも前のバージョンにアップグレードしており、vEdgeのアップグレードを実行中のお客様は、TACに連絡して、それぞれのvEdgeイメージにアクセスできます。
Cisco Bug ID CSCwd46600に関するアドバイザリ
このドキュメントの以前のバージョンでは、20.3.xの複数のバージョン(20.3.3.2、20.3.5.1、20.3.4.3、20.3.7.1)にアップグレードすることを推奨していました。
イメージ20.3.xを実行しているお客様は、コントローラとvEdgeをイメージ20.3.7.1にアップグレードすることをお勧めします。
20.3.7.1より前のリリース19.xおよび20.3.x、20.4、20.6.5.1より前のリリース20.6xを実行しているデバイスでは、アップグレード後にCisco Bug ID CSCwd46600が発生する可能性があります。この問題を一時的に解決するには、次のいずれかのコマンドを実行します。
request security ipsec-rekey
または
request port-hop color
ただし、お客様はコントローラとvEdgeデバイスを20.3.7.1または20.6.5.1にアップグレードすることを強く推奨します。
以前のガイダンスに基づいて、すべてのvEdgeデバイスを20.3.7.1より前の20.3.7.1リリース、20.3.4.3リリース、または20.6.5.1より前の20.6.xリリースに完全にアップグレードしたお客様は、この不具合の影響を受けていない場合は、このリリースのままにすることができます。20.3.7.1または20.6.5.1へのアップグレードは、スケジュールされたメンテナンスの時間帯に後で行うことをお勧めします。
20.6.xリリーストレインに関するアドバイザリ(2080年5月15日改訂UTC)
このドキュメントの以前のバージョンでは、20.6.xの複数のバージョン(20.6.3.2、20.6.4.1、20.6.5.2)にアップグレードすることを推奨しています。
イメージ20.6.xを実行し、インターフェイスにトラッカーを設定しているお客様は、コントローラとvEdgeをイメージ20.6.5.2にアップグレードすることを推奨します。
トラッカーが設定されたデバイスでは、アップグレード中にCisco Bug ID CSCvz44093が発生する可能性があります。 このバグの影響を回避するために、アップグレードの前にトラッカー設定を削除できます。
コントローラとvEdgeデバイスを20.6.5.2にアップグレードすることを強く推奨します。
以前のガイダンスに基づいてすべてのvEdgeデバイスを20.6.3.2および20.6.4.1に完全にアップグレードしたお客様は、このバグの影響を受けていない場合は、このリリースを継続することを選択できます。