Blog

From Idle to Established: BGP states, BGP ports and TCP interactions

Understanding BGP states is essential to grasp how BGP operates. Similar to interior gateway protocols (IGPs) like EIGRP, OSPF, or ISIS, BGP establishes peering with other routers before exchanging routing information. However, unlike IGPs, BGP does not utilize broadcast or multicast for neighbor discovery. Instead, neighbors are manually configured and BGP leverages TCP Port 179 to establish a reliable connection with neighboring BGP speakers. This allows for communication between BGP neighbors across any distance as long as TCP connectivity exists.

When routers are configured as BGP neighbors with each other’s IP address, one router functions as a TCP server while the other acts as a client, depending on which router initiates the connection. In the process of establishing a connection between a TCP client and server, the client initiates the connection by sending a TCP SYN packet to the server using the well-known port as the destination. This SYN serves as a request to open a session. If the server approves the session, it responds with a TCP SYN-ACK, indicating acknowledgment of the request and a desire to open the session. This response uses the well-known port as the source port and a randomly negotiated destination port. The final step of this three-way handshake is the client sending a TCP ACK to the server, acknowledging its response and completing the connection establishment.

The process is similar in the context of BGP, where routers act as TCP clients and servers. Let’s illustrate this with an example depicted in Figure 1. The router with the IP address 10.0.0.1 initiates the BGP session using TCP protocol moving from the Idle to Connect state of the BGP session, However, prior to sending any BGP message, a 3-way TCP handshake must be completed. The router initiating the handshake becomes the TCP client. The client sends a request (SYN packet) to the server, which is a BGP neighbor configured with the destination IP address 10.0.0.2. Syn packet is sent to port 179 with a randomly assigned source port 21888.

Understanding BGP states is essential to grasp how BGP operates. Similar to interior gateway protocols (IGPs) like EIGRP, OSPF, or ISIS, BGP establishes peering with other routers before exchanging routing information. However, unlike IGPs, BGP does not utilize broadcast or multicast for neighbor discovery. Instead, neighbors are manually configured and BGP leverages TCP Port 179 to establish a reliable connection with neighboring BGP speakers. This allows for communication between BGP neighbors across any distance as long as TCP connectivity exists.

When routers are configured as BGP neighbors with each other’s IP address, one router functions as a TCP server while the other acts as a client, depending on which router initiates the connection. In the process of establishing a connection between a TCP client and server, the client initiates the connection by sending a TCP SYN packet to the server using the well-known port as the destination. This SYN serves as a request to open a session. If the server approves the session, it responds with a TCP SYN-ACK, indicating acknowledgment of the request and a desire to open the session. This response uses the well-known port as the source port and a randomly negotiated destination port. The final step of this three-way handshake is the client sending a TCP ACK to the server, acknowledging its response and completing the connection establishment.

The process is similar in the context of BGP, where routers act as TCP clients and servers. Let’s illustrate this with an example depicted in Figure 1. The router with the IP address 10.0.0.1 initiates the BGP session using TCP protocol moving from the Idle to Connect state of the BGP session, However, prior to sending any BGP message, a 3-way TCP handshake must be completed. The router initiating the handshake becomes the TCP client. The client sends a request (SYN packet) to the server, which is a BGP neighbor configured with the destination IP address 10.0.0.2. Syn packet is sent to port 179 with a randomly assigned source port 21888.

Figure 1 – R1 and R2 Configured as eBGP Neighbors

Meanwhile, the BGP neighbor with IP 10.0.0.2 is not actively initiating a connection; instead, it serves as the TCP server. The server listens on port 179 and waits for incoming connection requests. Upon receiving the SYN packet from the client, the server then responds with a source port of 179 and the same randomly assigned destination port, 21888. As a result, all traffic from the client to the server uses destination port 179, while traffic from the server to the client uses source port 179 (Figure 2).

Note: Initially, the BGP session is in an Idle state, where BGP waits to start a BGP session. TCP 3-way TCP handshake occurs when the BGP session is in the Connect state.

Figure 2 – BGP connection Using TCP Ports

