このページの目次

このネットワーク構成例について
例:EVPN マルチホーミングの使用例での Junos OS のアップグレード

EVPN マルチホーミング設定での Junos OS のアップグレード

このネットワーク構成例について

このネットワーク構成例を使用して、EVPN Muiltihoming(ESI-LAGとも呼ばれる)用に設定されたJunos OSまたはJunos Evolvedデバイスのペア上のJunos OSを、接続されたサーバー(ホスト)に手動でアップグレードします。

この例は、QFX スイッチを使用した既存の ERB(エッジルーテッドブリッジング)EVPN 設定に基づいています。ここで示す手順は、中央ルーティングされたブリッジング(CRB)とブリッジされたオーバーレイEVPNアーキテクチャにも適用できます。

サポートされているプラットフォームと、EVPN ESI-LAGのJunosまたはJunos Evolvedリリースサポートの詳細については、 Feature Explorerを参照してください。

要件

EVPN マルチホームホスト接続をサポートするように構成された QFX シリーズリーフスイッチのペアをアップグレードするには、この手順を使用します。

始める前に:

両方のリーフデバイスでコンソールにアクセスできることを確認します。
ホストMACアドレスが両方のリーフデバイスのEVPNデータベースに存在していることを確認します。
両方のリーフスイッチの hold-time up LAGインターフェイスで60秒(60000ミリ秒)のタイマー値を設定することをお勧めします。このオプションの詳細については、保留時間を参照してください。ホールドアップタイマーを設定することで、スイッチがリブートイベント後に BGP ルート交換を完了する前に、ホスト側の LAG メンバーインターフェイスが動作状態にならないようにすることができます。
この例では、マルチホームホストから VLAN の IRB インターフェイスに設定された仮想ゲートウェイアドレスへの ping を生成します。ping 応答を生成するには、両方のスイッチの IRB インターフェイスにオプションを追加する virtual-gateway-accept-data 必要があります。

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

Junos OSリリース19.1R3.9を最初に実行していた2台のQFX5100-48S-6Qデバイス
Junos OSリリース19.2R1.8
両方のToRスイッチへのリンクを備えたUbuntuまたはCentosサーバー。サーバーは、LACPベースのリンクアグリゲーションをサポートするために、モード4ボンディングインターフェイスを使用して構成されています。

手順の概要

このセクションでは、アップグレード手順の概要について説明します。一連の手順は、マルチホームホストをサポートするリーフスイッチのペアをアップグレードする際の中断を最小限に抑えるように設計されています。

アップグレードの準備:
- 両方のスイッチでLAGインターフェイスが動作しており、EVPNコントロールプレーンが収束していることを確認します。
- 目的のJunos OSイメージを両方のスイッチの/var/tmpディレクトリにコピーします。
マルチホームホストから、同じ VLAN 内のオーバーレイ宛先への ping を開始します。たとえば、CRB の場合はスパインデバイス上の IRB インターフェイス、ERB の場合はリーフデバイス上の IRB インターフェイスなどです。この手順は、アップグレード手順に関連するパケット損失の程度を後で判断できるようにするために実行されます。
アップグレードするスイッチを選択し、サーバーまたはホストへのダウンリンクインターフェイスを無効にします。
スイッチを新しいJunosバージョンにアップグレードして再起動します。スイッチで新しいバージョンが実行されていることを確認します。
EVPN コントロールプレーンをチェックして、アップグレードされたスイッチがダウンリンクホストの MAC アドレスを再学習したことを確認します。
アップグレードしたスイッチのダウンリンクインターフェイスを有効にします。
もう一方のスイッチで手順 3 から 6 を繰り返して、アップグレードを完了します。
ホストが生成したpingを停止し、アップグレード手順中に失われたパケット数を確認します。

メモ：
アップグレード手順はヒットレスではありません。ダウンリンクで転送中のパケットは、アップグレードの準備のためにインターフェイスが無効になっていると失われる可能性があります。インターフェイスが無効になると、トラフィックは他のリーフスイッチに切り替わり、流れ続けます。この手順では、アップグレードする各スイッチのLAGメンバーインターフェイスを無効にすると、2つの小さな損失ウィンドウがあります。これらの損失ウィンドウは、50 ミリ秒を超えてはなりません。

