Neighbours with the lowest BGP router identifier will establish the connection to the remote peer via TCP port 179, the source port will be random. We can modify this behaviour with a few simple commands.
For example we want R1 to be a passive peer. That means that R2 and R3 will actively look to establish the session.
BGP
So from R1 if we leave everything as default then we can work out that R1 it the lowest router identifier, courtesy of a loop-back interface which is 10.4.1.1. So it will look to actively establish the connection with any configured peers.
R1#sh ip bgp summary
BGP router identifier 10.4.1.1, local AS number 500
We can verify this with the following command.
R1#sh ip bgp neighbors | i host
Local host: 150.1.1.2, Local port: 57717
Foreign host: 150.1.1.1, Foreign port: 179
Local host: 150.1.1.6, Local port: 63542
Foreign host: 150.1.1.5, Foreign port: 179
Lets modify this behaviour, use the commands.
router bgp 500
neighbor 150.1.1.1 transport connection-mode passive
neighbor 150.1.1.5 transport connection-mode passive
Then clear the BGP session with clear ip bgp *
Now use the same command as before.
R1#sh ip bgp neighbors | i host
Local host: 150.1.1.2, Local port: 179
Foreign host: 150.1.1.1, Foreign port: 34121
Local host: 150.1.1.6, Local port: 179
Foreign host: 150.1.1.5, Foreign port: 32711
This shows us that foreign host has established the bgp connection sourcing from random port to port 179 on our local router.
RFC4271 which is the holy grail for BGP-4 states that.
8.2.1
When a BGP speaker is configured as active,
it may end up on either the active or passive side of the connection
that eventually gets established. Once the TCP connection is
completed, it doesn’t matter which end was active and which was passive.
The only difference is in which side of the TCP connection has port number 179.
There exists a period in which the identity of the peer on the other
end of an incoming connection is known, but the BGP identifier is not
known. During this time, both an incoming and outgoing connection
may exist for the same configured peering. This is referred to as a
connection collision.
Interesting.
RH
all-things-networking 
Thanks, this is the only good info on BGP Active and Passive I could find.
Good post. Thanks!
clearly and useful information, thanks.
This is the best basic explanation on the internet! Thanks
Good post. Thanks!
And for better understanding about BGPConnection collision detection please go though below.
6.8 Connection collision detection.
If a pair of BGP speakers try simultaneously to establish a TCP connection to each other, then two parallel connections between this pair of speakers might well be formed. We refer to this situation as connection collision. Clearly, one of these 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 does occur. 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.
Upon receipt of an OPEN message, the local system must examine all of its connections that are in the OpenConfirm state. A BGP speaker may also examine connections in an OpenSent state if it knows the BGP Identifier of the peer by means outside of the protocol. If among these connections there is a connection to a remote BGP speaker whose BGP Identifier equals the one in the OPEN message, then the local system performs the following collision resolution procedure:
The BGP Identifier of the local system is compared to the BGP Identifier of the remote system (as specified in the OPEN message).
If the value of the local BGP Identifier is less than the remote one, the local system closes BGP connection that already exists (the one that is already in the OpenConfirm state), and accepts BGP connection initiated by the remote system.
Otherwise, the local system closes newly created BGP connection (the one associated with the newly received OPEN message), and continues to use the existing one (the one that is already in the OpenConfirm state).
Comparing BGP Identifiers is done by treating them as (4-octet long) unsigned integers.
A connection collision with an existing BGP connection that is in Established states causes unconditional closing of the newly created connection. Note that a connection collision cannot be detected with connections that are in Idle, or Connect, or Active states.
Closing the BGP connection (that results from the collision resolution procedure) is accomplished by sending the NOTIFICATION message with the Error Code Cease.
Thank you for copy pasting the RFC 🙂