EVPN-VXLANファブリックのリモートポートミラーリングを設定する方法
このネットワーク構成例について
このネットワーク構成例(NCE)では、EVPN-VXLANファブリックにリモートポートミラーリングを設定する方法を示しています。ポートミラーリングは、トラフィックフローをコピーし、GREトンネルを使用してRMON(リモート監視)ステーションに送信します。ERSPANと同様に、VXLANカプセル化されたテナントトラフィックのリモートポートミラーリングは、トラブルシューティングや監視のためにデータセンター環境で頻繁に使用されます。
リーンスパインスイッチとEVPN-VXLANファブリックのエッジルーティングリーフデバイスで、リモートポートミラーリングを追加する方法を示します。ジュニパーのサンプルファブリックは、エッジルーティングされたブリッジング(ERB)アーキテクチャに基づいています。VXLANポートミラーリングは、中央ルーティングされたブリッジング(CRB)ファブリックでもサポートされています。
「」も参照
ユース ケースの概要
リモートポートミラーリングとEVPN-VXLANファブリック
リモートポートミラーリングは、トラフィックフローをコピーし、ミラーリングされたトラフィックを1つ以上のミラーリング宛先ホストに配信します。トラフィックフローは、場合によってはファイアウォールフィルターを使用して粒度を高め、イングレスまたはエグレスインターフェイスによって識別されます。ミラーリング宛先ホストは、送信元スイッチと同じファブリックの一部であるリーフ スイッチに接続されます。
EVPN-VXLAN IPファブリックでは、ミラーリングされたトラフィックフローは GRE(一般ルーティングのカプセル化)でカプセル化され、アンダーレイIPファブリックを介して監視ホストのIPアドレスに配信されます。このホストを監視ステーションとして使用して、トラフィック フローをキャプチャしてデコードします。
GREトンネルによるリモートポートミラーリングは、EBGPアンダーレイにホストサブネットをアドバタイズすることで、監視ステーションをファブリック内の任意のリーフスイッチに接続できるため、EVPN-VXLANなどのIPファブリックに最適です。さらに、監視ステーションに接続された宛先スイッチは、GRE ストリームを監視ステーションに配信する前に GRE カプセル化解除を実行する必要はありません。GRE トンネルは、複数の中間 IP ノードを横断することも、ファブリックの外部に送信することもできます。
ポートミラーリング方法:アナライザインスタンスとポートミラーリングインスタンス
ポートミラーリングには、アナライザインスタンスとポートミラーリングインスタンスの2つの方法があります。各アプローチには異なる利点があり、異なるアーキテクチャと互換性があります。どちらの場合も、ミラーリング目的の GRE トンネルが自動的に作成されるため、GRE トンネルを設定する必要はありません。
アナライザインスタンス は、フィルタリング基準のないポートミラーリングです。アナライザは、実装する最もシンプルな形式のトラフィック ミラーリングです。必要なのは、ミラーリングされたトラフィックの送信元であるインターフェイスと、そのインターフェイスでミラーリングするトラフィックがエグレス、イングレス、またはその両方であるかどうかだけです。また、ミラーリングされたトラフィックの宛先のIPアドレスも指定します。ファイアウォールフィルターを設定または適用する必要はありません。
アナライザインスタンスはテナント固有ではないため、テナントストリームに関する情報がない場合に最適なアプローチです。
ポートミラーリングインスタンスは、 テナントトラフィック固有の基準を使用してトラフィックをミラーリングします。ファブリックの管理者は、ミラーリングするインターフェイスに関心のあるテナントソースIPアドレス、プロトコル、ポートなどを決定します。特定のトラフィックをミラーリングする必要がある場合は、ポートミラーリングインスタンスを使用します。
ジュニパーネットワークスは、3つの主要なデータセンターアーキテクチャをサポートしています。すべてリモートポートミラーリングをサポートします。アーキテクチャごとに、以下のポートミラーリング方法をお勧めします。
-
ブリッジオーバーレイ:アナライザインスタンス
-
一元的にルーティングされたブリッジング(CRB):ポート ミラーリング インスタンス
-
エッジルーティングされたブリッジング(ERB):ポートミラーリングインスタンス
技術概要
EVPN-VXLAN ERBファブリックのリモートポートミラーリング
このNCEは、リーンスパインを備えたERBアーキテクチャ向けのリモートポートミラーリングをカバーしています。
リーンスパインを備えたEVPN-VXLAN ERBファブリックでは、テナント固有の内部フローを選択的にトンネルに送信することはできません。リーンスパインデバイスでは、外部ヘッダーベースのフィルタリング(アンダーレイ)のみがサポートされています。例えば、スパインスイッチは、特定のソースIPv4ループバックアドレスから来るパケットをフィルタリングし、GREトンネルを使用して別のリーフデバイスに接続された監視ステーションにトラフィックを送信できます。
テナント固有のフローに対するGREによるリモートポートミラーリングは、ERBアーキテクチャのリーフデバイスでサポートされています。この場合、IRB(統合型ルーティングおよびブリッジング)インターフェイスでリモートポートミラーリングフィルターを実装して、VLAN間(ルーティング)トラフィックをミラーリングできます。VLAN内(ブリッジド)トラフィックをミラーリングするには、サーバーまたはホストデバイスに接続されたイングレスインターフェイスにインターフェイスフィルターを適用します。
スパインまたはリーフいずれの方法でも、ミラーリングされたトラフィックはGREトンネルを介してリモートアナライザに流れます。
QFXシリーズスイッチによるリモートポートミラーリング
次の例では、QFX シリーズ スイッチをベースにした ERB アーキテクチャでリモート ポート ミラーリングを使用するさまざまな方法を示しています。
QFX5110およびQFX5120スイッチは、ERBリファレンスデータセンターアーキテクチャのリーフデバイスと同様に機能します。これらのモデルはVNI(仮想ネットワーク識別子)間ルーティングを実行できるためです。
表 1 は、QFX10002 スイッチと QFX10008 スイッチを使用する場合の、さまざまなユースケースに対するポート ミラーリング インスタンス タイプのサポートを示しています。 表2 は、QFX5110スイッチとQFX5120スイッチを使用した場合も同じです。
導入事例 |
サブユース ケース |
アナライザ インスタンス |
ポートミラーリングインスタンス |
---|---|---|---|
IPトランジットを提供するスパイン |
リーフからスパインへのイングレス |
サポート |
サポート |
スパインからリーフへのエグレス |
サポート |
サポート |
|
CRBシナリオのスパイン |
トラフィックを終端する IRB のイングレス |
ge、xe、et、aeインターフェイスのみがサポートされています |
サポートされていません |
トラフィックを終端する IRB のエグレス |
ge、xe、et、aeインターフェイスのみがサポートされています |
サポートされていません |
|
境界カプセル化 |
ESI-LAGのアクセスイングレス |
サポート |
サポート |
境界のカプセル化解除 |
ファブリックのエグレス |
サポートされていません |
サポートされていません |
導入事例 |
サブユース ケース |
アナライザ インスタンス |
ポートミラーリングインスタンス |
---|---|---|---|
IPトランジットを提供するリーンスパイン |
リーフからスパインへのイングレス |
サポート |
サポート |
スパインからリーフへのエグレス |
サポート |
サポートされていません |
|
ERB シナリオのリーフ |
トラフィックを終端する IRB のイングレス |
ge、xe、et、aeインターフェイスのみがサポートされています |
サポート |
トラフィックを終端する IRB のエグレス |
ge、xe、et、aeインターフェイスのみがサポートされています |
サポートされていません |
|
境界カプセル化 |
ESI-LAGのアクセスイングレス |
サポート |
サポート |
ESI-LAGのアクセスエグレス |
サポート |
サポートされていません |
|
境界のカプセル化解除 |
ファブリックのイングレス |
サポートされていません |
サポートされていません |
ファブリックのエグレス |
サポートされていません |
サポートされていません |
この例のすべてのQFXスイッチは、Junos OSリリース18.4R2以降を実行しています。Junos OS リリース 18.4R2 を実行している QFX5110 および QFX5120 スイッチは、次のスケーリング数をサポートしています。
-
デフォルト アナライザ セッション数:4
-
ポートミラーリングセッション:3ポートミラーリングセッション+ 1グローバルポートミラーリングセッション
このNCEは、以下のユースケースを対象にしています。
-
例:EVPN-VXLAN ERBファブリックスパインデバイス向けのイングレス/エグレスソリューションは、ERBファブリック 内のリーンスパインデバイスを介してイングレストラフィックとエグレストラフィックをミラーリングする方法を示しています。
-
例:EVPN-VXLAN ERBファブリックリーフデバイスのイングレスソリューションは、ERB シナリオでリーフデバイスを介してイングレストラフィックをミラーリングする方法を示しています。
-
例:ESI-LAGインターフェイスでリモートミラーリングインスタンスを有効にする は、ボーダーカプセル化のユースケースでポートミラーリングインスタンスまたはアナライザインスタンスを使用して、ESI-LAGインターフェイスを介してイングレストラフィックとエグレストラフィックにアクセスする方法を示しています。
-
例:ESI-LAGインターフェイスでリモートアナライザインスタンスを有効にする 方法は、アナライザインスタンスを使用して、ESI-LAGインターフェイスを介してイングレストラフィックとエグレストラフィックをミラーリングする方法を示しています。
これらの例で説明されている手順を使用して、特定のユースケースでリモートポートミラーリングを有効にします。
トポロジ
要件
この設定例では、Junos OSリリース18.4R2以上を実行している以下のデバイスを使用しています。この例は、Junos 22.2R1を実行しているQFXスイッチで再検証されました。
-
QFX5110 スイッチ 2 台をリーン スパイン デバイスとして使用。
-
ボーダーリーフデバイスとしてのQFX10002スイッチ1台。
-
サーバーリーフ1およびサーバーリーフ2デバイスとして2台のQFX5110または5120スイッチ。
-
サーバーリーフ4として1つのQFX10002。必要に応じて、QFX10002 の代わりに QFX5110 または QFX5120 を使用できます。
-
EVPN-VXLANファブリックを介してトラフィックを送受信する2つのサーバー。
-
アナライザアプリケーションを搭載した監視ステーション。この例ではWiresharkを使用しています
ベースライン トポロジー
このNCEは、既存のEVPN-VXLANファブリックに異なるタイプのポートミラーリングを追加する方法に焦点を当てています。 図 1 は、以下のすべての例のベースライン トポロジーを詳細に示しています。
スパイン1および2は、VXLANカプセル化やカプセル化解除を実行しないリーンスパインデバイスです。サーバー1および2は、VLAN 101と10.1.101.0/24サブネットを共有します。サーバー1はリーフ1のシングルホームを開始します。以降のセクションでは、リーフ2にアタッチして、ESI-LAGインターフェイスを形成します。サーバー2はリーフ4に接続します。リーフ3はボーダーリーフとして機能します。その設定は、サーバーリーフで使用されるものと同じです。この例では、リーフ4はxe-0/0/33:1インターフェイス上のアナライザデバイスに接続されたQFX10000スイッチであることに注意してください。
このトポロジーは、サーバー1とリーフ1と2の間で、ESI-LAGを使用したマルチホーミングをサポートしています。このNCEのすべてのシナリオで、このマルチホーム機能を使用しているわけではありません。デバイスの完全な構成については、「 付録: 完全なデバイス設定」を参照してください。
例:EVPN-VXLAN ERBファブリックスパインデバイス向けイングレス/エグレスソリューション
概要
この例では、リーンスパインスイッチでリモートポートミラーリングを有効にします。ミラーリングされたトラフィックは、GREトンネルを介してリモート監視ステーションに送信されます。このユースケースは、ポートミラーリングインスタンスメソッドに基づいています。
この例では、リーフデバイスでユニキャストVNI(仮想間ネットワーク識別子)ルーティングを行うEVPN-VXLAN ERBアーキテクチャを使用します。リーンスパインデバイスは、VXLANトンネルを終端しません。IP転送や、IBGPベースのオーバーレイの場合はルートリフレクション機能を提供します。オーバーレイはEBGPベースなので、ルートリフレクションは使用しません。
この設定は、リーフデバイス間で送信されたすべてのトラフィックをミラーリングします。監視ステーションは、リーフ上のすべての VLAN の VLAN 内(ブリッジング)トラフィックと VLAN 間(ルーティング)トラフィックの両方をキャプチャします。テナントの特定の情報はリーンスパインデバイスではプロビジョニングされませんが、リーンスパインでミラーリングセッションを有効にできます。
アナライザ ポートの容量に注意してください。リーフペア間で送信されたすべてのオーバーレイトラフィックをミラーリングするため、大量のトラフィックがアナライザポートを通過します。リーフデバイスは、2つの40GEインターフェイスを備えたスパインに接続されているため、大量のトラフィックを伝送する容量を備えています。スイッチのバッファリング機能は限定的です。監視ステーションがサポートするよりも多くのトラフィックをミラーリングすると、フレームドロップが発生します。
容量を追加するには、複数のリンクメンバーを持つ集合型イーサネットインターフェイスを使用します。リーフデバイスでミラーリングを実行し、特定のテナントのみに対してトラフィックを選択的にミラーリングすることで、トラフィックの負荷を軽減します。
トポロジ
この設定例では 、「要件」に示すハードウェアとソフトウェアのコンポーネントを使用します。トポロジーのデバイスは、「 付録: 完全なデバイス設定」で示されているように、ベースライン設定から始まります。
図2に示すように、スパイン1は、et-0/0/7インターフェイスに適用されたファイアウォールフィルターを介してリーフ1とリーフ4の間を流れるイングレスおよびエグレスオーバーレイトラフィックをミラーリングします。このインターフェイスは、サーバーリーフ1に接続します。オーバーレイ トラフィックは、サーバー 1 とサーバー 2 の間で ping トラフィックを送信することで生成されます。ミラーリングされたトラフィックは、スパイン1によって、ボーダーリーフ3のxe-0/0/33:1インターフェイスに接続されたリモート監視ステーションに送信されます。
スパインは GRE トンネルを使用して、ミラーリングされたトラフィックを監視ステーションに送信します。ミラーリングされたトラフィックはレイヤー 2 またはオーバーレイ レイヤー 3 であるため、ファブリック アンダーレイ上でルーティングできないため、GRE が必要です。監視サブネット 172.16.1.0/24 への IP 到達可能性がアンダーレイを介して確立されると、GRE トンネルが自動的に形成されます。
このシナリオでは、サーバー1はリーフ1にシングルホームです。
構成
この例を使用して、スパイン1を通過するトラフィックをミラーリングします。すべてのトラフィックをミラーリングするには、スパイン2の設定を繰り返します。ポートミラーリングがスパイン1および2で設定されている場合、リーフが選択するECMPファブリックのネクストホップに関係なく、トラフィックがミラーリングされます。
-
(オプション)スパイン2のBGPを無効化します。テストの目的で、スパイン2のBGPスタンザを無効にします。このようにして、スパイン1のみに焦点を当て、リーフ1とリーフ4間のすべてのトラフィックがミラーリングされるようにすることができます。
user@spine2# deactivate protocols bgp user@spine2# commit
スパイン2でBGPを無効化した後、リーフ1はリーフ4のループバックに到達するための単一のネクストホップを持ちます。これは、et-0/0/48インターフェイスを介してスパイン1を経由しています。
user@leaf1> show route 10.1.255.14 inet.0: 11 destinations, 12 routes (11 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.1.255.14/32 *[BGP/170] 04:10:11, localpref 100 AS path: 65001 65014 I, validation-state: unverified > to 10.1.11.1 via et-0/0/48.0
-
スパイン1にミラーリングインスタンスを作成し、ミラーリングされたトラフィックをリモート監視ステーションに送信します。
user@spine1# set forwarding-options port-mirroring instance mirror-leaf1-and-leaf4 family inet output ip-address 172.16.1.2
-
リーン スパインは、ERB ファブリックではオーバーレイを認識しません。リーフデバイス間で送信されるすべてのVXLANカプセル化トラフィックは、ローカルVTEPアドレスを使用します。VTEP アドレスは通常、デバイスのループバック アドレスと一致します。つまり、スパインデバイスのフィルターを使用して、関連するリーフデバイスのループバックアドレスで一致させ、ポートミラーリングインスタンスにトラフィックを誘導することができます。
スパイン1で、リーフ1とリーフ4の送信元と宛先のIPアドレスに一致するファイアウォールフィルターを作成します。送信元と宛先の両方の IP を照合することで、これらのリーフ間で送信されたすべてのオーバーレイ トラフィックが GRE トンネルにミラーリングされます。
メモ:リーンスパインはVXLAN対応ではないため、この方法はリーフデバイスから送信されたすべてのオーバーレイトラフィックをミラーリングします。例えば、リーフに100個のVLANまたはVXLAN VNIが定義されている場合、100個すべてのVNIのトラフィックがミラーリングされます。より細かい粒度でミラーリングする場合は、 例:EVPN-VXLAN ERBファブリックリーフデバイスのイングレスソリューションを参照してください。この例では、VXLAN対応リーフデバイスでミラー機能が発生します。
リーフ1から送信されるトラフィックのファイアウォールフィルターを設定します。この例では、リーフ1(スパインを介して)送信されるすべてのVXLANトラフィックの送信元アドレスは10.1.255.11です。リーフ4によって送信されるすべてのVXLANトラフィックの送信元アドレスは10.1.255.14です。
[edit firewall family inet filter port-mirror-from-leaf1] user@spine1# set term term1 from source-address 10.1.255.11/32 user@spine1# set term term1 from destination-address 10.1.255.14/32 user@spine1# set term term1 then count from-leaf1-vtep user@spine1# set term term1 then port-mirror-instance mirror-leaf1-and-leaf4 user@spine1# set term term1 then accept user@spine1# set term term2 then accept
リーフ4から送信されるトラフィックのファイアウォールフィルターを設定します。
[edit firewall family inet filter port-mirror-from-leaf4] user@spine1# set term term1 from source-address 10.1.255.14/32 user@spine1# set term term1 from destination-address 10.1.255.11/32 user@spine1# set term term1 then count from-leaf4-vtep user@spine1# set term term1 then port-mirror-instance mirror-leaf1-and-leaf4 user@spine1# set term term1 then accept user@spine1# set term term2 then accept
-
ファイアウォールフィルターを、スパイン1のリーフ1およびリーフ4に面したファブリックインターフェイスに適用します。
user@spine1# set interfaces et-0/0/7 unit 0 family inet filter input port-mirror-from-leaf1 user@spine1# set interfaces et-0/0/6 unit 0 family inet filter input port-mirror-from-leaf4
フィルター・アプリケーションの方向性に注意してください。ジュニパーのフィルターは、 表 2 に示すように、ポート ミラーリング用のイングレス フィルターのみをサポートする QFX5110 プラットフォームに対応しています。ローカルリーフのVTEPに一致する入力フィルターを送信元アドレスとして使用し、リモートリーフのVTEPを宛先アドレスとして使用することで、これら2つのリーフ間のオーバーレイトラフィックのみがミラーリングされるようにします。宛先リーフに関係なく、リーフによって送信されたすべてのVXLANトラフィックをミラーリングしたい場合は、フィルター内のローカルリーフの送信元アドレスに一致します。
-
(オプション)フィルターを追加します。
ここまでの例では、サーバー 1 はリーフ 1 のみに対してシングルホームであると想定しています。サーバーがリーフ1とリーフ2にマルチホームされている場合、表示されているフィルターを適応させ、リーフ2からリーフ4に送信されたトラフィックをキャッチする必要があります。その逆も同様です。
例として、これらのステートメントは、スパイン1のリーフ2に面したインターフェイスの入力フィルターを作成します。
[edit firewall family inet filter port-mirror-from-leaf4] user@spine1# set term term1 from source-address 10.1.255.12/32 user@spine1# set term term1 from destination-address 10.1.255.14/32 user@spine1# set term term1 then count from-leaf2-vtep user@spine1# set term term1 then port-mirror-instance mirror-leaf1-and-leaf4 user@spine1# set term term1 then accept user@spine1# set term term2 then accept
[edit] user@spine1# set interfaces et-0/0/8 unit 0 family inet filter input port-mirror-from-leaf2
リーフの2 VTEPの宛先アドレスでも、既存
port-mirror-from-leaf4
のフィルターを簡単に変更する必要があります。[edit firewall family inet filter port-mirror-from-leaf4] user@spine1# set term term1 from destination-address 10.1.255.12/32
-
スパイン1で変更をコミットします。
開始する EVPN-VXLAN ベースラインからの変更を示します。
user@spine1# show | compare rollback 1 [edit interfaces et-0/0/6 unit 0 family inet] + filter { + input port-mirror-from-leaf4; + } [edit interfaces et-0/0/7 unit 0 family inet] + filter { + input port-mirror-from-leaf1; + } [edit] + forwarding-options { + port-mirroring { + instance { + mirror-leaf1-and-leaf4 { + family inet { + output { + ip-address 172.16.1.2; + } + } + } + } + } + } + firewall { + family inet { + filter port-mirror-from-leaf1 { + term term1 { + from { + source-address { + 10.1.255.11/32; + } + destination-address { + 10.1.255.14/32; + } + } + then { + count from-leaf1-vtep; + port-mirror-instance mirror-leaf1-and-leaf4; + accept; + } + } + term term2 { + then accept; + } + } + filter port-mirror-from-leaf4 { + term term1 { + from { + source-address { + 10.1.255.14/32; + } + destination-address { + 10.1.255.11/32; + } + } + then { + count from-leaf4-vtep; + port-mirror-instance mirror-leaf1-and-leaf4; + accept; + } + } + term term2 { + then accept; + } + } + } + }
-
モニターステーションに接続されたxe-0/0/33:1インターフェイスを設定するために、リーフ3の設定を変更します。
user@bl-leaf3# set interfaces xe-0/0/33:1 unit 0 family inet address 172.16.1.1/24
監視ステーションに接続されたリーフデバイスは、明示的なGRE設定を必要としません。これは、GRE トンネルが監視ステーションで終了するためです。ファブリックアンダーレイで監視ステーションのIPアドレスに到達可能であることを確認する必要があります。つまり、監視ステーションへのアンダーレイ到達可能性がない場合、スパインはGREカプセル化されたトラフィックを監視ステーションに送信できません。
-
境界リーフ3のアンダーレイエクスポートポリシーを変更して、監視ステーションのプレフィックスをアドバタイズします。ジュニパーのトポロジーでは、EBGPアンダーレイを使用しています。既存のアンダーレイエクスポートポリシーに新しい条件を追加するだけです
[edit policy-options policy-statement send-direct] user@bl-leaf3# set term 2 from protocol direct user@bl-leaf3# set term 2 from route-filter 172.16.1.0/24 exact user@bl-leaf3# set term 2 then accept
-
ボーダーリーフ3で変更をコミットします。
開始ベースラインの変更が表示されます。
user@bl-leaf3# show | compare rollback 1 [edit interfaces] + xe-0/0/33:1 { + unit 0 { + family inet { + address 172.16.1.1/24; + } + } + } [edit policy-options policy-statement send-direct] term 1 { ... } + term 2 { + from { + protocol direct; + route-filter 172.16.1.0/24 exact; + } + then accept; + }
検証
-
スパイン1から監視ステーションへのアンダーレイ接続を検証します。
スパイン1で、172.16.1.0/24へのルートを表示します。
user@spine1> show route 172.16.1.0/24 inet.0: 16 destinations, 17 routes (16 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.1.0/24 *[BGP/170] 00:32:00, localpref 100 AS path: 65013 I, validation-state: unverified > to 10.1.13.2 via et-0/0/5.0
メモ:厳密に言えば、スパインと監視ステーション間のシンプルな接続のみが必要です。監視ステーションに静的ルートを設定し、ファブリックアンダーレイに到達できるようにしました。これにより、障害分離のための ping テストが可能になります。
監視ステーションに Ping を実行して接続を確認します。
user@spine1> ping 172.16.1.2 count 2 PING 172.16.1.2 (172.16.1.2): 56 data bytes 64 bytes from 172.16.1.2: icmp_seq=0 ttl=63 time=1.116 ms 64 bytes from 172.16.1.2: icmp_seq=1 ttl=63 time=1.046 ms --- 172.16.1.2 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.046/1.081/1.116/0.035 ms
この出力により、スパインから監視ステーションへの予想されるアンダーレイ到達可能性が確認されます。
- スパイン1のポートミラーリングインスタンスを確認します。スパイン1で、リモートポートミラーリングの状態が
up
であることを確認します。user@spine1> show forwarding-options port-mirroring detail Instance Name: mirror-leaf1-and-leaf4 Instance Id: 2 Input parameters: Rate : 1 Run-length : 0 Maximum-packet-length : 0 Output parameters: Family State Destination Next-hop inet up 172.16.1.2 .local..0
出力は、ポートミラーリングインスタンスの正しい定義を確認します。の
up
状態は、スパインに監視ステーションへのアンダーレイ ルートがあることを示しています。GRE がステートレス プロトコルであることを思い出してください。そのため、前のステップで行ったように、スパインと監視ステーション間の接続性を検証することをお勧めします。 -
スパイン1に適用されたフィルターがテストトラフィックを正しく反映することを確認します。
ping を生成する前にカウンターをクリアします。
user@server1> clear firewall all
ファブリック上でサーバー 1 とサーバー 2 の間で ping を開始します。
user@server1> ping 10.1.101.20 count 10 rapid PING 10.1.101.20 (10.1.101.20): 56 data bytes !!!!!!!!!! --- 10.1.101.20 ping statistics --- 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.731/0.800/1.300/0.167 ms
次に、スパイン1にファイアウォールカウンターを表示します。スパイン1に適用されたフィルターがテストトラフィックを正しく反映することを確認します。この例のトポロジーには、1つのVLANと1組のサーバーしかありません。これにより、テストトラフィックを関連付けて、マッチをフィルタリングすることが容易になります。ゼロ以外のカウントは、フィルターが動作している良い兆候です。
user@spine1> show firewall Filter: port-mirror-from-leaf1 Counters: Name Bytes Packets from-leaf1-vtep 1520 10 Filter: port-mirror-from-leaf4 Counters: Name Bytes Packets from-leaf4-vtep 1520 10
ファイアウォール カウンターは、2 台のサーバー間のテスト トラフィックを正しく反映します。
-
サーバー1とサーバー2の間で送信されたトラフィックがスパイン1でミラーリングされ、監視ステーションに送信されていることを確認します。
サーバー 1 とサーバー 2 の間でトラフィックが生成されます(簡潔な表示はありません)。ping コマンドの オプションを
rapid
使用して、関連付けを容易にする大量のテスト トラフィックを生成します。監視ステーションに接続するボーダーリーフ3のインターフェイス上のインターフェイストラフィックカウントを監視します。エグレスパケット数に生成されたテストトラフィックが反映されたことを確認します。
user@bl-leaf3> monitor interface xe-0/0/33:1 bl-leaf3 Seconds: 17 Time: 19:58:30 Delay: 1/0/1 Interface: xe-0/0/33:1, Enabled, Link is Up Encapsulation: Ethernet, Speed: 10000mbps Traffic statistics: Current delta Input bytes: 1019608 (0 bps) [0] Output bytes: 5699872 (4752824 bps) [3382190] Input packets: 10115 (0 pps) [0] Output packets: 34752 (3126 pps) [17801]
出力は、トラフィックが監視ステーションにミラーリングされていることを確認します。モニター・ステーションが受信した GRE トラフィックに対する応答を生成しないため、入力パケットの不足が予想されます。
-
Wireshark または同等のアナライザ アプリケーションを使用して、ミラーリングされたトラフィックをキャプチャしてデコードします。
図 3:ミラーリングされたトラフィックの分析キャプチャは、サーバー 1 が ping トラフィックをサーバー 2 に送信し、サーバー 2 が応答することを示しています。これにより、リーフ1とリーフ4のペア間で送信されたオーバーレイトラフィックが、スパイン1で正しくミラーリングされていることを確認します。VXLAN カプセル化トラフィック(UDP ポート 4789)は、次に GRE(IP プロトコル 47)にカプセル化されることに注意してください。GREヘッダーのプロトコルタイプは「ERSPAN」(リモートポートミラーリングに匹敵)で、その他のすべてのフラグはゼロに設定されています。
デコードにより、アンダーレイ(10.1.255.x)で使用されるリーフ VTEP またはループバック アドレスを確認できます。サーバーから送信された元のレイヤー2フレームも存在し、VNI 101を使用してVXLANにカプセル化されたと表示されます。サーバーから送信されたIPパケットもデコードされます。オーバーレイ内のサーバーで使用される IP アドレスは、生成された IP/ICMP パケットの詳細と同様に、表示されます(10.1.100.x/24)。
トポロジーでポートミラーリングを正常に設定しました。
例:EVPN-VXLAN ERBファブリックリーフデバイスのイングレスソリューション
概要
次の例を使用して、EVPN-VXLAN ERBファブリック上のリーフデバイスを通過するトラフィックをミラーリングします。最初の例で説明したリーンスパインベースのポートミラーリングシナリオとは異なり、リーフはERB設計においてテナント認識とVLAN認識です。つまり、すべてのオーバーレイトラフィックではなく、リーフデバイス間で送信された特定のトラフィックをミラーリングできるということです。ERBリーフデバイスのフィルタリング基準に一致するテナントフローは、境界リーフ3に接続された監視ステーションで終了するGREトンネルにミラーリングされます。
トポロジ
この設定例では 、「要件」に示すハードウェアとソフトウェアのコンポーネントを使用します。トポロジーのデバイスは、「 付録: 完全なデバイス設定」で示されているように、ベースライン設定から始まります。
図 4 は、テナント フロー フィルタリング機能を備えたリモート ポート ミラーリングのトポロジーを示しています。
なお、サーバー 1 は依然としてリーフ 1 へのみシングルホームです。違いは、リーフデバイスでフィルターとポートミラーリングインスタンスが定義されていることです。目標は、サーバー 1 が VLAN 101 に関連付けられた 10.1.101.0/24 サブネットに送信したすべてのトラフィックで一致することです。サーバー1からVLAN 101の宛先に送信されたトラフィックは、 で一致し、ボーダーリーフ3のポートミラーリングステーションに送信されます。
構成
最初のシナリオでは、Spine 2のBGPを無効にして、スパイン1のアプリケーションをフィルターすることに重点を置きました。残りの例では、スパイン1とスパイン2の両方が完全に動作しています。
-
リーフ1でポートミラーリングインスタンスを設定します。監視ステーションに IP アドレス 172.16.1.2 を使用します。
user@leaf1# set forwarding-options port-mirroring instance mirror-leaf1-v101 family inet output ip-address 172.16.1.2
-
次に、VLAN 101 に割り当てられたサブネット上で一致するファイアウォール フィルターを作成します。目標は、サーバー1からリーフ1に送信されたすべてのVLAN内101トラフィックをミラーリングすることです。VLAN 間トラフィックをキャッチするには、宛先アドレスのターゲット VLAN のサブネットを指定します。
[edit firewall family ethernet-switching filter mirror-leaf-1] user@leaf1# set term 1 from ip-source-address 10.1.101.0/24 user@leaf1# set term 1 from ip-destination-address 10.1.101.0/24 user@leaf1# set term 1 then accept user@leaf1# set term 1 then port-mirror-instance mirror-leaf1-v101 user@leaf1# set term 1 then count from-s1-v101 user@leaf1# set term 2 then accept
メモ:ルーティングされたトラフィック(VLAN間)のみをミラーリングしたい場合は、VLANのIRBインターフェイスに適用されるフィルターを使用
family inet
します。各 VLAN に対して定義される IRB インターフェイスは 1 つだけです。VLANのIRBインターフェイスに適用されたフィルターは、トラフィックが到着するフロントパネルポートに関係なく、関連するVLANのすべてのVLAN間トラフィックをキャッチします。ここで示す方法は VLAN 間および VLAN 内トラフィックで機能しますが、VLAN メンバーシップに基づいてサーバー側インターフェイスにフィルターを適用する必要があります。
inet
IRB インターフェイスに適用されたフィルターは、ブリッジド(VLAN 内)トラフィックを確認しません。 -
サーバー 1 に接続されたアクセス ポートに、リモート ポート ミラーリング ファイアウォール フィルターを入力方向に適用します。
user@leaf1# set interfaces xe-0/0/0 unit 0 family ethernet-switching filter input mirror-leaf-1
メモ:QFX5110およびQFX5120スイッチでは、ファイアウォールフィルターを出力方向に適用したり、スパインデバイスに接続されたファブリックインターフェイスで使用することはできません。
-
境界リーフ3は、GREトンネルが監視ステーションで終端するため、GREカプセル化解除を実行するように設定する必要はありません。ただし、リーフ3は、監視ステーションのサブネットの到達可能性をファブリックのアンダーレイにアドバタイズする必要があります。監視ステーションへの到達性を確立するために、リーフ3に以下を設定します。
まず、監視ステーションに接続されたxe-0/0/33:1インターフェイスを設定します。
user@bl-leaf3# set interfaces xe-0/0/33:1 unit 0 family inet address 172.16.1.1/24
-
境界リーフ3のアンダーレイエクスポートポリシーを変更して、監視ステーションのプレフィックスをアドバタイズします。ジュニパーのトポロジーでは、EBGPアンダーレイを使用しています。既存のアンダーレイエクスポートポリシーに新しい条件を追加するだけです
[edit policy-options policy-statement send-direct] user@bl-leaf3# set term 2 from protocol direct user@bl-leaf3# set term 2 from route-filter 172.16.1.0/24 exact user@bl-leaf3# set term 2 then accept
-
設定をコミットします。
開始ベースラインからの変更はリーフ1に表示されます。
user@bl-leaf1# show | compare rollback 1 [edit interfaces xe-0/0/0 unit 0 family ethernet-switching] + filter { + input mirror-leaf-1; + } [edit] + forwarding-options { + port-mirroring { + instance { + mirror-leaf1 { + family inet { + output { + ip-address 172.16.1.2; + } + } + } + } + } + } + firewall { + family ethernet-switching { + filter mirror-leaf-1 { + term 1 { + from { + ip-source-address { + 10.1.101.0/24; + } + ip-destination-address { + 10.1.101.0/24; + } + } + then { + accept; + port-mirror-instance mirror-leaf1; + count from-s1; + } + } + term 2 { + then accept; + } + } + } + }
EVPN-VXLAN ERBファブリック上のリーフデバイスを介してリモートポートミラーリングを正常に設定しました。
検証
-
リーフ1から監視ステーションへのアンダーレイ接続を検証します。
リーフ1で、172.16.1.0/24へのルートを表示します。
user@leaf1> show route 172.16.1.0/24 inet.0: 12 destinations, 13 routes (12 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.1.0/24 *[BGP/170] 4d 00:56:23, localpref 100 AS path: 65001 65013 I, validation-state: unverified > to 10.1.11.1 via et-0/0/48.0
メモ:厳密に言えば、リーフと監視ステーション間のシンプルな接続のみが必要です。監視ステーションに静的ルートを設定し、ファブリックアンダーレイに到達できるようにしました。これにより、pingテストを可能にし、障害分離を支援します。
監視ステーションに Ping を実行して接続を確認します。
user@leaf1> ping 172.16.1.2 count 2 source 10.1.255.11 PING 172.16.1.2 (172.16.1.2): 56 data bytes 64 bytes from 172.16.1.2: icmp_seq=0 ttl=62 time=1.380 ms 64 bytes from 172.16.1.2: icmp_seq=1 ttl=62 time=7.614 ms --- 172.16.1.2 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.380/4.497/7.614/3.117 ms
この出力により、リーフ1から監視ステーションへの予想されるアンダーレイ到達可能性が確認されます。アンダーレイエクスポートポリシーはループバックアドレスの到達可能性のみをアドバタイズするため、リーフのループバックアドレスからpingを送信する必要があります。リーンスパインの例では、ループバックアドレスからのソーシングは必要ありませんでした。これは、スパインとボーダーリーフがファブリックリンク上に直接接続されているからです。そのため、ボーダーリーフは、スパインのリーフに面したファブリックインターフェイスから供給されると、ping応答をスパインに戻すことができます。
-
リーフ1のポートミラーリングインスタンスを確認します。
リーフ1で、リモートポートミラーリングの状態が
up
であることを確認します。user@leaf1> show forwarding-options port-mirroring detail Instance Name: mirror-leaf1 Instance Id: 2 Input parameters: Rate : 1 Run-length : 0 Maximum-packet-length : 0 Output parameters: Family State Destination Next-hop inet up 172.16.1.2 et-0/0/48.0
出力は、ポートミラーリングインスタンスの正しい定義を確認します。の
up
状態は、リーフに監視ステーションへのアンダーレイ ルートがあることを示しています。GRE がステートレス プロトコルであることを思い出してください。そのため、前のステップで行ったように、リーフと監視ステーション間の接続性を検証することをお勧めします。 -
リーフ1に適用されたフィルターがテストトラフィックを正しく反映しているかどうかを確認します。
ファブリック上でサーバー 1 とサーバー 2 の間で ping を開始します。リーフ1に適用されたフィルターがトラフィックを正しく反映することを確認します。この例のトポロジーには、1つのVLANと1組のサーバーしかありません。これにより、テストトラフィックを関連付けて、マッチをフィルタリングすることが容易になります。ゼロ以外のカウントは、フィルターが動作している良い兆候です。
user@server1> ping 10.1.101.20 count 10 rapid PING 10.1.101.20 (10.1.101.20): 56 data bytes !!!!!!!!!! --- 10.1.101.20 ping statistics --- 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.731/0.800/1.300/0.167 ms
ping を生成する前にカウンターをクリアします。
user@server1> clear firewall all
次に、スパイン1にファイアウォールカウンターを表示します。
user@leaf1> show firewall Filter: mirror-leaf-1 Counters: Name Bytes Packets from-s1 1020 10
ファイアウォール カウンターは、2 台のサーバー間のテスト トラフィックを正しく反映します。
-
サーバー1とサーバー2の間で送信されたトラフィックがリーフ1で監視ステーションにミラーリングされていることを確認します。
サーバー 1 とサーバー 2 の間でトラフィックが生成されます(簡潔な表示はありません)。ping コマンドの rapid オプションを使用して大量のパケットを生成し、検出を容易にしました。
ボーダーリーフ3のインターフェイストラフィックカウンターを監視して、テストトラフィックが監視ステーションに送信されていることを確認します。
user@bl-leaf3> monitor interface xe-0/0/33:1 bl-leaf3 Seconds: 17 Time: 19:58:30 Delay: 1/0/1 Interface: xe-0/0/33:1, Enabled, Link is Up Encapsulation: Ethernet, Speed: 10000mbps Traffic statistics: Current delta Input bytes: 1019608 (0 bps) [0] Output bytes: 5699872 (4752824 bps) [3382190] Input packets: 10115 (0 pps) [0] Output packets: 34752 (3126 pps) [17801]
出力は、トラフィックが監視ステーションにミラーリングされていることを確認します。モニター・ステーションは、受信した GRE トラフィックに対する応答を生成しないため、入力パケットの不足が予想されます。
-
Wireshark または同等のアナライザ アプリケーションを使用して、ミラーリングされたトラフィックをキャプチャしてデコードします。
図 5:ミラーリングされたトラフィックの分析キャプチャは、サーバー 1 が ping トラフィックをサーバー 2 に送信することを示しています。入力方向にフィルターをリーフ1のみで適用したため、応答トラフィックはミラーリングされません。同様のポートミラーインスタンスを適用し、リーフ4でフィルター設定を行い、リターントラフィックもミラーリングします。リーンスパインの場合、ミラーリングされたトラフィックはVXLANカプセル化を示したことを思い出してください。ERBリーフの場合 VXLANにカプセル化される前にレイヤー2トラフィックをミラーリングしますトラフィックのミラーリングに使用されるフィルターは、サーバー側のインターフェイス上の入力フィルターとして適用されます。イングレスでは、VXLANカプセル化はありません。
これは、VLAN の IRB インターフェイスにフィルターを適用する場合と同様です。IRB の場合、ミラーリングされたトラフィックには VXLAN カプセル化が含まれていません。IRB ベースのフィルターは、IP レイヤーで VLAN 間トラフィックを処理します。したがって、IRB フィルターケースでは、レイヤー 3 IP トラフィックのみがミラーリングされます。
デコードでは、アンダーレイを介してGREトンネルがリーフ1と監視ステーションの間であることを示しています。サーバー1によって送信されたイーサネットフレームと関連するIPパケットがデコードされます。サーバーに割り当てられた IP アドレスは、サーバー 1 によって生成された IP/ICMP パケットの詳細と同様に表示されます(10.1.100.x/24)。
トポロジーでポートミラーリングを正常に設定しました。
例:ESI-LAGインターフェイスでリモートミラーリングインスタンスを有効にする
概要
ESI(イーサネット セグメント識別子)は、サーバーに接続された EVPN-VXLAN ファブリック内のイーサネット セグメントを識別する一意の 10 バイト番号です。ESIは、サーバーに接続するインターフェイス上で設定されています。複数のリンクが LAG(リンク アグリゲーション グループ)を形成し、サーバーに接続されている場合、これは EVPN LAG(インターフェース)とも呼ばれる ESI-LAG を形成します。場合によっては、ESI-LAGインターフェイスに出入りするトラフィックの全部または一部に対してポートミラーリングを有効にする必要があります。
EVPN-VXLAN ERBファブリックのESI-LAGレベルでリモートポートミラーリングを有効にするには、このセクションを使用します。
トポロジ
この設定例では 、「要件」に示すハードウェアとソフトウェアのコンポーネントを使用します。トポロジーのデバイスは、「 付録: 完全なデバイス設定」で示されているように、ベースライン設定から始まります。
この場合、EVPNファブリックを変更して、サーバー1から1と2へのマルチホーミングをサポートします。EVPN LAG(インターフェース)とも呼ばれる ESI-LAG を使用してこれを行います。ベストプラクティスについては 、 EVPN LAG構成のベストプラクティス をご覧ください。
図 6 は、この例のトポロジーを示しています。どちらのスパインも、このトポロジーで動作しています。ECMPとは、リーフ1とリーフ2が、スパインデバイスを介してトラフィックを送信できることを意味します。この図を簡素化するために、スパイン1を中心にしたトラフィックとミラーリングパスを示します。
インターフェイス ae0.0 は、サーバー 1 に接続された ESI-LAG インターフェイスです。サーバー 1 には IP アドレス 10.1.101.10/24 が割り当てられ、VLAN 101 に関連付けられています。目標は、サーバー 1 から送信されたトラフィックを、いずれかのリーフ上で ae0.0 を通過する際にフィルタリングし、ミラーリングすることです。ミラーリングされたトラフィックは GRE トンネルに配置され、監視ステーションに送信されます。以前と同様に、EBGP アンダーレイで監視ステーションサブネットに到達可能であることを確認する必要があります。
始める前に
「付録: 完全なデバイス構成」に示すベースライン構成から開始する場合は、開始する前に以下の手順に従ってトポロジーを変更します。
-
リーフ1とリーフ2の設定を変更して、サーバー1のマルチホーム接続をサポートします。既存の xe-0//0/0 インターフェイスの名前を新しい ae0.0 インターフェイスに変更することから始めます。この機能は、xe-0/0/0インターフェイスからのあらゆる設定に対応し、時間を節約します。
user@leaf1# rename interfaces xe-0/0/0 to ae0 user@leaf1# set interfaces ae0 esi 00:02:02:02:02:02:02:02:00:04 user@leaf1# set interfaces ae0 esi all-active user@leaf1# set interfaces ae0 aggregated-ether-options lacp active user@leaf1# set interfaces ae0 aggregated-ether-options lacp system-id 00:00:02:02:00:04
-
サーバーの集合型イーサネット・インターフェース(Linux ではしばしば結合インターフェースと呼ばれる)の設定仕様は、この NCE の範囲を超えています。サーバーには、標準的な集合型イーサネット構成しかありません。ESI-LAGに関連するステートメントは、リーフデバイスにのみ適用されます。
メモ:開始ベースライン設定では、 設定ステートメントを介して集合型イーサネットインターフェイスを
set chassis aggregated-devices ethernet device-count 1
有効にします。集約されたデバイスのシャーシサポートを有効にする必要があります。または、集約されたインターフェイスが作成されていません。 -
これらの変更をリーフデバイスとサーバーの両方に適用してコミットした後、ae0インターフェイスが両方のリーフで稼働していることを確認します。以下の出力例は、明確にするために短縮されました。
user@leaf2> show interfaces ae0 Physical interface: ae0, Enabled, Physical link is Up Physical interface: ae0, Enabled, Physical link is Up [...] Current address: b8:c2:53:ba:8b:80, Hardware address: b8:c2:53:ba:8b:80 Ethernet segment value: 00:02:02:02:02:02:02:02:00:04, Mode: all-active Last flapped : 2022-09-07 14:57:53 UTC (01:06:43 ago) [...] Egress queues: 12 supported, 5 in use Queue counters: Queued packets Transmitted packets Dropped packets 0 81129 81129 0 3 0 0 0 4 0 0 0 7 4135 4135 0 8 64 64 0 [...] Protocol eth-switch, MTU: 1514, Generation: 266, Route table: 7, Mesh Group: __all_ces__, EVPN multi-homed status: Forwarding, EVPN multi-homed ESI Split Horizon Label: 0, Next-hop: 1665, vpls-status: up Local Bias Logical Interface Name: vtep.32769, Index: 554, VXLAN Endpoint Address: 10.1.255.11 Flags: Is-Primary
また、サーバー 1 がサーバー 2 に ping を実行できることを確認します(簡潔にするために表示されていません)。
構成
この例では、リモートポートミラーリングインスタンスを使用して、ESI-LAGレベルでリモートポートミラーリングを有効にする方法を示しています。この方法では、(オーバーレイ VLAN 内で)テナント固有の一致条件をサポートし、トラフィックを選択的にミラーリングします。
-
リーフ1とリーフ2の両方でポートミラーリングインスタンスを設定します。サーバー1は、LAGメンバーインターフェイスのいずれかを介してVLAN 101のトラフィックを送信できます。ECMP とは、トラフィックがどちらのリーフにも到着できることを意味します。IP アドレス 172.16.1.2 は監視ステーションです。
user@leaf1# set forwarding-options port-mirroring instance mirror-leaf1-v101 family inet output ip-address 172.16.1.2
-
次に、両リーフの VLAN 101 に割り当てられたサブネットで一致するファイアウォール フィルターを作成します。目標は、サーバー1からリーフ1またはリーフ2に送信されたすべてのVLAN内101トラフィックをミラーリングすることです。VLAN 間トラフィックをキャッチするには、宛先アドレスのターゲット VLAN のサブネットを指定します。
複数の送信元または宛先 IP アドレスでフィルタリングする必要がある場合は、フィルターでの および/または の
destination-prefix-list
使用source-prefix-list
を検討してください。この方法では、フィルター定義を変更することなく、プレフィックスリストを変更できます。[edit firewall family ethernet-switching filter mirror-leaf-1] user@leaf1# set term 1 from ip-source-address 10.1.101.0/24 user@leaf1# set term 1 from ip-destination-address 10.1.101.0/24 user@leaf1# set term 1 then accept user@leaf1# set term 1 then port-mirror-instance mirror-leaf1-v101 user@leaf1# set term 1 then count from-s1-v101 user@leaf1# set term 2 then accept
メモ:ルーティングされたトラフィック(VLAN 間)のみをミラーリングする場合は、VLAN の IRB インターフェイスに適用されるフィルターを使用
family inet
します。各 VLAN に対して定義される IRB インターフェイスは 1 つだけです。そのため、VLANのIRBインターフェイスに適用されたフィルターは、トラフィックがイングレスしているフロントパネルポートに関係なく、関連するVLANのすべてのVLAN間トラフィックをキャッチします。この例で示す方法は、VLAN 間および VLAN 内トラフィックで機能しますが、VLAN メンバーシップに基づいてサーバー側インターフェイスにフィルターを適用する必要があります。
inet
IRB インターフェイスに適用されたフィルターは、ブリッジド(VLAN 内)トラフィックを確認しません。 -
リモートポートミラーリングファイアウォールフィルターを、両リーフの入力フィルターとして、ae0.0インターフェイスに適用します。
user@leaf1# set interfaces ae0 unit 0 family ethernet-switching filter input mirror-leaf-1
メモ:QFX5110およびQFX5120スイッチでは、ファイアウォールフィルターを送信方向で有効にしたり、スパインデバイスに接続されたインターフェイスで使用することはできません。
-
境界リーフ3は、GREトンネルが監視ステーションで終端するため、GREカプセル化解除を実行するように設定する必要はありません。ただし、リーフ3は、監視ステーションのサブネットの到達可能性をファブリックのアンダーレイにアドバタイズする必要があります。監視ステーションに接続する xe-0/0/33:1 インターフェイスを設定します。
user@bl-leaf3# set interfaces xe-0/0/33:1 unit 0 family inet address 172.16.1.1/24
境界リーフ3のアンダーレイエクスポートポリシーを変更して、監視ステーションのプレフィックスをアドバタイズします。ジュニパーのトポロジーでは、EBGPアンダーレイを使用しています。既存のアンダーレイエクスポートポリシーに新しい条件を追加するだけです
[edit policy-options policy-statement send-direct] user@bl-leaf3# set term 2 from protocol direct user@bl-leaf3# set term 2 from route-filter 172.16.1.0/24 exact user@bl-leaf3# set term 2 then accept
-
開始ベースラインの変更はリーフ1に表示されます。
#user@leaf1# show | compare base [edit interfaces xe-0/0/0] + gigether-options { + 802.3ad ae0; + } [edit interfaces xe-0/0/0] - unit 0 { - family ethernet-switching { - vlan { - members v101; - } - } - } [edit interfaces] + ae0 { + esi { + 00:02:02:02:02:02:02:02:00:04; + all-active; + } + aggregated-ether-options { + lacp { + active; + system-id 00:00:02:02:00:04; + } + } + unit 0 { + family ethernet-switching { + interface-mode access; + vlan { + members v101; + } + filter { + input mirror-leaf-1; + } + } + } + } [edit] + forwarding-options { + port-mirroring { + instance { + mirror-leaf1 { + family inet { + output { + ip-address 172.16.1.2; + } + } + } + } + } + } + firewall { + family ethernet-switching { + filter mirror-leaf-1 { + term 1 { + from { + ip-source-address { + 10.1.101.0/24; + } + ip-destination-address { + 10.1.101.0/24; + } + } + then { + accept; + port-mirror-instance mirror-leaf1; + count from-s1; + } + } + term 2 { + then accept; + } + } + } + }
EVPN-VXLAN ERBファブリック上のリーフデバイスを介してリモートポートミラーリングを正常に設定しました。
検証
-
リーフ1から監視ステーションへのアンダーレイ接続を検証します。
リーフ1で、172.16.1.0/24へのルートを表示します。
user@leaf1> show route 172.16.1.0/24 inet.0: 12 destinations, 13 routes (12 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.1.0/24 *[BGP/170] 4d 00:56:23, localpref 100 AS path: 65001 65013 I, validation-state: unverified > to 10.1.11.1 via et-0/0/48.0
メモ:厳密に言えば、リーフと監視ステーション間の接続はシンプルな接続のみが必要です。監視ステーションに静的ルートを設定し、ファブリックアンダーレイに到達できるようにしました。これにより、障害分離ツールとしての ping テストが可能になります。
監視ステーションに Ping を実行して接続を確認します。
user@leaf1> ping 172.16.1.2 count 2 source 10.1.255.11 PING 172.16.1.2 (172.16.1.2): 56 data bytes 64 bytes from 172.16.1.2: icmp_seq=0 ttl=62 time=1.380 ms 64 bytes from 172.16.1.2: icmp_seq=1 ttl=62 time=7.614 ms --- 172.16.1.2 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.380/4.497/7.614/3.117 ms
この出力により、リーフ1から監視ステーションへの予想されるアンダーレイ到達可能性が確認されます。アンダーレイエクスポートポリシーはループバックアドレスの到達可能性のみをアドバタイズするため、リーフのループバックアドレスからpingを送信する必要があります。リーンスパインケースでは、ループバックアドレスからのソーシングは必要ありません。スパインとボーダーリーフが直接接続されたファブリックリンクを共有するためです。
-
リーフ1のポートミラーリングインスタンスを確認します。
リーフ1で、リモートポートミラーリングの状態が
up
であることを確認します。user@leaf1> show forwarding-options port-mirroring detail Instance Name: mirror-leaf1 Instance Id: 2 Input parameters: Rate : 1 Run-length : 0 Maximum-packet-length : 0 Output parameters: Family State Destination Next-hop inet up 172.16.1.2 et-0/0/48.0
出力は、ポートミラーリングインスタンスの正しい定義を確認します。の
up
状態は、リーフに監視ステーションへのアンダーレイ ルートがあることを示しています。GRE がステートレス プロトコルであることを思い出してください。そのため、前のステップで行ったように、リーフと監視ステーション間の接続性を検証することをお勧めします。 -
リーフ1とリーフ2に適用されたフィルターがテストトラフィックを正しく反映することを確認します。ファブリック上でサーバー 1 とサーバー 2 の間で ping を開始します。
user@server1> ping 10.1.101.20 count 10 rapid PING 10.1.101.20 (10.1.101.20): 56 data bytes !!!!!!!!!! --- 10.1.101.20 ping statistics --- 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.731/0.800/1.300/0.167 ms
リーフ1とリーフ2に適用されたフィルターがトラフィックを正しく反映することを確認します。この例のトポロジーには、1つのVLANと1組のサーバーしかありません。これにより、テストトラフィックを関連付けて、マッチをフィルタリングすることが容易になります。ゼロ以外のカウントは、フィルターが動作している良い兆候です。
ECMP 動作のため、単一の ping フロー ハッシュは集約されたイーサネット インターフェイスのメンバー リンクの 1 つだけにハッシュされます。これは、テストトラフィックが一方のリーフ、またはもう一方のリーフに送信されることを意味しますが、両方には送信されません。サーバー 1 で多数のフローが生成された場合、両方のメンバー インターフェイスを使用して、両方のリーフに転送されるパケットが発生することを想定しています。
ping を生成する前にカウンターをクリアします。
user@server1> clear firewall all
次に、リーフ1とリーフ2にファイアウォールカウンターを表示します。
user@leaf1> show firewall user@leaf1# run show firewall Filter: mirror-leaf-1 Counters: Name Bytes Packets from-s1 0 0
出力は、リーフ1にパケットが見られない場合を示しています。これは、このフローでは、サーバーがリーフ2にハッシュしていることを示しています。
リーフ2のファイアウォールカウンターを確認します。
user@leaf2> show firewall Filter: mirror-leaf-1 Counters: Name Bytes Packets from-s1 1020 10
リーフ2のファイアウォールカウンターは、生成されたテストトラフィックを正しく反映しています。
-
サーバー1とサーバー2の間で送信されたトラフィックが、監視ステーションに送信するためにリーフ1またはリーフ2でミラーリングされていることを確認します。
サーバー 1 とサーバー 2 の間でトラフィックが生成されます(簡潔な表示はありません)。ping コマンドの rapid オプションを使用すると、大量のパケットが生成され、検出が容易になります。
ボーダーリーフ3のインターフェイストラフィックカウンターを監視して、テストトラフィックが監視ステーションに到着することを確認します。
user@bl-leaf3> monitor interface xe-0/0/33:1 bl-leaf3 Seconds: 17 Time: 19:58:30 Delay: 1/0/1 Interface: xe-0/0/33:1, Enabled, Link is Up Encapsulation: Ethernet, Speed: 10000mbps Traffic statistics: Current delta Input bytes: 1019608 (0 bps) [0] Output bytes: 5699872 (4752824 bps) [3382190] Input packets: 10115 (0 pps) [0] Output packets: 34752 (3126 pps) [17801]
出力により、トラフィックがモニター・ステーションに送信されたことを確認します。モニター・ステーションは、受信した GRE トラフィックに対する応答を生成しないため、入力パケットの不足が予想されます。
-
Wireshark または同等のアナライザ アプリケーションを使用して、ミラーリングされたトラフィックをキャプチャしてデコードします。
図 7:ミラーリングされたトラフィックの分析キャプチャは、サーバー 1 が ping トラフィックをサーバー 2 に送信することを示しています。入力方向にのみリーフ1とリーフ2でフィルターを適用しているため、応答トラフィックはミラーリングされません。同様のポートミラーインスタンスを適用し、リーフ4でフィルター設定を行い、リターントラフィックをミラーリングします。リーンスパインの場合、ミラーリングされたトラフィックはVXLANカプセル化を示したことを思い出してください。このERBリーフの場合、VXLANにカプセル化される前にレイヤー2トラフィックをミラーリングします。トラフィックのミラーリングに使用されるフィルターは、サーバー側の ae0.0 インターフェイス上の入力フィルターとして適用されます。イングレスでのVXLANカプセル化はありません。
これは、VLAN の IRB インターフェイスにフィルターを適用する場合と同様です。IRBフィルタリングの場合、ミラーリングされたトラフィックにはVXLANカプセル化も含まれていません。IRB フィルターは、IP レイヤーで VLAN 間トラフィックのみを処理します。したがって、IRB フィルターの場合、レイヤー 3 IP トラフィックのみがミラーリングされます。
デコードでは、アンダーレイを介してリーフ2と監視ステーション間のGREトンネルが表示されます。サーバー 1 によって送信されたイーサネット フレームと IP パケットもデコードされます。サーバーに割り当てられた IP アドレスは、サーバー 1 によって生成された IP/ICMP パケットの詳細と同様に表示されます(10.1.100.x/24)。
トポロジーでポートミラーリングを正常に設定しました。
例:ESI-LAGインターフェイスでリモートアナライザインスタンスを有効にする
概要
ESI(イーサネット セグメント識別子)は、イーサネット セグメントを識別する一意の 10 バイト番号です。ESIは、サーバーに接続されたインターフェイスで有効になっています。複数のリンクがリンク アグリゲーション グループ(LAG)を形成すると、EVPN LAG(インターフェース)とも呼ばれる ESI-LAG になります。場合によっては、ESI-LAGインターフェイスに出入りするトラフィックの全部または一部に対して、ポートミラーリングを直接有効にする必要があります。
エグレスとイングレスアナライザの両方のインスタンスは、EVPN-VXLANファブリックのリーフデバイス上のESI-LAGインターフェイスでサポートされています。これは、管理者が特定のESI-LAGポートを送受信するすべてのトラフィックをリモートホストと送受信する必要があるデータセンターで有効です。このセクションを使用して、EVPN-VXLAN ERBファブリックのESI-LAGレベルでアナライザインスタンスを有効にします。
アナライザインスタンスは、アナライザが入力、出力、または両方向で動作するという点で、ポートミラーリングインスタンスとは異なります。また、インターフェイス上 のすべての トラフィックをミラーリングします。たとえば、サーバー 1 にトランク インターフェイスを使用する VLAN が 10 個ある場合、すべての 10 個の VLAN からのトラフィックが監視ステーションに送信されます。前のポートミラーリングの例では、1つのVLANまたはVLAN内の特定のIPアドレスからのトラフィックを選択的にミラーリングするためにフィルターを使用します。
アナライザ インスタンスは、きめ細かいマッチングにファイアウォール フィルターを使用しません。指定されたインターフェイス上の指定された方向のすべてのトラフィックがミラーリングされます。
トポロジ
この設定例では 、「要件」に示すハードウェアとソフトウェアのコンポーネントを使用します。トポロジーのデバイスは、「 付録: 完全なデバイス設定」で示されているように、ベースライン設定から始まります。
この例では、EVPN LAGとも呼ばれるESI-LAGが、サーバー1とリーフ1とリーフ2の間でインターフェイスを使用しています。ベストプラクティスについては 、 EVPN LAG構成のベストプラクティス をご覧ください。
22.3R1以降を実行しているACX7100スイッチJunos OS Evolvedアナライザインスタンスを設定できます。
図 8 は、この例のトポロジーを示しています。
インターフェイス ae0.0 は、サーバー 1 に接続された ESI-LAG インターフェイスです。サーバー 1 には IP アドレス 10.1.101.10/24 が割り当てられ、VLAN 101 に関連付けられています。目標は、アナライザインスタンスを設定して、リーフ1とリーフ2の両方で、ae0.0インターフェイスで送受信したすべてのトラフィックを転送することです。ミラーリングされたトラフィックは GRE トンネルに配置され、監視ステーションに送信されます。以前と同様に、EBGP アンダーレイで監視ステーションサブネットに到達可能であることを確認する必要があります。
どちらのスパインも、このトポロジーで動作しています。ECMP とは、リーフ 1 とリーフ 2 がスパイン デバイスを介してトラフィックを送信できることを意味します。ここでは、スパイン1デバイスを中心にトラフィックとミラーリングパスを示し、図面の乱雑さを軽減します。
始める前に
「付録: 完全なデバイス構成」に示すベースライン構成から開始する場合は、開始する前に以下の手順に従ってトポロジーを変更します。
-
リーフ1とリーフ2の設定を変更して、サーバー1のマルチホーム接続をサポートします。まず、既存のxe-0//0/0インターフェイスの名前を変更して、新しいe0.0インターフェイスにします。この機能は、xe-0/0/0インターフェイスからのあらゆる設定に対応し、時間を節約します。
user@leaf1# rename interfaces xe-0/0/0 to ae0 user@leaf1# set interfaces ae0 esi 00:02:02:02:02:02:02:02:00:04 user@leaf1# set interfaces ae0 esi all-active user@leaf1# set interfaces ae0 aggregated-ether-options lacp active user@leaf1# set interfaces ae0 aggregated-ether-options lacp system-id 00:00:02:02:00:04
サーバーの集合型イーサネット・インターフェース(Linux ではしばしば結合インターフェースと呼ばれる)の設定仕様は、この NCE の範囲を超えています。なお、サーバーには、標準的な集合型イーサネット構成しかありません。ESI-LAGに関連するステートメントは、リーフデバイスにのみ適用されます。
メモ:開始ベースライン設定では、 設定ステートメントを使用して集合型イーサネットデバイスを
set chassis aggregated-devices ethernet device-count 1
有効にします。集約されたデバイスのシャーシサポートを有効にする必要があります。または、集約されたインターフェイスが作成されていません。 -
これらの変更をリーフデバイスとサーバーの両方に適用してコミットした後、ae0インターフェイスが両方のリーフで稼働していることを確認します。以下の出力例は、明確にするために短縮されました。
user@leaf2> show interfaces ae0 Physical interface: ae0, Enabled, Physical link is Up Physical interface: ae0, Enabled, Physical link is Up [...] Current address: b8:c2:53:ba:8b:80, Hardware address: b8:c2:53:ba:8b:80 Ethernet segment value: 00:02:02:02:02:02:02:02:00:04, Mode: all-active Last flapped : 2022-09-07 14:57:53 UTC (01:06:43 ago) [...] Queue counters: Queued packets Transmitted packets Dropped packets 0 81129 81129 0 3 0 0 0 4 0 0 0 7 4135 4135 0 8 64 64 0 [...] Protocol eth-switch, MTU: 1514, Generation: 266, Route table: 7, Mesh Group: __all_ces__, EVPN multi-homed status: Forwarding, EVPN multi-homed ESI Split Horizon Label: 0, Next-hop: 1665, vpls-status: up Local Bias Logical Interface Name: vtep.32769, Index: 554, VXLAN Endpoint Address: 10.1.255.11 Flags: Is-Primary
サーバー 1 がサーバー 2 に ping を実行できることを確認します(簡潔にするために表示されていません)。
構成
この例では、リモートアナライザインスタンスを使用して、ESI-LAGレベルでリモートポートミラーリングを有効にする方法を示しています。
-
ae0.0インターフェイスは、テナントサーバー1が接続するESI-LAGインターフェイスです。この ESI-LAG は、リーフ 1 とリーフ 2 の両方で終端します。ae0.0インターフェイスの両方のリーフでアナライザインスタンスを設定します。入力方向と出力方向の両方にリモート アナライザを設定する点に注意してください。
[edit forwarding-options analyzer my-analyzer1] user@leaf1# set input ingress interface ae0.0 user@leaf1# set input egress interface ae0.0 user@leaf1# set output ip-address 172.16.1.2
-
境界リーフ3は、GREトンネルが監視ステーションで終端するため、GREカプセル化解除を実行するように設定する必要はありません。ただし、リーフ3は、監視ステーションのサブネットの到達可能性をファブリックのアンダーレイにアドバタイズする必要があります。
監視ステーションに接続する xe-0/0/33:1 インターフェイスを設定します。
user@bl-leaf3# set interfaces xe-0/0/33:1 unit 0 family inet address 172.16.1.1/24
境界リーフ3のアンダーレイエクスポートポリシーを変更して、監視ステーションのプレフィックスをアドバタイズします。ジュニパーのトポロジーでは、EBGPアンダーレイを使用しています。既存のアンダーレイエクスポートポリシーに新しい条件を追加するだけです
[edit policy-options policy-statement send-direct] user@bl-leaf3# set term 2 from protocol direct user@bl-leaf3# set pterm 2 from route-filter 172.16.1.0/24 exact user@bl-leaf3# set term 2 then accept
-
開始ベースラインからの変更はリーフ1に表示されます。
user@leaf1# show | compare base [edit interfaces xe-0/0/0] + gigether-options { + 802.3ad ae0; + } [edit interfaces xe-0/0/0] - unit 0 { - family ethernet-switching { - vlan { - members v101; - } - } - } [edit interfaces] + ae0 { + esi { + 00:02:02:02:02:02:02:02:00:04; + all-active; + } + aggregated-ether-options { + lacp { + active; + system-id 00:00:02:02:00:04; + } + } + unit 0 { + family ethernet-switching { + interface-mode access; + vlan { + members v101; + } + } + } + } [edit] + forwarding-options { + analyzer { + my-analyzer1 { + input { + ingress { + interface ae0.0; + } + egress { + interface ae0.0; + } + } + output { + ip-address 172.16.1.2; + } + } + } + }
EVPN-VXLAN ERBファブリック上のリーフデバイスを介してリモートポートミラーリングを正常に設定しました。
検証
-
リーフ1とリーフ2からモニターステーションへのアンダーレイ接続を検証します。
リーフ1で、172.16.1.0/24へのルートを表示します。
user@leaf1> show route 172.16.1.0/24 inet.0: 12 destinations, 13 routes (12 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.1.0/24 *[BGP/170] 4d 00:56:23, localpref 100 AS path: 65001 65013 I, validation-state: unverified > to 10.1.11.1 via et-0/0/48.0
メモ:厳密に言えば、リーフと監視ステーション間の接続はシンプルな接続のみが必要です。監視ステーションに静的ルートを設定し、ファブリックアンダーレイに到達できるようにしました。これにより、障害分離ツールとしての ping テストが可能になります。
監視ステーションに Ping を実行して接続を確認します。
user@leaf1> ping 172.16.1.2 count 2 source 10.1.255.11 PING 172.16.1.2 (172.16.1.2): 56 data bytes 64 bytes from 172.16.1.2: icmp_seq=0 ttl=62 time=1.380 ms 64 bytes from 172.16.1.2: icmp_seq=1 ttl=62 time=7.614 ms --- 172.16.1.2 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.380/4.497/7.614/3.117 ms
この出力により、リーフ1から監視ステーションへの予想されるアンダーレイ到達可能性が確認されます。アンダーレイエクスポートポリシーはループバックアドレスの到達可能性のみをアドバタイズするため、リーフのループバックアドレスからpingを送信する必要があります。スパインとボーダーリーフは共有ファブリックリンクサブネットを介して直接接続されているため、ループバックアドレスからのソーシングはリーンスパインの例では必要ありませんでした。
-
リーフ1とリーフ2のアナライザインスタンスを確認します。
リーフ1で、リモートアナライザの状態が
up
.user@leaf1> show forwarding-options analyzer Analyzer name : my-analyzer1 Mirror rate : 1 Maximum packet length : 0 State : up Ingress monitored interfaces : ae0.0 Egress monitored interfaces : ae0.0 Destination IP : 172.16.1.2
出力は、アナライザ インスタンスの正しい定義を確認します。の
up
状態は、リーフに監視ステーションへのアンダーレイ ルートがあることを示しています。GRE がステートレス プロトコルであることを思い出してください。そのため、前のステップで行ったように、リーフと監視ステーション間の接続性を検証することをお勧めします。 -
サーバー1とサーバー2の間で送信されたトラフィックが、リーフ1および/またはリーフ2によって監視ステーションにミラーリングされていることを確認します。
サーバー 1 とサーバー 2 の間でトラフィックが生成されます(簡潔な表示はありません)。ping コマンドの rapid オプションを使用して大量のパケットを生成し、検出を容易にしました。
ボーダーリーフ3のインターフェイストラフィックカウンターを監視して、テストトラフィックが監視ステーションに到着することを確認します。
user@bl-leaf3> monitor interface xe-0/0/33:1 bl-leaf3 Seconds: 17 Time: 19:58:30 Delay: 1/0/1 Interface: xe-0/0/33:1, Enabled, Link is Up Encapsulation: Ethernet, Speed: 10000mbps Traffic statistics: Current delta Input bytes: 1019608 (0 bps) [0] Output bytes: 5699872 (4752824 bps) [3382190] Input packets: 10115 (0 pps) [0] Output packets: 34752 (3126 pps) [17801]
出力により、トラフィックが監視ステーションに到着したことを確認します。モニター・ステーションは受信した GRE トラフィックに対する応答を生成しないため、入力パケットの不足が予想されます。
-
Wireshark または同等のアナライザ アプリケーションを使用して、ミラーリングされたトラフィックをキャプチャしてデコードします。
図 9:ミラーリングされたトラフィックの分析キャプチャは、サーバー 1 が ping トラフィックをサーバー 2 に送信することを示しています。アナライザインスタンスが ae0.0 インターフェイスの両方向に適用されているため、応答トラフィックもミラーリングされます。アナライザはインターフェイス レベルで動作するため、集約されたイーサネット インターフェイスで使用されるリンク レベルのプロトコルである LACP もミラーリングされます。リーンスパインの場合、ミラーリングされたトラフィックはVXLANカプセル化を示したことを思い出してください。このERBリーフの場合 VXLANにカプセル化される前にレイヤー2トラフィックをキャプチャしますイングレスでは、VXLANカプセル化はありません。
これは、VLAN の IRB インターフェイスにフィルターを適用する場合と同様です。この場合、ミラーリングされたトラフィックにはVXLANカプセル化も含まれていません。IRB ベースのフィルターは、IP レイヤーで VLAN 間トラフィックのみをキャッチします。したがって、IRB フィルターの場合、非 VXLAN カプセル化されたレイヤー 3 IP トラフィックのみがミラーリングされます。
デコードでは、GREトンネルがアンダーレイを通ってリーフ2(10.1.12.2)と監視ステーションの間であることを示しています。サーバー1によって送信されたイーサネットフレームと関連するIPパケットもデコードされます。サーバーに割り当てられた IP アドレスは、サーバー 1 によって生成された IP/ICMP パケットの詳細と同様に表示されます(10.1.100.x/24)。この例では、アナライザインスタンスが双方向に適用されるため、サーバー2からの応答もミラーリングされます。
トポロジーでポートミラーリングを正常に設定しました。