🧘🏽 🤸🏿 🎎 Juniper MXのトラフィックミラーリング 👏🏾 🛣️ 🌪️

今日は、ジュニパーMXシリーズルーターでのトラフィックミラーリングについて説明します。 Cisco、Huawei、またはAristaによる切り替えの後、JunOSでのSPANおよびRSPANの構成は非常に複雑に見えますが、複雑な（一見）構成は、トラフィックミラーリングの分野でMXプラットフォームの巨大な機能を隠します。ジュニパーのアプローチは一見複雑ですが、設定をあるボックスから別のボックスにコピーアンドペーストせずに、何が行われているのか、そしてその理由を理解すれば、シンプルで理解しやすくなります。 JunOSのイデオロギーでは、ミラーリングの目的でフィルターベースの転送（FBF）を使用することを推奨しています。これにより、複雑なトラフィックミラーリングスキームの実装に柔軟性がもたらされます。

それでは始めましょう。ミラーリングの例をいくつか見ていきます。

1.ローカルポート間ミラーリング

2.複数のコンシューマーへのミラーリング

3.リモートホストへのミラーリング

4.複数のコンシューマーの選択的ミラーリング

5. L2トラフィックのローカルミラーリング

6. L2トラフィックをリモートサーバーにミラーリングする

7. 1つのFPCで3つ以上のミラーリングインスタンスを使用する

それでは、順番に始めましょう。

ポートからポートへのローカルミラーリング。

テストベンチは常に変化します-消費者を追加し、受信したトラフィックのコピーに応じて希望を変更します。最初の段階では、テストベンチは次のようになります。

注：最初はトラフィックジェネレーターを使用したかったのですが、トラフィックアナライザーでキャプチャされたhping3 tcp / udp / icmpによって生成されたパケット（アナライザーはボード上のubuntuサーバー14.04を持つホストのみを使用したため）は、ポートからのカウンターよりも視覚的であると判断しましたpps（たとえば、送信データと受信データの関連性を比較できます）。この機能を使用する場合は、負荷テスト中にカウンターを使用して、ルーターのパフォーマンスを確認する必要があります。ただし、仮想MXでは、パフォーマンスをチェックしても意味がありません。すべて同じように、すべてが仮想化サーバーの機能に依存します。

Server-1（11.0.0.1）とServer-2（12.0.0.1）の間に何らかのトラフィック交換があるとします。 Analyzer-1サーバーの所有者は、これら2つのサーバー間で正確に転送される内容を確認するため、Server-1とServer-2間のすべてのトラフィックのコピーをAnalyzer-1に送信するように構成する必要があります。つまり、ローカルミラーリングを行います。それでは始めましょう。

理論的には、これは次のように機能します。着信トラフィックのパラメーター（トラフィックをミラーリングする頻度）とトラフィックをポイズニングするポートまたは発信ポートを指定するミラーリングインスタンスを作成します。作成したインスタンスにトラフィックを誘導するには、トラフィックのコピーを削除するインターフェイスを使用し、必要なインスタンスでトラフィックをラップする特別なフィルターを切る必要があります。つまり、これは、ジュニパーの観点から見ると、古典的なポリシーベースルーティングスキーム、またはフィルターベースルーティングです。理論を理解したので、今すぐ練習しましょう。このようなミラーリングスキームを組み立てる必要があります。

最初に、[転送オプションのポートミラーリングの編集]階層にインスタンスを作成する必要があります。これを使用して、トラフィックをミラーリングします。

[edit forwarding-options port-mirroring] bormoglotx@RZN-PE-1# show instance { SPAN-1 { input { rate 1; run-length 0; } family inet { output { interface ge-0/0/1.0 { next-hop 169.254.0.1; } } } }

インスタンス構成は2つの部分で構成されます。最初に入力セクションを扱います-ご想像のとおり、これらは着信トラフィックのパラメーターであり、ミラーリングする必要があります。ここでは、速度とランレングスのパラメーターが重要です。最初のパラメーターは、パケットがミラーリングされる頻度（トリガーがトリガーされる）を担当し、2番目のパラメーターは、レートトリガーがトリガーされた後もミラーリングされるパケット数を担当します。

この場合、レートは1に設定されます。つまり、各パケットがミラーリングされます。ランレングスは0に設定されます。これは、レートが1の場合、その存在は何の役割も果たさないからです。

完全を期すために、これらのパラメーターの意味をより具体的な例で分析します。レートパラメーターはトラフィックミラーリングの頻度を設定します。レートが5であると仮定します。つまり、トリガーは5番目のパケットごとに起動します。つまり、5番目のパケットごとにミラーリングされます。ここで、ランレングスが4に設定されているとします。これは、5番目のパケットごとにさらに4つのパケットがミラーリングされることを示しています。つまり、5番目のパケットのトリガーが最初に機能しました。このパケットはミラーリングされ、すでにミラーリングされたパケットに続く4つのパケットもミラーリングされます。その結果、5番目のパケットごとにミラーリングされ、さらに4つのパケットが続くことになります-合計100％のトラフィック。これらのパラメーターを変更することにより、たとえば、100パケットのうち10パケットごとにミラーリングすることができます（これは、ミラーリングよりもサンプリングに必要です。動作原理は同じです）。

ケースに戻ると、各パッケージを既にミラーリングしているため、単にrun-lengthパラメーターを必要とせず、デフォルト値のゼロのままにします。

ミラーリングされたトラフィックの割合を計算するには、式％=（（run-length + 1）/ rate）* 100）を使用できます。ランレングス1およびレート1のパラメーターを使用すると、トラフィックの200％のミラーリングを取得できます。たとえば、レート1およびランレングス4-500％のトラフィックを取得できます。私はあなたを悲しませたり、喜んでいます-トラフィックの100％以上はミラーリングされません-ジュニパーネットワークスは論理的な以上のパケットを増加させません。そして、同じトラフィックのコピーを2つ作成する必要がある場合、シナリオを思い付くことができませんでした（誰かが知っているなら、コメントを書いてください）。

もう1つの重要なパラメーターは、maximum-packet-lengthです。これは、ミラーリングされる最大パケットサイズです。たとえば、128に設定した場合、128バイト（たとえば、1514）を超えるパケットを受信すると、最初の128バイトがカットされてコンシューマーに送信されます。パケットの残りは単に破棄されます。これは、ヘッダーのみをサーバーに送信する必要があり、ペイロードが不要な場合に便利です。 ipv4に20未満を設定することは推奨されません。

それでは、出力パラメーターに移りましょう。ここで、一般的なケースでは、トラフィックをミラーリングするインターフェイスを指定する必要があります。 p2pインターフェースだけがある場合、他に何も指定する必要はありません-すべてが飛ぶでしょう。しかし、私たち全員が覚えているように、イーサネットはp2pから遠く（正確にはcsma / cdです）、インターフェイスに加えて、トラフィックが目的とするホストアドレス（IPとMACの両方）を指定する必要があります（ただし、後で説明します））既存のアドレスとの交差を回避するために、リンクローカルアドレス範囲からアドレスを選択しました-任意のアドレス指定を行うことができますが、これはテクノロジーの動作方法をまったく変更しません。イーサネットでは、あるホストにパケットを送信するために、ルーターはARPを使用してこのホストのMACアドレスを見つける必要があります。私の場合、宛先サーバーの側には何も設定されていません-ただの空のインターフェースであり、ルーターは無駄にリモートホストのアドレスを解決しようとします。当然、すべてのミラーリングはそこで終了します。この状況になるには？独創的なものはすべてシンプルです-静的ARPレコードが作成されます。

 bormoglotx@RZN-PE-1# show interfaces ge-0/0/1 description Analyzer-1; unit 0 { family inet { address 169.254.0.0/31 { arp 169.254.0.1 mac 02:00:00:00:00:01; } } }

その結果、インターフェイスにそのようなエントリができます。

 [edit] bormoglotx@RZN-PE-1# run show arp interface ge-0/0/1.0 MAC Address Address Name Interface Flags 02:00:00:00:00:01 169.254.0.1 169.254.0.1 ge-0/0/1.0 permanent

ここで、私はもっと詳しく説明したいと思います。理論的には、サーバーに設定された実際のアドレスにトラフィックを送信できますが、最も単純で最も柔軟なアプローチは、架空のIPアドレスとARPエントリをトラフィックのコンシューマ側に作成することです。 IP / MACアドレスは、最終的にボックスに愚かなトラフィックを送信させますが、理解せずに、実際に指定されたホストがあるかどうか-主なことはポートがアップしていることです。ミラーリングで静的ARP記録を使用することには大きな利点があります-静的ARP記録は期限切れにならず、ルーターはARPサーバーに要求を送信しません（削除されるトラフィックのダンプに陥る可能性があり、あまり良くありません）。

ここで、トラフィックをミラーリングするために、作成したインスタンスに何らかの形でラップする必要があります。これを行うには、フィルターベース転送を使用します。フィルターを作成し、興味のあるインターフェイスに適用します：

 [edit] bormoglotx@RZN-PE-1# show firewall family inet filter MIRROR>>>SPAN-1 term MIRROR { then port-mirror-instance SPAN-1; } [edit] bormoglotx@RZN-PE-1# show interfaces ge-0/0/3 description Server-1; unit 0 { family inet { filter { input MIRROR>>>SPAN-1; output MIRROR>>>SPAN-1; } address 11.0.0.254/24; } }

着信トラフィックと発信トラフィックの両方を収集する必要があるため、両方向にフィルターを掛けます。

実践が示すように、このフィルターはサーバー自体の間のトラフィックの通過をブロックしません。そのため、受け入れアクションを記述する必要はありませんが、多くの場合、それらを保護するために追加されます。

