カットの下の詳細。
最初に、Junosのルーティングテーブルがどのように読み込まれるかを理解する必要があります。 これは（概略的に）次のように発生します。
[プロトコル] _____ [プロトコルのデータベース] _____ [RIB]
ここで：
protocol-Junosルーティングプロトコル（これは厳密にはルーティングプロトコルではありません
これには、たとえばルーターインターフェイスも含まれます）
プロトコルのdb-プロトコルデータベース（例：isis / ospf / bgpデータベース） すべてのルートがここに入力され、最適なルートが選択された後、RIBにインストールされます。
RIBはルーティングテーブルそのものです。 使用するプロトコルと使用する場所によって異なります（例：Ipv4ルートはinet.0、ldpはinet.3、vrf / virtルーター内のルートは<vrf.name> .inet.0など）
リブグループメカニズムにより、次の構造を使用できます。
[protocol] _________ [protocol's db] ______________________ [RIB-Group]、
ここで、RIBグループは以下で構成されます。
プライマリRIB-プロトコルがデフォルトでルートをインストールするテーブル
セカンダリRIB-プロトコルにルートもインストールする1つ以上の追加のルーティングテーブル。
Import-Policy-セカンダリRIBへのインストールを許可するルートと、許可しないルートを記述するポリシー。
ルーティングプロトコルから受け取ったルートを、デフォルトで動作するテーブルだけでなく、その他にもインストールする機会を得ました。 さらに、プライマリおよびセカンダリRIBの概念が表示されます。 （インポートポリシーを使用して）セカンダリRIBにインストールするルートを明示的に指定できる点が異なります（インポートポリシーに関係なく、すべてがプライマリにインストールされます）。
リブグループを使用した例を考えてみましょう。
例：
指定：MPLSネットワーク、その中にIGPとMP-BGPのみが実行されている専用BGP RR（これらのLDP / RSVP-TEは存在しません（たとえば、JCSをリフレクターとして使用し、転送方法がわからないため、LDPはありません） +安定性（不要なものはすべてオフになっているため）が必要です）、それに応じて、inet.3テーブルにルートをインストールする人はいません）。 このシナリオの問題は、vpnv4ルートを適切にするには、Junosのbgpの観点から、そのネクストホップがinet.3テーブル内にある必要があるということです。
root@JunLAB:RR> show route table bgp.l3vpn.0
bgp.l3vpn.0: 9 destinations, 9 routes (0 active, 0 holddown, 9 hidden )
root@JunLAB:RR>
9つの隠されたルート。 理由：
root@JunLAB:RR> ...ute table bgp.l3vpn.0 hidden extensive | grep "Next hop"
Next hop type: Unusable
root@JunLAB:RR> show route table inet.3
root@JunLAB:RR>
inet.3が空であるように
LDPはオフになっていますが、デフォルトですべてをinetにインストールするIGPがあります。
inet.0とinet.3を含むrib-groupを作成し、bgpループバックルートのみがinet.3にインストールされていることを確認します（ルートフィルターと既知のIPアドレス範囲を使用）。
リブグループの説明：
root@JunLAB:RR> show configuration routing-options
rib-groups {
MPBGP_LB {
import-rib [ inet.0 inet.3 ];
import-policy INET3_LB;
}
}
ここで：
inet.0-プライマリ
inet.3-セカンダリ
ポリシーの説明：
policy-statement INET3_LB {
term LOOPBACKS {
from {
route-filter 192.168.250.0/24 longer;
}
to rib inet.3;
then accept;
}
then reject;
}
IGPへのポリシーのバインド：
root@JunLAB:RR# show protocols isis
lsp-lifetime 65535;
no-ipv6-routing;
rib-group inet MPBGP_LB;
level 1 disable;
level 2 wide-metrics-only;
interface fxp1.14 {
point-to-point;
}
interface lo0.8 {
passive;
}
commitaの後、ループバックへのルートがinetであることを確認してください。
root@JunLAB:RR> show route table inet.3
inet.3: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.250.1/32 *[IS-IS/18] 00:00:41, metric 20
> to 10.0.0.25 via fxp1.14
192.168.250.2/32 *[IS-IS/18] 00:00:41, metric 20
> to 10.0.0.25 via fxp1.14
192.168.250.3/32 *[IS-IS/18] 00:00:41, metric 10
> to 10.0.0.25 via fxp1.14
192.168.250.4/32 *[IS-IS/18] 00:00:41, metric 30
> to 10.0.0.25 via fxp1.14
192.168.250.5/32 *[IS-IS/18] 00:00:41, metric 30
> to 10.0.0.25 via fxp1.14
192.168.250.6/32 *[IS-IS/18] 00:00:41, metric 20
> to 10.0.0.25 via fxp1.14
192.168.250.7/32 *[IS-IS/18] 00:00:41, metric 30
> to 10.0.0.25 via fxp1.14
root@JunLAB:RR>
また、inet内にはネクストホップへのルートがあるため、vpnv4ルートは非表示になりません。
bgp.l3vpn.0: 9 destinations, 9 routes ( 9 active , 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.250.1:1:192.168.0.0/30
*[BGP/170] 00:22:08, localpref 100, from 192.168.250.1
AS path: I
> to 10.0.0.25 via fxp1.14, Push 16
...
また、リブグループは、vrfs間のルートリークを作成する必要がある場合に非常に便利です（IOSでは、このためにbgpプロセスを上げる必要があります。Junosでは、それなしで実行できます）。
または、vrfからGRTへのリークを実行します（IOSでは、これを実行できません（静的ルートを除き、あまり便利ではありません）。また、rib-groupはFBF（フィルターベースフォワーディング-シスコの世界のPBRのアナログ）で使用されます。