Hi, I had the same issue some time before. I agree that this lock is too restrictive. Because in some cases you cannot change remote IP or port. I tried to make 2 multihop sessions to a remote bgp monitoring service. And its IP is fixed for me and cannot be changed.
On Sat, Jan 21, 2023, 19:49 Ondrej Zajicek <santi...@crfreenet.org> wrote: > On Sat, Jan 21, 2023 at 06:05:16PM +0000, Prem Anand wrote: > > Hi all, > > New user here > > > > I am trying to get 2 ebgp neighbours on bird to peer with a remote bgp > endpoint on frr node. > > One between 10.100.101.1 <—> 10.100.1.1 and other between 10.100.102.1 > <—> 10.100.1.1 > > > > ┌──────────────────┐ ┌─────────────┐ > > 10.100.101.1 │ │ensp5s0 │ │ > > loop1 * Bird │◄──────────────────────►┘ Frr │ > > │ 2.0.10 │10.100.1.2 10.100.1.1 │ > > loop2 * │ │ │ > > 10.100.102.1 │ │ │ │ > > └──────────────────┘ └─────────────┘ > > > > > > I find that only the first ebgp neighbour comes up and moves to > "Established” state whereas the second ebgp neighbour remains in “Idle” > state. > > However if I restart the bgp neighbour in “Established” state, the other > bgp neighbour comes up and moves to “Established” state, but the restarted > one remains in Idle state. > > > > Is there any limitation that I can’t have 2 neighbours to the same peer? > Or do I have to ensure that the 2 neighbours use different tables? > > Hi > > Yes, there is an explicit lock for remote IP to be assigned to one BGP > protocol. You can avoid it by using different IP on Frr side like you use > on Bird side, or by using pair of non-standard ports (with the same IP). > > Thinking about it, the explicit lock seems unnecessary restrictive. If > the local IP is defined, then the lock should be for (local IP, remote > IP, ports) pair. > > -- > Elen sila lumenn' omentielvo > > Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) > OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) > "To err is human -- to blame it on a computer is even more so." > >
