pretty sure that will be due to OSPF then. bgpd doesn't know that OSPF
hasn't converged and will try to connect, probably fail, and then wait
for connect-retry. this can't be set per-peer, only globally, and you
don't want it to retry too quickly if you have EBGP peers, but if it's
a router with only IBGP peers, you might consider lowering it.

or you could try something like "ping -c 1 $somerouter_ip; bgpctl nei
somerouter up" in rc.local and see if that helps?


On 2026/07/23 12:31, Tom Smyth wrote:
> Thanks Claudio, 
> replies in line 
> 
> On Thu, 23 Jul 2026 at 12:20, Claudio Jeker <cjeker@diehard.n-r-g.com> wrote:
> 
> 
> 
>     This really depends on the remote peer. Also does it take 2-3min before
>     the session is established or 2-3min until routes have settled.
> 
> it takes  2-3 minutes before the session establishes ( it may BGP not connecting first time
> round (because OSPF has not converged)  (loopback to loopback reachability via OSPF, and then
> BGP multi-hop between the loopbacks)
>  
> 
>     If you rapidly reboot a system multiple times then the IdleHold timer will
>     punish your constant flaps and delay connects. For a single reset
>     connections should reestablish more or less instantly.
> 
> It would be one reboot or 2 reboots (upgrade + syspatch)   
> ( it may BGP not connecting first time round (because OSPF has not converged)  (loopback to
> loopback reachability via OSPF, and then BGP multi-hop between the loopbacks) 
> 
> 
> 
>     With log verbose you should see connection atempts from peers that are in
>     state idle. Also show neig X timer is good to see which timers are
>     running and for how long.
> 
> Ill take a look at that ..  it was more just that the interruption seemed to extend by 2
> minutes more than necessary (but it was in maintenance windows with redundant routers so its
> impact is low (except for post crash recovery )  
> 
> Thanks again  
> 
> 
>     --
>     :wq Claudio
> 
> 
> 
> 
> --
> Kindest regards,
> Tom Smyth.