Understanding and configuring Rib Groups

Summary

RIB groups (or Routing Table Groups) are similar to the Auto Export feature, allowing a PE to share local routes across multiple VRFs (or RIBs).

The end goal of Auto Export and a Rib Group is the same however the latter is more flexible as it allows more specific configuration where by individual routes can be leaked between different VRFs based on configuration options and policy; this is more flexible and powerful than the more basic VRF import/export statements that Auto Export offers.

Rib Groups are also bound to specific routing protocols, static routes or directly connected routes, so by nature the policies for leaking routes are more structured and defined.

How to configure a Rib Group

The first configuration step should be applied at the global routing-options level to define a Rib Group name. Within that heirarchy statements are made to request which RIB (or VRF) routes are taken from and where they are placed. The “import-rib” statement is used for this by taking copies of routes from the first listed rib in the square brackets and placing those routes into the second listed rib in the square brackets.

Furthermore the optional import-policy statement allows the Rib Group to be linked to a policy that can be used to specify certain routes to be leaked; this is where the functionality of a Rib Group becomes more flexible, as Auto Export relies specifically on the policies applied within the VRF import/export statements; these statements are considered to be more fundamental to the structure of the wider VPN topology and therefore should be kept as simplistic as possible.

In the following configuration green-vpn-a.inet.0 will place a route into green-vpn-b.inet.0:

routing-options {
rib-groups {
green-a-to-b {
import-rib [ green-vpn-a.inet.0 green-vpn-b.inet.0 ];
import-policy rib-group-green-vpn-policy;
}
}
router-id 172.25.1.1;
autonomous-system 45501;
}

The import into green-vpn-a.inet.0 is also passed through a policy called rib-group-green-vpn-policy which has been explicitly configured to only leak a direct 1.1.1.1/32 route:

policy-options {
policy-statement rib-group-green-vpn-policy {
term a {
from {
protocol direct;
route-filter 1.1.1.1/32 exact accept;
}
}
term z {
then reject;
}
}
}

The Rib Group is then applied within the routing options hierarchy in the source VRF; which in this case is green-vpn-a. In addition to applying the rib group within the VRF the “interface-routes” statement is also added to instruct the PE to also copy directly connected routes within the source VRF that are associated as next hops to the routes being leaked. This is an important aspect of the configuration because without this statement the routes that are leaked would become hidden, because the protocol next-hop would not be available in the destination RIB.

Because rib groups operate at a protocol level the rib group must also be applied to the respective routing protocols that exist within the source VRF; this allows the routes to be ‘picked up’ from the source protocol and delivered into the rib group. In this configuration the rib group a-to-b is placed at the BGP inet unicast level and thus will match on all routes being received across this BGP neighbourship.

One important aspect of rib groups that differs from auto export is that the BGP split horizon rule is not considered when leaking routes. When configuring rib groups it’s considered best practice to change the vrf export policy on the destination table to stop the announcement of the leaked routes. This protects from any potential routing loops or sub optimal routing. It may not always be required, it depends on the VPN topology and requirements for applying route leaking.

http://kb.juniper.net/InfoCenter/index?page=content&id=KB16133&smlogin=true

RIB Groups

Section 1: The Requirement For RIB Groups

This article is going to take you through the process of setting up a RIB group, and will help to clear up any misunderstanding of how this feature works, and how it differs from other methods of routing leaking.

Due to the way in which Juniper uses certain terminology, this feature can seem confusing and convoluted. What’s more confusing is that both auto-export and RIB groups can provide route leaking, so why bother having both?

Well, the answer is simply that RIB groups are more powerful than traditional route leaking methods. RIB groups effectively leak routes by using a router’s RIB-in/import process, as opposed to the more commonly understood method of using route-target import and export leaking policies between VRFs.

The benefit of using a RIB group over traditional configuration is that by decoupling the policy away from the VRF import/export policy, and associating the route leaking at a protocol level (which is how a RIB group works), you have more flexibility to apply granular policy, that is not convoluted and tied into another process the router is handling.

So by design, it makes more sense to use VRF policies for their sole purpose (which is to control routes that are being imported and exported into MP-BGP), and to apply route leaking policies at a local protocol level, using a different set of policies and commands.

Section 2: Setting Up The Lab

In order to demonstrate how this works I’m going to use the lab environment detailed below to leak a number of routes between two VRFs.

The lab will consist of these elements:

  • Two PE routers known as r2 and r4 connected using MP-BGP
  • Two VRFs known as vpn-b and vpn-c configured on each of the PEs
  • Site A CPE2 attached to the r2 PE
  • Site B CPE1 attached to the r4 PE

The IP addresses and associated VRFs shown below will be used to simulate route leaking between the two VRFs known as vpn-b and vpn-c:

  • Site A CPE2 Lo.10 172.18.0.1/32 inside vpn-b
  • Site B CPE1 Lo.11 172.18.1.2/32 inside vpn-c

Figure 2.1: Lab Topology

