0

I am studying about BGP adjacencies at the moment.

About the Idle state. I've read from my Cisco book that errors can cause the neighbor 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 and not 60 or higher. 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) enter image description here

I've also tried configuring BGP only on one side and left the other router unconfigured which caused the configured router to attempt to establish the connection and go back to Idle again, since no response was received, but then it attempted the connection again a few seconds later, without setting the ConnectRetryTimer and doubling it.

Could someone please clear this up for me? Thank you in advance.

1 Answer 1

3

Mis-configuration of 2 peers that are able to otherwise communicate will usually not result in Idle state. The most common cause for Idle state would be one-way communication or timeout due to connection issues, resource issues, or traffic filter/block etc.

If you want to simulate this kind of state, you need to have the 2 peers initially connected and then prevent traffic from flowing between them after the connection is initially opened.

It's a relatively rare state to reach, it is much more common to have bidirectional communication but mis-configuration due to mismatched MD5 password/secret, AS number mismatch, IP address issues, etc. In the case of those problems, the state doesn't go Idle, it will retry more quickly because it is expected that an MD5 might be mismatched during setup, IP address configuration might be changed during setup, AS might be changed during setup, etc.

The Idle backoff timer is to prevent excessive peer attempts when the peer is no longer responding at all or is responding too slowly. You don't want to add to that issue by overwhelming a peer with repeated requests while it is already having problems.

If the peer is responding quickly and the session cannot complete then the routers might as well try again relatively quickly since the connection attempt was completed quickly (even if with a negative result).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.