BGP Routing Information Base (RIB)

BGP is an intimate friend for all service provider engineers. Without BGP there is no internet, there is no MPLS VPN and there are no many other things now and in the days to come. I believe its healthy to visit your friends from time to time and know how you live :)

Any BGP speaker receives routing updates from other peers, processes the information for local use and then advertise selected routes to different peers based on predefined policies. In order for BGP to be able to perform its functions it stores this information is a special type of database called the BGP  Routing Information Base.

BGP Routing Information Base consists of three parts as explained below:

• The Adj-RIBs-In: BGP RIB-In stores BGP routing information received from different peers. The stored information is used as an input to BGP decision process. In other words this is the information received from peers before applying any attribute modifications or route filtering to them.

• The Local RIB: The local routing information base stores the resulted information from processing the RIBs-In database's information. These are the routes that are used locally after applying BGP policies and decision process.

• The Adj-RIBs-out: This one stores the routing information that was selected by the local BGP router to advertise to its peers through BGP update messages. Do not forget;  BGP only advertises best routes if they are allowed by local outbound policies.

The database described in this post is not to be confused with the routing table as these are only tables used by the BGP process only and never by the router for packet forwarding. Only the set of routes that exist in the Local-RIB are installed in the routing table based on a criteria specified by local BGP speaker (vendor implementation and preference of routing protocols).

The concept described above is not an implementation obligatory. This means that each vendor is free to use this exact approach for BGP implementation or not. For example Juniper is using the three distinct tables described in this post by default for its implementation while Cisco does not.

Vendor implementation is going to affect your daily operations with BGP, if you need to change your BGP policies at anytime, in case of Cisco you will need to reset the BGP connection to the peer so you receive the updates again to reprocess. To avoid the hard reset of BGP sessions (which is not accepted in service provider environments) you need to  configure the soft configuration inbound feature on Cisco routers OR your BGP speakers need to support Route Refresh Capability.