これで、ミラーリングセッションの状態を確認できます。

 bormoglotx@RZN-PE-1> show forwarding-options port-mirroring Instance Name: SPAN-1 Instance Id: 2 Input parameters: Rate : 1 Run-length : 0 Maximum-packet-length : 0 Output parameters: Family State Destination Next-hop inet up ge-0/0/1.0 169.254.0.1

どうやら職場でミラーリング。 Server-1からServer-2に5つのパッケージを実行して、Analyzer-1アナライザーで何をキャッチできるかを見てみましょう。

 bormoglotx@Server-1:~$ sudo hping3 -S -c 5 12.0.0.1 -d 40 -I eth1 HPING 12.0.0.1 (eth1 12.0.0.1): S set, 40 headers + 40 data bytes len=40 ip=12.0.0.1 ttl=63 DF id=34108 sport=0 flags=RA seq=0 win=0 rtt=3.4 ms len=40 ip=12.0.0.1 ttl=63 DF id=34121 sport=0 flags=RA seq=1 win=0 rtt=3.5 ms len=40 ip=12.0.0.1 ttl=63 DF id=34229 sport=0 flags=RA seq=2 win=0 rtt=3.5 ms len=40 ip=12.0.0.1 ttl=63 DF id=34471 sport=0 flags=RA seq=3 win=0 rtt=3.5 ms len=40 ip=12.0.0.1 ttl=63 DF id=34635 sport=0 flags=RA seq=4 win=0 rtt=3.5 ms --- 12.0.0.1 hping statistic --- 5 packets transmitted, 5 packets received, 0% packet loss

次に、サーバーAnalyzer-1でダンプできるものを見てみましょう。

 bormoglotx@Analyzer-1:~$ sudo tcpdump -i eth1 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes ^C 0 packets captured 0 packets received by filter 0 packets dropped by kernel

すべてがそれほどバラ色ではありません。結論は、ジュニパーネットワークスが上記の結論で私たちにすべてが大丈夫だと報告したが、実際には何も私たちにとってうまくいかないことを示しています。実際には、自分自身をミラーリングするためのインスタンスを作成することができます（これを行いました）か、デフォルトのインスタンスを使用します（ボックス全体用です）。インスタンスを自分で作成する場合、ミラーリングを行うFPCにこのインスタンスを関連付ける必要があります（ポートが複数のFPCにある場合、複数のFPCに関連付けることを意味します）。 Juniperに戻り、FPC構成で作成したインスタンスを示しましょう。なぜこれに焦点を合わせたのですか？事実、彼自身がこの問題に何度か遭遇し、キャッチが何であるかを理解できませんでした-結局のところ、結論はすべてがうまくいっていると言います。

 [edit] bormoglotx@RZN-PE-1# show | compare [edit] + chassis { + fpc 0 { + port-mirror-instance SPAN-1; + } + }

次に、ミラーが機能するかどうかをもう一度確認します。

 bormoglotx@Server-1:~$ sudo hping3 -S -c 5 12.0.0.1 -d 40 -I eth1 HPING 12.0.0.1 (eth1 12.0.0.1): S set, 40 headers + 40 data bytes len=40 ip=12.0.0.1 ttl=63 DF id=43901 sport=0 flags=RA seq=0 win=0 rtt=4.4 ms len=40 ip=12.0.0.1 ttl=63 DF id=44117 sport=0 flags=RA seq=1 win=0 rtt=3.4 ms len=40 ip=12.0.0.1 ttl=63 DF id=44217 sport=0 flags=RA seq=2 win=0 rtt=3.4 ms len=40 ip=12.0.0.1 ttl=63 DF id=44412 sport=0 flags=RA seq=3 win=0 rtt=3.7 ms len=40 ip=12.0.0.1 ttl=63 DF id=44416 sport=0 flags=RA seq=4 win=0 rtt=3.5 ms --- 12.0.0.1 hping statistic --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 3.4/3.7/4.4 ms

 bormoglotx@Analyzer-1:~$ sudo tcpdump -i eth1 -B 4096 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes 14:48:43.641475 IP 11.0.0.1.2237 > 12.0.0.1.0: Flags [S], seq 1075183755:1075183795, win 512, length 40 14:48:43.642024 IP 12.0.0.1.0 > 11.0.0.1.2237: Flags [R.], seq 0, ack 1075183796, win 0, length 0 14:48:44.641981 IP 11.0.0.1.2238 > 12.0.0.1.0: Flags [S], seq 1410214066:1410214106, win 512, length 40 14:48:44.642818 IP 12.0.0.1.0 > 11.0.0.1.2238: Flags [R.], seq 0, ack 1410214107, win 0, length 0 14:48:45.642022 IP 11.0.0.1.2239 > 12.0.0.1.0: Flags [S], seq 1858880488:1858880528, win 512, length 40 14:48:45.642873 IP 12.0.0.1.0 > 11.0.0.1.2239: Flags [R.], seq 0, ack 1858880529, win 0, length 0 14:48:46.642127 IP 11.0.0.1.2240 > 12.0.0.1.0: Flags [S], seq 1472273281:1472273321, win 512, length 40 14:48:46.642947 IP 12.0.0.1.0 > 11.0.0.1.2240: Flags [R.], seq 0, ack 1472273322, win 0, length 0 14:48:47.642017 IP 11.0.0.1.2241 > 12.0.0.1.0: Flags [S], seq 1810623498:1810623538, win 512, length 40 14:48:47.642601 IP 12.0.0.1.0 > 11.0.0.1.2241: Flags [R.], seq 0, ack 1810623539, win 0, length 0 ^C 10 packets captured 10 packets received by filter 0 packets dropped by kernel

その結果、サーバー1とサーバー2の間のトラフィック交換全体がアナライザーに落ちました。

次に、スキームが変更され、アナライザー2が追加されました。アナライザー2では、サーバー1とサーバー2の間のすべてのトラフィックを受信することもできます。

複数の消費者へのミラーリング

その結果、別のタスクがあります。次のような新しいミラーリングスキームを実装する必要があります。

複雑なことはないようです。Analyzer-2の方向にインターフェイスを作成し、インスタンスと帽子に追加します。

 [edit] bormoglotx@RZN-PE-1# show interfaces ge-0/0/2 description Analyzer-2; unit 0 { family inet { address 169.254.0.2/31 { arp 169.254.0.3 mac 02:00:00:00:00:01; } } } [edit] bormoglotx@RZN-PE-1# show forwarding-options port-mirroring instance SPAN-1 input { rate 1; run-length 0; } family inet { output { interface ge-0/0/1.0 { next-hop 169.254.0.1; } interface ge-0/0/2.0 { next-hop 169.254.0.3; } } }

しかし、ミラーリングインスタンスの出力階層に別のポートを追加しようとすると、コミット時にエラーが発生します。

 [edit] bormoglotx@RZN-PE-1# commit check [edit forwarding-options port-mirroring instance SPAN-1 family inet output] Port-mirroring configuration error Port-mirroring out of multiple nexthops is not allowed on this platform error: configuration check-out failed

一見したところひどいフレーズ-プラットフォームの制限により、ミラー化されたトラフィックに対する2つの次の希望を一度に設定することができません。しかし、ネクストホップグループを使用する場合、この制限は非常に簡単です。

ネクストホップグループが何であるかはすでに明確になっていると思います。名前はそれを表しています。 Juniper MXは最大30のネクストホップグループをサポートし、各グループは最大16のネクストホップグループを持つことができます。ただし、これに加えて、各ネクストホップグループで、ネクストホップサブグループを作成できます。 1つのネクストホップグループには、少なくとも2つのネクストホップが必要です。そうでない場合、JunOSはコミットを許可しません。

次に、構成に移り、次ホップグループを作成します。

 [edit] bormoglotx@RZN-PE-1# show forwarding-options next-hop-group Analyzer-servers group-type inet; interface ge-0/0/1.0 { next-hop 169.254.0.1; } interface ge-0/0/2.0 { next-hop 169.254.0.3; }

そして、このグループを出力のネクストホップとして示します。

 [edit] bormoglotx@RZN-PE-1# show forwarding-options port-mirroring instance SPAN-1 input { rate 1; run-length 0; } family inet { output { next-hop-group Analyzer-servers; } }

残りの構成は変更されません。

検証に進みます。最初に、ネクストホップグループの状態を確認します。

 bormoglotx@RZN-PE-1> show forwarding-options next-hop-group detail Next-hop-group: Analyzer-servers Type: inet State: up Number of members configured : 2 Number of members that are up : 2 Number of subgroups configured : 0 Number of subgroups that are up : 0 Members Interfaces: State ge-0/0/1.0 next-hop 169.254.0.1 up ge-0/0/2.0 next-hop 169.254.0.3 up

すべてがグループで正常に動作しています-動作しています（少なくとも1つのインターフェイスがアップしている場合、グループはアップになります）。次に、ミラーリングセッションの状態を確認します。

 bormoglotx@RZN-PE-1> show forwarding-options port-mirroring SPAN-1 Instance Name: SPAN-1 Instance Id: 2 Input parameters: Rate : 1 Run-length : 0 Maximum-packet-length : 0 Output parameters: Family State Destination Next-hop inet up Analyzer-servers

すべて順調ですが、前に見たように、これはすべてを正しく行い、すべてがうまくいくという意味ではありません。したがって、2つのサーバーへのトラフィックがミラーリングされるかどうかを確認します。

 bormoglotx@Server-1:~$ sudo hping3 -S -c 5 12.0.0.1 -d 40 -I eth1 HPING 12.0.0.1 (eth1 12.0.0.1): S set, 40 headers + 40 data bytes len=40 ip=12.0.0.1 ttl=63 DF id=64150 sport=0 flags=RA seq=0 win=0 rtt=3.4 ms len=40 ip=12.0.0.1 ttl=63 DF id=64222 sport=0 flags=RA seq=1 win=0 rtt=3.5 ms len=40 ip=12.0.0.1 ttl=63 DF id=64457 sport=0 flags=RA seq=2 win=0 rtt=3.7 ms len=40 ip=12.0.0.1 ttl=63 DF id=64593 sport=0 flags=RA seq=3 win=0 rtt=3.5 ms len=40 ip=12.0.0.1 ttl=63 DF id=64801 sport=0 flags=RA seq=4 win=0 rtt=3.4 ms --- 12.0.0.1 hping statistic --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 3.4/3.5/3.7 ms

