Editing Border Gateway Protocol (section)

=== Router connectivity and learning routes ===
{{technical|section|date=April 2021}}
In the simplest arrangement, all routers within a single AS and participating in BGP routing must be configured in a full mesh: each router must be configured as a peer to every other router. This causes scaling problems, since the number of required connections [[quadratic growth|grows quadratically]] with the number of routers involved. To alleviate the problem, BGP implements two options: [[route reflector]]s (RFC 4456) and [[BGP confederation]]s (RFC 5065). The following discussion of basic update processing assumes a full iBGP mesh.

A given BGP router may accept [[#Update Packet|network-layer reachability information (NLRI) updates]] from multiple neighbors and advertise NLRI to the same, or a different set, of neighbors. The BGP process maintains several [[routing information base]]s:
* <code>RIB</code>: routers main routing information base table.
* <code>Loc-RIB</code>: local routing information base BGP maintains its own master routing table separate from the main routing table of the router.
* <code>Adj-RIB-In</code>: For each neighbor, the BGP process maintains a conceptual ''adjacent routing information base, incoming'', containing the NLRI received from the neighbor.
* <code>Adj-RIB-Out</code>: For each neighbor, the BGP process maintains a conceptual ''adjacent routing information base, outgoing '', containing the NLRI sent to the neighbor.

The physical storage and structure of these conceptual tables are decided by the implementer of the BGP code. Their structure is not visible to other BGP routers, although they usually can be interrogated with management commands on the local router. It is quite common, for example, to store the <code>Adj-RIB-In</code>, <code>Adj-RIB-Out</code> and the <code>Loc-RIB</code> together in the same data structure, with additional information attached to the RIB entries. The additional information tells the BGP process such things as whether individual entries belong in the <code>Adj-RIBs</code> for specific neighbors, whether the peer-neighbor route selection process made received policies eligible for the <code>Loc-RIB</code>, and whether <code>Loc-RIB</code> entries are eligible to be submitted to the local router's routing table management process.

BGP submits the routes that it considers best to the main routing table process. Depending on the implementation of that process, the BGP route is not necessarily selected. For example, a directly connected prefix, learned from the router's own hardware, is usually most preferred. As long as that directly connected route's interface is active, the BGP route to the destination will not be put into the routing table. Once the interface goes down, and there are no more preferred routes, the Loc-RIB route would be installed in the main routing table.

BGP carries the information with which rules inside BGP-speaking routers can make policy decisions. Some of the information carried that is explicitly intended to be used in policy decisions are:
* [[#Communities|Communities]]
* [[#Multi-exit discriminators|multi-exit discriminators]] (MED).
* [[autonomous system (Internet)|autonomous systems]] (AS)