4 メンバーの QFX シリーズ VCF をアップグレードする方法

設定した管理者権限を持つ root ユーザーまたは別のログイン ユーザーを使用してデバイスにログインします。

アップグレードを開始する前に、VCF のステータスを確認してください。デバイスのシリアル番号、メンバーの ID、および関連するロールをメモします。

VCP(バーチャル シャーシ ポート)を確認し、参照用のトポロジー図を作成します。 図 1 は、この例の VCF のトポロジーを示しています。

4 人のメンバー全員が存在することを確認します。各デバイスで実行されているJunos OSイメージを確認します。各デバイスは、同じ Junos OS バージョンを実行している必要があります。バージョンが一致しない場合、デバイスは非アクティブとして表示されます。

FTP を使用して、新しい Junos OS イメージをプライマリ ルーティング エンジンにコピーします。次に、新しいイメージをプライマリ ルーティング エンジンから他の VCF メンバーにコピーします。FTP を構成する方法については、「 リモート アクセスの概要 」を参照してください。

図 2 は、新しい Junos OS イメージがメンバー間でどのように配信されるかを示しています。

図 2:Junos OS イメージを VCF メンバー にコピーする

プライマリ ルーティング エンジン上の /var/tmp ディレクトリからメンバー 3( fpc 3 の/var/tmp とも呼ばれる)にイメージをコピーするには、次のステートメントを使用します。

他のメンバーにも同じことをします。FPC 番号はメンバー番号と同じです。

VCF プライマリ ルーティング エンジンから各メンバーにアクセスし、ファイルが各メンバーにコピーされたことを確認します。たとえば、メンバー 3 にアクセスするには、次の手順にいます。

次に、この VCF メンバーの /var/tmp ディレクトリに新しい Junos OS イメージがないか確認します。

完了したら、 exit プライマリ デバイスに戻ります。

VCF 内の各デバイスでイメージ チェックを繰り返します。

VCF を半分に分割すると、2 つのバーチャル シャーシが一時的に形成され、各メンバーが 2 つになります。メンバーが 2 つだけのバーチャル シャーシを形成するたびに、分割検出を無効にすることをお勧めします。分割検出を無効にしない場合、この例の後半でバックアップ ルーティング エンジンから切断した場合、プライマリ デバイスがラインカードの役割を担い、コントロール プレーンとデータ プレーンを停止することがあります。

プライマリ デバイスでの分割検出を無効にします。

手順中にトラフィックロスが発生するかどうかを確認するには、アップリンクMXシリーズルーター上でサーバーからIRB 192.168.100.1への継続的なpingを開始します。

上記の図を使用して、メンバー 0 および 2 で無効にして、VCF の残りの部分から分離する必要があるリンク アグリゲーション制御プロトコル(LACP)メンバー インターフェイスと VCP を識別します。無効にするVCPは、メンバー0のポート2とメンバー2のポート53です。

プライマリ ルーティング エンジン(メンバー 1)で以下のコマンドを使用して、関連するインターフェイスの名前を決定します。アップリンク デバイスとサーバーに向けて、LACP メンバー インターフェイスを無効にします。この場合、et-0/0/23.0 はメンバー 0 アップストリーム インターフェイス、xe-2/0/46.0 はメンバー 2 ダウンストリーム インターフェイスです。

プライマリ デバイス(メンバー 1)コンソールにアクセスし、次の操作を行います。

メンバー 0 のアップリンク デバイスへのインターフェイスを無効にします。

メンバー 2 からサーバーへのインターフェイスを無効にします。

設定をコミットして有効にします。

メンバー 1:

VCP をメンバー 0 からメンバー 3 に削除します。

どの VCP を無効にする必要があるかについては、「 アップグレードの準備」 のステップ 3 とトポロジー図を参照してください。テーブルのfpc0の下で、ネイバーID 3に行くインターフェイスタイプまたはPIC/ポート列のVCPを識別します。この場合、PIC/Port 0/2(vcp-255/0/2)として識別される VCP を無効にします。

VCP をメンバー 2 からメンバー 1 に削除します。

メンバーが VCF から削除され、として NotPrsntマークされていることを確認します。

メンバー 0 および 2 のコンソールにアクセスします。次のコマンドを入力して、デバイスにコピーされたJunos OSイメージにメンバーをアップグレードします。

各分離メンバーがアップグレードされると、分離メンバー、メンバー 0、メンバー 2 が存在することを確認します。

新しい VCF が自動的に形成されたのは、メンバー 0 がバックアップ ルーティング エンジンとしてすでに構成されているため、元のプライマリ デバイスから切断されたときにプライマリ ルーティング エンジンの役割を担っていました。メンバー 2 はラインカード ロールですでに設定されています。

上記の出力は、デバイスをリンクする VCP インターフェイスを示しています。出力に最後の列に VCP インターフェイスが表示されない場合は、ステップ 3 を完了します。

前のステップの出力で、メンバー 0 とメンバー 2 が接続されており、それらが新しい VCF のメンバーであることを示していない場合は、それらの間の VCP リンクを設定します。

メンバー 0 で、VCP 10 を有効にします。

メンバー 2 で、VCP 52 を有効にします。

アップグレードが成功したことを確認します。

古い VCF ペア(メンバー 1 とメンバー 3)のアップリンク ポートとサーバー側ポートを同時に無効にし、アップグレードされたメンバー 0 とメンバー 2 から形成された新しい VCF のサーバー インターフェイスとアップリンク インターフェイスを有効にします。これにより、トラフィックが新しい VCF を介してリダイレクトされます。

