Hi all,
A quick try to fix the problem. But I'm not sure in complete correctness
though.
On Sat, Jan 21, 2023 at 8:17 PM Prem Anand <h.prem.an...@gmail.com> wrote:
> Hi Ondrej,
> Thanks for your quick reply.
> I tried after adding another ip address to the interface on the FRR side
> and can confirm that both my bgp neighbours came up :)
>
> Unfortunately, my original intention is to peer this with a Brocade
> hardware router, that I don’t have control of. So it is difficult for me to
> add another IP address or bind to a different port.
>
> Given that you feel that the explicit lock is restrictive and unnecessary,
> it would be really helpful, if you could remove that explicit lock when you
> get some time.
>
> Regards
> Prem
>
> On 21 Jan 2023, at 18:43, 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."
>
>
>
commit c5e716a8020ee487e3050b4e0f8229bfd0b441c8
Author: Alexander Zubkov <gr...@qrator.net>
Date: Mon Jan 23 00:28:58 2023 +0100
BGP: add local IP to lock key
Teh lock for BGP session had only remote IP in its key. Thus multiple
BGP sessions to the single remote IP from different local IPs were not
possible. The patch adds local IP to the lock key so that such sessions
can coexist and do not lock one another.
diff --git a/nest/locks.c b/nest/locks.c
index 812a6534..13c12b64 100644
--- a/nest/locks.c
+++ b/nest/locks.c
@@ -48,7 +48,8 @@ olock_same(struct object_lock *x, struct object_lock *y)
x->vrf == y->vrf &&
x->port == y->port &&
x->inst == y->inst &&
- ipa_equal(x->addr, y->addr);
+ ipa_equal(x->addr, y->addr) &&
+ ipa_equal(x->addr2, y->addr2);
}
static void
diff --git a/nest/locks.h b/nest/locks.h
index 37026c68..e98113e4 100644
--- a/nest/locks.h
+++ b/nest/locks.h
@@ -26,6 +26,7 @@
struct object_lock {
resource r;
ip_addr addr; /* Identification of a object: IP address */
+ ip_addr addr2; /* ... second IP address (ex. local) */
uint type; /* ... object type (OBJLOCK_xxx) */
uint port; /* ... port number */
uint inst; /* ... instance ID */
diff --git a/proto/bgp/bgp.c b/proto/bgp/bgp.c
index 2e442e16..fca5a492 100644
--- a/proto/bgp/bgp.c
+++ b/proto/bgp/bgp.c
@@ -1570,6 +1570,7 @@ bgp_start(struct proto *P)
struct object_lock *lock;
lock = p->lock = olock_new(P->pool);
lock->addr = p->remote_ip;
+ lock->addr2 = p->cf->local_ip;
lock->port = p->cf->remote_port;
lock->iface = p->cf->iface;
lock->vrf = p->cf->iface ? NULL : p->p.vrf;