Analyzer-1のトラフィック：

 bormoglotx@Analyzer-1:~$ sudo tcpdump -i eth1 -B 4096 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes 15:09:36.837983 IP 11.0.0.1.2304 > 12.0.0.1.0: Flags [S], seq 1255230673:1255230713, win 512, length 40 15:09:36.839367 IP 12.0.0.1.0 > 11.0.0.1.2304: Flags [R.], seq 0, ack 1255230714, win 0, length 0 15:09:37.838115 IP 11.0.0.1.2305 > 12.0.0.1.0: Flags [S], seq 2135769685:2135769725, win 512, length 40 15:09:37.839054 IP 12.0.0.1.0 > 11.0.0.1.2305: Flags [R.], seq 0, ack 2135769726, win 0, length 0 15:09:38.838528 IP 11.0.0.1.2306 > 12.0.0.1.0: Flags [S], seq 1139555126:1139555166, win 512, length 40 15:09:38.839369 IP 12.0.0.1.0 > 11.0.0.1.2306: Flags [R.], seq 0, ack 1139555167, win 0, length 0 15:09:39.838328 IP 11.0.0.1.2307 > 12.0.0.1.0: Flags [S], seq 1181209811:1181209851, win 512, length 40 15:09:39.838924 IP 12.0.0.1.0 > 11.0.0.1.2307: Flags [R.], seq 0, ack 1181209852, win 0, length 0 15:09:40.838335 IP 11.0.0.1.2308 > 12.0.0.1.0: Flags [S], seq 1554756347:1554756387, win 512, length 40 15:09:40.838901 IP 12.0.0.1.0 > 11.0.0.1.2308: Flags [R.], seq 0, ack 1554756388, win 0, length 0 ^C 10 packets captured 10 packets received by filter 0 packets dropped by kernel

また、Analyzer-2のトラフィックの同様のコピー：

 bormoglotx@Analyzer-2:~$ sudo tcpdump -i eth1 -B 4096 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes 15:09:35.125093 IP 11.0.0.1.2304 > 12.0.0.1.0: Flags [S], seq 1255230673:1255230713, win 512, length 40 15:09:35.126394 IP 12.0.0.1.0 > 11.0.0.1.2304: Flags [R.], seq 0, ack 1255230714, win 0, length 0 15:09:36.125044 IP 11.0.0.1.2305 > 12.0.0.1.0: Flags [S], seq 2135769685:2135769725, win 512, length 40 15:09:36.126107 IP 12.0.0.1.0 > 11.0.0.1.2305: Flags [R.], seq 0, ack 2135769726, win 0, length 0 15:09:37.125552 IP 11.0.0.1.2306 > 12.0.0.1.0: Flags [S], seq 1139555126:1139555166, win 512, length 40 15:09:37.126418 IP 12.0.0.1.0 > 11.0.0.1.2306: Flags [R.], seq 0, ack 1139555167, win 0, length 0 15:09:38.125374 IP 11.0.0.1.2307 > 12.0.0.1.0: Flags [S], seq 1181209811:1181209851, win 512, length 40 15:09:38.125930 IP 12.0.0.1.0 > 11.0.0.1.2307: Flags [R.], seq 0, ack 1181209852, win 0, length 0 15:09:39.125320 IP 11.0.0.1.2308 > 12.0.0.1.0: Flags [S], seq 1554756347:1554756387, win 512, length 40 15:09:39.125844 IP 12.0.0.1.0 > 11.0.0.1.2308: Flags [R.], seq 0, ack 1554756388, win 0, length 0 ^C 10 packets captured 10 packets received by filter 0 packets dropped by kernel

すばらしい-タスクは完了し、トラフィックは必要な場所に流れます-両方の消費者は、要求されたトラフィックのコピーを受け取ります。

しかし、ネットワークは途方もないペースで発展しており、当社はゼカリゼーションとSORMにお金をspareしみません。これで、別のサーバー、Analyzer-3ができました。これもトラフィックのコピーを受信する必要があります。しかし、問題は、このサーバーがRZN-PE-1にローカルではなく、RZN-PE-2に接続されていることです。

リモートホストミラーリング

上記のすべての観点から、ミラーリングスキームを再度やり直す必要があります。これは次のようになります。

Analyzer-3サーバーはRZN-PE-2の背後にあるため、この問題を解決するために以前に使用した方法は機能しません。主な問題は、トラフィックをミラーリングする方法ではなく、この既にミラーリングされたトラフィックをRZN-PE-2の背後にあるAnalyzer-3サーバーにドラッグし、ネットワークに対して透過的にする方法です。後で参照）。これを行うには、ジュニパーの機器でgreトンネルを使用するのが一般的です。これは、リモートホストへのトンネルを作成し、ミラー化されたすべてのトラフィックをこのトンネルにまとめて、サーバーまたは宛先サーバーを終端するルーターに直接送信するという考え方です。 greトンネルを使用するには2つのオプションがあります。

オプション1 ミラーリングを実行するルーターで、greトンネルが構成され、トラフィックを受信するサーバーの宛先アドレスが宛先として指定されます。当然、このサーバーが配置されているネットワーク（この場合はAnalyzer-3）は、何らかのルーティングプロトコル（BGPまたはIGP-重要ではありません）を介して認識されている必要があります。問題は、このようなシナリオでは、サーバーへのトラフィックがgreヘッダーとともに注がれることです。最新のトラフィック分析および監視システムでは、これは問題になりません。greはIPSecではなく、トラフィックは暗号化されません。つまり、スケールの片側、実装の容易さ、もう1つ-追加の見出しです。おそらく、いくつかのシナリオでは、余分なヘッダーの存在は受け入れられないため、オプション2を使用する必要があります。

オプション2 ミラーリングを実行するルーターと、トラフィックを受信するサーバーを終了するルーターの間で、greトンネルが上昇します（通常、これはループバックで行われます）。ソースからのミラーリングを実行するルーター側では、すべてがオプション1と同じですが、受信側では、greトンネルから受信したトラフィックをアナライザーにミラーリングするルーターのインスタンスを構成する必要があります。つまり、1つのミラーについて、ソースでミラーリングの1つのインスタンスを使用し、トラフィックの受信者で2つ目のインスタンスを使用する必要があることがわかります。これにより、スキームが大幅に複雑になります。しかし一方で、このシナリオでは、純粋なトラフィックが余分なgreヘッダーなしでサーバーに流れます。さらに、このスキームを実装するときは、厳密に遵守する必要があるルールがあります-トンネルエンドポイントgreを終了するルーターには、ミラートラフィックの受信者（つまり、元のミラーパケットの受信者）として示されるホストへのルートがありません。この条件が満たされない場合、重複パケットを受信します。トラフィックはgreトンネルから飛び出し、指定したポートにミラーリングされることに加えて、通常のipパケットのようにルーティングされます。そして、ルーターが宛先ホストへのルートを知っている場合、トラフィックはそこに送信されます。これを回避するには、greインターフェイスを仮想ルータータイプの別のインスタンスに浸漬する必要がありますが、以下で説明する他の方法もあります。誰かが興味を持っている場合、構成、問題の本質、およびネタバレの下でそれを打ち負かす方法：

gre問題によるミラーリング

ソースのサーバー側のgreトンネルの構成：

 bormoglotx@RZN-PE-1# show interfaces gr-0/0/0 description RSPAN; unit 0 { tunnel { source 62.0.0.1; destination 62.0.0.2; } family inet { address 169.254.100.1/31; } }

トンネルの宛先アドレスのみが変更されました-RZN-PE-2ループバックになりました。

RZN-PE-2では、最初にRZN-PE-1へのgreトンネルを作成する必要があります。

 bormoglotx@RZN-PE-2> show configuration interfaces gr-0/0/0 description SPAN; unit 0 { tunnel { source 62.0.0.2; destination 62.0.0.1; } family inet { filter { input MIRROR-RSPAN-GE0/0/1; } } }

このインターフェイスからミラーリングインスタンスにトラフィックを送信するには、次のようにフィルターをかける必要があります。

 bormoglotx@RZN-PE-2> show configuration firewall family inet filter MIRROR-RSPAN-GE0/0/1 term MIRROR { then port-mirror-instance RSAPN; }

最後に、インスタンス自体を作成し、それをfpcにバインドして、トラフィックが送信されるインターフェイスを作成します。

 bormoglotx@RZN-PE-2> show configuration forwarding-options port-mirroring instance RSAPN input { rate 1; } family inet { output { interface ge-0/0/1.0 { next-hop 169.254.100.1; } } } bormoglotx@RZN-PE-2> show configuration chassis fpc 0 { pic 0 { tunnel-services { bandwidth 10g; } } port-mirror-instance RSAPN; } bormoglotx@RZN-PE-2> show configuration interfaces ge-0/0/1 description Analyzer-3; unit 0 { family inet { address 169.254.100.0/31 { arp 169.254.100.1 mac 02:00:00:19:21:68; } } }

Server-1とServer-2の間でpingを実行し、ミラーリングされていることを確認します。

 bormoglotx@Server-1:~$ ping 12.0.0.1 -I eth1 PING 12.0.0.1 (12.0.0.1) from 11.0.0.1 eth1: 56(84) bytes of data. 64 bytes from 12.0.0.1: icmp_seq=1 ttl=63 time=1.44 ms 64 bytes from 12.0.0.1: icmp_seq=1 ttl=60 time=3.24 ms (DUP!) … ... 64 bytes from 12.0.0.1: icmp_seq=1 ttl=3 time=34.7 ms (DUP!) ^C --- 12.0.0.1 ping statistics --- 1 packets transmitted, 1 received, +41 duplicates, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1.444/17.916/34.712/9.126 ms