ホスト上のLACP状態とアップリンクMXシリーズルーターが維持されるように、両方のデバイス で同時 に設定をコミットすることが非常に重要です。これは、Ansible ツールなどのスクリプティングを使用して行うことができます。

同時に設定をコミットしないと、古いVCFのポートを無効にして、新しいVCF上のインターフェイスを有効にするのにかかる限り、トラフィックはドロップされ、サービスに影響を受けます。

メンバー 1 では、4 メンバー VCF のプライマリ デバイスだったときに残余構成を削除します。

メンバー 1 のアップリンク ポートとサーバー側ポートを無効にします。

メンバー 0 でアップリンク ポートとサーバー側ポートを有効にします。

メンバー 1 とメンバー 0 で同時に実行 commit します。

アップリンク MX シリーズ ルーター上のサーバーから IRB 192.168.100.1 への継続的 ping が正常に実行されていることを確認します。これにより、トラフィック パスが正常に切り替されたことを確認できます。

古い VCF がラインカード ロールの 1 つのプライマリ デバイスと 1 つのデバイスで構成されていることを確認します。

メンバー 1 とメンバー 3 の間で VCP を削除して、古い VCF を分割します。メンバー 1 はプライマリ デバイスであるため、メンバー 1 でこれらのコマンドを実行できます。

メンバー 3 からメンバー 1 に向けて VCP を削除するには、以下の手順にしたがってください。

VCP をメンバー 1 からメンバー 3 に削除するには、以下の手順にしたがってください。

各デバイスで正常に実行されたことを確認します。

メンバー 1:

メンバー 3 コンソールにアクセスします。

メンバー 3 を Junos OS リリース 18.4R1 にアップグレードします。

アップグレードが成功したことを確認します。

メンバー 1 を Junos OS リリース 18.4R1 にアップグレードします。

アップグレードが成功したことを確認します。

メンバー 3 で VCP 49 を有効にし、メンバー 0 で VCP 2 を有効にすることで、メンバー 3 を新しい VCF に追加します。 図 3 は、これらのポートが有効になった後の新しい VCF の状態を示しています。

図 3:メンバー 3 を新しい VCF に追加する

メンバー 3 で、メンバー 0 に向けて VCP を有効にします。

メンバー 0:

• メンバー 3 に向けて VCP を有効にします。

• メンバー 0 で vcp-255/0/2 が有効になり、vcp-255/0/49 がメンバー 3 で有効になっていることを確認します。

メンバー 1 は元の VCF のプライマリ ルーティング エンジンであるため、メンバー 0、2、3 の残余構成がいくつか存在します。これらの設定は、特にメンバー 1 が新しい VCF のプライマリ デバイスとしてメンバー 0 をプリエンプトした場合に、新しい VCF に追加するときに VCF に影響を与える可能性があります。

新しい VCF のプライマリ デバイスであるメンバー 0 では、次のコマンドを使用して、メンバー 3 のサーバー側インターフェイスを再度有効にし、メンバー 1 が誤ってシャットダウンしないようにします。

メンバー 1 では、アップリンク側インターフェイス et-1/0/23 を無効にしたままにします。トラフィックは、隣接する新しい VCF プライマリ デバイスからアップリンク MX シリーズ ルーターに渡されます。

メンバー 1 を新しい VCF に追加するには、 図 4 に示すように、VCP リンクをメンバー 1 からメンバー 2 および 3 に復元します。

図 4:メンバー 1 を新しい VCF に追加する

メンバー 1:

• メンバー 3 に接続する VCP を設定します。

• メンバー 2 に接続する VCP を設定します。

メンバー 0 では、新しい VCF プライマリ デバイス:

• メンバー 1 に接続するメンバー 2 で VCP を設定します。

• メンバー 1 に接続するメンバー 3 で VCP を設定します。

ほとんどの場合、新しい VCF プライマリ ルーティング エンジンの設定は、新しく結合されたバックアップ ルーティング エンジンに適用されます。新しく参加したバックアップ ルーティング エンジン(元の VCF プライマリ ルーティング エンジン)が、新しい VCF プライマリ デバイスからプライマリ ロールを優先して引き継ぐ場合があります。これが発生したかどうかを確認します。

メンバー 1 が主な役割を引き継ぎこれにより、トラフィック フローが中断する可能性があります。これを確認した場合は、次のステップで示すアップリンクを迅速に有効にします。

メンバー 1 で、新しい VCF でアップリンク側インターフェイス et-1/0/23 を有効にします。

図 5 に示すように、4 メンバーの VCF が作成されました。

図 5:4 メンバー VCF の復元

メンバー 1 が新しい VCF に参加すると、LACP 状態がリセットされると、1 分未満のトラフィック中断が予想されます。サーバーからの継続的な ping を監視します。

メンバー 1 はプライマリ ロールを再取得しているので、残余構成のため、アップリンク インターフェイスとサーバー側インターフェイスが自動的に無効になっていないか確認します。メンバー 1 で次のコマンドを実行し、LACP 子インターフェイスが稼働し、状態が collecting distributing 戻っているかどうかを確認します。

VCF の新しいプライマリ デバイスであるメンバー 1 で、すべての VCF メンバーが対象の Junos OS リリースを実行していることを確認します。

進行中の ping で、サーバーからのトラフィックが VCF を介して正常にフローしていることを確認します。40~50 秒のダウンタイムを想定しています。

トラフィックは通常、VCF を通って流れます。4 メンバーの VCF がアップグレードされ、完全に機能します。