What is BGP Neighbor Adjacency?
78656
Created On 04/25/19 10:03 AM - Last Modified 04/25/19 18:44 PM
Question
What is BGP Neighbor Adjacency?
Environment
Palo Alto Networks firewall
Border Gateway Protocol (BGP)
Answer
BGP PEERING ISSUES
We commonly come across issues with BGP peering, and this article will explain what can go wrong when you try to form neighbors and are not able to do so. BGP is a simple protocol and the neighborship process is not quite complex like OSPF. There are only some things that need to be taken care of in order to get a successful neighborship between two devices.
If you have look at the BGP process, it starts with a TCP handshake on port 179 as it runs on top of TCP as a Layer 4 protocol. Now every peer or device that is participating in the BGP peering goes through some states. These states have significance in order to troubleshoot what and why the BGP peering is failing between any two devices.
IDLE
This is the initial state of BGP. Here the BGP speaker will be waiting for a TCP connection to happen. If you are seeing your peers stuck in the idle state, that might mean that you don’t have a path to reach the peer. If, for any reason, the BGP peer is going to the idle state, it will wait 15 seconds by default before trying to make a connection again. This happens because of the default value set in the BGP.
Connect
In this state, the BGP will try and initiate the BGP connection. If the 3-way handshake is completed, then you will see your state transitioning from connect to the open-sent, which is the next state of the BGP process. If the connection fails to establish, you might see the status go to active another state of BGP after the connection-retry timer has depleted.
If you are seeing peerings stuck in this state, the problem is likely with your security rules or something. If you are seeing your peering stuck in this state, the issue is likely related to something blocking your communication on port 179, or it can also be a case where you might have misconfigured our routing for the peers.
Active
This state is like the previous state and is linked to the TCP-connection. The BGP process will start a new TCP 3-way handshake. If the process is completed, the transition will happen to the OPEN_SENT state, otherwise it will go back to the connect and from where it will wait for the connect retry interval. If that expires, it will come back to active and will try to establish a new connection. If you see the peers in any of the two states that is connect and active, the problem is with the TCP and the issue should be troubleshooted as any other normal application running on port 179.
Open-Sent
In this state the BGP_OPEN message would be sent to the peer. This is the message that will include all the information regarding the BGP process.
This is the message that will have the parameters that should match for the BGP peerings to form:
The Parameters that are compared are as follows:
– The BGP versions should be matching on both sides.
– The number that you have specified for the peer on your config should be the same as advertised by the peer in its open message.
– The BGP open message should come from a source IP address that is same as the neighbor address you configured (you might see a different source of the message in case of non-directly connected neighbors in BGP).
– The Router IDs should be unique, which means the Router ID of the peer should not be the same.
– All the security parameters such as password if used for authenticating the BGP peers.
Once the open message is sent and you have received an open message from our peer, the hold-down timer and the keepalive timers will also be negotiated. The lower value for the fields will be chosen and will be agreed upon by both the peer. This stage and the next that is the open-confirm are very transient stages, and you will see only your peers in any of these two stages if you have misconfigured any of the above values.
Open-confirm
You will see this state once you have received an open message from your neighbor. In this state, you will wait for a keepalive message to be received from your neighbor before going to the established state. If, in case, you don’t receive a keepalive message or you receive a notification message or the hold timer expires, you might see the state transition back to the idle.
Established
This is the state where you would like your peers to be most of the time. Anything other than the established state is bad. Once you have entered this state, the routes will be shared in the update message between the BGP peers, and keepalives will be sent after continuous intervals. If you fail to receive keepalives from the peer after the peerings are established, you will move back to the idle state and the process starts over again.
If you have look at the BGP process, it starts with a TCP handshake on port 179 as it runs on top of TCP as a Layer 4 protocol. Now every peer or device that is participating in the BGP peering goes through some states. These states have significance in order to troubleshoot what and why the BGP peering is failing between any two devices.
IDLE
This is the initial state of BGP. Here the BGP speaker will be waiting for a TCP connection to happen. If you are seeing your peers stuck in the idle state, that might mean that you don’t have a path to reach the peer. If, for any reason, the BGP peer is going to the idle state, it will wait 15 seconds by default before trying to make a connection again. This happens because of the default value set in the BGP.
Connect
In this state, the BGP will try and initiate the BGP connection. If the 3-way handshake is completed, then you will see your state transitioning from connect to the open-sent, which is the next state of the BGP process. If the connection fails to establish, you might see the status go to active another state of BGP after the connection-retry timer has depleted.
If you are seeing peerings stuck in this state, the problem is likely with your security rules or something. If you are seeing your peering stuck in this state, the issue is likely related to something blocking your communication on port 179, or it can also be a case where you might have misconfigured our routing for the peers.
Active
This state is like the previous state and is linked to the TCP-connection. The BGP process will start a new TCP 3-way handshake. If the process is completed, the transition will happen to the OPEN_SENT state, otherwise it will go back to the connect and from where it will wait for the connect retry interval. If that expires, it will come back to active and will try to establish a new connection. If you see the peers in any of the two states that is connect and active, the problem is with the TCP and the issue should be troubleshooted as any other normal application running on port 179.
Open-Sent
In this state the BGP_OPEN message would be sent to the peer. This is the message that will include all the information regarding the BGP process.
This is the message that will have the parameters that should match for the BGP peerings to form:
The Parameters that are compared are as follows:
– The BGP versions should be matching on both sides.
– The number that you have specified for the peer on your config should be the same as advertised by the peer in its open message.
– The BGP open message should come from a source IP address that is same as the neighbor address you configured (you might see a different source of the message in case of non-directly connected neighbors in BGP).
– The Router IDs should be unique, which means the Router ID of the peer should not be the same.
– All the security parameters such as password if used for authenticating the BGP peers.
Once the open message is sent and you have received an open message from our peer, the hold-down timer and the keepalive timers will also be negotiated. The lower value for the fields will be chosen and will be agreed upon by both the peer. This stage and the next that is the open-confirm are very transient stages, and you will see only your peers in any of these two stages if you have misconfigured any of the above values.
Open-confirm
You will see this state once you have received an open message from your neighbor. In this state, you will wait for a keepalive message to be received from your neighbor before going to the established state. If, in case, you don’t receive a keepalive message or you receive a notification message or the hold timer expires, you might see the state transition back to the idle.
Established
This is the state where you would like your peers to be most of the time. Anything other than the established state is bad. Once you have entered this state, the routes will be shared in the update message between the BGP peers, and keepalives will be sent after continuous intervals. If you fail to receive keepalives from the peer after the peerings are established, you will move back to the idle state and the process starts over again.