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

Reply via email to