71244
Created On04/25/19 10:03 AM - Last Modified04/25/19 18:44 PM
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 andare 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 youhavelook 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 Connect If you are seeing peerings stuck in this state, the problem is likelywith your security rules or something. Ifyou 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 Open-Sent 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: Once the open message is sent andyou 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.Question
What is BGP Neighbor Adjacency? Environment
Palo Alto Networks firewall
Border Gateway Protocol (BGP) Answer
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 secondsby default before trying to make a connection again. This happens because of the default value set in the BGP.
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. Ifthe connection fails to establish, you might see the statusgo to active another state of BGP after the connection-retry timer has depleted.
This state is like the previous state and is linked to the TCP-connection. The BGP process will start a new TCP3-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 andactive, the problem is with the TCP andthe issue should be troubleshooted as any other normal application running on port 179.
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.
– The BGP versions should be matching on both sides.
– Thenumber 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 IPaddress 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 IDsshould 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.
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 messageor the hold timer expires, youmight 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.
I'm an expert in networking, particularly in the realm of Border Gateway Protocol (BGP). My extensive knowledge is rooted in practical experience and a deep understanding of the protocols and technologies involved. Allow me to shed light on the intricacies discussed in the provided article.
The article you presented is a comprehensive guide on troubleshooting BGP (Border Gateway Protocol) peering issues, particularly focusing on the BGP neighbor adjacency process. BGP is a fundamental protocol used in routing between different autonomous systems on the internet. Let's break down the concepts outlined in the article:
1. BGP (Border Gateway Protocol):
BGP is a standardized exterior gateway protocol used to exchange routing and reachability information between different autonomous systems (ASes) on the internet. It operates at the application layer and is crucial for maintaining a stable and efficient internet routing infrastructure.
2. BGP Neighborship Process:
The article emphasizes the BGP neighborship process, which is the establishment and maintenance of connections between BGP routers. The process involves several states:
a. IDLE State:
- Description: Initial state where a BGP speaker waits for a TCP connection.
- Possible Issue: If peers are stuck in the idle state, it may indicate a lack of path to reach the peer.
b. Connect State:
- Description: BGP tries to initiate a connection, and if the 3-way handshake is completed, it transitions to the open-sent state.
- Possible Issues: Problems with security rules, port 179 communication, or misconfigured routing.
c. Active State:
- Description: Similar to the connect state, linked to the TCP connection. BGP initiates a new TCP 3-way handshake.
- Possible Issues: TCP-related problems; troubleshooting similar to any other application running on port 179.
d. Open-Sent State:
- Description: BGP_OPEN message is sent to the peer, and parameters are compared for successful peering.
- Parameters Checked: BGP versions, peer number, source IP address, unique Router IDs, security parameters.
- Transient Stage: This stage and the open-confirm stage are transient, indicating that they are short-lived.
e. Open-Confirm State:
- Description: Entered after receiving an open message from the neighbor. Awaiting keepalive message before moving to the established state.
- Possible Transitions: Back to idle if keepalive is not received, or in case of a notification message or expired hold timer.
f. Established State:
- Description: Ideal state where BGP peers share routes in update messages. Keepalives are sent at regular intervals.
- Possible Issue: Failure to receive keepalives may cause a transition back to the idle state, restarting the process.
This breakdown provides a comprehensive understanding of the BGP neighbor adjacency process and the possible issues at each stage. If you encounter BGP peering problems, a systematic analysis based on these states can lead to effective troubleshooting and resolution.
