Hello,
For performance reasons that do not deserve to be detailed here, I am
trying to set up 2 separate BGP sessions between my Linux server running
Bird and an Arista switch.
The Linux machines has 2 IPs on loopback, i would like to initiate a
connexion from each of them.
I have IPs 192.168.0.11 and 192.168.0.12 on the server loopback, and
192.168.0.1 on the switch loopback.
These machines are connected with two different bonds, each of which has
an OSPF session writing to a different routing table.
Thus, I have those routes and rules:
[root@bz-perflab-3-vr] ip route show table 1
10.10.50.44/30 via 10.10.50.41 dev bond0.510 proto bird
192.168.0.1 via 10.10.50.41 dev bond0.510 proto bird
192.168.0.12 via 10.10.50.41 dev bond0.510 proto bird
[root@bz-perflab-3-vr] ip route show table 2
10.10.50.40/30 via 10.10.50.45 dev bond1.511 proto bird
192.168.0.1 via 10.10.50.45 dev bond1.511 proto bird
192.168.0.11 via 10.10.50.45 dev bond1.511 proto bird
[root@bz-perflab-3-vr] ip rule show
0: from all lookup local
32752: from 192.168.0.12 lookup 2
32753: from 192.168.0.11 lookup 1
When I ping 192.168.0.1, the output interface depends on the source I
use. So, this works.
However, I cannot set up both BGP sessions. One is established and the
other is idle, which makes me think there is a limitation somewhere in
Bird that prevents opening several sessions with the same neighbour.
TCPdump on the interface that has the "idle" BGP session shows
absolutely no traffic on port 179.
My BGP configuration is as follows:
protocol bgp bgp_bond0 {
import all;
export filter {
if proto = "static_bond0" then {
bgp_local_pref = 105;
accept;
}
reject;
};
local as 16276;
neighbor 192.168.0.1 as 16276;
source address 192.168.0.11;
multihop;
advertise ipv4;
};
protocol bgp bgp_bond1 {
import all;
export filter {
if proto = "static_bond1" then {
bgp_local_pref = 105;
accept;
}
reject;
};
local as 16276;
neighbor 192.168.0.1 as 16276;
source address 192.168.0.12;
multihop;
advertise ipv4;
};
Can you confirm this is a limitation in Bird ? Is there a reason for it,
apart from the fact that it is a non-standard case ? Is there a way to
bypass it ?
Regards,
--
Damien Clabaut
Network Engineer
OVH.pl
