Demystifying Juniper's rib-groups
Many of my friends do not fully understand the mechanism of work of rib-groups inside Juniper's JunOS. In this article, I will try to most simply explain what it is - rib-groups, and why they are needed.
Details under the cut.
First you need to understand how the routing table in Junos is populated. This happens (schematically) as follows:
[protocol] _____ [protocol's db] _____ [RIB]
where:
protocol is the routing protocol in the framework of Junos (this is not exactly a routing protocol in its
classical understanding, for this also includes, say, the router interfaces)
protocol db - protocol database (e.g. isis / ospf / bgp database). All routes are entered here, and the best one is selected, after which it is installed in RIB.
RIB is the routing itself. Depends on which protocol we use and where we use it (eg. Ipv4 routes go to inet.0, ldp to inet.3; routes inside vrf / virt router in.inet.0, etc.)
The rib-group mechanism allows us to use the following construction:
[protocol] _________ [protocol's db] ______________________ [RIB-Group],
where the RIB-Group consists of:
Primary RIB - a table where the protocol installs its default
Secondary RIB routes - one or more additional routing tables where we want the protocol to install its routes as well.
Import-Policy - a policy that describes how of the routes we allow to install in 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. Moreover, the concepts of Primary and Secondary RIB appear. They differ in that we can (using import policy) explicitly specify which routes to install in secondary RIB (everything is installed in primary, regardless of import policy).
Consider an example using rib-groups.
Example:
Given: MPLS network, in it a dedicated BGP RR, on which only IGP and MP-BGP are running (those LDP / RSVP-TE are not present (for example, we use JCS as a reflector, and, since it doesn’t know how to forward, LDP is not there anyway you need + stability (since everything superfluous is turned off)), and, accordingly, there is no one to install routes in inet.3 table). The problem with this scenario is that in order for the vpnv4 route to be suitable, from the point of view of bgp in Junos, its next-hop must be inside the inet.3 table. 9 hidden routes. Reason: as we see inet.3 is empty. We have LDP turned off, but there is IGP, which by default installs everything in inet.0
Let's create a rib-group that includes inet.0 and inet.3, and make sure that only bgp loopback routes (via route-filter and a previously known range of ip addresses) are
installed in inet.3 rib-group description: where: inet.0 - primary inet.3 - secondary Policy description: Bind the policy to IGP: After commita, make sure that routes to loopbacks are inet.3 and vpnv4 routes are no longer hidden, because routes to next-hop appeared s inside inet.3 Just rib-group's very convenient to use when you need to make a route leak between vrf'ami (in IOS for this it is necessary to raise the bgp process Junos can do without Mr. th)
Or leak from vrf to GRT (you can't do it in IOS (except for static routes, which is not very convenient). Also, rib-group are used in FBF (filter bassed forwarding - analogue of PBR from cisco's world).
Details under the cut.
First you need to understand how the routing table in Junos is populated. This happens (schematically) as follows:
[protocol] _____ [protocol's db] _____ [RIB]
where:
protocol is the routing protocol in the framework of Junos (this is not exactly a routing protocol in its
classical understanding, for this also includes, say, the router interfaces)
protocol db - protocol database (e.g. isis / ospf / bgp database). All routes are entered here, and the best one is selected, after which it is installed in RIB.
RIB is the routing itself. Depends on which protocol we use and where we use it (eg. Ipv4 routes go to inet.0, ldp to inet.3; routes inside vrf / virt router in
The rib-group mechanism allows us to use the following construction:
[protocol] _________ [protocol's db] ______________________ [RIB-Group],
where the RIB-Group consists of:
Primary RIB - a table where the protocol installs its default
Secondary RIB routes - one or more additional routing tables where we want the protocol to install its routes as well.
Import-Policy - a policy that describes how of the routes we allow to install in 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. Moreover, the concepts of Primary and Secondary RIB appear. They differ in that we can (using import policy) explicitly specify which routes to install in secondary RIB (everything is installed in primary, regardless of import policy).
Consider an example using rib-groups.
Example:
Given: MPLS network, in it a dedicated BGP RR, on which only IGP and MP-BGP are running (those LDP / RSVP-TE are not present (for example, we use JCS as a reflector, and, since it doesn’t know how to forward, LDP is not there anyway you need + stability (since everything superfluous is turned off)), and, accordingly, there is no one to install routes in inet.3 table). The problem with this scenario is that in order for the vpnv4 route to be suitable, from the point of view of bgp in Junos, its next-hop must be inside the inet.3 table. 9 hidden routes. Reason: as we see inet.3 is empty. We have LDP turned off, but there is IGP, which by default installs everything in inet.0
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>
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>
Let's create a rib-group that includes inet.0 and inet.3, and make sure that only bgp loopback routes (via route-filter and a previously known range of ip addresses) are
installed in inet.3 rib-group description: where: inet.0 - primary inet.3 - secondary Policy description: Bind the policy to IGP: After commita, make sure that routes to loopbacks are inet.3 and vpnv4 routes are no longer hidden, because routes to next-hop appeared s inside inet.3 Just rib-group's very convenient to use when you need to make a route leak between vrf'ami (in IOS for this it is necessary to raise the bgp process Junos can do without Mr. th)
root@JunLAB:RR> show configuration routing-options
rib-groups {
MPBGP_LB {
import-rib [ inet.0 inet.3 ];
import-policy INET3_LB;
}
}
policy-statement INET3_LB {
term LOOPBACKS {
from {
route-filter 192.168.250.0/24 longer;
}
to rib inet.3;
then accept;
}
then reject;
}
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;
}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> 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
...
Or leak from vrf to GRT (you can't do it in IOS (except for static routes, which is not very convenient). Also, rib-group are used in FBF (filter bassed forwarding - analogue of PBR from cisco's world).