Re: bgpd: allow quick open on startup

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 <[email protected]> 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.