出力から重複の一部を削除しましたが、重複の数を確認できます-1つの有効なパッケージと41のテイク。トラフィックアナライザーでは、同じ画像が自然に表示されます。

 bormoglotx@Analyzer-3:~$ sudo tcpdump -i eth1 -B 9192 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes 11:52:13.275451 IP 11.0.0.1 > 12.0.0.1: ICMP echo request, id 1601, seq 1, length 64 11:52:13.275462 IP 12.0.0.1 > 11.0.0.1: ICMP echo reply, id 1601, seq 1, length 64 11:52:13.276703 IP 12.0.0.1 > 11.0.0.1: ICMP echo reply, id 1601, seq 1, length 64 … …

ミラーリングに加えて、ルーターは、宛先アドレスへのルートを知っているため、greトンネルから受信したパケットも転送します。これを修正するには、仮想ルータータイプでインスタンスを作成し、greインターフェイスとトラフィックをミラーリングするインターフェイスを追加します。

 [edit] bormoglotx@RZN-PE-2# show routing-instances RSPAN-VR description "for RSPAN use only"; instance-type virtual-router; interface gr-0/0/0.0; interface ge-0/0/1.0;

pingを再度実行し、回線の動作を確認します。複製サーバーは表示されなくなりました。

 bormoglotx@Server-1:~$ ping 12.0.0.1 -I eth1 PING 12.0.0.1 (12.0.0.1) from 11.0.0.1 eth1: 56(84) bytes of data. 64 bytes from 12.0.0.1: icmp_seq=1 ttl=63 time=2.56 ms 64 bytes from 12.0.0.1: icmp_seq=2 ttl=63 time=8.13 ms 64 bytes from 12.0.0.1: icmp_seq=3 ttl=63 time=1.33 ms 64 bytes from 12.0.0.1: icmp_seq=4 ttl=63 time=2.09 ms 64 bytes from 12.0.0.1: icmp_seq=5 ttl=63 time=2.30 ms ^C --- 12.0.0.1 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4006ms rtt min/avg/max/mdev = 1.332/3.288/8.137/2.459 ms

まあ、重複がないことは、Analyzer-3アナライザーのダンプを証明しています。

 bormoglotx@Analyzer-3:~$ sudo tcpdump -i eth1 -B 9192 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes 11:59:12.605205 IP 11.0.0.1 > 12.0.0.1: ICMP echo request, id 1602, seq 1, length 64 11:59:12.605350 IP 12.0.0.1 > 11.0.0.1: ICMP echo reply, id 1602, seq 1, length 64 11:59:13.611070 IP 11.0.0.1 > 12.0.0.1: ICMP echo request, id 1602, seq 2, length 64 11:59:13.612356 IP 12.0.0.1 > 11.0.0.1: ICMP echo reply, id 1602, seq 2, length 64 11:59:14.606350 IP 11.0.0.1 > 12.0.0.1: ICMP echo request, id 1602, seq 3, length 64 11:59:14.606739 IP 12.0.0.1 > 11.0.0.1: ICMP echo reply, id 1602, seq 3, length 64 11:59:15.612423 IP 11.0.0.1 > 12.0.0.1: ICMP echo request, id 1602, seq 4, length 64 11:59:15.612488 IP 12.0.0.1 > 11.0.0.1: ICMP echo reply, id 1602, seq 4, length 64 11:59:16.614228 IP 11.0.0.1 > 12.0.0.1: ICMP echo request, id 1602, seq 5, length 64 11:59:16.614588 IP 12.0.0.1 > 11.0.0.1: ICMP echo reply, id 1602, seq 5, length 64 ^C 10 packets captured 10 packets received by filter 0 packets dropped by kernel

RZN-PE-2, . .

, discard ( discard, reject, Juniper icmp , )

 bormoglotx@RZN-PE-2# show firewall family inet filter MIRROR-RSPAN-GE0/0/1 term MIRROR { then { port-mirror-instance RSAPN; discard; } }

, :

 bormoglotx@Server-1:~$ ping 12.0.0.1 -I eth1 PING 12.0.0.1 (12.0.0.1) from 11.0.0.1 eth1: 56(84) bytes of data. 64 bytes from 12.0.0.1: icmp_seq=1 ttl=63 time=2.68 ms 64 bytes from 12.0.0.1: icmp_seq=2 ttl=63 time=1.22 ms 64 bytes from 12.0.0.1: icmp_seq=3 ttl=63 time=1.96 ms 64 bytes from 12.0.0.1: icmp_seq=4 ttl=63 time=2.30 ms 64 bytes from 12.0.0.1: icmp_seq=5 ttl=63 time=1.96 ms ^C --- 12.0.0.1 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4005ms rtt min/avg/max/mdev = 1.220/2.028/2.685/0.487 ms

 bormoglotx@Analyzer-3:~$ sudo tcpdump -i eth1 -B 9192 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes 12:03:11.934805 IP 11.0.0.1 > 12.0.0.1: ICMP echo request, id 1604, seq 1, length 64 12:03:11.934834 IP 12.0.0.1 > 11.0.0.1: ICMP echo reply, id 1604, seq 1, length 64 12:03:12.982685 IP 11.0.0.1 > 12.0.0.1: ICMP echo request, id 1604, seq 2, length 64 12:03:12.982716 IP 12.0.0.1 > 11.0.0.1: ICMP echo reply, id 1604, seq 2, length 64 12:03:13.935027 IP 11.0.0.1 > 12.0.0.1: ICMP echo request, id 1604, seq 3, length 64 12:03:13.935607 IP 12.0.0.1 > 11.0.0.1: ICMP echo reply, id 1604, seq 3, length 64 12:03:14.936859 IP 11.0.0.1 > 12.0.0.1: ICMP echo request, id 1604, seq 4, length 64 12:03:14.937654 IP 12.0.0.1 > 11.0.0.1: ICMP echo reply, id 1604, seq 4, length 64 12:03:15.937650 IP 11.0.0.1 > 12.0.0.1: ICMP echo request, id 1604, seq 5, length 64 12:03:15.938375 IP 12.0.0.1 > 11.0.0.1: ICMP echo reply, id 1604, seq 5, length 64 ^C 10 packets captured 10 packets received by filter 0 packets dropped by kernel

RZN-PE-2. next-hop ( , , , JunOS ), gre , next-hop :

 bormoglotx@RZN-PE-2> show configuration interfaces gr-0/0/0 description SPAN; unit 0 { tunnel { source 62.0.0.2; destination 62.0.0.1; } family inet { filter { input MIRROR-RSPAN-GE0/0/1; } } } bormoglotx@RZN-PE-2> show configuration firewall family inet filter MIRROR-RSPAN-GE0/0/1 term MIRROR { then next-hop-group Analyzer-3; }

Next-hop :

 bormoglotx@RZN-PE-2> show forwarding-options next-hop-group Analyzer-3 detail Next-hop-group: Analyzer-3 Type: inet State: up Number of members configured : 2 Number of members that are up : 1 Number of subgroups configured : 0 Number of subgroups that are up : 0 Members Interfaces: State ge-0/0/1.0 next-hop 169.254.100.1 up ge-0/0/100.0 down

 bormoglotx@Server-1:~$ ping 12.0.0.1 -I eth1 -c 5 PING 12.0.0.1 (12.0.0.1) from 11.0.0.1 eth1: 56(84) bytes of data. 64 bytes from 12.0.0.1: icmp_seq=1 ttl=63 time=3.38 ms 64 bytes from 12.0.0.1: icmp_seq=2 ttl=63 time=2.17 ms 64 bytes from 12.0.0.1: icmp_seq=3 ttl=63 time=2.14 ms 64 bytes from 12.0.0.1: icmp_seq=4 ttl=63 time=2.06 ms 64 bytes from 12.0.0.1: icmp_seq=5 ttl=63 time=1.89 ms --- 12.0.0.1 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4006ms rtt min/avg/max/mdev = 1.891/2.332/3.387/0.538 ms

, , :

 bormoglotx@Analyzer-3:~$ sudo tcpdump -i eth1 -B 9192 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes 12:19:28.306816 IP 11.0.0.1 > 12.0.0.1: ICMP echo request, id 1609, seq 1, length 64 12:19:28.306840 IP 12.0.0.1 > 11.0.0.1: ICMP echo reply, id 1609, seq 1, length 64 12:19:29.306887 IP 11.0.0.1 > 12.0.0.1: ICMP echo request, id 1609, seq 2, length 64 12:19:29.307273 IP 12.0.0.1 > 11.0.0.1: ICMP echo reply, id 1609, seq 2, length 64 12:19:30.308323 IP 11.0.0.1 > 12.0.0.1: ICMP echo request, id 1609, seq 3, length 64 12:19:30.308455 IP 12.0.0.1 > 11.0.0.1: ICMP echo reply, id 1609, seq 3, length 64 12:19:31.309897 IP 11.0.0.1 > 12.0.0.1: ICMP echo request, id 1609, seq 4, length 64 12:19:31.310117 IP 12.0.0.1 > 11.0.0.1: ICMP echo reply, id 1609, seq 4, length 64 12:19:32.313234 IP 11.0.0.1 > 12.0.0.1: ICMP echo request, id 1609, seq 5, length 64 12:19:32.313271 IP 12.0.0.1 > 11.0.0.1: ICMP echo reply, id 1609, seq 5, length 64 ^C 10 packets captured 10 packets received by filter 0 packets dropped by kernel

— . — .

