White Papers

Sessions and Peers
When two routers communicate using the BGP protocol, a BGP session is started. The two endpoints of that session are Peers.
A Peer is also called a Neighbor.
Establish a Session
Events and timers drive information exchange between peers. The focus in BGP is on the traffic routing policies.
In order to make decisions in its operations with other BGP peers, a BGP process uses a simple finite state machine that
consists of six states: Idle, Connect, Active, OpenSent, OpenConfirm, and Established. For each peer-to-peer session, a BGP
implementation tracks which of these six states the session is in. The BGP protocol defines the messages that each peer should
exchange to change the session from one state to another.
State
Description
Idle BGP initializes all resources, refuses all inbound BGP connection attempts, and initiates a TCP connection
to the peer.
Connect In this state the router waits for the TCP connection to complete, transitioning to the OpenSent state if
successful.
If that transition is not successful, BGP resets the ConnectRetry timer and transitions to the Active state
when the timer expires.
Active The router resets the ConnectRetry timer to zero and returns to the Connect state.
OpenSent After successful OpenSent transition, the router sends an Open message and waits for one in return.
OpenConfirm After the Open message parameters are agreed between peers, the neighbor relation is established and is
in the OpenConfirm state. This is when the router receives and checks for agreement on the parameters
of open messages to establish a session.
Established Keepalive messages are exchanged next, and after successful receipt, the router is placed in the
Established state. Keepalive messages continue to be sent at regular periods (established by the
Keepalive timer) to verify connections.
After the connection is established, the router can now send/receive Keepalive, Update, and Notification messages to/from its
peer.
Peer Groups
Peer Groups are neighbors grouped according to common routing policies. They enable easier system configuration and
management by allowing groups of routers to share and inherit policies.
Peer groups also aid in convergence speed. When a BGP process needs to send the same information to many peers, the BGP
process needs to set up a long output queue to get that information to all the proper peers. If the peers are members of a peer
group however, the information can be sent to one place and then passed onto the peers within the group.
Route Reflectors
Route reflectors reorganize the iBGP core into a hierarchy and allow some route advertisement rules.
Route reflection divides iBGP peers into two groups: client peers and nonclient peers. A route reflector and its client peers
form a route reflection cluster. Because BGP speakers announce only the best route for a given prefix, route reflector rules are
applied after the router makes its best path decision.
● If a route was received from a nonclient peer, reflect the route to all client peers.
● If the route was received from a client peer, reflect the route to all nonclient and all client peers.
To illustrate how these rules affect routing, refer to the following illustration and the following steps. Routers B, C, D, E, and G
are members of the same AS (AS100). These routers are also in the same Route Reflection Cluster, where Router D is the Route
Reflector. Router E and H are client peers of Router D; Routers B and C and nonclient peers of Router D.
158
Border Gateway Protocol IPv4 (BGPv4)