トポロジ

図 1 に、この EVPN マルチホーミングのアップグレード例のトポロジーを示します。両方のスイッチには、接続されたホストに関連付けられたVLAN用に設定されたIRBインターフェイスがあることに注意してください。これらの IRB は、共有仮想ゲートウェイアドレス 192.168.0.1 を使用して設定されます。ホストには、bond0 インターフェイスでアドレス 192.1689.1.100 が割り当てられています。この図には、ホスト上のbond0インターフェイスのMACアドレスと、両方のリーフスイッチのLAGインターフェイスに設定されているイーサネットセグメント識別子(ESI)も詳しく記載されています。

図 1: トポロジ

EVPN マルチホーミングのアップグレード設定

アップグレードの準備
リーフ 3 のアップグレード
leaf2のアップグレード

アップグレードの準備

手順

EVPNマルチホーミングが動作していることを確認します。サーバーにログインし、ボンドインターフェイスが稼働していることを確認します。その間に、bond0 インターフェイスの MAC アドレスをメモします。この例では、ホストは Ubuntu を実行しているため、 ifconfig コマンドが使用されます。Centosディストリビューションを使用している場合は、ip link show bond0 コマンドを使用します。この例でのホストの bond0 インターフェイスの MAC アドレスは、 00:1B:21:79:5A:ECです。

コマンドで show interfaces ae1 、両方のリーフデバイスでLAGインターフェイスが動作していることを確認します。この例では、LAGインターフェイスは ae1 両方のリーフデバイスにあります。集約されたインターフェイス番号は、2つのリーフデバイス間で異なる可能性があるローカルインデックスであることに注意してください。これはインターフェイス名ではなく、2つのリーフ間のLAGインターフェイスを論理的にバインドする一致するESIと system-id パラメータの設定です。両方のリーフデバイスでLAGインターフェイスが起動していることを確認してください。

出力では、LAGインターフェイスが動作しており、ESIが両方のリーフで00:01:01:01:01:01:01:01:01 :01:01として設定されていることを確認します。

前の手順でメモした ESI 値を使用して、両方のメンバースイッチの EVPN データベースにホスト MAC アドレスが存在することを確認します。

両方のリーフデバイスで集約されたインターフェイス設定を表示します。なお、このオプションは、 hold-time up この例の推奨事項に従って、6 秒間に設定されています。

両方のスイッチのLAGメンバーインターフェイス名をメモします。アップグレードするスイッチでこのインターフェイスをシャットダウンする必要があります。LAGメンバーのインターフェイス名は、スイッチのペア間で異なるのが一般的です。この例では、両方のリーフデバイスでLAGメンバーインターフェイスがxe-0/0/46です。

図2に示すように、目的のJunos OSイメージを両方のリーフデバイスに転送します。イメージは必ずスイッチの /var/tmp ディレクトリに配置してください。通常、リーフデバイスにイメージをコピーするには、FTPまたはSCPのいずれかが使用されます。CLIを使用してファイルをコピーする方法の詳細については、ファイルコピーを参照してください。

メモ：
request system storage cleanupアップグレードに十分な領域があることを確認するために、新しいイメージを転送する前にコマンドを実行することを検討してください。

図2:新しいJunosイメージを転送する

両方のEVPNマルチホーミングリーフで、Junos OSの開始バージョンを確認します。この例では、Junos OS の起動バージョンは 19.1R3.9 です。簡潔にするために、リーフ2からの出力のみを示しています。

これまでに実行した手順は、LAGインターフェイスが動作しており、EVPNコントロールプレーンが収束していることを示しています。アップグレードを開始する前に、ホストから VLAN の IRB インターフェイスに割り当てられた仮想ゲートウェイの IP アドレスに対して ping を開始します。このトラフィックは、いずれかのメンバーリンクにハッシュします。両方のスイッチが同じ仮想ゲートウェイIPで構成されているため、ホストがトラフィックを送信するスイッチは関係ありません。

どちらのスイッチもpingに応答できることに注意することが重要です。つまり、一方のスイッチが再起動しても、もう一方のスイッチは使用可能であり、ping に応答できます。

メモ：
ping を成功させるには、両方のスイッチで IRB インターフェイスにオプションが virtual-gateway-accept-data 設定されていることを確認する必要があります。

