ジュニパーネットワークス：コンポジットネクストホップ

EVPNの記事で、EVPNのコンポジットネクストホップを有効にする必要性について言及しました。その後、少なくとも10人が同じ質問をしました-コンポジットネクストホップとは何ですか。 そして、多くの人にとってのコンポジットネクストホップは、ネクストホップの数を劇的に減らすことができる神秘的な技術だと思います。 このトピックは、「SDLS時代のMPLS」という本で非常によく開示されていますが、この本の記事に基づいて、その仕組みを簡単に説明します。

ルーターを扱うすべてのエンジニアは、ルーティング情報ベース（RIB）とFIB（転送情報ベース）があることを知っていると思います。 RIBは、動的ルーティングプロトコルから受信した情報、および静的ルートと接続されたインターフェイスに基づいてコンパイルされます。 各プロトコルは、bgpであろうとisisであろうと、そのデータベースにルートをインストールします。そのデータベースの中で、プロトコルプリファレンス（シスコの観点からの管理距離）に基づく最適なルートがルーティングテーブル（RIB）に既にインストールされています。 。 プレフィックス10.0.0.0/24へのルートのrib骨のエントリの例を次に示します。

bormoglotx@RZN-PE2> show route table VRF1.inet.0 10.0.0.0/24 VRF1.inet.0: 8 destinations, 13 routes (8 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.0.0/24 *[BGP/170] 15:42:58, localpref 100, from 62.0.0.64 AS path: I, validation-state: unverified to 10.0.0.0 via ae0.1, Push 16 > to 10.0.0.6 via ae1.0, Push 16, Push 299888(top) [BGP/170] 15:42:58, localpref 100, from 62.0.0.65 AS path: I, validation-state: unverified to 10.0.0.0 via ae0.1, Push 16 > to 10.0.0.6 via ae1.0, Push 16, Push 299888(top) 

RIBは、各ルートに関する完全な情報を提供します。たとえば、このルートをインストールしたプロトコル、ルートのメトリック、同等のパスの可用性、コミュニティなど、および現在ルートが非アクティブである理由です。 ただし、RIBは純粋な形のコントロールプレーンであり、ルーターがこのテーブルを使用して転送するのは便利ではありません。 そのため、RIBに基づいて、ルーター（より正確にはREが実行）がFIBを形成し、すべてのPFEに送信します。 FIBには、プロトコルとメトリックに関する冗長な情報がなくなりました。PFEが知る必要があるのは、プレフィックス自体、次のホップ、このプレフィックスを利用できること、およびパケット送信時にハングアップする必要があるラベルだけです。

 bormoglotx@RZN-PE2> show route forwarding-table vpn VRF1 destination 10.0.0.0/24 Routing table: VRF1.inet Internet: Destination Type RtRef Next hop Type Index NhRef Netif 10.0.0.0/24 user 0 indr 1048576 4 ulst 1048575 2 0:5:86:71:49:c0 Push 16 572 1 ae0.1 0:5:86:71:9d:c1 Push 16, Push 299888(top) 583 1 ae1.0 

注：通常、FIBに入るルートは1つだけですが、ECMPバランシングを使用し、同等のパスがある場合、REは2つのルートをPFEに送信します。

今日はネクストホップとトークについて話します。 ジュニパーの機器には、次のホップのいくつかのタイプがあります。

 VMX(RZN-PE2 vty)# show nhdb summary detail Type Count --------- --------- Discard 18 Reject 17 Unicast 47 Unilist 4 Indexed 0 Indirect 4 Hold 0 Resolve 5 Local 20 Recv 17 Multi-RT 0 Bcast 9 Mcast 11 Mgroup 3 mdiscard 11 Table 17 Deny 0 Aggreg. 18 Crypto 0 Iflist 0 Sample 0 Flood 0 Service 0 Multirtc 0 Compst 7 DmxResolv 0 DmxIFL 0 DmxtIFL 0 LITAP 0 Limd 0 LI 0 RNH_LE 0 VCFI 0 VCMF 0 

それらの多くは直観的であり、上記のいくつかはあなたの練習ではまったく会わないでしょう。 上記のいくつかについて説明し、単純な直接ネクストホップから開始します。これは、ジュニパーの観点ではユニキャストと呼ばれます。

ユニキャストネクストホップ。

  604(Unicast, IPv4->MPLS, ifl:340:ge-0/0/2.0, pfe-id:0) <<<<<< 605(Unicast, IPv4->MPLS, ifl:341:ge-0/0/3.0, pfe-id:0) <<<<<< 606(Unicast, IPv4->MPLS, ifl:342:ge-0/0/4.0, pfe-id:0) <<<<<< 

ネクストホップの最も単純な形式は、直接ネクストホップです。 プレフィックスが使用可能な物理インターフェイスを直接指します。 このタイプのネクストホップが一意である場合、各プレフィックスに対して個別のネクストホップが作成され、このプレフィックスがどのルーティングテーブルにあるかは関係ありません（vrfまたはgrt）。 はい、それは非常にシンプルで理解しやすいですが、エンジニアに一見して明らかなすべてが良いというわけではありません。 たとえば、100個のVRFがあり、それぞれに100個のプレフィックスがある場合、10,000個の物理ネクストホップを取得します（これはVRFプレフィックスのみです）。 isis、ldp、rsvpプロトコルルートなどを追加します。

注：推論の単純化と理解の単純化のために、同等のパスと集約インターフェースがないと仮定します。 ある場合は、少し後でネクストホップの階層について説明します。

その結果、次のホップの制限は非常に迅速に到達できます。 しかし、これは主な問題ではありません-現在、腺はFIBで1M以上のIPv4プレフィックスに耐えることができます。 実際には、インターフェイスの1つがクラッシュし、ルートが再計算された場合、ルーターは、転送テーブルに現在インストールされているすべてのネクストホップ（この場合はすべて10,000）を書き換える必要があります。 はい、IGPルートはすぐに書き換えられます-それらの数はそれほど多くありませんが、vpnv4 / l2vpn / evpnルートでは、原則として数十（時には数百）あります。 当然、非常に多くのネクストホップの書き換えには時間がかかり、トラフィックの一部が失われる可能性があります。 そしてこれは、ボックスFWにある可能性をまだ考慮していません。FWには645Kルートがあります。

ダイレクトネクストホップを使用することで最も興味深いのは、これらの10,000個すべてのプレフィックスが同じPEから到着する（つまり、同じプロトコルネクストホップを持つ）場合でも、すべてを更新する必要があることです。 10,000ネクストホップ しかし、論理的に考えると、実際、この状況では、サービスラベルのみが異なる100個の一意のネクストホップ（vrfごとのサービスラベルの配布の対象）しかありません。トランスポートラベルと発信インターフェイスはまったく同じです。 （とにかくJunosで）vrfのプレフィックスの直接ネクストホップを見つけることができません-より正確には、TRIOチップセットを搭載したカードでは、L3VPNや他のサービスの直接ネクストホップを有効にしてもできません-それはただサポートされていません。 しかし、それをまったく拒否することもできません。ユニキャストネクストホップは、パケットを送信するインターフェイスを直接指し、階層のネクストホップ（後で説明します）を使用すると、階層の最後のレベルでユニキャストネクストホップになります。 さて、他にどのように？ 発信インターフェイスに加えて、このネクストホップビューにはラベルスタックとカプセル化も含まれますが、これについては後で詳しく説明します。

次のように、isisによって取得されたルートのユニキャストネクストホップのように見えます。

 bormoglotx@RZN-PE2> show route forwarding-table destination 10.0.0.2/31 table default Routing table: default.inet Internet: Destination Type RtRef Next hop Type Index NhRef Netif 10.0.0.2/31 user 0 10.0.0.6 ucst 693 19 ae1.0 bormoglotx@RZN-PE2> show route forwarding-table destination 10.0.0.2/31 table default extensive Routing table: default.inet [Index 0] Internet: Destination: 10.0.0.2/31 Route type: user Route reference: 0 Route interface-index: 0 Multicast RPF nh index: 0 Flags: sent to PFE, rt nh decoupled Nexthop: 10.0.0.6 Next-hop type: unicast Index: 693 Reference: 19 Next-hop interface: ae1.0 

ネクストホップの集約

  584(Aggreg., IPv4, ifl:326:ae0.1, pfe-id:0) <<<<<<<< 585(Unicast, IPv4, ifl:337:ge-0/0/0.1, pfe-id:0) 586(Unicast, IPv4, ifl:339:ge-0/0/1.1, pfe-id:0) 603(Aggreg., IPv4->MPLS, ifl:327:ae1.0, pfe-id:0) <<<<<<< 604(Unicast, IPv4->MPLS, ifl:340:ge-0/0/2.0, pfe-id:0) 605(Unicast, IPv4->MPLS, ifl:341:ge-0/0/3.0, pfe-id:0) 606(Unicast, IPv4->MPLS, ifl:342:ge-0/0/4.0, pfe-id:0) 

ここではすべてが非常に簡単です-プレフィックスが集計インターフェイスを介して表示されている場合、この階層が表示されると思います。 集約ネクストホップは、本質的に、集約の一部である実際のネクストホップ（物理インターフェース）のリストです。 集約を使用する場合、ネクストホップの数は、集約内のリンクの数に比例して増加します。 上記の出力では、2つのAggregate next-hopが表示され、それぞれがこれらの集約に含まれる物理的なnext-hopを指し示しています。

ユニリストネクストホップ

  1048574(Unilist, IPv4, ifl:0:-, pfe-id:0) <<<<<<<< 584(Aggreg., IPv4, ifl:326:ae0.1, pfe-id:0) 585(Unicast, IPv4, ifl:337:ge-0/0/0.1, pfe-id:0) 586(Unicast, IPv4, ifl:339:ge-0/0/1.1, pfe-id:0) 603(Aggreg., IPv4->MPLS, ifl:327:ae1.0, pfe-id:0) 604(Unicast, IPv4->MPLS, ifl:340:ge-0/0/2.0, pfe-id:0) 605(Unicast, IPv4->MPLS, ifl:341:ge-0/0/3.0, pfe-id:0) 606(Unicast, IPv4->MPLS, ifl:342:ge-0/0/4.0, pfe-id:0) 

実際、これも非常に単純な階層であり、集約に多少似ています。 同等のパスがある場合にのみ表示され、本質的には、すべての同等のパスのリストにすぎません。 この例では、2つの同等のパスがあり、両方が集約を介しています。

注：私たちの場合、星は一致しているため、ユニキャストID（585、586）は集合ID（584）の後に（階層の順序ではなく、数字で）順番に並んでいますが、これは必ずしもそうではありません。

リストされているすべてのネクストホップは、物理的なネクストホップの数を減らすのに役立ちませんが、むしろそれらの数を増やします。 次の2種類のネクストホップは、FIBを最適化し、ユニキャストネクストホップの数を減らすように設計されています。

間接ネクストホップ。

  1048577(Indirect, IPv4, ifl:327:ae1.0, pfe-id:0, i-ifl:0:-) <<<<<< 1048574(Unilist, IPv4, ifl:0:-, pfe-id:0) 584(Aggreg., IPv4, ifl:326:ae0.1, pfe-id:0) 585(Unicast, IPv4, ifl:337:ge-0/0/0.1, pfe-id:0) 586(Unicast, IPv4, ifl:339:ge-0/0/1.1, pfe-id:0) 603(Aggreg., IPv4->MPLS, ifl:327:ae1.0, pfe-id:0) 604(Unicast, IPv4->MPLS, ifl:340:ge-0/0/2.0, pfe-id:0) 605(Unicast, IPv4->MPLS, ifl:341:ge-0/0/3.0, pfe-id:0) 606(Unicast, IPv4->MPLS, ifl:342:ge-0/0/4.0, pfe-id:0) 

文字通り、間接という言葉は間接として翻訳されます。 このタイプのネクストホップは、物理的なネクストホップの数を減らすために使用されます。 それでも、ユニキャストネクストホップを検討する際に単純な計算方法で取得した10,000のネクストホップは、どういうわけか多すぎます。 次のホップをもう一度読んでください。 100個のVRFがあり、それぞれに100個のプレフィックスがあり（プレフィックスはVRFごとに生成され）、同じPEからアナウンスされます。 このシナリオのこれらのプレフィックスはすべて、同じプロトコルネクストホップ（リモートPEのループバック）と発信インターフェイス（および結果として、同じトランスポートラベル）を持つことがわかります。 違いはサービスタグのみです。 ただし、vrfごとのタグを生成するため、タグは100個しかありません。 その結果、10,000個の直接ネクストホップを、まったく同じラベルスタックを持つ100個のネクストホップに集約できます。

間接ネクストホップの概念により、同じプロトコルネクストホップを介して到達可能なすべてのプレフィックスが同じ間接ネクストホップを使用できるようになります。 サービスラベル（インターネットへのルートなど）がまったくない場合があるため、プロトコルネクストホップに従って集約が発生するという事実に読者の注意を喚起したいと思いますが、その存在は間接ネクストホップに大きな影響を与えます。

残念ながら、間接ネクストホップの主な問題は、ユニキャストネクストホップを参照することです。これは、サービスラベルを含む完全なラベルスタックを示します。

 bormoglotx@RZN-PE2>show route forwarding-table table VRF1 destination 10.2.0.0/24 extensive Routing table: VRF1.inet [Index 9] Internet: Destination: 10.2.0.0/24 Route type: user Route reference: 0 Route interface-index: 0 Multicast RPF nh index: 0 Flags: sent to PFE Next-hop type: indirect Index: 1048587 Reference: 2 Nexthop: 10.0.0.6 Next-hop type: Push 24008, Push 299920(top) Index: 706 Reference: 2 Load Balance Label: None Next-hop interface: ae1.0 

この行は、完全なラベルスタックについて説明しています。

  Next-hop type: Push 24008, Push 299920(top) Index: 706 Reference: 2 

ご覧のとおり、タグ24008はサービスタグであり、ネクストホップ階層の最後のレベルでスタックにプッシュされます。 これに基づいて、複数の間接ネクストホップが同じ物理的なものを指すことは不可能です。サービスラベルはすべての人で異なります。 さらに、たとえば、L2CKTとVPLSは異なるカプセル化を使用します。 したがって、上記の特定の条件下では、間接ネクストホップは利益を生まない場合があります。

プレフィックスごとのラベル配布を使用する場合（何らかの理由でこのラベル配布方法がデフォルトでCiscoおよびHuaweiで使用される場合）、indirect-next-hopがあまり役に立たないことを推測するのは難しくありません。各プレフィックスには個別のサービスラベルがあります。 結果として、複数のプレフィックスを1つのネクストホップに結合することはできません。同じプロトコルのネクストホップを介して到達可能ですが、異なるサービスラベルがあり、最悪のシナリオでは10,000になります。ネクストホップ、直接ではなく間接的。 「大根は甘くない」ということわざのようになりました。さらに、他のすべてのL2CKTは、同じPE-shekのペアで終端されていても、異なるラベルを持ちます（それについては何もしません-1つのラベルを生成しますいくつかのL2CKTでは機能しません）。 開発者がこの問題に打ち勝った方法については、後で説明します。

もちろん、実際の条件では、間接ネクストホップを使用すると、ネクストホップの数を大幅に削減できます（vrf-table-labelまたはper-vrfラベルの配布を使用する人はほとんどいないため）。 さらに、Juniper MXでは、間接ネットホップがデフォルトで有効になっているため、この機能をオフにすることはできません。 さらに、ルーターにFWがある場合、これらのプレフィックスにはサービスマークがまったくありません（もちろん、FWにFWを配置しない限り）。インターネット上のすべてのプレフィックスには、同じinirect-next-hopがあります。

しかし、完璧に制限はなく、さらにスケーラブルなソリューションが必要です。 その上、私は繰り返しますが、L2CKT-あなたは常に異なるサービスラベルを持っているので、異なる間接ネクストホップを持っています。 この問題を解決するソリューションは、chained-composite-next-hopと呼ばれます（ジュニパーの観点から、シスコのアプローチは少し異なります）。

連鎖複合ネクストホップ

 607(Compst, IPv4->MPLS, ifl:0:-, pfe-id:0, comp-fn:Chain) <<<<<<< 1048577(Indirect, IPv4, ifl:327:ae1.0, pfe-id:0, i-ifl:0:-) 1048574(Unilist, IPv4, ifl:0:-, pfe-id:0) 584(Aggreg., IPv4, ifl:326:ae0.1, pfe-id:0) 585(Unicast, IPv4, ifl:337:ge-0/0/0.1, pfe-id:0) 586(Unicast, IPv4, ifl:339:ge-0/0/1.1, pfe-id:0) 603(Aggreg., IPv4->MPLS, ifl:327:ae1.0, pfe-id:0) 604(Unicast, IPv4->MPLS, ifl:340:ge-0/0/2.0, pfe-id:0) 605(Unicast, IPv4->MPLS, ifl:341:ge-0/0/3.0, pfe-id:0) 606(Unicast, IPv4->MPLS, ifl:342:ge-0/0/4.0, pfe-id:0) 

わかったように、間接ネクストホップはネクストホップからのマトリョーシカです。 まったく同じマトリョーシカとchained-composite-next-hopですが、現在は階層に別のレベルがあります。 他にどのようにプレフィックスをグループに結合し、同じネクストホップに関連付けることができますか？ すべてのL3VPNまたはすべてのL2CKTに共通するものは何ですか？ True-これはアドレスのファミリーです。 ネクストホップ階層の最上部には複合ネクストホップがあり、これはサービスラベルごとにルートを結合しますが、間接ネクストホップとは異なり、複合ネクストホップはこのラベルを指します。 つまり、サービスラベルは、階層の最後のレベル-uniastではなく、階層の最初のレベルで表示されるようになりました。 これにより、間接ネクストホップの議論で特定した問題を解決できます。 たとえば、同じプレフィックス10.2.0.0/24のFIBエントリを見てみましょう。ただし、すでに複合ネクストホップが有効になっています。

 bormoglotx@RZN-PE2> show route forwarding-table table VRF1 destination 10.2.0.0/24 extensive Routing table: VRF1.inet [Index 9] Internet: Destination: 10.2.0.0/24 Route type: user Route reference: 0 Route interface-index: 0 Multicast RPF nh index: 0 Flags: sent to PFE Nexthop: Next-hop type: composite Index: 608 Reference: 2 Load Balance Label: Push 24008, None Next-hop type: indirect Index: 1048578 Reference: 3 Nexthop: 10.0.0.6 Next-hop type: Push 299920 Index: 664 Reference: 3 Load Balance Label: None Next-hop interface: ae1.0 

行のLoad Balance Labelは、サービスラベルを示します

 Load Balance Label: Push 24008, None 

平凡な博学の方法によって、次の結論に到達することができます。サービスマークはいくつあるので、複合ネクストホップは多くなります。 階層の次のレベルは間接ネクストホップですが、これは前に説明したものとは少し異なります。 コンポジットネクストホップを使用する場合、間接ネクストホップの特権は、アドレスファミリおよびプロトコルネクストホップによって集約されることです。 つまり、ご理解のとおり、同じプロトコルネクストホップを持つすべてのvpnv4プレフィックスは、同じ間接ネクストホップになります。 さて、間接ネクストホップは実際のネクストホップ（通常はユニリストまたは集約）を指します。 最も重要なことは、複数の間接ネクストホップが同じユニリストネクストホップを指すことができるようになったことです。ユニリストネクストホップでは、完全なラベルスタックではなく、トランスポートラベルだけでなく、同じPEまでは同じトランスポートラベルになります。

ここで、100のVRFを検討しているケースに戻ります。 最悪のシナリオでは、間接ネクストホップを使用すると、10,000個の間接ネクストホップが得られ、その結果、実際のネクストホップが多くなりました。 次に、composite-next-hopが提供するものを見てみましょう。 最初に、複合ネクストホップの階層があります。タグがプレフィックスごとに生成される場合、10,000個の異なるサービスタグを取得します。これは、同じ数の複合ネクストホップを意味します。 ただし、前のケースとは異なり、複合ネクストホップは実際のネクストホップではなく、間接ネクストホップを参照します。間接ネクストホップは、アドレスファミリおよびプロトコルネクストホップによってvpnv4宛先プレフィックスを集約します。 これにより、実際のネクストホップの数が大幅に削減されます。 このシナリオでは、vpnv4とprotocol-net-hopのアドレスファミリは1つだけです。つまり、10,000のすべてのコンポジットネクストホップは1つの間接ネクストホップを参照し、1つの実ネクストホップを指します。ネクストホップ！ つまり、最終的には1つの実際のネクストホップしか得られませんでした。

私は、イングレスlspにコンポジットネクストホップを含めると、ネクストホップの合計数を5〜8倍減らすことができると言うことができます（たとえば、実際の数字、1.1Mネクストホップからの減少（オンにする前）この関数）（170Kを含む）（包含後）、つまり6.5倍の削減-同意、良い指標）。

注：composite-next-hopを有効にすると、転送テーブルにラベルスタックは表示されません。ラベルスタックは2つの階層で指定され、たとえば次のような広範な出力でのみ表示されるためです。

間接ネクストホップ：

 bormoglotx@RZN-PE2> show route forwarding-table table VRF1 destination 10.0.0.0/24 Routing table: VRF1.inet Internet: Destination Type RtRef Next hop Type Index NhRef Netif 10.0.0.0/24 user 0 indr 1048578 4 ulst 1048577 2 0:5:86:71:49:c0 Push 16 699 1 ae0.1 0:5:86:71:9d:c1 Push 16, Push 299888(top) 702 1 ae1.0 

複合ネクストホップ：

 bormoglotx@RZN-PE2> show route forwarding-table table VRF1 destination 10.0.0.0/24 Routing table: VRF1.inet Internet: Destination Type RtRef Next hop Type Index NhRef Netif 10.0.0.0/24 user 0 comp 608 2 

注：Juniper MXシャーシにDPCボードが含まれている場合（サービスボードを除く）、Juniper Webサイトの次のメッセージが示すように、コンポジットネクストホップを有効にできません。

DPCとMPC FPCの両方を含むMXシリーズ3Dユニバーサルエッジルーターでは、連鎖複合ネクストホップはデフォルトで無効になっています。 MX240、MX480、およびMX960で連鎖複合ネクストホップを有効にするには、ネットワークサービスモードで拡張IPオプションを使用するようにシャーシを構成する必要があります。

電源が入らないと直接言っているわけではありませんが、誰かに驚かれるかもしれませんが、DPCカードは拡張IPモードをサポートしていません。

拡張ネットワークサービスモードオプションでは、マルチサービスDPC（MS-DPC）とMS-MPCのみがパワーオンされます。 拡張ネットワークサービスモードオプションでは、他のDPCは機能しません。

ただし、コンポジットネクストホップはPEルーターでのみ必要であるとは思わないでください。ただし、それらは主にPEルーターで役立ちます（通常、Pには多くのルートはありません）。 Composite-next-hopは、入力lsp（PE上）および通過lsp（P上）に対して有効にできます。 さらに、Pルーターとしても機能するステロイドPEがあります（まあ、またはネットワーク設計がまったく無料のコアを提供しない）、またはカーネル（Pレベル）が他の自律システムへのルートを受け取ります（オプションC）境界上のigpでのBGP-LUルートの再配布ではなく、リフレクタを使用したBGPラベル付きユニキャストセッションによる。

入力lspの場合、L3VPN、L2VPN、EVPN、BGP-LUなどのサービスに対してのみコンポジットネクストホップを有効にできます。

  evpn Create composite-chained nexthops for ingress EVPN LSPs fec129-vpws Create composite-chained nexthops for ingress fec129-vpws LSPs l2ckt Create composite-chained nexthops for ingress l2ckt LSPs l2vpn Create composite-chained nexthops for ingress l2vpn LSPs l3vpn Create composite-chained nexthops for ingress l3vpn LSPs labeled-bgp Create composite-chained nexthops for ingress labeled-bgp LSPs 

LDP、RSVP、さらに静的lspの複合ネクストホップオプションは、中継デバイスで使用できます。

  l2vpn Create composite-chained nexthops for transit l2vpn LSPs l3vpn Create composite-chained nexthops for transit l3vpn LSPs labeled-bgp Create composite-chained nexthops for transit labeled BGP routes ldp Create composite-chained nexthops for LDP LSPs ldp-p2mp Create composite-chained nexthops for LDP P2MP LSPs rsvp Create composite-chained nexthops for RSVP LSPs rsvp-p2mp Create composite-chained nexthops for RSVP p2mp LSPs static Create composite-chained nexthops for static LSPs 

これにより、中継lspのネクストホップの数を大幅に削減できます。 たとえば、ラボにはデバイスが5つしかありません。つまり、P-keのmpls.0テーブルはやや小さいように見えます。

 bormoglotx@RZN-P2> show route table mpls.0 | find ^2[0-9]+ 299872 *[LDP/9] 1w1d 12:59:13, metric 1 > to 10.0.0.5 via ae0.0, Pop 299872(S=0) *[LDP/9] 1w1d 12:59:13, metric 1 > to 10.0.0.5 via ae0.0, Pop 299888 *[LDP/9] 1w1d 12:58:30, metric 1 > to 10.0.0.5 via ae0.0, Swap 299792 299904 *[LDP/9] 1w1d 12:55:57, metric 1 > to 10.0.0.7 via ae1.0, Pop 299904(S=0) *[LDP/9] 1w1d 12:55:57, metric 1 > to 10.0.0.7 via ae1.0, Pop 299920 *[LDP/9] 1w1d 12:47:06, metric 1 > to 10.0.0.5 via ae0.0, Swap 299824 

しかし、LDPのコンポジットネクストホップを有効にすることの効果は、このような小さな研究室でも既に明らかになっています。 以下は、コンポジットネクストホップを有効にする前のネットホップの総数です。

 VMX(RZN-P2 vty)# show nhdb summary Total number of NH = 116 VMX(RZN-P2 vty)# show nhdb summary detail Type Count --------- --------- Discard 12 Reject 11 Unicast 32 <<<<<<<<<<<<<< Unilist 0 Indexed 0 Indirect 0 Hold 0 Resolve 2 Local 13 Recv 8 Multi-RT 0 Bcast 4 Mcast 7 Mgroup 1 mdiscard 7 Table 11 Deny 0 Aggreg. 8 <<<<<<<<<<<<<< Crypto 0 Iflist 0 Sample 0 Flood 0 Service 0 Multirtc 0 Compst 0 <<<<<<<<<<<<<< DmxResolv 0 DmxIFL 0 DmxtIFL 0 LITAP 0 Limd 0 LI 0 RNH_LE 0 VCFI 0 VCMF 0 

次に、ldpのchained-composite-next-hopを有効にして、結果を確認します。

 bormoglotx@RZN-P2> show configuration routing-options router-id 62.0.0.65; autonomous-system 6262; forwarding-table { chained-composite-next-hop { transit { ldp; } } 

ルーティングテーブルのすべては同じですが、ルートは更新されていますが、その寿命によって確認できます（トランジットデバイスでコンポジットネクストホップをオンにするときは、これを考慮する必要があります）。

 bormoglotx@RZN-P2> show route table mpls.0 | find ^2[0-9]+ 299872 *[LDP/9] 00:00:57, metric 1 > to 10.0.0.5 via ae0.0, Pop 299872(S=0) *[LDP/9] 00:00:57, metric 1 > to 10.0.0.5 via ae0.0, Pop 299888 *[LDP/9] 00:00:57, metric 1 > to 10.0.0.5 via ae0.0, Swap 299792 299904 *[LDP/9] 00:00:57, metric 1 > to 10.0.0.7 via ae1.0, Pop 299904(S=0) *[LDP/9] 00:00:57, metric 1 > to 10.0.0.7 via ae1.0, Pop 299920 *[LDP/9] 00:00:57, metric 1 > to 10.0.0.5 via ae0.0, Swap 299824 

次に、FIB内のルートの総数を確認します。

 VMX(RZN-P2 vty)# show nhdb summary Total number of NH = 94 VMX(RZN-P2 vty)# show nhdb summary detail Type Count --------- --------- Discard 12 Reject 11 Unicast 10 <<<<<<<<<<<<<< Unilist 0 Indexed 0 Indirect 0 Hold 0 Resolve 2 Local 13 Recv 8 Multi-RT 0 Bcast 4 Mcast 7 Mgroup 1 mdiscard 7 Table 11 Deny 0 Aggreg. 2 <<<<<<<<<<<<<< Crypto 0 Iflist 0 Sample 0 Flood 0 Service 0 Multirtc 0 Compst 6 <<<<<<<<<<<<<< DmxResolv 0 DmxIFL 0 DmxtIFL 0 LITAP 0 Limd 0 LI 0 RNH_LE 0 VCFI 0 VCMF 0 

トランジットラベルがいくつかあるため、各ラベルには独自のユニキャストネクストホップがあり、JunOSはトランジットトラフィックを送信できるインターフェースが2つしかないことを気にしませんでした。ホップsは、ユニキャストのネクストホップの増加を必然的に伴います。コンポジットネクストホップを有効にした後、コンポジットネクストホップは、ラベルごとに独自のネクストホップを生成する代わりに、既存の2つの集約ネクストホップをすでに参照しています。

入力LSPのコンポジットネクストホップをオンにすると、すべてのBGPセッションジャークをオンにし、トランジットLSPセッションのコンポジットネクストホップをオンにすると、ジャークしません（BGP-LUがオンになっていても）、すべてのMPLSラベルがリセットされます転送テーブルに戻ります。

結論として、写真の間接ネクストホップと複合ネクストホップを明確に比較したいと思います。
3つのL3VPNが実験室で発売され、PE3プレフィックス（10.2.0.0/24および10.3.0.0/24）がプレフィックスごとのラベル、およびPE1ごとの



VRF ：および3つのL2CKTで発表されました（2つはPE1に、1つはPE3に） ：



さらに、回線は集約インターフェイスで組み立てられ、PE1の前に同等のパスがあります。

この図は、間接ネクストホップを使用する場合のネクストホップ「ツリー」を示しています。



プレフィックス10.0.0.0/24、10.0.1.0/24、10.0.2.0/24には、1つのシリアルラベルがあり、プレフィックス20.0.0.0/24、20.0.1.0/24、20.0.2.0/24にも同じです1つのサービスタグ-それらはすべてPE1でアナウンスされます。ご覧のとおり、これらのプレフィックスは同じ間接ネクストホップを介して利用できます。ただし、10.2.0.0 / 24と10.3.0.0/24のラベルは異なります（それらのラベルはプレフィックスごとに生成されます）。つまり、間接間接ホップが異なります。まあ、L2CKTでは、すべてが非常に明確だと思います-誰もが異なるサービスラベルと間接ネクストホップを持っています。その結果、29のユニキャストネクストホップがあります。

同じことですが、composite-next-hopが有効になっています。



ここでは、次のホップはすでに少なくなっています。同じサービスラベルを持つプレフィックスには、同じコンポジットネクストホップを介してアクセスできます。思い出すと、サービスラベルは複合ネクストホップ階層で指定されています。さらに、すべての複合ネクストホップは間接ネクストホップで参照されます。上の図では、2つのプロトコルネクストホップ（PE1とPE3）と2つのサービスL3VPNとL2CKTがあります。その結果、4つの間接ネクストホップがあります。L3VPN

、PE1
L3VPN、PE2
L2CKT LDP、PE1
L2CKT LDP、PE2
そして、ユニキャストネクストホップ階層レベルではトランスポートラベルのみがあり、間接ネクストホップがあります。 hopは同じunicast-next-hopを参照できます。その結果、ユニキャストネクストホップの数は29から8に減少しました。

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