BGP State Machine

BGP goes through six states to establish an adjacency.
Idle – incoming connections are refused, and the system gets ready to start speaking BGP. After this is done (by way of a Start event), move to Connect.
Connect – a connection is made to the peer. Send a BGP OPEN message, and go to OpenSent.
Active – a connection comes in from a peear. Send a BGP OPEN message, and go to OpenSent.
OpenSent – Wait for an OPEN message from the peer. When received, send a KEEPALIVE and go to OpenConfirm.
OpenConfirm – Wait for the KEEPALIVE from the peer, then move to Established.
Established – Bidirectional communication is established. Start sending UPDATE and KEEPALIVE messages as required

BGP Message Types

There are four types of packets that are part of the base BGPv4 protocol:
OPEN – As above, used to negotiate the parameters of a session (ie timers) during initialization
UPDATE – Used to advertise new routes, or withdraw old routes. The packet looks like:

+-----------------------------------------------------+
      |   Withdrawn Routes Length (2 octets)                |
      +-----------------------------------------------------+
      |  Withdrawn Routes (variable)                        |
      +-----------------------------------------------------+
      |   Total Path Attribute Length (2 octets)            |
      +-----------------------------------------------------+
      |    Path Attributes (variable)                       |
      +-----------------------------------------------------+
      |   Network Layer Reachability Information (variable) |
      +-----------------------------------------------------+

Since the list of added and removed routes is variable, it is possible (and encouraged) to have multiple routes in one packet if they share common path attributes. For example, if two routes had an AS-PATH of “1 2″, they could both go in the NLRI field. If a third route had an AS-PATH of “3 1 2″, then it would need a separate packet.
KEEPALIVE – Sent every 1/3 of the HoldTime to indicate the peer is still alive
NOTIFICATION – Indicate an error condition, after which both sides close the connection and move back to the Idle state.

BGP Timers

Several timers are in use to control the intervals of BGP events.
HoldTime – If a peer has not received an UPDATE or KEEPALIVE message by this time, it is considered dead. By default this is 180 seconds on Cisco, though is determined in the OPEN packet (smallest of the two is used)
KeepAlive – Set to 1/3 of HoldTime, a peer should send a KEEEPALIVE message if it hasn’t sent an UPDATE in that interval
ConnectRetry – 120 seconds by default, it controls how often an idle router will try to connect to its peer.
MinASOriginationInterval – Used to space out UPDATE messages dealing with routes coming from the speaker’s AS
MinRouteAdvertisementInterval – Any route will not be advertised twice within this interval. The RFC states that it will be difficult to keep a timer for every route, so it proposes some alternatives.