メモ：

失われたパケットの総数を特定できるように、アップグレード手順の間、ホストから IRB インターフェイスへの ping が実行されていることを確認します。

リーフ 3 のアップグレード

手順

図 3 の赤い「X」で示されているように、LAG メンバー xe-0/0/46 に面しているサーバーをシャットダウンして、リーフ 3 でアップグレードプロセスを開始します。

メモ：
リーフ 3 の xe-0/0/46 インターフェイスで転送中の少数のパケットは、このステップで失われる可能性があります。この時点で、ping トラフィックはアップグレードが完了し、リーフ 3 でダウンリンクインターフェイスを再度有効にするまで、リーフ 2 デバイスを通過します。

図 3: リーフ 3 のダウンリンクインターフェイスの無効化

コンソール接続を使用し、コマンドを使用してリーフ 3 request system software add /var/tmp/jinstall-host-qfx-5e-x86-64-19.2R1.8-secure-signed.tgz reboot でアップグレードを開始します。イメージの読み込みとその後の再起動プロセスは、図 4 の歯車アイコンで表されています。アップグレードプロセスが完了するまでに数分かかります。この間、ping はリーフ 2 を流れるはずです。これは、リーフ 3 のアップグレード中もフル稼働しているためです。

図 4: リーフ 3 Start the Upgrade of Leaf 3

のアップグレードの開始

スイッチの再起動後、アップグレードが成功したことを確認します。

この時点で、すべてのアンダーレイおよびオーバーレイBGPセッションを再確立する必要があります。リーフ 3 で LAG メンバーインターフェイスを有効にする前に、すべての BGP ピアがバックアップされ、EVPN コントロールプレーンが再コンバージェンスしていることを確認します。
図 5 の緑色のチェックマークで示されているように、リーフ 3 のダウンリンクインターフェイスを有効にします。

図 5: リーフ 3 でダウンリンクインターフェイスを有効にする

leaf2のアップグレード

手順

リーフ2のアップグレード手順を開始するには、図6の赤いXで示すように、ダウンリンクインターフェイスを無効にします。ping はリーフ 2 を通って流れている可能性が高いため、この手順は手順の 2 番目の損失ウィンドウを示します。ping は、リーフ 2 のアップグレード後も、リーフ 3 デバイスを介して流れ続けるはずです。

図6:leaf2 のダウンリンクインターフェイスを無効にする

イメージのロードを開始し、リーフ2でコマンドで request system software add /var/tmp/jinstall-host-qfx-5e-x86-64-19.2R1.8-secure-signed.tgz 再起動します。リーフ2のアップグレードと再起動は、図7の歯車のアイコンで示されています。

図 7: リーフ 2 Start the Upgrade at Leaf 2

でのアップグレードの開始

リーフ2の再起動後、Junos OSのバージョンをチェックして、アップグレードが成功したことを確認します。

EVPN コントロールプレーンがリーフ 2 で再コンバージェンスされていることを確認します。すべてのBGPセッションが再確立され、ホストのMACアドレスがEVPNデータベースに入力されるまでに数分かかる場合があります。
図8の緑色のチェックマークで示されているように、リーフ2のLAGメンバーインターフェイスを有効にします。

図 8: リーフ 2 でダウンリンクインターフェイスを有効にする
これで、両方のスイッチがアップグレードされ、すべてのLAGメンバーインターフェイスが再び動作できるようになりました。アップグレードプロセス中のトラフィックの中断を測定するには、ping を停止し、ping の統計情報をメモします。この例では、マルチホームホストをサポートするリーフデバイスのペアのアップグレード中に、合計 2 つのパケットが失われます。

多くの場合、進行中のpingが中断されると、単一のパケットの損失が示されます。実際に失われたのが1パケットであろうと2パケットであろうと、アップグレードは事実上ヒットレスとみなされます。これは、この例で示した手順の期待値に従ったものです。

結論

EVPNマルチホーミングは、ハイパフォーマンスと高可用性の両方をサポートする必要があるデータセンターアーキテクチャにとって重要な機能です。この例では、マルチホームホスト接続をサポートするリーフスイッチのペアを最小限の中断でアップグレードするために必要な構成と手順を示しました。