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 previous which did work, now does not. bird.conf: router id 100.100.100.100; filter f_export { accept; } template bgp clients { neighbor 204.42.112.1; local as 65000; neighbor as 65000; ipv4 { import none; export filter f_export; add paths rx; }; } include "clients.conf"; clients.conf: ipv4 table t_client1; protocol bgp client1 from clients { router id 204.42.112.100; source address 204.42.112.100; ipv4 { table t_client1; }; } include "routes/client1.conf"; ipv4 table t_client2; protocol bgp client2 from clients { router id 204.42.112.101; source address 204.42.112.101; ipv4 { table t_client2; }; } include "routes/client2.conf"; clients1.conf: protocol static { ipv4 { table t_client1; }; route 100.101.1.0/24 unreachable; route 100.101.2.0/24 unreachable { bgp_local_pref = 99; }; } I'm running debugging on, and getting no complains. I don't really have any idea how to debug this in 'birdc', everything I check seems fine. I tried for heck of it 'strict bind;' no help. bird: client1: Channel ipv4 connected to table t_client1 bird: client1: Initializing bird: client2: Channel ipv4 connected to table t_client2 bird: client2: Initializing bird: client1: Starting bird: client1: State changed to start bird: client2: Starting bird: client2: State changed to start bird: Started bird: client1: Started bird: client1: Connect delayed by 5 seconds bird: client1: Connecting to 204.42.112.1 from local address 204.42.112.100 bird: client1: Connected bird: client1: Sending OPEN(ver=4,as=65000,hold=240,id=cc2a7064) bird: client1: Got OPEN(as=65000,hold=90,id=204.42.110.40) bird: client1: Sending KEEPALIVE bird: client1: Got KEEPALIVE bird: client1: BGP session established bird: client1: State changed to up bird: client1: Got UPDATE bird: client1 > filtered out 129.250.15.35/32 unreachable bird: client1 > filtered out 198.64.6.173/32 unreachable bird: client1 > filtered out 129.250.15.39/32 unreachable bird: client1 > filtered out 129.250.15.40/32 unreachable bird: client1 > filtered out 129.250.26.240/28 unreachable bird: client1 > filtered out 129.250.35.250/32 unreachable bird: client1 > filtered out 129.250.35.251/32 unreachable bird: client1 > filtered out 129.250.38.61/32 unreachable bird: client1 > filtered out 129.250.47.99/32 unreachable bird: client1 > filtered out 129.250.48.0/24 unreachable bird: client1 > filtered out 129.250.49.0/24 unreachable bird: client1 > filtered out 157.238.66.224/27 unreachable bird: client1 > filtered out 165.254.18.128/25 unreachable bird: client1 > filtered out 165.254.19.128/25 unreachable bird: client1 > filtered out 198.58.5.0/24 unreachable bird: client1 > filtered out 198.64.6.107/32 unreachable bird: client1 > filtered out 198.64.6.110/32 unreachable bird: client1 > filtered out 198.64.6.116/32 unreachable bird: client1 > filtered out 198.64.6.127/32 unreachable bird: client1 > filtered out 198.64.6.205/32 unreachable bird: client1 > filtered out 198.64.6.229/32 unreachable bird: client1 > filtered out 202.47.30.113/32 unreachable bird: client1 > filtered out 129.250.38.85/32 unreachable bird: client1 > filtered out 198.64.6.151/32 unreachable bird: client1 > filtered out 213.130.47.24/32 unreachable bird: client1 > filtered out 66.129.224.37/32 unreachable bird: client1 > filtered out 207.17.137.34/32 unreachable bird: client1 > filtered out 129.250.38.101/32 unreachable bird: client1 > filtered out 198.64.6.172/32 unreachable bird: client1 > filtered out 203.105.73.118/32 unreachable bird: client1 > filtered out 198.64.72.220/32 unreachable bird: client1: Got UPDATE bird: client1 > filtered out 204.42.111.0/25 unreachable bird: client1 > filtered out 204.42.112.0/24 unreachable bird: client1 > filtered out 204.42.110.40/32 unreachable bird: client1 > filtered out 129.250.0.254/32 unreachable bird: client1 > filtered out 129.250.0.255/32 unreachable bird: client1: Got UPDATE bird: client1: Got END-OF-RIB bird: client1 < added 100.101.1.0/24 unreachable bird: client1 < added 100.101.2.0/24 unreachable bird: client1: Sending UPDATE bird: client1: Sending UPDATE bird: client1: Sending END-OF-RIB bird: client1: Got UPDATE bird: client1: Got UPDATE bird: client1: Got KEEPALIVE bird: client1: Sending KEEPALIVE bird: client1: Got KEEPALIVE bird: client1: Sending KEEPALIVE bird: client1: Got KEEPALIVE bird: client1: Sending KEEPALIVE bird: client1: Got KEEPALIVE bird: client1: Sending KEEPALIVE bird: client1: Got KEEPALIVE bird: client1: Sending KEEPALIVE -- ++ytti
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. Fugly hack to deal with what is broken sanity check. And in fact the hack probably shouldn't work, we likely shouldn't accept those sessions as peerPort is not right. But for me this works great for now :) On Mon, 10 Sep 2018 at 13:54, Saku Ytti <saku@ytti.fi> wrote:
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 previous which did work, now does not.
bird.conf: router id 100.100.100.100;
filter f_export { accept; }
template bgp clients { neighbor 204.42.112.1; local as 65000; neighbor as 65000; ipv4 { import none; export filter f_export; add paths rx; }; }
include "clients.conf";
clients.conf:
ipv4 table t_client1; protocol bgp client1 from clients { router id 204.42.112.100; source address 204.42.112.100; ipv4 { table t_client1; }; } include "routes/client1.conf";
ipv4 table t_client2; protocol bgp client2 from clients { router id 204.42.112.101; source address 204.42.112.101; ipv4 { table t_client2; }; } include "routes/client2.conf";
clients1.conf: protocol static { ipv4 { table t_client1; }; route 100.101.1.0/24 unreachable; route 100.101.2.0/24 unreachable { bgp_local_pref = 99; }; }
I'm running debugging on, and getting no complains.
I don't really have any idea how to debug this in 'birdc', everything I check seems fine. I tried for heck of it 'strict bind;' no help.
bird: client1: Channel ipv4 connected to table t_client1 bird: client1: Initializing bird: client2: Channel ipv4 connected to table t_client2 bird: client2: Initializing bird: client1: Starting bird: client1: State changed to start bird: client2: Starting bird: client2: State changed to start bird: Started bird: client1: Started bird: client1: Connect delayed by 5 seconds bird: client1: Connecting to 204.42.112.1 from local address 204.42.112.100 bird: client1: Connected bird: client1: Sending OPEN(ver=4,as=65000,hold=240,id=cc2a7064) bird: client1: Got OPEN(as=65000,hold=90,id=204.42.110.40) bird: client1: Sending KEEPALIVE bird: client1: Got KEEPALIVE bird: client1: BGP session established bird: client1: State changed to up bird: client1: Got UPDATE bird: client1 > filtered out 129.250.15.35/32 unreachable bird: client1 > filtered out 198.64.6.173/32 unreachable bird: client1 > filtered out 129.250.15.39/32 unreachable bird: client1 > filtered out 129.250.15.40/32 unreachable bird: client1 > filtered out 129.250.26.240/28 unreachable bird: client1 > filtered out 129.250.35.250/32 unreachable bird: client1 > filtered out 129.250.35.251/32 unreachable bird: client1 > filtered out 129.250.38.61/32 unreachable bird: client1 > filtered out 129.250.47.99/32 unreachable bird: client1 > filtered out 129.250.48.0/24 unreachable bird: client1 > filtered out 129.250.49.0/24 unreachable bird: client1 > filtered out 157.238.66.224/27 unreachable bird: client1 > filtered out 165.254.18.128/25 unreachable bird: client1 > filtered out 165.254.19.128/25 unreachable bird: client1 > filtered out 198.58.5.0/24 unreachable bird: client1 > filtered out 198.64.6.107/32 unreachable bird: client1 > filtered out 198.64.6.110/32 unreachable bird: client1 > filtered out 198.64.6.116/32 unreachable bird: client1 > filtered out 198.64.6.127/32 unreachable bird: client1 > filtered out 198.64.6.205/32 unreachable bird: client1 > filtered out 198.64.6.229/32 unreachable bird: client1 > filtered out 202.47.30.113/32 unreachable bird: client1 > filtered out 129.250.38.85/32 unreachable bird: client1 > filtered out 198.64.6.151/32 unreachable bird: client1 > filtered out 213.130.47.24/32 unreachable bird: client1 > filtered out 66.129.224.37/32 unreachable bird: client1 > filtered out 207.17.137.34/32 unreachable bird: client1 > filtered out 129.250.38.101/32 unreachable bird: client1 > filtered out 198.64.6.172/32 unreachable bird: client1 > filtered out 203.105.73.118/32 unreachable bird: client1 > filtered out 198.64.72.220/32 unreachable bird: client1: Got UPDATE bird: client1 > filtered out 204.42.111.0/25 unreachable bird: client1 > filtered out 204.42.112.0/24 unreachable bird: client1 > filtered out 204.42.110.40/32 unreachable bird: client1 > filtered out 129.250.0.254/32 unreachable bird: client1 > filtered out 129.250.0.255/32 unreachable bird: client1: Got UPDATE bird: client1: Got END-OF-RIB bird: client1 < added 100.101.1.0/24 unreachable bird: client1 < added 100.101.2.0/24 unreachable bird: client1: Sending UPDATE bird: client1: Sending UPDATE bird: client1: Sending END-OF-RIB bird: client1: Got UPDATE bird: client1: Got UPDATE bird: client1: Got KEEPALIVE bird: client1: Sending KEEPALIVE bird: client1: Got KEEPALIVE bird: client1: Sending KEEPALIVE bird: client1: Got KEEPALIVE bird: client1: Sending KEEPALIVE bird: client1: Got KEEPALIVE bird: client1: Sending KEEPALIVE bird: client1: Got KEEPALIVE bird: client1: Sending KEEPALIVE
-- ++ytti
-- ++ytti
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 proper ordering of protocol startups during reconfiguration. We should fix it to avoid this issue.
And in fact the hack probably shouldn't work, we likely shouldn't accept those sessions as peerPort is not right. But for me this works great for
It should, because incoming connection has random/ephemeral source port, so it is not verified. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@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."
Hey Ondrej, On Tue, 11 Sep 2018 at 14:01, Ondrej Zajicek <santiago@crfreenet.org> 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 this issue.
Many thanks!. And thank you for your work on bird. I spent maybe 50h trying to do this on IXIA, but just does not scale. On bird I could do it in about 10h, with Bird using just 25GB of memory.
It should, because incoming connection has random/ephemeral source port, so it is not verified.
You're right, I noticed that after posting, that I can't check anything, so nothing to fix there, but didn't want to add noise :) -- ++ytti
participants (2)
-
Ondrej Zajicek -
Saku Ytti