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)を実行する方法を示しています。

要件

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

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

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

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

始める前に

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

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

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

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

    • プラットフォームにインストールされている FRU(フィールド交換可能ユニット)が統合型 ISSU 機能をサポートしているか、統合型 ISSU をサポートしていない一部の FRU でアップグレードを実行した結果を受け入れることができるか検証します。

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

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

    ベストプラクティス:

    デバイスのソフトウェアのダウンロードWebページにアクセスしたら、md5チェックサムを記録します。ソフトウェアパッケージをデバイスにダウンロードした後、 file checksum md5 コマンドを使用して、いかなる方法でも変更されていないことを確認します。
    注:

    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 のアップグレード を参照し、 システム ソフトウェアのアップグレードをリクエストしてください(アップグレードされた FreeBSD を使用した Junos OS)

概要

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

この例では、ホスト名、ファイル名、FRUは代表的なものです。デバイスでこの手順を実行すると、ホスト名、ファイル名、FRUが異なります。コマンド出力は切り捨てられ、この手順で対象のテキストのみが表示されます。

トポロジー

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

図1:統合型ISSUトポロジーの例 Network diagram showing a network server, an MX Series device with RE0 and RE1 routing engines, and a remote admin at the network operations center.

設定

新しいソフトウェアを一方または両方のルーティングエンジンにインストールするか、両方のルーティングエンジンを自動的に再起動するか、一方のルーティングエンジンを手動で再起動するかに応じて、手順にはバリエーションがあります。

いずれの場合も、デュアルルーティングエンジンがインストールされていること、およびグレースフルルーティングエンジンスイッチオーバー(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コマンドを使用して、NSRがプライマリルーティングエンジン(re0)に設定されていることを確認します。

    出力で、 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秒×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 コマンドを使用して、いかなる方法でも変更されていないことを確認します。

  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. プロキシARPがM Series、MXシリーズ、またはEX9200デバイスで有効になっていて、以前に 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 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 コマンドを使用して、いかなる方法でも変更されていないことを確認します。

    表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 コマンドを使用して、いかなる方法でも変更されていないことを確認します。

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

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

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

    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)の実行

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

注:

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 Replication が Disabled)、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(Link Aggregation Control Protocol)パケットの定期送信のためのインターバルスロー(30秒ごと)をサポートします。

  • ISSUは、VRRP(Virtual Router Redundancy Protocol)バージョン3をサポートしています。

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

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

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

  • 接続障害管理(CFM)。

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

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

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

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

  • LACP(Link Aggregation Control Protocol)パケットを定期的に送信するための高速(毎秒)の間隔。定期間隔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. ジュニパーネットワークスサポートWebサイト 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、およびJNP10K-LC4802ラインカードで利用可能なインサービスソフトウェアアップグレード(ISSU)オプションで、統合型ISSUプロセス中のパケットロスを排除します。これは、新しいラインカードアーキテクチャの改善を活用することで実現され、スタンバイモードでラインカード上で実行中のJunos OSソフトウェアの2番目のコピーを、統合型ISSU中にソフトウェアが古いイメージから新しいイメージに移行する間、すぐに引き継ぐことができます。request system software in-service-upgradeCLIコマンドにenhanced-modeオプションを追加することで、拡張モードを有効にすることができます。

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

拡張モードによる統合型ISSUのメリット

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

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

  • パケットロスを、設定やネットワークの状態に応じてゼロまたは数ミリ秒に低減

  • メンテナンス期間を必要とせずにソフトウェアのアップグレードを実行可能

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

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

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

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

    注:

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

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

  • 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 クラスター in-service-upgrade abort(ISSU) 」を参照してください。

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

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

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

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

注意:

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

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

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

変更履歴テーブル

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

リリース
説明
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を実行することはできません。