The diagram below shows the network topology with each CPE attached to each PE. The CPE in site A has an interface in vpn-b, and the CPE in site B has an interface in vpn-c.

physical_rib

The purpose of the lab will be to provide connectivity between the loopback addresses on each of the CPEs; this will require bidirectional route leaking on each local PE, using a RIB group.

I will document each step of the configuration, and will explain how each step relates to the process of route leaking within the RIB group.

At the end of the lab some pings will be sent between the two CPEs, to confirm the RIB group configuration has been successful.

Section 3: Creating The RIB Group

Under the global routing-options heirarchy the name of the RIB group should be configured first. The RIB group can be referenced at various protocol and RIB levels, so having the main policy and configuration location at global level makes sense.

Once the RIB group has been named subsequent parameters should define the source RIB that routes should be taken from, and the destination RIB they should be sent to.

As shown in figure 3.1 the import-rib statement is used to name the RIB group on PE r2, and is followed by a list of RIBs that are in scope for route leaking.

The router interpretes the first RIB in the square brackets (vpn-b) as the source table, (which is where routes are copied from), and any subsequent RIBs as the destination tables where the routes will be copied to.

Note: The configuration created here includes an optional import policy – this is to be used to explicitly state the prefix and protocol that will be imported into the RIB group.

Figure 3.1

routing-options {
vpn-b-to-vpn-c {
import-rib [ vpn-b.inet.0 vpn-c.inet.0 ];
import-policy rib-group-vpn-b-to-c;
}
}

Figure 3.2

The import-policy referenced in the above configuration is shown below. Applying this gives granularity to the routes that are going to be leaked into vpn-c.

Without this policy all routes in vpn-b would be leaked into vpn-c.

policy-options {
policy-statement rib-group-vpn-b-to-c {
term 10 {
from {
protocol bgp;
route-filter 172.18.0.1/32 exact;
}
then accept;
}
term 100 {
then reject;
}
}
}

Figure 3.3

I have included some outputs of the current VRFs on PE r2. The outputs are specifically  querying the route that I wish to leak into vpn-c.

lab@r2# run show route table vpn-b.inet.0 172.18.0.1/32 exact
vpn-b.inet.0: 11 destinations, 12 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, – = Last Active, * = Both
172.18.0.1/32 *[BGP/170] 03:54:32, localpref 100
AS path: 65501 I, validation-state: unverified
> to 172.17.0.2 via ge-0/0/0.30

Figure 3.4

As we can see PE r2’s vpn-c table currently has no route to 172.18.0.1/32, because this route is learnt via an attached CPE in vpn-b.

lab@r2# run show route table vpn-c.inet.0 172.18.0.1/32 exact
[edit]
lab@r2#

Section 4: Applying The Configuration To BGP

As previously explained route leaking using RIB groups is carried out at the protocol level, as routes enter RIB-in.

Based on that theory, the configuration shown in figure 4.1 will be applied to the BGP protocol in vpn-b, under the respective address family; applying at the address family level makes sense, as Junos stores address families in different RIBs, such as inet0 for IPv4, and inet6 for IPv6.

The configuration calls the RIB group previously setup under the global routing-options heirarchy, thus inheriting all policy defined within that configuration.

Figure 4.1

routing-instances vpn-b {
protocols {
bgp {
group vpn-b {
neighbor 172.17.0.2 {
description vpn-b-test-ebgp;
mtu-discovery;
family inet {
unicast {
rib-group vpn-b-to-vpn-c;
}
}
peer-as 65501;
}
}
}
}
}

Figure 4.2

Once the above configuration has been commited the vpn-c routing tables on the r2 PE can be checked again.

The output shown below confirms that the route leaking configuration has been successful, as vpn-c now has a route to the loopback address of site A CPE2.

This isn’t the end of this task though, as there are a number of additional steps that need to be taken to successfully ping from site B CPE1 (via vpn-c), to the route that has just been leaked from vpn-b.

lab@r2# run show route table vpn-c.inet.0 172.18.0.1/32 exact
vpn-c.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, – = Last Active, * = Both
172.18.0.1/32 *[BGP/170] 01:14:50, localpref 100
   AS path: 65501 I, validation-state: unverified
> to 172.17.0.2 via ge-0/0/0.30
[edit]
lab@r2#

Section 5: Next Hop Interfaces

The previous steps have enabled the loopback address of 172.18.0.1/32 from site A CPE2 to be successfully route leaked into vpn-c, with a next hop of address of 172.17.0.2, via ge-0/0/0.30.

This next hop interface presents a problem though, as it exists exclusively in vpn-b, and we need this next hop interface available in vpn-c, otherwise routing to the destination loopback address in vpn-b is not going to be possible.

Figure 5.1

To confirm the current situation, the output below from PE r2 shows there is currently no route in vpn-c to the next hop address of 172.17.0.2.

lab@r2# run show route table vpn-c 172.17.0.2
[edit]
lab@r2#

Section 6: Understanding Interface Routes

Because RIB groups act on protocols using RIB-in, some additional configuration is going to be needed to route leak the connected next hop interface into vpn-c – this is taken care of using the interface-routes command.

Now we know that RIB groups operate at a protocol RIB-in level, so it should be expected that when handling connected routes, the commands are going to look slightly different to that of importing from a dynamic routing protocol.

Figure 6.1

Below you can see the interface-routes command being applied under the routing options heirarchy within the source RIB, which in our case is vpn-b.

This command will use the previously defined RIB group policy setup under the global routing-options heirarchy to match any directly connected routes within vpn-b, thus leaking them into vpn-c.

routing-instances vpn-b {
routing-options {
interface-routes {
rib-group inet vpn-b-to-vpn-c;
}
}
}

Figure 6.2

Because the interface-routes command references the main RIB group configuration it will of course inherit any policy that’s previously been applied to the RIB group.

In order to allow the next hop address to leak into vpn-c a change is also going to be required to the initial policy I created to control which routes can be leaked into vpn-c.

Shown below is an additional term (term 20) that has been added to that policy to enable this requirement.

policy-options {
policy-statement rib-group-vpn-b-to-c {
term 20 {
from {
protocol direct;
route-filter 172.17.0.0/30 exact;
}
then accept;
}
}
}

Figure 6.3

Once the configuration is committed vpn-c has aquired the next hop route 172.17.0.0/30.

lab@r2# run show route table vpn-c 172.17.0.0
vpn-c.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, – = Last Active, * = Both
172.17.0.0/30 *[Direct/0] 00:47:50
> via ge-0/0/0.30
[edit]
lab@r2#

Section 7: Final Steps

Theoretically vpn-c now has all of the required routes to forward packets towards the CPE2 loopback address in vpn-b at site A.

To establish end to end connectivity routing has to work in both directions, and in order to achieve this the steps we have take above (from vpn-c’s perspective) will need to be implemented from vpn-b’s perspective; so a loopback address that’s originated in vpn-c can also be reached from the CPE at site A.

Because the fundamental steps of route leaking have been detailed in the previous sections I’m going to summarise this configuration in a few figures below.

Figure 7.1

Here you can see the creation of the RIB group on PE r2 at site B, where everything is effectively reversed to leak back into vpn-b.

routing-options {
vpn-c-to-vpn-b {
import-rib [ vpn-c.inet.0 vpn-b.inet.0 ];
import-policy rib-group-vpn-c-to-b;
}
}

Figure 7.2

The RIB group policy that stipulates route leaking of the loopback address and next-hop interface at site B in vrf-c is shown below.

policy-options {
policy-statement rib-group-vpn-c-to-b {
term 10 {
from {
protocol bgp;
route-filter 172.18.1.2/32 exact;
}
then accept;
}
term 20 {
from {
protocol direct;
route-filter 172.17.1.4/30 exact;
}
then accept;
}
term 100 {
then reject;
}
}
}

Figure 7.3

The final configuration step is to apply the RIB group on PE r2 under the BGP protocol heirarchy in vpn-c, which is shown below.

routing-instances vpn-c {
protocols {
bgp {
group vpn-c {
neighbor 172.17.1.6 {
description vpn-c-test-ebgp;
mtu-discovery;
family inet {
unicast {
rib-group vpn-c-to-vpn-b;
}
}
peer-as 65503;
}
}
}
}
}

Section 8: Testing Connectivity

Now that everything is in place we can test connectivity using a ping sourced from the site A CPE1 device, pinging from the test loopback address to the test loopback address at site B on CPE2.

The results of which are shown below in figure 8.1.

Figure 8.1

lab123@site-a-cpe-1# …rce 172.18.0.1 routing-instance vpn-b
PING 172.18.1.2 (172.18.1.2): 56 data bytes
64 bytes from 172.18.1.2: icmp_seq=0 ttl=62 time=24.225 ms
64 bytes from 172.18.1.2: icmp_seq=1 ttl=62 time=20.661 ms
64 bytes from 172.18.1.2: icmp_seq=2 ttl=62 time=20.334 ms
64 bytes from 172.18.1.2: icmp_seq=3 ttl=62 time=20.884 ms

Appendix A: Link-State Protocols (OSPF/ISIS)

Because route leaking with RIB groups is applied at the RIB in (or import) level, configuring this feature with link-state protocols is effectively the same process as when using BGP.

For this reason I have not included an example of how to this with OSPF or ISIS. One can assume that the configuration is exactly the same, you simply create the RIB group at the global routing-options heirarchy and then apply it directly under the protocol heirarchy.

Appendix B: Notes regarding BGP Split Horizon

One important aspect of RIB groups that differs from auto export is that the BGP split horizon rule is not considered when leaking routes. When configuring RIB groups it’s considered best practice to change the vrf export policy on the destination table to stop the announcement of the leaked routes. This protects from any potential routing loops or sub optimal routing. It may not always be required, it depends on the VPN topology and requirements for applying route leaking.

Continue reading “RIB Groups”