why the error occurred. If there is no error, a Keepalive message is sent, various timers are set and the state is changed to OpenConfirm. OpenConfirm State: The peer is listening for a Keepalive message from its peer. If a Keepalive message is received and no timer has expired before reception of the Keepalive, BGP transitions to the Established state. If a timer expires before a Keepalive message is received, or if an error condition occurs, the router transitions back to the Idle state. Established State: In this state, the peers send Update messages to exchange information about each route being advertised to the BGP peer. If there is any error in the Update message then a Notification message is sent to the peer, and BGP transitions back to the Idle state. Router connectivity and learning routes 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 grows quadratically with the number of routers involved. To alleviate the problem, BGP implements two options: route reflectors (RFC 4456) and BGP confederations (RFC 5065). The following discussion of basic update processing assumes a full iBGP mesh. A given BGP router may accept 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: RIB: routers main routing information base table. Loc-RIB: local routing information base BGP maintains its own master routing table separate from the main routing table of the router. Adj-RIB-In: For each neighbor, the BGP process maintains a conceptual adjacent routing information base, incoming, containing the NLRI received from the neighbor. Adj-RIB-Out: For each neighbor, the BGP process maintains a conceptual adjacent routing information base, outgoing , containing the NLRI send 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 Adj-RIB-In, Adj-RIB-Out and the Loc-RIB together in the same data structure, with additional information attached to the RIB entries. The additional information tells the BGP process