Hi Stuart

On Thu, 23 Jul 2026 at 13:06, Stuart Henderson <stu@spacehopper.org> wrote:

> 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,

ok I  Ill take a look at the connect-retry,  on my IBGP clients to my Route
Reflectors,



> 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.
>
agreed on that


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




i wonder if it would be useful to have a  a flag on multihop bgp sessions,
to say where the reachability of the Neighbour  should come from,
so if OSPF is not fully converged dont try to connect to a neighbour that
needs OSPF ..
just a thought,

>
> 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.
>


-- 
Kindest regards,
Tom Smyth.