Demystifying Juniper's rib-groups

Many of my friends do not fully understand the mechanism of rib-groups inside Juniper's JunOS. In this article I will try to explain most simply what it is - rib-groups, and why they are needed.
Details under the cut.


First you need to understand how the routing table is filled in Junos. Occurs (schematically) this as follows:

[protocol] _____ [protocol's db] _____ [RIB]
')
Where:

protocol - the routing protocol within Junos (this is not exactly the routing protocol in its
a classic understanding, because here we will also say router interfaces)

protocol's db - protocol database (for example, isis / ospf / bgp database). All routes are entered here and the best one is selected, after which it is installed in the RIB.

RIB is the routing tag itself. It depends on what protocol we use and where we use it (eg. Ipv4 routes go to inet.0, ldp - inet.3; route inside vrf / virt router in <vrf.name> .inet.0 and etc.)

The rib-group mechanism allows us to use a trace structure:

[protocol] _________ [protocol's db] ______________________ [RIB-Group],

where RIB-Group consists of:
Primary RIB - a table where the protocol by default installs its routes
Secondary RIB - one or more additional routing tables, where we want the protocol to also install its own routes.
Import-Policy is a policy that describes how we allow installation of routes in the Secondary RIB, and which are not.

Those we got the opportunity to install the routes received from the routing protocol, not only in the table with which it works by default, but also in any other. And there are concepts of Primary and Secondary RIB. They differ in that we can (with the help of the import policy) explicitly indicate which routes to install in the secondary RIB (everything will be installed in the primary, regardless of the import policy).

Consider an example of using rib-groups.

Example:
Given: MPLS network, there is a dedicated BGP RR in it, on which only IGP and MP-BGP are launched (LDP / RSVP-TE are not available (for example, we use JCS as a reflector, and because I cannot forward it anyway) need + stability (tk all unnecessary off)), and, accordingly, there is no one to install the routes in the inet.3 table). The problem with this scenario is that in order for the vpnv4 route to be valid, from the bgp point of view in Junos, its next-hop must be inside the inet.3 of the table.

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 hidden routes. Cause:

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>

as we see inet.3 empty

We have LDP turned off, but there is IGP, which by default installs everything in inet.0

Create a rib-group, including inet.0 and inet.3, and make it so that only bgp loopback routes will be installed in inet.3 (via route-filter and a previously known ip address range)

description of rib-group:

root@JunLAB:RR> show configuration routing-options
rib-groups {
MPBGP_LB {
import-rib [ inet.0 inet.3 ];
import-policy INET3_LB;
}
}

Where:
inet.0 - primary
inet.3 - secondary

Policy description:

policy-statement INET3_LB {
term LOOPBACKS {
from {
route-filter 192.168.250.0/24 longer;
}
to rib inet.3;
then accept;
}
then reject;
}


Bind policy to 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;
}

After commita we make sure that the paths to the loopbacks are in inet.3

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>

And vpnv4 routes are no longer hidden, since routes appeared to next-hop inside inet.3

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
...


It’s very convenient to use rib-group's when you need to make route leak between vrfs (in IOS, you need to raise the bgp process, you can do without it in Junos)
Or make a leak from vrf to GRT (in IOS, this cannot be done (acrometing route statics, which is not very convenient). Also, rib-group is used in FBF (filter bassed forwarding is an analogue of PBR from cisco's world).