SR-IOVおよびPCI

冗長イーサネットインターフェイス(RETH)は、SRXクラスターの各参加ノードからの同数のメンバーインターフェイスで構成される仮想インターフェイスです。IPアドレス、QoS、ゾーン、VPNなどのすべての論理設定は、このインターフェイスにバインドされます。物理プロパティは、メンバー インターフェイスまたは子インターフェイスに適用されます。RETHインターフェイスには、クラスタIDを使用して計算される仮想MACアドレスがあります。RETHは、Junos OSに集合型インターフェイス/LAGとして実装されています。LAG の場合、親(論理)IFD の MAC アドレスが各子インターフェイスにコピーされます。RETHインターフェイスの下で子インターフェイスを設定すると、RETHインターフェイスの仮想MACが子物理インターフェイスのフィールドで上書き current MAC address されます。これには、対応するNICで仮想MACアドレスをプログラムする必要もあります。

Junos OSは、vSRX仮想ファイアウォール上のVMとして稼働します。Junos OS は NIC に直接アクセスできず、ハイパーバイザーによって提供される仮想 NIC アクセスのみを有し、同じホスト マシン上で実行されている他の VM と共有される可能性があります。この仮想アクセスには、NICで仮想MACアドレスをプログラムするために必要なトラストモードと呼ばれる特別なモードなどの特定の制限があります。デプロイ中は、セキュリティの問題が発生する可能性があるため、信頼モードのアクセスを提供できない場合があります。このような環境でRETHモデルが動作できるようにするために、MAC書き換え動作が変更されています。親仮想MACアドレスを子にコピーする代わりに、子の物理MACアドレスをそのまま保持し、クラスタのアクティブノードに属する子の物理MACアドレスをrethインターフェイスの 現在のMAC にコピーします。このようにすると、信頼モードが無効になっている場合、MAC書き換えアクセスは必要ありません。

vSRX仮想ファイアウォールの場合、DPDKはハイパーバイザーから提供された物理MACアドレスを読み取り、Junos OSコントロールプレーンと共有します。スタンドアロン モードでは、この物理 MAC アドレスは物理 IF にプログラムされます。ただし、クラスタモードでは同じ機能をサポートしていないため、物理インターフェイスのMACアドレスはジュニパーの予約済みMACプールから取得されます。信頼モードを実現できない環境では、ハイパーバイザーは物理的なMACアドレスを提供できません。

この問題を克服するために、予約済み MAC プールから割り当てる代わりに、ハイパーバイザー提供の物理 MAC アドレスを使用するサポートを追加しました。 信頼モードを無効にして SR-IOV サポートを構成する(KVM のみ)を参照してください。

図1:アクティブな子インターフェイスから親RETH へのMACアドレスのコピー

Junos OS Release 19.4R1以降、SR-IOV HAはトラストモードを無効にしてサポートされます。このモードを有効にするには、 use-active-child-mac-on-reth use-actual-mac-on-physical-interfaces 階層レベルで および 設定ステートメント [edit chassis cluster] を設定します。クラスタでコマンドを設定する場合、ハイパーバイザーは子物理インターフェイスのMACアドレスを割り当て、親RETHインターフェイスのMACアドレスはアクティブな子物理インターフェイスのMACアドレスで上書きされます

このモードを有効にするには、vSRX仮想ファイアウォールインスタンスを再起動する必要があります。コマンドを有効にするには、クラスタ内の両方のノードを再起動する必要があります。

この機能を有効にするには、コマンド use-active-child-mac-on-reth と use-actual-mac-on-physical-interfaces を一緒に設定する必要があります。

KVMでトラストモードを無効にした状態でのSR-IOV HAサポートには、以下の制限があります。

• トラストモードを無効にしたSR-IOV HAサポートは、KVMベースのシステムでのみサポートされています。

• rethインターフェイスでは、各vSRX仮想ファイアウォールクラスターノードのメンバーとして最大1つのポートを持つことができます。

• NAT プール内の IP アドレスのフェイルオーバー時に G-ARP が送信されないため、NAT プールに機能を使用 security nat proxy-arp できません。代わりに、アップストリームルーターのNATプール範囲へのルートを設定して、vSRX仮想ファイアウォールrethインターフェイスのIPアドレスをネクストホップとして指すことができます。または、直接接続されたホストがNATプールアドレスにアクセスする必要がある場合は、これらのNATプールアドレスをrethインターフェイスでプロキシARP用に設定できます。

• reth インターフェイスに多数の VLAN が設定されている場合、フェイルオーバー時にすべての G-ARP を送信するのに時間がかかることがあります。これにより、トラフィックの顕著な中断が発生する可能性があります。

• データプレーンのフェイルオーバーにより、rethインターフェイスのMACアドレスが変更されます。そのため、フェイルオーバーは、直接接続された隣接するレイヤー3デバイス(ルーターまたはサーバー)に対して透過的ではありません。vSRX仮想ファイアウォールのIPアドレスは、隣接デバイスのARPテーブルで新しいMACアドレスにマッピングする必要があります。vSRX仮想ファイアウォールは、これらのデバイスに役立つG-ARPを送信します。これらの隣接デバイスがvSRX仮想ファイアウォールから受信したG-ARPに作用しない場合、または応答が遅い場合、そのデバイスがARPテーブルを正しく更新するまでトラフィックが中断される可能性があります。

• 以下の vSRX 仮想ファイアウォール機能は、SR-IOV インターフェイスを使用する展開ではサポートされていません。

  これらの制限は、PF ドライバーを更新または制御できない展開に適用されます。この制限は、サポートされているジュニパーネットワークスのデバイスにvSRX仮想ファイアウォールが導入されている場合は適用されません。

  • 高可用性(HA)

  • IRB インターフェイス

  • IPv6アドレッシング

  • ジャンボフレーム

  • レイヤー 2 のサポート

  • OSPF や IPv6 などの他の機能とのマルチキャスト

  • パケットモード