最初のオプションを使用します。最初に、greサービス（gr-X / X / X）を得るために、トンネルサービスを有効にする必要があります。

 bormoglotx@RZN-PE-1# show chassis fpc 0 pic 0 { tunnel-services { bandwidth 10g; } } port-mirror-instance SPAN-1;

ここで、理論に戻り、トンネルインターフェースとリソースの予約について説明します。この構成では、ゼロFPCのゼロPICのトンネルサービスに10Gを割り当てます。これは、10GのPFE帯域幅が切断されることを意味するものではありません-これは、トンネルサービスが10G PFEの帯域幅しか使用できず、それらによって占有されていないリソースの一部が物理ポートトラフィックの転送に使用できることを示唆します-つまり、PFE上の10Gは共有されますトンネルサービスと実際のインターフェイス。しかし、これはMPCカード上にあります。 DPCカードの「幸せな」所有者である場合（たとえば、4ダースのカードがある場合）、上記の構成では1つのポートが失われます（つまり、xeポートはシステムから単純に消え、cliからアクセスできなくなり、ポートの近くでライトが点灯します）ポートがトンネルモードになっていることを伝えます）。あいにくこれらのカードでは、ご存知のとおり、リソースは厳しく予約されていますが、これらのカードは古く、古くなっており、これまでのところ大量に使用されていました。

第二に、ポート番号についてお話したいと思います-1Gを予約するとポート番号はgr-0 / 0/10になり、10G以上を予約するとポート番号はgr-0 / 0/0になります（以下に表示されます）オプション）。

 [edit] bormoglotx@RZN-PE-1# run show interfaces terse | match "^(gr|lt|vt)-" gr-0/0/0 up up lt-0/0/0 up up vt-0/0/0 up up

TRIOチップセットを搭載したラインカードでは、トンネルサービス用に予約可能な最大帯域幅は60Gです。

注：ltとvtは異なるインターフェースであることを追加したいと思います。lt-論理トンネル-通常、論理システムの接続またはインスタンスのルーティングを相互に目的とする論理トンネル-これらのインスタンスまたは論理システムが直接パッチコードで接続されているかのように、それらの間のトラフィックを駆動できます。ただし、vtは仮想トンネルです。仮想ループバックは、何らかの仮想エンティティをバインドするのではなく、繰り返し検索するためにpfeでトラフィックをラップすることを目的としています（たとえば、vplsで）。

トンネルインターフェイスを作成した後、gr-0 / 0/0を設定する機会があります。リモートPEルーターがgreトンネルを終了せず、単にサーバー側にトラフィックを送信するオプションを破棄したため、RZN-PE-1上のトンネルのソースアドレスとして、独自のループバックを指定しますが、ミラーリングされたトラフィックの受信者サーバーの宛先アドレスとして、さらに、このアドレスが利用可能である必要があります。

実際のところ、サーバーにはアドレスがある場合とない場合があります。以下に示すように、自分で選択して静的ARPレコードを作成できます。

 [edit] bormoglotx@RZN-PE-2# show | compare [edit interfaces] + ge-0/0/1 { + description Analyzer-3; + unit 0 { + family inet { + address 192.168.0.0/31 { + arp 192.168.0.1 mac 02:00:00:19:21:68; + } + } + } + } [edit protocols ospf area 0.0.0.0] interface ge-0/0/0.0 { ... } + interface ge-0/0/1.0 { + passive; + }

さらに、提示された構成からわかるように、インターフェイスはospfでパッシブとして追加され、RZN-PE-1はこのネットワークへのルートを認識します。

 [edit] bormoglotx@RZN-PE-1# run show route 192.168.0.1 inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.0.0/31 *[OSPF/10] 00:00:16, metric 3 > to 10.0.0.0 via ge-0/0/0.0

次に、RZN-PE-1にgreトンネルを作成し、次のホップグループに追加します。

 [edit] bormoglotx@RZN-PE-1# show interfaces gr-0/0/0 description RSPAN; unit 0 { tunnel { source 62.0.0.1; destination 192.168.0.1; } family inet { address 169.254.100.1/31; } } [edit] bormoglotx@RZN-PE-1# show forwarding-options next-hop-group Analyzer-servers group-type inet; interface gr-0/0/0.0; interface ge-0/0/1.0 { next-hop 169.254.0.1; } interface ge-0/0/2.0 { next-hop 169.254.0.3; }

geインターフェイスとは異なり、greインターフェイスはp2pであるため、ネクストホップアドレスを指定しても意味がありません。指定することはできますが、トラフィックは反対側から引き続き送信されます。

それでは、すべてが通常どおりです-ミラーリングセッションの状態を確認します。

 [edit] bormoglotx@RZN-PE-1# run show forwarding-options next-hop-group detail Next-hop-group: Analyzer-servers Type: inet State: up Number of members configured : 3 Number of members that are up : 3 Number of subgroups configured : 0 Number of subgroups that are up : 0 Members Interfaces: State gr-0/0/0.0 up ge-0/0/1.0 next-hop 169.254.0.1 up ge-0/0/2.0 next-hop 169.254.0.3 up

さて、ここでリモートサーバー上のトラフィックが取得されていることを確認します。

 bormoglotx@Server-1:~$ sudo hping3 -S -c 5 12.0.0.1 -d 40 -I eth1 HPING 12.0.0.1 (eth1 12.0.0.1): S set, 40 headers + 40 data bytes len=40 ip=12.0.0.1 ttl=63 DF id=53439 sport=0 flags=RA seq=0 win=0 rtt=8.2 ms len=40 ip=12.0.0.1 ttl=63 DF id=53515 sport=0 flags=RA seq=1 win=0 rtt=3.5 ms len=40 ip=12.0.0.1 ttl=63 DF id=53610 sport=0 flags=RA seq=2 win=0 rtt=3.4 ms len=40 ip=12.0.0.1 ttl=63 DF id=53734 sport=0 flags=RA seq=3 win=0 rtt=3.8 ms len=40 ip=12.0.0.1 ttl=63 DF id=53897 sport=0 flags=RA seq=4 win=0 rtt=3.3 ms --- 12.0.0.1 hping statistic --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 3.3/4.4/8.2 ms

 bormoglotx@Analyzer-3:~$ sudo tcpdump -i eth1 -B 4096 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes 16:34:34.923370 IP 62.0.0.1 > 192.168.0.1: GREv0, length 84: IP 11.0.0.1.2894 > 12.0.0.1.0: Flags [S], seq 1149405522:1149405562, win 512, length 40 16:34:34.926586 IP 62.0.0.1 > 192.168.0.1: GREv0, length 44: IP 12.0.0.1.0 > 11.0.0.1.2894: Flags [R.], seq 0, ack 1149405563, win 0, length 0 16:34:35.923022 IP 62.0.0.1 > 192.168.0.1: GREv0, length 84: IP 11.0.0.1.2895 > 12.0.0.1.0: Flags [S], seq 1598018315:1598018355, win 512, length 40 16:34:35.923855 IP 62.0.0.1 > 192.168.0.1: GREv0, length 44: IP 12.0.0.1.0 > 11.0.0.1.2895: Flags [R.], seq 0, ack 1598018356, win 0, length 0 16:34:36.922903 IP 62.0.0.1 > 192.168.0.1: GREv0, length 84: IP 11.0.0.1.2896 > 12.0.0.1.0: Flags [S], seq 592229199:592229239, win 512, length 40 16:34:36.924048 IP 62.0.0.1 > 192.168.0.1: GREv0, length 44: IP 12.0.0.1.0 > 11.0.0.1.2896: Flags [R.], seq 0, ack 592229240, win 0, length 0 16:34:37.923278 IP 62.0.0.1 > 192.168.0.1: GREv0, length 84: IP 11.0.0.1.2897 > 12.0.0.1.0: Flags [S], seq 694611591:694611631, win 512, length 40 16:34:37.924765 IP 62.0.0.1 > 192.168.0.1: GREv0, length 44: IP 12.0.0.1.0 > 11.0.0.1.2897: Flags [R.], seq 0, ack 694611632, win 0, length 0 16:34:38.924275 IP 62.0.0.1 > 192.168.0.1: GREv0, length 84: IP 11.0.0.1.2898 > 12.0.0.1.0: Flags [S], seq 1423363395:1423363435, win 512, length 40 16:34:38.924291 IP 62.0.0.1 > 192.168.0.1: GREv0, length 44: IP 12.0.0.1.0 > 11.0.0.1.2898: Flags [R.], seq 0, ack 1423363436, win 0, length 0 ^C 10 packets captured 10 packets received by filter 0 packets dropped by kernel

しかし、私が言ったように、greトラフィックは進んでおり、これがサーバーにとって問題でない場合、このアプローチは最も単純で最も柔軟です。

しかし、判明したように、ミラーリングされた受信サーバーの所有者は、トラフィックが多すぎるため、すべてのトラフィックを受信することを望みません。 Analyzer-1サーバーはTCPトラフィックのみを必要とし、Analyzer-2サーバーはUDPトラフィックのみを必要としますが、Analyzer-3サーバーはすべてのトラフィックを必要とし、TCP / UDPに限定されません。つまり、次のようなスキームを実装する必要があり

ます。複数のコンシューマーの選択的ミラーリング

ここでは、トンネルインターフェイスvt-0 / 0/0（仮想ループバック）が必要です。または、lt-0 / 0/0（仮想トンネル）を使用できますが、最初の方がより望ましいです。そのため、選択的ミラーリングの目的は次のとおりです-ポートからのトラフィックは最初に仮想ループバックvtポートにミラーリングされ、次に、選択したパラメーター（プロトコル、ポートなど）に基づいて、このポートから異なるネクストホップグループに分散されます何が起こっているかをよりよく理解するために、このスキームを組み立てましょう。最初に、トラフィックが仮想ループバックにミラーリングされるように、ミラーリングインスタンスを変更します。

 [edit] bormoglotx@RZN-PE-1# show forwarding-options port-mirroring instance SPAN-1 input { rate 1; run-length 0; } family inet { output { interface vt-0/0/0.0; no-filter-check; } }

no-filter-checkパラメーターは非常に重要です-このコマンドを使用すると、トラフィックがミラーリングされるインターフェイスにフィルターを接続できます。デフォルトでは、これらのインターフェースでフィルタリングは無効になっています。次に、vtインターフェイス自体を作成します。

 [edit] bormoglotx@RZN-PE-1# show interfaces vt-0/0/0 unit 0 { description SPAN-USE; family inet; }

このインターフェイスでアドレスをハングさせることはできません。また、このインターフェイスで解決できるアドレスファミリは制限されています。

次の図があります-ge-0 / 0/3インターフェイスからのすべてのトラフィックはvt-0 / 0 / 0.0ポートに向けられます。次に、このトラフィックをさまざまなコンシューマにミラーリングする必要があります。これを行うには、まず必要なコンシューマを含むネクストホップグループを作成する必要があります。

 [edit] bormoglotx@RZN-PE-1# show forwarding-options next-hop-group Analyzer-TCP group-type inet; interface gr-0/0/0.0; interface ge-0/0/1.0 { next-hop 169.254.0.1; } [edit] bormoglotx@RZN-PE-1# show forwarding-options next-hop-group Analyzer-UDP group-type inet; interface gr-0/0/0.0; interface ge-0/0/2.0 { next-hop 169.254.0.3; } [edit] bormoglotx@RZN-PE-1# show forwarding-options next-hop-group Analyzer-default group-type inet; interface gr-0/0/0.0; interface ge-0/0/100.0;

Analyzer-3でトラフィックをミラーリングするように設計されたgr-0 / 0/0インターフェイスは、3つすべてのグループに追加されます。これは、このサーバーがTCPとUDPの両方のトラフィックを受信したいという事実によるものであり、そのための別個のグループを作成してフィルターに適用することはできません。異なるグループで同じネクストホップを使用することは禁止されていません。Analyzer-defaultグループには、ge-0 / 0 / 100.0ポートもあります-これは、グループを少なくとも2つのインターフェイスを持つ必要があるため、構成をコミットできるようにグループに追加された偽のポートです。

次に、必要な基準に従ってトラフィックを照合し、ネクストホップグループに沿って分散するフィルターを作成する必要があります。

 [edit] bormoglotx@RZN-PE-1# show firewall family inet filter MIRROR-SORTED term MIRROR-TCP { from { protocol tcp; } then next-hop-group Analyzer-TCP; } term MIRROR-UDP { from { protocol udp; } then next-hop-group Analyzer-UDP; } term MIRROR-DEFAUL { then next-hop-group Analyzer-default; }

そして、vtインターフェースに固定します。

 [edit] bormoglotx@RZN-PE-1# show interfaces vt-0/0/0 unit 0 { description SPAN-USE; family inet { filter { input MIRROR-SORTED; } } }

デザインをチェックします。アップ状態のvtインターフェイスでのミラーリング：

 bormoglotx@RZN-PE-1> show forwarding-options port-mirroring SPAN-1 Instance Name: SPAN-1 Instance Id: 2 Input parameters: Rate : 1 Run-length : 0 Maximum-packet-length : 0 Output parameters: Family State Destination Next-hop inet up vt-0/0/0.0

すべてのグループが稼働中です（グループが稼働するには少なくとも1つのポートが稼働している必要があることに注意してください）。

 bormoglotx@RZN-PE-1> show forwarding-options next-hop-group detail Next-hop-group: Analyzer-TCP Type: inet State: up Number of members configured : 2 Number of members that are up : 2 Number of subgroups configured : 0 Number of subgroups that are up : 0 Members Interfaces: State gr-0/0/0.0 up ge-0/0/1.0 next-hop 169.254.0.1 up Next-hop-group: Analyzer-UDP Type: inet State: up Number of members configured : 2 Number of members that are up : 2 Number of subgroups configured : 0 Number of subgroups that are up : 0 Members Interfaces: State gr-0/0/0.0 up ge-0/0/2.0 next-hop 169.254.0.3 up Next-hop-group: Analyzer-default Type: inet State: up Number of members configured : 2 Number of members that are up : 1 Number of subgroups configured : 0 Number of subgroups that are up : 0 Members Interfaces: State gr-0/0/0.0 up ge-0/0/100.0 down

さて、5つのicmp、tcp、udpパケットを生成し、どのサーバーに到達するかを確認します。すべてのクライアントサーバーで、tcpdumpを同時に有効にします。--rand-sourceスイッチでhping3を使用したので、トラフィックはServer-1に向かうポートでのみ取得されるため、リターントラフィックは表示されません。

そのため、Analyzer-1で捕捉したものを見てください。TCPのみが存在するはずです。

 bormoglotx@Analyzer-1:~$ sudo tcpdump -i eth1 -B 9192 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes 19:58:25.457641 IP 108.215.126.169.1668 > 12.0.0.1.0: Flags [S], seq 1842749676:1842749716, win 512, length 40 19:58:26.458098 IP 230.181.170.188.1669 > 12.0.0.1.0: Flags [S], seq 1810452177:1810452217, win 512, length 40 19:58:27.459245 IP 112.6.155.46.1670 > 12.0.0.1.0: Flags [S], seq 1524555644:1524555684, win 512, length 40 19:58:28.459006 IP 50.45.169.23.1671 > 12.0.0.1.0: Flags [S], seq 1362080290:1362080330, win 512, length 40 19:58:29.459294 IP 135.146.14.177.1672 > 12.0.0.1.0: Flags [S], seq 2122009219:2122009259, win 512, length 40 ^C 5 packets captured 5 packets received by filter 0 packets dropped by kernel

次に、Analyzer-2で何が発生したかを確認しましょう（ここにはUDPトラフィックのみが存在するはずです）

 bormoglotx@Analyzer-2:~$ sudo tcpdump -i eth1 -B 9192 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes 19:58:09.340702 IP 132.43.66.243.1121 > 12.0.0.1.0: UDP, length 40 19:58:10.341308 IP 205.172.124.143.1122 > 12.0.0.1.0: UDP, length 40 19:58:11.341239 IP 253.127.33.120.1123 > 12.0.0.1.0: UDP, length 40 19:58:12.341204 IP 246.68.75.25.1124 > 12.0.0.1.0: UDP, length 40 19:58:13.341819 IP 95.89.126.64.1125 > 12.0.0.1.0: UDP, length 40 ^C 5 packets captured 5 packets received by filter 0 packets dropped by kernel

さて、私はAnalyzer-3にとどまり、そこですべてを連続してキャッチし、パケットの総数は15（5 UDP / 5 TCP / 5 ICMP）であるはずです：

 bormoglotx@Analyzer-3:~$ sudo tcpdump -i eth1 -B 9192 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes 19:58:11.782669 IP 62.0.0.1 > 192.168.0.1: GREv0, length 72: IP 132.43.66.243.1121 > 12.0.0.1.0: UDP, length 40 19:58:12.783508 IP 62.0.0.1 > 192.168.0.1: GREv0, length 72: IP 205.172.124.143.1122 > 12.0.0.1.0: UDP, length 40 19:58:13.783166 IP 62.0.0.1 > 192.168.0.1: GREv0, length 72: IP 253.127.33.120.1123 > 12.0.0.1.0: UDP, length 40 19:58:14.782758 IP 62.0.0.1 > 192.168.0.1: GREv0, length 72: IP 246.68.75.25.1124 > 12.0.0.1.0: UDP, length 40 19:58:15.783594 IP 62.0.0.1 > 192.168.0.1: GREv0, length 72: IP 95.89.126.64.1125 > 12.0.0.1.0: UDP, length 40 19:58:18.310249 IP 62.0.0.1 > 192.168.0.1: GREv0, length 100: IP 65.173.140.215 > 12.0.0.1: ICMP net 5.6.7.8 unreachable, length 76 19:58:19.311045 IP 62.0.0.1 > 192.168.0.1: GREv0, length 100: IP 171.91.95.222 > 12.0.0.1: ICMP net 5.6.7.8 unreachable, length 76 19:58:20.312496 IP 62.0.0.1 > 192.168.0.1: GREv0, length 100: IP 228.215.127.12 > 12.0.0.1: ICMP net 5.6.7.8 unreachable, length 76 19:58:21.311067 IP 62.0.0.1 > 192.168.0.1: GREv0, length 100: IP 214.149.191.71 > 12.0.0.1: ICMP net 5.6.7.8 unreachable, length 76 19:58:22.311398 IP 62.0.0.1 > 192.168.0.1: GREv0, length 100: IP 119.130.166.53 > 12.0.0.1: ICMP net 5.6.7.8 unreachable, length 76 19:58:26.186528 IP 62.0.0.1 > 192.168.0.1: GREv0, length 84: IP 108.215.126.169.1668 > 12.0.0.1.0: Flags [S], seq 1842749676:1842749716, win 512, length 40 19:58:27.187385 IP 62.0.0.1 > 192.168.0.1: GREv0, length 84: IP 230.181.170.188.1669 > 12.0.0.1.0: Flags [S], seq 1810452177:1810452217, win 512, length 40 19:58:28.188726 IP 62.0.0.1 > 192.168.0.1: GREv0, length 84: IP 112.6.155.46.1670 > 12.0.0.1.0: Flags [S], seq 1524555644:1524555684, win 512, length 40 19:58:29.188846 IP 62.0.0.1 > 192.168.0.1: GREv0, length 84: IP 50.45.169.23.1671 > 12.0.0.1.0: Flags [S], seq 1362080290:1362080330, win 512, length 40 19:58:30.188499 IP 62.0.0.1 > 192.168.0.1: GREv0, length 84: IP 135.146.14.177.1672 > 12.0.0.1.0: Flags [S], seq 2122009219:2122009259, win 512, length 40 ^C 15 packets captured 15 packets received by filter 0 packets dropped by kernel

