Hey Ondrej,
On Tue, 11 Sep 2018 at 14:01, Ondrej Zajicek wrote:
> You are right, there is a lock to avoid run two instances for the same
> neighbor. Although the primary reason for this lock is to have proper
> ordering of protocol startups during reconfiguration. We should fix it
> to avoid thi
On Mon, Sep 10, 2018 at 04:05:25PM +0300, Saku Ytti wrote:
> Ok. This is because unnecessary and undesirable sanity check that same
> peerIP cannot exist twice.
Hi
You are right, there is a lock to avoid run two instances for the same
neighbor. Although the primary reason for this lock is to have
Ok. This is because unnecessary and undesirable sanity check that same
peerIP cannot exist twice.
You can fool this check, by configuring random peerPort. Then set bird
as passive and DUT as active. Even though DUT opens all BGP from
source_port 179, bird will happily accept the connections.
Fugl
I'm trying to setup between DUT<->Bird in same interface multiple iBGP
neighbours with DUT IP and routerID staying same, and Bird sourceIP
and table changing.
If I configure just 1, it works grand, the 2nd one won't come up. If I
change the order, the previous one which didn't work now works, and