Here is the access-list 100 which demonstrates TCP port logic for BGP described above. The ACL 100 is applied inbound on the router R2.
access-list 100 permit tcp host 10.0.0.1 host 10.0.0.2 eq bgp 
access-list 100 permit tcp host 10.0.0.1 eq bgp host 10.0.0.2
The first line permits TCP traffic from host 10.0.0.1 to host 10.0.0.2 with the destination port set to BGP (port 179), indicating that router R2 is acting as the TCP server.
The second line permits TCP traffic from host 10.0.0.1 with the source port set to BGP (port 179) to host 10.0.0.2, indicating that router R2 is acting as the TCP client.

Once R1 and R2 have completed the TCP 3-way handshake, they proceed to exchange Open messages, transitioning the session to the OpenSent state. Subsequently, the BGP session progresses to the OpenConfirm state. In this state, routers await acknowledgment of the OPEN message along with Keepalive messages from their peers. Upon successful receipt of these messages, the session enters the Established state. In the Established state, peers engage in the exchange of UPDATE messages and routing information. This is the only state where BGP peers actively exchange routing information.

Role of BGP Identifier During TCP Peering Session Process

When two BGP routers aim to establish a peering relationship, one router assumes the role of the active peer, while the other takes on the passive role, similar to a client-server dynamic where the passive router acts as the server and the active router as the client. This terminology aligns with the concepts of BGP listener (server) and BGP initiator (client).

Typically, the active peer actively seeks and establishes the connection with the passive peer. Determination of which router becomes the active peer is based on their respective BGP router IDs, with the router possessing the higher ID assuming the active role. Each router knows its own router ID and can also ascertain the router ID of its neighbor through the BGP neighbor command.

Open messages are used by a router to identify itself and specify it’s operation parameters (Figure 3). An Open message contains the BGP Version number, AS number, Hold Time, BGP identifier and Optional parameters (Figure 3). BGP identifier is the same as a router-id, and is actually configured with the bgp router-id command.

Figure 3 – BGP Open Message with BGP Identifier 10.0.0.1

Even though one router is designated “active” based on Router ID, there is no guarantee that both routers will not try to initiate the connection at the exact same time. According to RFC 4271, in such case, connection collision occurs and 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. In other words, higher-valued BGP identifier becomes the client and its connection is preserved.

R2 Configuration

To avoid potential collisions in establishing BGP sessions, we can explicitly determine which BGP peer should act as the server (listen on TCP port 179 and await incoming connection requests) and which should act as the client (initiate TCP handshakes to establish connections). This will ensure there will be only single TCP session between BGP peers.

router bgp 64502
   neighbor 10.0.0.1 remote-as 64501
   neighbor 10.0.0.1 transport connection-mode passive

In this configuration:

Neighbor 10.0.0.1 specifies the IP address of the BGP neighbor (R1).
Remote-as 64501 indicates that the remote BGP neighbor is in AS 64501.
Transport connection-mode passive instructs R2 to listen passively on TCP port 179. R2 will not initiate a TCP handshake with R1 until R1 sends a TCP SYN packet to port 179.

By configuring R2 in this manner, it will wait for R1 to initiate the TCP handshake, thereby avoiding any potential collision scenarios. While configuring R1 as active (initiating the TCP handshake) is optional, it can further ensure that only one TCP session is established between the BGP peers, enhancing network stability and reliability.

The command show ip bgp neighbors is executed to verify if R2 serves as the TCP connection server, as depicted in Figure 4.

R2# show ip bgp neighbors | include host

Figure 4 – Checking BGP Ports

Local host: 10.0.0.2 – This is the IP address of the local router (R2), which is acting as the BGP server.
Local port: 179 – This is the well-known port for BGP, indicating that R2 is listening for incoming BGP connections on this port.
Foreign host: 10.0.0.1 – This is the IP address of the remote router (R1), which is initiating the BGP session.
Foreign port: 41457 – This is the source port used by R1 for the BGP session, indicating that R1 is acting as the client and initiating the connection to R2.

Conclusion

In summary, understanding BGP states is crucial for comprehending how BGP operates. Unlike interior gateway protocols (IGPs), BGP manually configures neighbors and uses TCP port 179 for establishing reliable connections.

When two routers attempt to establish a BGP session, one becomes the client and the other the server. The client sends a TCP SYN packet to the server, and upon receiving it, the server responds with a TCP SYN-ACK packet. The routers complete a three-way handshake, and if a collision occurs, the connection initiated by the router with the higher BGP Identifier is preserved.

Configuring one router as the server and the other as the client helps avoid collisions and ensures a single TCP session between BGP peers, enhancing network stability.