さて、実装しなければならないことはすべて行われました-意図したとおり、トラフィックは消費者の間でミラーリングおよび分散されます。

上記のL3トラフィックをミラーリングしましたが、Juniper MXシリーズルーターは非常に柔軟なデバイスであり、IPトラフィック（inet / inet6ファミリー）だけでなく、vplsやl2ckt（Ciscoの用語ではxconnect）などのL2トラフィックもミラーリングできます。

L2トラフィックのローカルミラーリング

L2CKTに送信されているものをスパイする必要がある最も単純なケースを考えてみましょう（これは、分析するのにトラフィックをラップしているクライアントがそれについても知らないので、これは確かに良いことではありません。顧客）。スキームは単純です-何らかの種類のL2CKTがRZN-PE-1とRZN-PE-2の間に引き込まれます。

つまり、このようなミラーリングスキームを実装する必要があります。

RZN-PE-1とRZN-PE-2の間にL2CKTがプルされます。これを確認します。

 bormoglotx@RZN-PE-1> show configuration protocols l2circuit neighbor 62.0.0.2 { interface ge-0/0/6.100 { virtual-circuit-id 100; } } bormoglotx@RZN-PE-1> show configuration interfaces ge-0/0/6.100 encapsulation vlan-ccc; vlan-id 100; family ccc { filter { input MIRROR-L2CKT-SPAN-1; output MIRROR-L2CKT-SPAN-1; } }

cccファミリがインターフェイスに含まれているのは論理的です-これは結局L2CKTです。この構成では、L2CKTを通過するすべてのトラフィックを受信する必要があるため、両側のフィルターが必要なインターフェイスに既にハングしています。フィルターは以前と基本的に同じです。アドレスファミリーのみがinetではなく、cccです。

 bormoglotx@RZN-PE-1> show configuration firewall family ccc filter MIRROR-L2CKT-SPAN-1 term MIRROR { then port-mirror-instance SPAN-1; }

次に、ミラーリングに使用するミラーリングインスタンスをセットアップします。入力セクションに変更はありません-すべては以前と同じですが、出力セクションには大きな違いがあります。

 bormoglotx@RZN-PE-1> show configuration forwarding-options port-mirroring instance SPAN-1 input { rate 1; run-length 0; } family ccc { output { interface ge-0/0/1.0; } }

アドレスファミリが変更されました-現在はcccです。これにより、トラフィックの送信先となるインターフェイスの構成に必然的な変更が生じます。以前に非p2pインターフェイスで行われたように、次ホップアドレスを設定しようとすると、成功しません。

 bormoglotx@RZN-PE-1# set forwarding-options port-mirroring instance SPAN-1 family ccc output interface ge-0/0/1 ? Possible completions: <[Enter]> Execute this command + apply-groups Groups from which to inherit configuration data + apply-groups-except Don't inherit configuration data from these groups no-filter-check Do not check for filters on port-mirroring interface | Pipe through a command

私たちにはそのような機会はありません。したがって、トラフィックを送信する必要があるインターフェイスには、ブリッジまたはcccファミリを含める必要があります。

 [edit] bormoglotx@RZN-PE-1# show interfaces ge-0/0/1 description Analyzer-1; encapsulation ethernet-ccc; unit 0 { family ccc; }

cccファミリーは当然使いやすいですが、ブリッジを使用する必要がある場合は、重要なニュアンスを忘れないでください-ブリッジカプセル化とのインターフェイスをブリッジドメインに配置する必要があります（ドメインのvlan番号をゼロに使用できるため、実際のvlan番号を選択しません他のサービスのミラーリング中）。

すべての準備が整ったら、ミラーリングセッションの状態を確認します。

 bormoglotx@RZN-PE-1> show forwarding-options port-mirroring Instance Name: SPAN-1 Instance Id: 2 Input parameters: Rate : 1 Run-length : 0 Maximum-packet-length : 0 Output parameters: Family State Destination Next-hop ccc up ge-0/0/1.0

すべてが正常です-セッションでアップ。ホスト間でpingを実行し、アナライザーで何が起こるかを確認します。

 bormoglotx@TEST-1> ping routing-instance VR-1 10.0.0.2 count 5 PING 10.0.0.2 (10.0.0.2): 56 data bytes 64 bytes from 10.0.0.2: icmp_seq=0 ttl=64 time=10.159 ms 64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=11.136 ms 64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=9.723 ms 64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=7.754 ms 64 bytes from 10.0.0.2: icmp_seq=4 ttl=64 time=10.619 ms --- 10.0.0.2 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 7.754/9.878/11.136/1.162 ms

収集したものは次のとおりです。

 bormoglotx@Analyzer-1:~$ sudo tcpdump -i eth1 -B 9192 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes 23:44:31.948237 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 17420, seq 0, length 64 23:44:31.954408 IP 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 17420, seq 0, length 64 23:44:32.955149 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 17420, seq 1, length 64 23:44:32.964115 IP 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 17420, seq 1, length 64 23:44:33.967789 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 17420, seq 2, length 64 23:44:33.973388 IP 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 17420, seq 2, length 64 23:44:34.975442 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 17420, seq 3, length 64 23:44:34.980370 IP 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 17420, seq 3, length 64 23:44:35.986900 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 17420, seq 4, length 64 23:44:35.992213 IP 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 17420, seq 4, length 64 ^C 10 packets captured 10 packets received by filter 0 packets dropped by kernel

実際、すべてのパケットがアナライザーに到達しました。

ここで、より複雑なスキームを検討してください-ブリッジドメインまたは仮想スイッチにあるインターフェイスのミラーリングを構成する必要があります。受信は、上記のようにローカルポートにコピーを送信せず、このトラフィックをリモートボックスにドロップします。

L2トラフィックをリモートサーバーにミラーリングする

最初の考えは、すべてが単純であり、greトンネルを使用できるということです。しかし、残念ながら、greはccc / tcc / vpls / bridgeカプセル化をサポートしていません。ただし、Junosには、さまざまな方法を使用して同じ問題を解決できるさまざまなツールがあり、時には何かを行うのは非現実的と思われることもありますが、最終的には、N番目の時間とN番目のスモークマニュアルの後にすべてが始まります。ここでも同じです。次に、このような複雑なスキームを組み立てます。

何と理由を説明します。そのため、仮想スイッチ（L2CKTまたはブリッジドメイン）からミラーリングインスタンスへのトラフィックをミラーリングし、トラフィックは一部の物理インターフェイスではなく、仮想トンネルインターフェイスlt-0 / 0/0にミラーリングされます。このインターフェイスはボックスごとに1つあり、そのユニットはピアユニットと呼ばれるペアで作成されます。1つのユニットはトンネルの入力端で、2番目のユニットは出力です。その結果、1つのユニットに分類されるものはすべて、それに関連付けられている2番目のユニットから飛び出します。このインターフェイスで、cccカプセル化を有効にし、そこから受信者サーバーを終端するリモートルーターにL2CKTを構築します。つまり、L2CKTを介してL2トラフィックを直接リモートサーバーに送信します。リモートルーターの場合、これは単純なL2CKTになります。

それでは、構成に移りましょう。サーバー側へのインターフェースはアクセス中であり、仮想スイッチにあります：

 bormoglotx@RZN-PE-1# wildcard range show interfaces ge-0/0/[3-4] description Server-1; encapsulation ethernet-bridge; unit 0 { family bridge { filter { input MIRROR-BRIDGE-vSwitch-1; } interface-mode access; vlan-id 100; } } description Server-2; encapsulation ethernet-bridge; unit 0 { family bridge { filter { input MIRROR-BRIDGE-vSwitch-1; } interface-mode access; vlan-id 100; } } [edit] bormoglotx@RZN-PE-1# show routing-instances vSwitch-1 instance-type virtual-switch; interface ge-0/0/3.0; interface ge-0/0/4.0; bridge-domains { BD100 { vlan-id 100; } }

着信トラフィックをSPAN-1インスタンスにミラーリングするために、フィルターがインターフェイスでハングします。フィルターは、ファミリーを除き、以前に使用されたものと変わりません-このシナリオでは、ブリッジが使用されます：

 [edit] bormoglotx@RZN-PE-1# show firewall family bridge filter MIRROR-BRIDGE-vSwitch-1 term MIRROR { then port-mirror-instance SPAN-1; }

次に、SPAN-1インスタンスを作成します。

 [edit] bormoglotx@RZN-PE-1# show forwarding-options port-mirroring instance SPAN-1 input { rate 1; run-length 0; } family vpls { output { interface lt-0/0/0.0; } }

小さなニュアンスがあります。アドレスファミリはブリッジによって示されません。インスタンス構成ではそのようなファミリは見つかりませんが、vplsは見つかります。このファミリ（VPLS）は、vpl /ブリッジドメインからのトラフィックをミラーリングするために使用されます。

次に、トラフィックを送信するトンネルインターフェイスを作成します。

 [edit] bormoglotx@RZN-PE-1# show interfaces lt-0/0/0 unit 0 { description RSPAN-IN; encapsulation ethernet-ccc; peer-unit 1; family ccc; } unit 1 { description RSPAN-OUT; encapsulation ethernet-ccc; peer-unit 0; family ccc; }

前に書いたように、ltインターフェースは2つのユニットで構成されています-私たちの場合、ユニット0と1です。ユニット0に飛ぶものはすべてユニット1を通ります。一般的に、ユニットはL3のようになります。たとえばccc-これは動作します。両端にcccがあります。ゼロユニットでは、トラフィックをccc / bridge / vplsファミリのインスタンスにミラーリングする必要があるため、最初のユニットでcccを使用するのは、このユニットからL2CKTが構築されるためです。

