Take the 2-minute tour ×

when the bgp peer is down or during initial startup if the bgp speaker is not able to reach the peer, how long will the reconnect tries happen? will the bgp speaker try reconnecting infinitely ?

share|improve this question

2 Answers 2

up vote 3 down vote accepted

BGP should always keep trying to connect to a down peer. This should continue indefinitely, as long as no TCP connection to that peer is alive.

The timer on the retry interval can vary by implementation, but the RFC recommendation and at least the Cisco implementation are 120 seconds.

share|improve this answer

if the bgp speaker is not able to reach the peer

In networking parlance, "peer" means equal participant in a connection. BGP peers swap information with each other, so both will speak though in rare instances one might not send any routes. In most well-behaved cases, both sides put filters limiting routes that they're willing announce and filters on routes they're willing to listen to.

Whenever an interface is active with a BGP instance assigned to it, that instance will always announce its routes whether or not it hears anything from the other side. It is up to the receiver to decide whether the route is useful to it.

The receiving process may filter some incoming routes out or adjust their preference for the route. Routes that constantly change state will also be temporarily filtered in a process called damping because constantly announces and withdrawing a route is computationally expensive. Note that damping for a route you didn't originate is a receiver-only action: you still announce that you brought the route offline.

share|improve this answer
I think you are talking about the update messages. Does the same apply to BGp's tcp reconnect and open messages. will they be sent continuously –  Hemanth Nov 22 '12 at 7:39
@Saran Yes, the initial setup state will be run continuously as well. –  Jeff Ferland Nov 25 '12 at 5:24

Your Answer


