which peer will send the open message first?
Normally, the speaker that opens the socket sends the first OPEN message. But it actually doesn't matter (ref the DelayOpen timer), because BGP also provides a way to delay the OPEN message so the opposite peer can send first:
Option 1: DelayOpen
Description: The DelayOpen optional session attribute allows
implementations to be configured to delay sending
an OPEN message for a specific time period
(DelayOpenTime). The delay allows the remote BGP
Peer time to send the first OPEN message.
Value: TRUE or FALSE
In the event that both speakers open duplicate TCP sessions and send OPEN messages on each socket simultaneously, the BGP Identifier is used to resolve which socket should be closed. See RFC 4271, Section 6.8:
6.8. BGP Connection Collision Detection
If a pair of BGP speakers try to establish a BGP connection with each other
simultaneously, then two parallel connections well be formed. If the source IP address
used by one of these connections is the same as the destination IP address used by the
other, and the destination IP address used by the first connection is the same as the
source IP address used by the other, connection collision has occurred. In the event
of connection collision, one of the connections MUST be closed.
Based on the value of the BGP Identifier, a convention is established for detecting
which BGP connection is to be preserved when a collision occurs. The convention is to
compare the BGP Identifiers of the peers involved in the collision and to retain only
the connection initiated by the BGP speaker with the higher-valued BGP Identifier.
Is there any good BGP Peer fsm diagram?
Wikipedia has this simplified BGP FSM.
Absent any non-standard configuration, it is how you say. For outbound traffic, which uplink is used depends on which router the traffic hits. For inbound traffic, it should work the same way but that depends largely on your upstream's configuration. Full routes are really only required if you intend to peer with another upstream.
Best Answer
BGP Peers start in Idle state. In Idle state, the peers have been configured to form an adjacency with one another other, but have not yet initiated or received any communication.
BGP uses TCP as it's transport. So for there to be a BGP adjacency, the first step is to establish a TCP connection. While both peers are in IDLE state, they will each periodically attempt to initiate a TCP connection at independent intervals (based upon when the BGP peering configuration was actually completed).
When one peer initiates the TCP three way handshake with a SYN , that peer transitions into Active state. This state indicates the local router is actively trying to initiate a TCP connection.
When the other peer receives the TCP SYN from it's peer, it will transition into Connect state. This state indicates the local router has received a TCP initiation from the other router, and is/has responded with a SYN ACK.
From there, both peers continue through the remaining states: Open Sent, Open Confirmed, Established.
To summarize:
The "initiating" BGP speaker's state transitions to form the adjacency will be:
Idle,Active,Open Sent,Open Received,EstablishedThe "responding" BGP speaker's state transitions to form the adjacency will be:
Idle,Connect,Open Sent,Open Received,EstablishedNotice, only the peer which Initiated the TCP handshake passes through
Activestate. And only the peer which did NOT initiate the TCP handshake passes through theConnectstate.Adding some debugs which prove the behavior. This is Cisco router code Version 15.4(1)T.
This is from a BGP peering session between R1 (9.9.12.1) and R2 (9.9.12.2).
R2 is the initiator for this TCP session:
Confirmed on the other Router:
This is the (filtered) debug on R2, the initiator:
And this is the (filtered) debug on R1, the responder: