Confused About The BGP Neighbor States and Timers

[Mitrixsen]

Hello, everyone!

I am studying about BGP adjacencies at the moment.

With the Idle state, I've read that errors can cause the state to revert back to Idle and the ConnectRetryTimer is set to 60 seconds initially, doubling on subsequent failures.

What in BGP is considered an "error"?

Is there any way to produce something like this in a lab? I’ve tried all sorts of different scenarios, yet I’ve never seen this timer in action, nor it doubling on subsequent failures.

For example, I’ve purposely mismatched the AS numbers specified in the neighbor statements which caused the connection to be torn down, the routers moved back into the Idle state and retried the connection for several attempts in a row. It took them just a few seconds, so when exactly does this ConnectRetryTimer come into play?

Here's a packet capture of it (Open it in a new tab if it's too small)

 

 

[M02@rt37 · Accepted solution]

Hello @Mitrixsen,

In the context of BGP, an "error" refers to any condition that causes a failure in establishing or maintaining a BGP session. This can include issues:

--TCP connection failures: These can occur due to network connectivity problems, misconfiguration, or incompatible parameters between BGP peers.

--BGP configuration errors: Mismatches in BGP configuration settings, such as AS number mismatches, incorrect neighbor statements, or authentication failures, can lead to errors and session teardown.

--Protocol errors: Errors can also occur due to protocol-specific issues, such as malformed or unrecognized BGP messages.

In BGP, the ConnectRetryTimer is used to control the timing of reconnection attempts after an error occurs during the establishment of a BGP session. However, the doubling of the timer value on subsequent failures is not a standard behavior specified in the BGP protocol.

The BGP ConnectRetryTimer is typically set to an initial value of 60 seconds. If the initial connection attempt fails, the BGP router will enter the Idle state and initiate a new connection attempt after the ConnectRetryTimer expires. The timer is restarted if subsequent connection attempts fail.

The behavior you observed in your lab scenario, where the routers quickly retried the connection within a few seconds, aligns with the default behavior of many BGP implementations. Some implementations may have their own timers or mechanisms that control the reconnection interval, which could explain the observed behavior.

To simulate the ConnectRetryTimer behavior in a lab environment, you can try configuring BGP sessions between two routers and intentionally introduce errors that cause the sessions to fail. Make sure the error persists for longer than the ConnectRetryTimer interval. You may need to experiment with different configurations, timer values, or software versions to observe the desired behavior accurately.

[MHM Cisco World]

try this way, 
make BGP session establish, then cofig ACL deny TCP/179 and check idle status