次に、RZN-PE-1とRZN-PE-2の間にL2CKTを作成します。RZN-PE-1の側面から：

 [edit] bormoglotx@RZN-PE-1# show protocols l2circuit neighbor 62.0.0.2 { interface lt-0/0/0.1 { virtual-circuit-id 1; encapsulation-type ethernet; } }

RZN-PE-2の側面から：

 bormoglotx@RZN-PE-2> show configuration protocols l2circuit neighbor 62.0.0.1 { interface ge-0/0/1.0 { virtual-circuit-id 1; encapsulation-type ethernet; } } bormoglotx@RZN-PE-2> show configuration interfaces ge-0/0/1 description Analyzer-3; encapsulation ethernet-ccc; unit 0 { family ccc; }

これで、フランケンシュタインが機能しているかどうかを確認できます。まず、L2CKTの状態を見てみましょう。

 [edit] bormoglotx@RZN-PE-1# run show l2circuit connections | find ^Nei Neighbor: 62.0.0.2 Interface Type St Time last up # Up trans lt-0/0/0.1(vc 1) rmt Up Sep 2 07:28:05 2017 1 Remote PE: 62.0.0.2, Negotiated control-word: Yes (Null) Incoming label: 299840, Outgoing label: 299872 Negotiated PW status TLV: No Local interface: lt-0/0/0.1, Status: Up, Encapsulation: ETHERNET Flow Label Transmit: No, Flow Label Receive: No

素晴らしい、L2CKTは仕事中。次に、ミラーリングセッションの状態を確認します。

 [edit] bormoglotx@RZN-PE-1# run show forwarding-options port-mirroring SPAN-1 Instance Name: SPAN-1 Instance Id: 2 Input parameters: Rate : 1 Run-length : 0 Maximum-packet-length : 0 Output parameters: Family State Destination Next-hop vpls up lt-0/0/0.0

すべて順調です。Server-1サーバーとServer-2サーバー間でpingを実行し、トラフィックアナライザーに到達するものを確認します。

 bormoglotx@Server-1:~$ ping 11.0.0.2 -I 11.0.0.1 -c 5 -i 0.2 PING 11.0.0.2 (11.0.0.2) from 11.0.0.1 : 56(84) bytes of data. 64 bytes from 11.0.0.2: icmp_seq=1 ttl=64 time=3.86 ms 64 bytes from 11.0.0.2: icmp_seq=2 ttl=64 time=2.34 ms 64 bytes from 11.0.0.2: icmp_seq=3 ttl=64 time=2.30 ms 64 bytes from 11.0.0.2: icmp_seq=4 ttl=64 time=9.56 ms 64 bytes from 11.0.0.2: icmp_seq=5 ttl=64 time=1.43 ms --- 11.0.0.2 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 803ms rtt min/avg/max/mdev = 1.436/3.903/9.565/2.937 ms

次に、Analyzer-3に移動して、tcpdumpの内容を確認します。

 bormoglotx@Analyzer-3:~$ sudo tcpdump -i eth1 -B 9192 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes 10:48:46.296920 IP 11.0.0.1 > 11.0.0.2: ICMP echo request, id 2000, seq 1, length 64 10:48:46.297969 IP 11.0.0.2 > 11.0.0.1: ICMP echo reply, id 2000, seq 1, length 64 10:48:46.496380 IP 11.0.0.1 > 11.0.0.2: ICMP echo request, id 2000, seq 2, length 64 10:48:46.497647 IP 11.0.0.2 > 11.0.0.1: ICMP echo reply, id 2000, seq 2, length 64 10:48:46.700540 IP 11.0.0.1 > 11.0.0.2: ICMP echo request, id 2000, seq 3, length 64 10:48:46.700547 IP 11.0.0.2 > 11.0.0.1: ICMP echo reply, id 2000, seq 3, length 64 10:48:46.897518 IP 11.0.0.1 > 11.0.0.2: ICMP echo request, id 2000, seq 4, length 64 10:48:46.907024 IP 11.0.0.2 > 11.0.0.1: ICMP echo reply, id 2000, seq 4, length 64 10:48:47.098414 IP 11.0.0.1 > 11.0.0.2: ICMP echo request, id 2000, seq 5, length 64 10:48:47.098799 IP 11.0.0.2 > 11.0.0.1: ICMP echo reply, id 2000, seq 5, length 64 10:48:51.307134 ARP, Request who-has 11.0.0.1 tell 11.0.0.2, length 46 10:48:51.307542 ARP, Reply 11.0.0.1 is-at 00:50:01:00:07:00 (oui Unknown), length 46 ^C 12 packets captured 12 packets received by filter 0 packets dropped by kernel

さて、pingに加えて、要求/応答arpもダンプに入りました。これは、すべてのトラフィックがミラーリングされていることを証明しています。これが必要なことです。

結論として、最大2つのミラーリングインスタンスを同じfpcにバインドできることを書いたことを思い出します。しかし、3つのインスタンスを使用する必要がある場合はどうでしょうか？

もちろん、2つのユーザー定義インスタンスと1つのデフォルトインスタンス（1つのみ）を使用できますが、これは最善の解決策ではありません。次に、デフォルトインスタンスが既に使用されている場合当然、JunOSではこの制限を回避できます。原則として、超自然的なものはありません-操作の原理は同じで、変更はインスタンスの構成のみに関係します。

同じFPCで3つ以上のミラーリングインスタンスを使用する

したがって、主なポイントは、複数のミラーリングインスタンス間にリンクを作成することです。それを参照する親インスタンスと子インスタンスが作成されます。親インスタンスでは、入力パラメーター、つまりミラーリング/サンプリングの速度、最大パケットサイズを指定します。子インスタンスでは、出力パラメーターはすでに示されています-インターフェースまたはネクストホップグループですが、入力パラメーターは構成で指定された親インスタンスから継承されます。構成がなければ、これは明らかに理解できないので、

次のようなミラーリングスキームをまとめましょう。まず、親インスタンスを作成し、SPANと呼びます。

 bormoglotx@RZN-PE-1# show forwarding-options port-mirroring instance SPAN input { rate 1; run-length 0; }

インスタンスでは、着信ミラーパラメータのみが指定されます。ここに示すことはこれ以上ありません。

次に、3つの子インスタンスを作成します。

 [edit] bormoglotx@RZN-PE-1# show forwarding-options port-mirroring instance SPAN-1 input-parameters-instance SPAN; family inet { output { interface ge-0/0/1.0 { next-hop 169.254.0.1; } } } [edit] bormoglotx@RZN-PE-1# show forwarding-options port-mirroring instance SPAN-2 input-parameters-instance SPAN; family inet { output { interface ge-0/0/2.0 { next-hop 169.254.0.3; } } } [edit] bormoglotx@RZN-PE-1# show forwarding-options port-mirroring instance SPAN-3 input-parameters-instance SPAN; family inet { output { interface gr-0/0/0.0 { } }

ここでは、発信ミラーリングパラメーターを既に示しています。親と子のインスタンス間のリンクは、次のコマンドを使用して行われます。

 input-parameters-instance SPAN;

その結果、作成した3つのSPAN-1 / 2/3インスタンスはすべて、SPANインスタンスから入力パラメーターを継承します。覚えているように、ここでインスタンスをいくつか（または異なるカードの着信ポートの場合はいくつか）にバインドする必要があります。前にも言ったように、親インスタンスのみをFPCにバインドする必要があります。

 bormoglotx@RZN-PE-1# show chassis fpc 0 pic 0 { tunnel-services { bandwidth 10g; } } port-mirror-instance SPAN;

それでは、すべてが同じです-フィルターを作成し、着信ポートに掛けます：

 bormoglotx@RZN-PE-1# wildcard range show interfaces ge-0/0/[3-5] description Server-1; unit 0 { family inet { filter { input MIRROR>>>SPAN-3; output MIRROR>>>SPAN-3; } address 11.0.0.254/24; } } description Server-2; unit 0 { family inet { filter { input MIRROR>>>SPAN-2; output MIRROR>>>SPAN-2; } address 12.0.0.254/24; } } description Server-3; unit 0 { family inet { filter { input MIRROR>>>SPAN-1; output MIRROR>>>SPAN-1; } address 13.0.0.254/24; } }

フィルターは親インスタンスではなく、子インスタンスを示すことに注意してください。

 [edit] bormoglotx@RZN-PE-1# wildcard range show firewall family inet filter MIRROR>>>SPAN-[1-3] term MIRROR { then port-mirror-instance SPAN-1; } term MIRROR { then port-mirror-instance SPAN-2; } term MIRROR { then port-mirror-instance SPAN-3; }

次に、ミラーリングセッションの状態を確認します。

 bormoglotx@RZN-PE-1# run show forwarding-options port-mirroring Instance Name: SPAN-1 Instance Id: 3 Input parameters: Rate : 1 Run-length : 0 Maximum-packet-length : 0 Output parameters: Family State Destination Next-hop inet up gr-0/0/0.0 Instance Name: SPAN-2 Instance Id: 4 Input parameters: Rate : 1 Run-length : 0 Maximum-packet-length : 0 Output parameters: Family State Destination Next-hop inet up ge-0/0/2.0 169.254.0.3 Instance Name: SPAN-3 Instance Id: 5 Input parameters: Rate : 1 Run-length : 0 Maximum-packet-length : 0 Output parameters: Family State Destination Next-hop inet up ge-0/0/1.0 169.254.0.1

出力から、トラフィックミラーリングセッションが動作中であり、着信トラフィック処理パラメーターが親インスタンスから継承されていることがわかります。実際、この記事を減らすために作業の結論を直接示すことはしません。この記事を読んだ後、そのようなスキームを自分で組み立ててそのパフォーマンスをチェックできると思います。

私が書きたかったすべてが書いたようです。コメントや追加がある場合-書き込みます。

ご清聴ありがとうございました。

Juniper MXのトラフィックミラーリング

More articles: