Geekly Articles each Day

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

出力から、トラフィックミラヌリングセッションが動䜜䞭であり、着信トラフィック凊理パラメヌタヌが芪むンスタンスから継承されおいるこずがわかりたす。実際、この蚘事を枛らすために䜜業の結論を盎接瀺すこずはしたせん。この蚘事を読んだ埌、そのようなスキヌムを自分で組み立おおそのパフォヌマンスをチェックできるず思いたす。

私が曞きたかったすべおが曞いたようです。コメントや远加がある堎合-曞き蟌みたす。

ご枅聎ありがずうございたした。

Source: https://habr.com/ru/post/J336978/

More articles:


All Articles