例:統合型 ISSU の実行

手順

どの種類の統合型 ISSU 手順を使用するかにかかわらず、GRES および NSR の有効化が必要です。

デバイスにデュアル ルーティング エンジンが搭載されていることを確認し、GRES と NSR を有効にするには:

1. デバイスにログインします。

2. コマンドを使用して show chassis hardware 、デュアルルーティングエンジンがデバイスにインストールされていることを確認します。

   コマンド出力には、ルーティング エンジン 0 とルーティング エンジン 1 をリストする行が含まれています。

3. デフォルトでは、GRES は無効になっています。まだ実施していない場合は、プライマリ ルーティング エンジンの 階層レベルで ステートメントをgraceful-switchover[edit chassis redundancy]含めて GRES を有効にします。

4. デフォルトでは、NSRは無効になっています。まだそうしていない場合は、 階層レベルで ステートメントを nonstop-routing 含めてNSRを [edit routing-options] 有効にします。

5. NSR を設定する場合、両方の commit synchronize ルーティング エンジンで [edit system] 設定変更が同期されるように、 階層レベルにも ステートメントを含める必要があります。

6. 設定を検証し、それに満足したら、 コマンドを使用して変更を commit コミットします。

   GRES を有効にし、設定をコミットすると、CLI プロンプトが変更され、使用しているルーティング エンジンが示されます。例えば：

7. コマンドを使用して、設定モードを exit 終了します。

8. コマンドを使用してshow task replication、NSR がプライマリ ルーティング エンジン(re0)で設定されていることを確認します。

   出力で、 フィールドに Synchronization Status . が表示されていることを確認します Complete。

9. コマンドを使用してshow system switchover、バックアップのルーティングエンジン()でGRESがre1有効になっていることを確認します。

   出力で、 フィールドの状態が Graceful switchover 表示されていることを確認しますOn。コマンドの詳細については、 システムスイッチオーバーをshow system switchover表示するを参照してください。

手順

統合型 ISSU では、アップグレードの前に両方のルーティング エンジンが同じバージョンの Junos OS を実行している必要があります。アップグレード中に問題が発生した場合の予防策として、システム ソフトウェアをデバイス のハード ディスクにバックアップすることをお勧めします。

ソフトウェアバージョンを検証し、デバイスソフトウェアをバックアップするには、次の手順に従います。

1. コマンドを使用して show version 、同じバージョンのJunos OSが両方のルーティングエンジンにインストールされ、実行されていることを確認します。

2. Routing Engine の コマンドを使用して、システム ソフトウェアを request system snapshot デバイス ハード ディスクに each バックアップします。

   メモ：

   ルート ファイル システムは /altroot にバックアップされ、 /config は /altconfig にバックアップされます。コマンドを request system snapshot 発行すると、デバイスのフラッシュとハードディスクが同一になります。リムーバブル メディアからデバイスを起動して、以前のバージョンのソフトウェアに戻すことができます。

手順

デバイスに以下の機能固有の設定がある場合は、適切な手順を実行します。

タイマーを調整し、機能固有の設定を変更するには:

1. BFD(Bidirectional Forwarding Detection)セッションは、統合型 ISSU 手順中に検出および送信タイマーを一時的に増加させます。アップグレード後、これらのタイマーは、統合型 ISSU が開始される前に使用中の値に戻ります。

   デバイスで BFD が有効になっていて、統合型 ISSU 中に BFD タイマー ネゴシエーションを無効にする場合は、 階層レベルに no-issu-timer-negotiation ステート メントを [edit protocols bfd] 含めます。

   メモ：

   このステートメントを含める場合、BFD タイマーは統合型 ISSU 中に元の値を維持し、検出間隔に応じて統合型 ISSU またはルーティング エンジン のスイッチオーバー中に BFD セッションがフラップすることがあります。

2. M シリーズ、MX シリーズ、または EX 9200 シリーズ デバイスでプロキシ ARP が有効になっている場合は、 階層レベルから ステートメントを[edit interfaces interface-name unit 0 family inet]削除unconditional-src-learnします。

   デフォルトでは、 ステートメントは含まれません。この例では、ge-0/0/1 インターフェイスのみを示しています。

3. PTX シリーズ デバイスで LACP が有効になっている場合は、 階層レベルから ステートメントを[edit interfaces interface-name aggregated-ether-options]削除lacpします。

4. MシリーズまたはT SeriesデバイスでATMポイントツーポイントプロトコル(PPP)が有効になっている場合、キープアライブ間隔を10秒以上に設定します。

   PPPでは、セッションがダウンする前に3つのキープアライブが失敗する必要があります。30 秒(10 秒 x 3)は、統合型 ISSU 操作中にトラフィックロスが発生した場合に PPP セッションを維持するための安全なマージンを提供します。

   この例では、at-0/0/1 インターフェイスのみを示しています。

5. M シリーズまたは T シリーズ デバイスで ATM OAM が有効になっている場合、統合型 ISSU 全体で ATM 接続を維持するために、OAM F5 ループバック セル期間を 20 秒以上に設定します。

   階層レベルに oam-period ステートメントを [edit interfaces interface-name unit logical-unit-number] 含め、20 秒を指定します。この例では、at-0/0/1 インターフェイスのみを示しています。

6. 設定を検証し、それに満足したら、 コマンドを使用して変更を commit コミットします。

7. コマンドを使用して、設定モードを exit 終了します。

手順

この手順では、両方のルーティング エンジンが自動的に再起動します。最も一般的なシナリオは、両方のルーティング エンジンを自動的に再起動することです。この手順のバリエーションについては、他のセクションで説明します。

表 1 は、統合型 ISSU を起動する前のルーティング エンジンの状態を示しています。

両方のルーティング エンジンを自動的にアップグレードして再起動するには、次の手順にいます。

1. コマンドを使用して、Junos OS ソフトウェア パッケージをデバイスに file copy ftp://username@hostname.net/filename /var/tmp/filename コピーします。

   パッケージは、ハードディスク上の大きなファイルシステムである /var/tmp ディレクトリにコピーすることをお勧めします。

   ベスト プラクティス:

   デバイスのソフトウェアのダウンロード Web ページにアクセスしたら、md5 チェックサムを記録します。ソフトウェア パッケージをデバイスにダウンロードした後、 コマンドを使用して修正されていないことを file checksum md5 確認します。md5 チェックサムの検証の詳細については、「 https://kb.juniper.net/InfoCenter/index?page=content&id=KB17665 」を参照してください。

2. プライマリ ルーティング エンジンで、 コマンドを使用してアップグレードを request system software in-service-upgrade package-name reboot 開始します。

   メモ：

   メッセージが表示され、セッションが切断されるまで、追加の Connection closed コマンドを実行しないでください。

   以前はプライマリだったルーティング エンジンが再起動されると、デバイスからログアウトされます。

3. 数分待ってから、もう一度デバイスにログインします。

   表 2 は、統合型 ISSU の後のルーティング エンジンステータスを示しています。

   表 2:両方のルーティング エンジンのアップグレードと再起動後のルーティング エンジン ステータス

   RE0	RE1
   バックアップ	プライマリ
   インストールされた新しいソフトウェア バージョン	インストールされた新しいソフトウェア バージョン
   実行中の新しいソフトウェア バージョン	実行中の新しいソフトウェア バージョン

   新しいバックアップルーティングエンジン(re0)にログインしています。

4. 両方のルーティング エンジンが、 コマンドを使用して show version アップグレードされていることを確認します。

5. 必要に応じて、 コマンドを使用して統合型 ISSU ログ メッセージを show log messages 表示することもできます。

6. 必要に応じて、 コマンドを使用してプライマリルーティングエンジンをrequest chassis routing-engine master acquire作成re0することもできます。

   表 3 は、ステップ 5 が完了した後のルーティング エンジンのステータスを示しています。

   表 3:プライマリ ロールのアップグレード、再起動、スイッチング後のルーティング エンジンステータス

   RE0	RE1
   プライマリ	バックアップ
   インストールされた新しいソフトウェア バージョン	インストールされた新しいソフトウェア バージョン
   実行中の新しいソフトウェア バージョン	実行中の新しいソフトウェア バージョン

7. 機能固有の設定の復元に関する該当する手順を実行します。

8. テストの結果に問題がない場合は、ルーティング エンジンの コマンドを使用 request system snapshot して、オプションでシステム ソフトウェアをデバイスのハード ディスクに each バックアップできます。

   メモ：

   ルート ファイル システムは /altroot にバックアップされ、 /config は /altconfig にバックアップされます。コマンドを request system snapshot 発行すると、デバイスのフラッシュとハードディスクが同一であるため、以前のバージョンのソフトウェアに簡単に戻すことはできません。以前のバージョンのソフトウェアに戻すためには、リムーバブル メディアからデバイスを起動する必要があります。

手順

デバイスに以下の機能固有の設定がある場合は、適切な手順を実行します。

機能固有の設定を復元するには:

1. デバイスで BFD が有効になっていて、以前に BFD タイマー ネゴシエーションを無効にした場合は、 階層レベルで ステートメントを[edit protocols bfd]削除no-issu-timer-negotiationします。

2. M シリーズ、MX シリーズ、または EX9200 デバイスでプロキシ ARP が有効になっていて、以前に ステートメントを unconditional-src-learn 削除した場合は、もう一度 ステートメントを含めます。

   この例では、ge-0/0/1 インターフェイスのみを示しています。

3. PTXシリーズデバイスでLACPが有効になっていて、以前にステートメントを lacp 削除した場合は、もう一度ステートメントを含めます。

4. M SeriesまたはT SeriesデバイスでATM PPPが有効になっており、キープアライブ間隔を10秒以上に設定した場合、元の値を復元します。

   この例では、at-0/0/1 インターフェイスのみを示し、間隔がデフォルトの 3 秒に設定されていることを示しています。

5. M シリーズまたは T シリーズ デバイスで ATM OAM が有効になっていて、以前に OAM F5 ループバック セル期間を 20 秒以上に設定した場合、設定を元の値に戻します。

   この例では、at-0/0/1 インターフェイスのみを示し、ピリオドが 10 秒に設定されていることを示しています。

6. 設定を検証し、それに満足したら、 コマンドを使用して変更を commit コミットします。

7. コマンドを使用して、設定モードを exit 終了します。

手順

特定の状況では、新しいソフトウェアをテストできるまで、1 つのルーティング エンジンにのみ新しいソフトウェアをインストールし、プライマリのみを再起動することができます。ルーティング エンジンは、再起動されるまで新しいソフトウェアの実行を開始しません。

利点は、テストの結果、ソフトウェアをダウングレードする必要がある場合、ルーティングエンジンを切り替えて、1つのルーティングエンジンで古いソフトウェアを実行し、もう一方のルーティングエンジンに古いソフトウェアをインストールできることです。これは典型的なシナリオではありません。

両方のルーティング エンジンをアップグレードし、新しいバックアップ ルーティング エンジンを手動で再起動するには、次の手順にしたがってください。

1. デュアル ルーティング エンジンの検証と GRES と NSR の有効化の手順を実行します。

2. ソフトウェアバージョンの検証とデバイスソフトウェアのバックアップの手順を実行します。

3. タイマーの調整と機能固有の設定の変更の手順を実行します。

4. コマンドを使用して、Junos OSソフトウェアパッケージをデバイスに file copy ftp://username@hostname.net/filename /var/tmp/filename コピーします。

   パッケージは、ハードディスク上の大きなファイルシステムである /var/tmp ディレクトリにコピーすることをお勧めします。

   ベスト プラクティス:

   デバイスのソフトウェアのダウンロード Web ページにアクセスしたら、md5 チェックサムを記録します。ソフトウェア パッケージをデバイスにダウンロードした後、 コマンドを使用して修正されていないことを file checksum md5 確認します。md5 チェックサムの検証の詳細については、「 https://kb.juniper.net/InfoCenter/index?page=content&id=KB17665 」を参照してください。

   表 4 は、統合型 ISSU を起動する前のルーティング エンジンのステータスを示しています。

   表 4:バックアップ ルーティング エンジンのアップグレードと手動再起動前のルーティング エンジン ステータス

   RE0	RE1
   プライマリ	バックアップ
   インストール済みの古いソフトウェア バージョン	インストール済みの古いソフトウェア バージョン
   実行されている古いソフトウェア バージョン	実行されている古いソフトウェア バージョン

5. プライマリ ルーティング エンジンで、再起動オプションを使用せずに コマンドを request system software in-service-upgrade package-name 使用してアップグレードを開始します。

   表 5 は、統合型 ISSU の後とバックアップ のルーティング エンジンを手動で再起動する前のルーティング エンジンステータスを示しています。

   表 5:アップグレード後およびバックアップ ルーティング エンジンの手動再起動前のルーティング エンジン ステータス

   RE0	RE1
   バックアップ	プライマリ
   インストールされた新しいソフトウェア バージョン	インストールされた新しいソフトウェア バージョン
   実行されている古いソフトウェア バージョン	実行中の新しいソフトウェア バージョン

6. コマンドを使用して、新しいバックアップ(古いプライマリ)ルーティングエンジン(re0)がまだ以前のソフトウェアイメージを実行していること、および新しいプライマリルーティングエンジン(re1)が新しいソフトウェアイメージを show version 実行していることを確認します。

7. この時点で、新しいバックアップルーティングエンジン(re0)に新しいソフトウェアバージョンをインストールしない場合は、 コマンドを request system software delete package-name 発行します。

   それ以外の場合は、アップグレードを完了するには、次のステップに進みます。

8. コマンドを発行して、新しいバックアップルーティングエンジン(re0)を request system reboot 再起動します。

   コンソール ポートにない場合、デバイス セッションから切断されます。

   表 6 は、統合型 ISSU の後、バックアップ ルーティング エンジンを再起動した後、プライマリ ロールを切り替える前のルーティング エンジンステータスを示しています。

   表 6:アップグレード後、手動再起動後、プライマリ ロールの切り替え前のルーティング エンジンのステータス

   RE0	RE1
   バックアップ	プライマリ
   インストールされた新しいソフトウェア バージョン	インストールされた新しいソフトウェア バージョン
   実行中の新しいソフトウェア バージョン	実行中の新しいソフトウェア バージョン

9. 数分待ってから、もう一度デバイスにログインします。

   新しいバックアップルーティングエンジン(re0)にログインしています。

10. 両方のルーティング エンジンが、 コマンドを使用して show version アップグレードされていることを確認します。

11. 必要に応じて、 コマンドを使用して統合型 ISSU ログ メッセージを show log messages 表示することもできます。

12. 必要に応じて、 コマンドを使用して、オプションでプライマリルーティングエンジンをrequest chassis routing-engine master acquire作成re0できます。

    表 7 は 、統合型 ISSU の後、バックアップ ルーティング エンジンの再起動後、プライマリ ロールの切り替え後のルーティング エンジンの状態を示しています。

    表 7:アップグレード後のルーティング エンジン のステータス、手動での再起動、プライマリ ロールのスイッチング

    RE0	RE1
    プライマリ	バックアップ
    インストールされた新しいソフトウェア バージョン	インストールされた新しいソフトウェア バージョン
    実行中の新しいソフトウェア バージョン	実行中の新しいソフトウェア バージョン

13. 機能固有の設定の復元に関する該当する手順を実行します。

14. テストの結果に問題がない場合は、ルーティング エンジンの コマンドを使用 request system snapshot して、オプションでシステム ソフトウェアをデバイスのハード ディスクに each バックアップできます。

    メモ：

    ルート ファイル システムは /altroot にバックアップされ、 /config は /altconfig にバックアップされます。コマンドを request system snapshot 発行すると、デバイスのフラッシュとハードディスクが同一であるため、以前のバージョンのソフトウェアに簡単に戻すことはできません。以前のバージョンのソフトウェアに戻すためには、リムーバブル メディアからデバイスを起動する必要があります。

手順

特定の状況では、1 つのルーティング エンジンにのみ新しいソフトウェアをインストールすることができます。

利点は、テストの結果、ソフトウェアをダウングレードする必要がある場合、ルーティングエンジンを切り替えて、1つのルーティングエンジンで古いソフトウェアを実行し、もう一方のルーティングエンジンに古いソフトウェアをインストールできることです。これは典型的なシナリオではありません。

表 8 は、統合型 ISSU を起動する前のルーティング エンジンのステータスを示しています。

1 つのルーティング エンジンのみをアップグレードして再起動するには、次の手順に示します。

1. デュアル ルーティング エンジンの検証と GRES と NSR の有効化の手順を実行します。

2. ソフトウェアバージョンの検証とデバイスソフトウェアのバックアップの手順を実行します。

3. タイマーの調整と機能固有の設定の変更に該当する手順を実行します。

4. コマンドを使用して、Junos OS ソフトウェア パッケージをデバイスに file copy ftp://username@hostname.net/filename /var/tmp/filename コピーします。

   パッケージは、ハードディスク上の大きなファイルシステムである /var/tmp ディレクトリにコピーすることをお勧めします。

   ベスト プラクティス:

   デバイスのソフトウェアのダウンロード Web ページにアクセスしたら、md5 チェックサムを記録します。ソフトウェア パッケージをデバイスにダウンロードした後、 コマンドを使用して修正されていないことを file checksum md5 確認します。md5 チェックサムの検証の詳細については、「 https://kb.juniper.net/InfoCenter/index?page=content&id=KB17665 」を参照してください。

5. プライマリ ルーティング エンジンで、 コマンドを使用してアップグレードを request system software in-service-upgrade package-name no-old-master-upgrade 開始します。

   表 9 は、統合型 ISSU がプライマリ ルーティング エンジンをアップグレードした後、バックアップ ルーティング エンジンがアップグレードされる前のルーティング エンジン ステータスを示しています。

   表 9:1 つのルーティング エンジンをアップグレードした後、もう一方のルーティング エンジンをアップグレードする前のルーティング エンジンのステータス

   RE0	RE1
   バックアップ	プライマリ
   インストール済みの古いソフトウェア バージョン	インストールされた新しいソフトウェア バージョン
   実行されている古いソフトウェア バージョン	実行中の新しいソフトウェア バージョン

6. コマンドを使用して、新しいバックアップ(古いプライマリ)ルーティングエンジン(re0)がまだ以前のソフトウェアイメージを実行していること、および新しいプライマリルーティングエンジン(re1)が新しいソフトウェアイメージを show version 実行していることを確認します。

7. テストが完了し、新しいソフトウェアをバックアップのルーティング エンジンにインストールする場合、まず両方のルーティング エンジンで GRES と NSR を無効にし、設定をコミットする必要があります。

8. コマンドを使用して、バックアップルーティングエンジン(re0)に新しいソフトウェアを request system software add /var/tmp/jinstall64-14.1R4.10-domestic-signed.tgz インストールします。

9. コマンドをrequest system reboot使用して再起動re0します。

   コンソール ポートにない場合、ルーター セッションから切断されます。

10. 数分待ってから、もう一度デバイスにログインします。

    バックアップのルーティング エンジン(re0)にログインしています。

11. 両方のルーティング エンジンが、 コマンドを使用して新しいソフトウェア イメージを show version 実行していることを確認します。

12. 必要に応じて、 コマンドを使用して統合型 ISSU ログ メッセージを show log messages 表示することもできます。

13. 必要な場合は、 コマンドを使用してプライマリルーティングエンジンを作成re0request chassis routing-engine master acquireします。

    表 10 は 、統合型 ISSU の後、バックアップ ルーティング エンジンの再起動後、プライマリ ロールの切り替え後のルーティング エンジンステータスを示しています。

    表 10:アップグレード後のルーティング エンジンのステータス、手動での再起動、プライマリ ロールのスイッチング

    RE0	RE1
    プライマリ	バックアップ
    インストールされた新しいソフトウェア バージョン	インストールされた新しいソフトウェア バージョン
    実行中の新しいソフトウェア バージョン	実行中の新しいソフトウェア バージョン

14. デュアル ルーティング エンジンの検証と GRES と NSR の有効化の手順を実行して 、GRES と NSR を再度有効にします。

15. 機能固有の設定の復元に関する該当する手順を実行します。

16. テストの結果に問題がない場合は、ルーティング エンジンの コマンドを使用 request system snapshot して、オプションでシステム ソフトウェアをデバイスのハード ディスクに each バックアップできます。

    メモ：

    ルート ファイル システムは /altroot にバックアップされ、 /config は /altconfig にバックアップされます。コマンドを request system snapshot 発行すると、デバイスのフラッシュとハードディスクが同一であるため、以前のバージョンのソフトウェアに簡単に戻すことはできません。以前のバージョンのソフトウェアに戻すためには、リムーバブル メディアからデバイスを起動する必要があります。