RIB Groups

RIB groups (or routing table groups) are similar in their function to the auto export feature, allowing a PE to share local routes across multiple VRFs (or RIBs). Although the objective of auto export and rib groups is the same the rib group feature is more flexible as it allows routes to be leaked between different VRFs based on configuration and optional policy that’s bound within the rib group as opposed to the VRF import/export statements that auto export uses. Rib groups are also bound to routing protocols, static routes or directly connected routes so by nature the policies for leaking routes are more structured within the rib group configuration.

In order to create a rib group the first step of configuration should be applied at the global routing-options level to define a rib group name. Within that heirarchy rib group statements are made to stipulate which RIB (or VRF) routes are taken from and where they are placed. The import-rib statement is used for this and takes copies of routes from the first listed rib in the square brackets into the second listed rib in the square brackets of the configuration.

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 than using auto export as auto export relies specifically on the policies applied within the VRF import/export statements, which are considered to be more fundamental to the structure of the wider VPN topology and therefore should be kept as simplistic as possible.

In this configuration rib vpn-a.inet.0 will place routes into vpn-b.inet.0. This import into vpn-b rib will be passed through a policy called vpn-a-policy which could be used to filter certain routes.

rib-group1

The rib group created above is then applied within the routing options hierarchy in the source VRF which in this case is vpn-a. In addition to applying the rib group within the VRF a second statement is also added (interface-routes) to instruct the PE to also copy directly connected routes within the source VRF. 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 excerpt 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.

Capture

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

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s