Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

統合型ISSUの実行

以下の手順に従って、統合型 ISSU を実行します。

統合型ISSUを実行するためのベストプラクティス

統合型インサービスソフトウェアアップグレード(ISSU)の実行を計画している場合は、ネットワークができるだけ安定している時間を選択してください。通常のアップグレードと同様に、Telnet セッション、SNMP、および CLI アクセスが一時的に中断されます。さらに、次の制限が適用されます。

  • 統合型ISSUを実行する前に、プライマリルーティングエンジンとバックアップルーティングエンジンで同じソフトウェアバージョンが実行されている必要があります。

  • プラットフォームが統合型 ISSU 機能をサポートしていることを確認します。

  • 「統合型ISSUのシステム要件」の章の「統合型ISSUに関する考慮事項」トピックを読んで、アップグレードに影響を与える可能性のある特別な状況を予測してください。

例:統合型 ISSU の実行

この例では、統合型インサービスソフトウェアアップグレード(ISSU)を実行する方法を示しています。

必要条件

この例では、以下のハードウェアとソフトウェアのコンポーネントを使用しています。

  • デュアルルーティングエンジン搭載のMX480ルーター

  • 開始リリースとしてのJunos OS リリース 13.3R6

  • 終了リリースとしての Junos OS リリース 14.1R4

始める前に

統合型 ISSU を実行する前に、必ず以下を実行してください。

  • コマンドを使用して、互換性チェックを実行し、デバイス上のソフトウェアとハードウェアのコンポーネント、および設定が統合型ISSUをサポートしていることを確認します

  • 「統合型ISSUのシステム要件」の章を読んで、アップグレードに影響を与える可能性のある特別な状況を予測してください。

    • プラットフォームが統合型 ISSU 機能をサポートしていることを確認します。

    • プラットフォームに取り付けられているFRU(現場交換可能ユニット)が統合型ISSU機能をサポートしているか、または統合型ISSUをサポートしていない一部のFRUでアップグレードを実行した結果を受け入れることができることを確認します。

    • プラットフォームに設定されているプロトコルと機能が統合型ISSU機能をサポートしていること、または統合型ISSUをサポートしていない一部のプロトコルと機能でアップグレードを実行した結果を受け入れることができることを確認します。

  • https://www.juniper.net/support/ のジュニパーネットワークスサポートウェブサイトからソフトウェアパッケージをダウンロードし、ローカルサーバーに配置します。

    ベスト プラクティス:

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

    手記:

    Junos OS リリース 16.1R1 以降では、FreeBSD 6.1 ベースの Junos OS からアップグレードされた FreeBSD 10.x ベースの Junos OS への統合型 ISSU を実行する際に、リモート ホストまたはルーティング エンジンで設定を検証する必要があります。リモートホストまたはルーティングエンジンは、FreeBSDがアップグレードされたJunos OSを実行している必要があります。さらに、FreeBSD 6.1 ベースの Junos OS から FreeBSD 10.x ベースの Junos OS へのアップグレード時に保持されるのは、選択した少数のディレクトリとファイルのみです。アップグレードされた FreeBSDを備えたJunos OS およびリクエストシステム ソフトウェアvaldiateを参照してください(アップグレードされたFreeBSDを搭載したJunos OS)

概要

この手順は、デュアル ルーティング エンジンがインストールされ、統合型 ISSU をサポートする M Series、T Series、MXシリーズ、EXシリーズ、PTXシリーズ シリーズのデバイスをアップグレードするために使用できます。

この例では、ホスト名、ファイル名、FRUは表記されています。お使いのデバイスでこの手順を実行する場合、ホスト名、ファイル名、FRUは異なります。コマンド出力は、この手順で関心のあるテキストのみを表示するために切り捨てられます。

位相幾何学

図 1 は、この例で使用されているトポロジーを示しています。

図 1:統合型 ISSU のトポロジー例 Unified ISSU Example Topology

構成

新しいソフトウェアを一方または両方のルーティング エンジンにインストールする場合や、両方のルーティング エンジンを自動的に再起動するか、一方のルーティング エンジンを手動で再起動するかによって、手順は異なります。

いずれの場合も、デュアルルーティングエンジンがインストールされていること、グレースフルルーティングエンジンスイッチオーバー(GRES)とノンストップアクティブルーティング(NSR)が有効になっていることを確認する必要があります。アップグレードの前に、デバイス ソフトウェアをバックアップすることをお勧めします。

統合型ISSU を実行するには、次のリストから適切なタスクを選択します。

デュアルルーティングエンジンの検証とGRESとNSRの有効化

プロシージャ

手順

GRES と NSR は、使用する統合型 ISSU 手順のバリエーションに関係なく必須です。

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

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

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

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

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

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

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

  6. 設定を確認して問題がなければ、 commit コマンドを使用して変更をコミットします。

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

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

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

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

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

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

ソフトウェアのバージョンの確認とデバイスソフトウェアのバックアップ

プロシージャ

手順

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

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

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

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

    手記:

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

タイマーの調整と機能固有の設定の変更

プロシージャ

手順

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

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

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

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

    手記:

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

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

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

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

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

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

  6. 設定を検証して問題がなければ、 commit コマンドを使用して変更をコミットします。

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

両方のルーティング エンジンの自動アップグレードと再起動

プロシージャ

手順

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

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

表 1: アップグレード前のルーティングエンジン ステータス

RE0

RE1の

原発

バックアップ

インストールされている古いソフトウェアバージョン

インストールされている古いソフトウェアバージョン

実行中の古いソフトウェアバージョン

実行中の古いソフトウェアバージョン

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

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

    パッケージを /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. 必要に応じて、 show log messages コマンドを使用して、オプションで統合型 ISSU ログ メッセージを表示できます。

  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 Series、MXシリーズ、または EX9200 デバイスで プロキシ ARP が有効になっていて、以前に unconditional-src-learn ステートメントを削除した場合は、ステートメントを再度含めます。

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

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

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

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

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

    この例では、at-0/0/1インターフェイスのみを示し、10秒に設定された周期を示しています。

  6. 設定を検証して問題がなければ、 commit コマンドを使用して変更をコミットします。

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

両方のルーティング エンジンをアップグレードし、新しいバックアップ ルーティングエンジンを手動で再起動する

プロシージャ

手順

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

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

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

  1. デュアルルーティングエンジンの検証および GRES と NSR の有効化のステップを実行します。

  2. ソフトウェア バージョンの確認および デバイス ソフトウェアのバックアップの手順を実行します。

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

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

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

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

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

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

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

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

    表 6: アップグレード後、手動再起動後、およびプライマリ ロールを切り替える前のルーティングエンジンの状態

    RE0

    RE1の

    バックアップ

    原発

    新しいソフトウェアバージョンがインストールされました

    新しいソフトウェアバージョンがインストールされました

    新しいソフトウェアバージョンが稼働中

    新しいソフトウェアバージョンが稼働中

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

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

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

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

  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 を起動する前のルーティングエンジンの状態を示しています。

表 8: 1 つのルーティングエンジンをアップグレードして再起動する前のルーティングエンジンの状態

RE0

RE1の

原発

バックアップ

インストールされている古いソフトウェアバージョン

インストールされている古いソフトウェアバージョン

実行中の古いソフトウェアバージョン

実行中の古いソフトウェアバージョン

1つのルーティングエンジンのみをアップグレードおよび再起動する場合は、次の手順に従います。

  1. デュアルルーティングエンジンの検証および GRES と NSR の有効化のステップを実行します。

  2. ソフトウェア バージョンの確認および デバイス ソフトウェアのバックアップの手順を実行します。

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

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

    パッケージを /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つのルーティングエンジンをアップグレードした後、もう1つのルーティングエンジンをアップグレードする前のルーティングエンジンのステータス

    RE0

    RE1の

    バックアップ

    原発

    インストールされている古いソフトウェアバージョン

    新しいソフトウェアバージョンがインストールされました

    実行中の古いソフトウェアバージョン

    新しいソフトウェアバージョンが稼働中

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

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

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

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

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

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

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

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

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

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

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

    表 10: アップグレード、手動再起動、およびプライマリ ロールの切り替え後のルーティングエンジンの状態

    RE0

    RE1の

    原発

    バックアップ

    新しいソフトウェアバージョンがインストールされました

    新しいソフトウェアバージョンがインストールされました

    新しいソフトウェアバージョンが稼働中

    新しいソフトウェアバージョンが稼働中

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

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

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

    手記:

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

ノンストップルーティングでISSU(In-Service Software Upgrade)を実行

ノンストップルーティングによるインサービスソフトウェアアップグレードを使用して、アップグレード中のトラフィックの中断を最小限に抑えながら、スイッチで実行されているソフトウェアをアップグレードできます。

手記:

QFX5200スイッチのJunos OS リリース 18.2R1以降では、インサービスソフトウェアアップグレードの間に少なくとも5分空けることをお勧めします。

手記:

Junos OS リリース 17.1R1以降、QFX5100およびEX4600スイッチでは、17.1R1より前のJunos OS リリースからJunos OS リリース 17.1R1へのISSUを実行することはできません。

このトピックの内容は次のとおりです。

ソフトウェアをインストールするためのスイッチの準備

ISSU を使用したソフトウェアのインストールを開始する前に、以下を行ってください。

手記:

インサービス ソフトウェア アップグレードを実行する前に、該当する場合は、設定から set system internet-options no-tcp-reset drop-all-tcp コマンドを削除してください。そうしないと、アップグレードが失敗し、エラー メッセージが表示されます。

NSB およびノンストップ ルーティングにより、NSB がサポートするレイヤー 2 プロトコルは、プライマリおよびバックアップ ルーティング エンジン間でプロトコル情報を同期できます。

ISSU を使用したソフトウェアのアップグレード

この手順では、スタンドアロン スイッチで実行されているソフトウェアをアップグレードする方法について説明します。

手記:

ホストOSソフトウェアを更新する必要がある場合、ISSUは実行できません。代わりに、標準のソフトウェア アップグレードを実行してください。

ISSU を使用してスイッチをアップグレードするには、次の手順を実行します。

  1. QFXシリーズ デバイスへのソフトウェア パッケージのインストールの「ブラウザによるソフトウェア ファイルのダウンロード」セクションの手順に従って、ソフトウェア パッケージをダウンロードします。

  2. ソフトウェア パッケージをスイッチにコピーします。ファイルを /var/tmp ディレクトリにコピーすることをお勧めします。

  3. コンソール接続にログインします。コンソール接続を使用すると、アップグレードの進行状況を監視できます。

  4. ISSU を起動します。

    • スイッチで、次のように入力します。

      ここで、 package-name.tgz は、例えば、 jinstall-host-qfx-5e-18.1R1-secured-signed.tgzです。

    手記:

    アップグレード中は、Junos OS CLIにアクセスできなくなります。

    アップグレードの実行時に、スイッチに次のようなステータス メッセージが表示されます。

    手記:

    ISSU プロセスが停止した場合、 request system software in-service-upgrade コマンドを発行するときに CLI 出力を確認して問題を診断できます。詳細については、syslog ファイルを参照してください。

  5. スイッチの再起動が完了したら、ログインします。ソフトウェアがアップグレードされたことを確認するには、次のコマンドを入力します。

ACX5000シリーズルーターでのISSU(インサービスソフトウェアアップグレード)の実行

インサービス ソフトウェア アップグレードを使用すると、アップグレード中のトラフィックの中断を最小限に抑えながら、ルーターで実行されているソフトウェアをアップグレードできます。

手記:

ISSU は、Junos OS リリース 15.1X54–D60 以降の ACX5000 シリーズ ルーターでサポートされています。

このトピックの内容は次のとおりです。

ソフトウェアをインストールするためのルーターの準備

ISSU を使用したソフトウェアのインストールを開始する前に、以下を行ってください。

手記:

インサービス ソフトウェア アップグレードを実行する前に、該当する場合は、設定から set system internet-options no-tcp-reset drop-all-tcp コマンドを削除します。そうしないと、アップグレードが失敗し、エラー メッセージが表示されます。

  • ノンストップ アクティブ ルーティング(NSR)とノンストップ ブリッジング(NSB)が有効になっていることを確認します。NSRとGRを同時に有効にできないため、有効にする場合は、グレースフルリスタート(GR)を無効にします。NSB と GR は、NSB がサポートするレイヤー 2 プロトコルが、プライマリとバックアップのルーティング エンジン間でプロトコル情報を同期することを可能にします。

  • NSRが有効になっていない(Stateful ReplicationDisabled)の場合は、NSRを有効にします。NSRでは、グレースフルルーティングエンジンスイッチオーバー(GRES)を設定する必要があります。デフォルトでは、NSR は無効になっています。

    • グレースフル ルーティングエンジン スイッチオーバーを有効にするには、[edit chassis redundancy] 階層レベルで graceful-switchover ステートメントを user@host#set chassis redundancy graceful-switchover として含めます。

    • NSR を有効にするには、[edit routing-options] 階層レベルに user@host#set routing-options nonstop-routing として nonstop-routing ステートメントを含めます。

  • ノンストップ ブリッジング(NSB)を有効にします。ノンストップブリッジングでは、グレースフルルーティングエンジンスイッチオーバー(GRES)を設定する必要があります。デフォルトでは、NSB は無効になっています。

    • グレースフル ルーティングエンジン スイッチオーバーを有効にするには、[edit chassis redundancy] 階層レベルで graceful-switchover ステートメントを user@host#set chassis redundancy graceful-switchover として含めます。

    • NSB を有効にするには、[edit protocols layer2-control] 階層レベルで nonstop-bridging ステートメントを user@host#set protocols layer2-control nonstop-bridging として含めます。

  • (オプション) request system snapshot コマンドを使用して、ルーター上のシステム ソフトウェア(Junos OS、アクティブ設定、ログ ファイル)を外部ストレージ デバイスにバックアップします。

ACX5000シリーズルーターでは、ISSUを実行する前に、次の機能を考慮する必要があります。

  • ISSU は、1 秒間隔の LFM(リンク障害管理)タイムアウト セッションをサポートします。ISSU 中に、タイムアウト間隔が 1 秒未満のセッションで LFM フラップが見られる場合があります。

  • タイムアウト間隔が 1 秒未満の BFD(双方向フォワーディング検出)セッションは、ISSU プロセスを開始する前に 1 秒に再設定する必要があります。ISSU プロセスの完了後に、タイムアウト間隔を元の値に戻すことができます。

  • ISSU は、LACP(リンク アグリゲーション制御プロトコル)パケットの定期送信に対して、低速インターバル(30 秒ごと)をサポートします。

  • ISSU は、VRRP(仮想ルーター冗長プロトコル)バージョン 3 をサポートしています。

ISSU は、次のACX5000機能をサポートしていません。

  • Junos OSソフトウェアの以前のバージョンにダウングレードします。Junos OSソフトウェアの以前のバージョンをインストールする場合は、 request system software add CLIコマンドを使用します。

  • ホストOSソフトウェアのアップグレード。

  • CFM(Connectivity Fault Management)。

  • TWAMP、RPF、RFC2544、clocksyncd デーモン(タイミング機能)。

  • ミラーリングと疑似配線クロスコネクト。

  • IPv6ファイアウォール、IPv6 COS(分類と書き換え)、IPv6 VPN、VPLSメッシュグループ。

  • VRRP(Virtual Router Redundancy Protocol)バージョン 1 および 2。

  • Link Aggregation Control Protocol(LACP)パケットの定期送信の間隔を速く(毎秒)。定期的な間隔 fast が設定されている場合、ISSU 中に LACP リンクがダウンすることでトラフィックが落ちることがあります。ACX5000シリーズルーターは、ISSUを起動する前にメインルーターとピアルーターで fast-hello-issu オプション(user@host# set protocols lacp fast-hello-issu)を設定することで、高速helloでLACPをサポートできます。

    手記:

    ピアルーターには、この機能をサポートするための Junos OS ソフトウェアが必要です。

ISSU を使用したソフトウェアのアップグレード

この手順では、スタンドアロン ルーターで実行されているソフトウェアをアップグレードする方法について説明します。

手記:

ホストOSソフトウェアを更新する必要がある場合、ISSUは実行できません。代わりに、標準のソフトウェア アップグレードを実行してください。

ISSU プロセスを開始する前に、 /var ディレクトリ(/var/log/var/tmp)から不要なデータをクリーンアップすることを推奨します。

ISSU を使用してルーターをアップグレードするには、次の手順を実行します。

  1. ジュニパーネットワークスのサポートウェブサイト https://www.juniper.net/support/downloads/junos.html からソフトウェア パッケージをダウンロードします。

    手記:

    ダウンロードサイトにアクセスするには、ジュニパーネットワークスとのサービス契約とアクセスアカウントが必要です。アカウントの取得でサポートが必要な場合は、ジュニパーネットワークスの Web サイトhttps://www.juniper.net/registration/Register.jsp の登録フォームに必要事項をご記入ください。

  2. ACXシリーズセクションに移動し、ダウンロードするACX5000シリーズプラットフォームソフトウェアを選択します。

  3. ソフトウェア パッケージをルータにコピーします。ファイルを /var/tmp ディレクトリにコピーすることをお勧めします。

  4. コンソール接続にログインします。コンソール接続を使用すると、アップグレードの進行状況を監視できます。

  5. ISSU を起動します。

    • ルーターで、次のように入力します。

      ここで、 package-name.tgz は、例えば、 jinstall-acx5k-15.1X54-D60.9-domestic-signed.tgzです。

    手記:

    アップグレード中は、Junos OS CLIにアクセスできなくなります。

    ルーターは、アップグレードの実行時に、次のようなステータス メッセージを表示します。

    手記:

    FPCがウォームブート段階にある場合、ISSUは終了する代わりに停止することがあります。また、ダウンとアップのリンクは、パケット転送エンジン(PFE)のウォームブート中には検出されません。

    手記:

    ISSU プロセスが停止した場合は、ログ ファイルを確認して問題を診断できます。ログファイルは /var/log/vjunos-log.tgzにあります。

  6. ルーターの再起動後にログインします。ソフトウェアがアップグレードされたことを確認するには、次のコマンドを入力します。

  7. ISSUを有効にするために行われた設定を無効にするか削除します。これには、ノンストップアクティブルーティング(NSR)、ノンストップブリッジング(NBR)、およびグレースフルルーティングエンジン(GRES)の無効化が含まれます。

統合型ISSUの検証

最新の統合型ISSU後のFPCとそれに対応するPICのステータスを確認します。

プライマリ ルーティングエンジンで show chassis in-service-upgrade コマンドを発行します。

show log messages コマンドを使用して、統合型 ISSU プロセス メッセージを表示します。

統合型 ISSU と拡張モードの使用方法

拡張モードを備えた統合型ISSUの概要

拡張モードは、MPC8E、MPC9E、MPC11E ライン カードで利用可能なインサービス ソフトウェア アップグレード(ISSU)オプションで、統合型 ISSU プロセス中のパケット ロスをなくします。これは、統合型ISSU中にソフトウェアが古いイメージから新しいイメージに移行している間に、スタンバイモードのラインカード上で実行されているJunos OSソフトウェアの2つ目のコピーを引き継ぐことができる、新しいラインカードアーキテクチャの改善を活用することで実現します。request system software in-service-upgrade CLI コマンドに enhanced-mode オプションを追加することで、拡張モードを有効にできます。

このドキュメントでは、拡張モードを使用した統合型ISSU とその使用方法について説明します。

拡張モードを備えた統合型ISSUのメリット

拡張モードを備えた統合型ISSUには、次のメリットがあります。

  • トランジットやホストバウンドトラフィックの損失なしに、新しいソフトウェアバージョンにアップグレード

  • パケットロスをゼロまたは数ミリ秒に短縮(設定やネットワークの状態による)

  • メンテナンス期間なしでソフトウェアアップグレードが可能

  • 既存の統合型ISSUプロセスを使用し、特別な設定は不要

拡張モードで統合型 ISSU を実行するための前提条件

拡張モードで統合型 ISSU を開始する前に、留意すべきいくつかの前提条件があります。

  • 拡張モードで統合型ISSUを実行するデバイスは、MPC8E、MPC9E、またはMPC11Eラインカードを使用する必要があります。

    手記:

    サポートされているラインカードとサポートされていないラインカードが混在するデバイスで、拡張モードを備えた統合型ISSUを実行している場合、サポートされていないラインカードを通過するトラフィックのトラフィック損失が1秒未満に発生します。

    手記:

    ゲストネットワーク機能(GNF)上で拡張モードを備えた統合型ISSUを実行している場合、トラフィックの損失を回避するために、すべてのGNFでMPC8E、MPC9E、またはMPC11Eラインカードを使用する必要があります。

  • FPC(フレキシブルPICコンセントレータ)上で動作するLinuxバージョンと、ターゲットリリースのラインカードLinuxバージョンには互換性が必要です。

  • 拡張モードは、ターゲット リリースに ASIC ブロックのリセットが必要な変更が含まれている場合は機能しません。

  • 統合型 ISSU プロセス中にパケット損失が発生しないように、転送メモリ使用率を 75% 未満にする必要があります

    手記:

    拡張モードの統合型 ISSU は、転送メモリ使用率が 75% を超えている場合でも機能しますが、数ミリ秒のパケット損失が発生する可能性があります。

  • 統合型 ISSU のすべての前提条件は、拡張モードにも適用されます。詳細については、 統合型ISSU のシステム要件 を参照してください。

request system software validate in-service-upgrade package-name.tgz enhanced-mode コマンドを使用して、デバイスが拡張モードで統合型 ISSU を使用して特定のリリースにアップグレードできるかどうかを確認できます。デバイスとターゲットリリースが拡張モードと互換性がない場合でも、通常の統合型ISSUを使用して、トラフィックの中断を最小限に抑えながらアップグレードできます。

拡張モードでの統合型ISSUの実行

拡張モードで統合型 ISSU を実行するには、次の手順を実行します。

  1. 「ソフトウェアのダウンロード」の手順に従って、ソフトウェア パッケージをダウンロードします。

  2. ソフトウェア パッケージをデバイスにコピーします。ファイルを /var/tmp ディレクトリにコピーすることをお勧めします。

  3. コンソール接続にログインします。コンソール接続を使用すると、アップグレードの進行状況を監視できます。

  4. 目的のリリースで、拡張モードで統合型 ISSU を使用できることを確認します。

    1. デバイスで、次のように入力します。

      ここで、 package-name.tgz は、ステップ 1 でダウンロードしたソフトウェア パッケージの名前です。

  5. 統合型 ISSU を拡張モードで起動します。

    1. デバイスで、次のように入力します。

      ここで、 package-name.tgz はステップ 1 でダウンロードしたソフトウェア パッケージの名前です。

    手記:

    アップグレード中は、Junos OS CLIにアクセスできなくなります。

    アップグレードが実行されると、デバイスに次のようなステータス メッセージが表示されます。

    手記:

    統合型ISSU プロセスが停止した場合、 request system software in-service-upgrade コマンドを使用して CLI 出力を確認し、問題を診断できます。詳細については、syslog ファイルを参照してください。

  6. デバイスの再起動が完了したら、ログインします。ソフトウェアがアップグレードされたことを確認するには、次のコマンドを入力します。

手記:

拡張モードで統合型ISSUを使用する場合、FPC上のベースLinux OSをISSUプロセスの一部としてアップグレードすることはできません。Linuxは、定期的な統合型ISSUまたはFPCの再起動を通じて行われるアップグレードで更新できます。

統合型ISSUの検証

目的

最新の統合型ISSU後のFPCとそれに対応するPICのステータスを確認します。

アクション

プライマリ ルーティングエンジンで show chassis in-service-upgrade コマンドを発行します。

show log messages コマンドを使用して、統合型 ISSU プロセス メッセージを表示します。

意味

詳細については、 show chassis in-service-upgrade を参照してください。

統合型ISSU の問題のトラブルシューティング

統合型ISSU手順の進行が停止した場合:

  1. プライマリ ルーティングエンジンで新しいセッションを開き、 request system software abort in-service-upgrade コマンドを発行します。

  2. 既存のルーター セッションをチェックして、アップグレードが終了したことを確認します。

    「ISSU: terminated!」というメッセージが表示されます。追加のシステム・メッセージには、アップグレードが停止した場所に関する情報と、次のステップに関する推奨事項が示されます。

詳細については、 request chassis cluster in-service-upgrade abort(ISSU) を参照してください。

統合型ISSU手順中のBFDセッションの管理とトレース

BFD(双方向転送検出)セッションは、統合型ISSU手順中に検出および送信タイマーを一時的に増加させます。アップグレード後、これらのタイマーは統合型 ISSU が開始される前に使用されていた値に戻ります。BFD プロセスは、統合型 ISSU の状態とタイマー値を各セッションのバックアップ ルーティングエンジンに複製します。

BFD の統合型 ISSU を有効にするために、追加の設定は必要ありません。ただし、[edit protocols bfd] 階層レベルで no-issu-timer-negotiation ステートメントを含めることで、統合型 ISSU 中に BFD タイマー ネゴシエーションを無効にすることができます。

このステートメントを含めると、統合型ISSU の間、BFD タイマーは元の値を維持します。

注意:

BFD セッションは、検出間隔によっては、統合型 ISSU またはルーティングエンジンのスイッチオーバー中にフラップする可能性があります。

BFDの詳細については、 Junos OSルーティングプロトコルライブラリをご覧ください。

BFD セッションに統合型 ISSU トレース オプションを設定するには、[edit protocols bfd traceoptions flag] 階層レベルで ステートメントを issu 含めます。

変更履歴

サポートされる機能は、使用しているプラットフォームとリリースによって決まります。特定の機能がお使いのプラットフォームでサポートされているかどうかを確認するには、 Feature Explorer を使用します。

解放
形容
18.1R1
QFX5200スイッチのJunos OS リリース 18.2R1以降では、インサービスソフトウェアアップグレードの間に少なくとも5分空けることをお勧めします。
17.1R1
Junos OS リリース 17.1R1以降、QFX5100およびEX4600スイッチでは、17.1R1より前のJunos OS リリースからJunos OS リリース 17.1R1へのISSUを実行することはできません。