Fellow BIRD users, The Vienna Internet Exchange is using BIRD now in production mode. No issues so far, BIRD runs perfectly smooth. Additionally I have now deployed a quarantine route server that would simulate real peerings in a quarantine setup, in order to check stuff on new peers. by doing so, I've setup one instance that should simulate 3 different BGP Peerings on each address-family. ip setup as follows: quarantine:/etc# ip addr sho dev eth1 3: eth1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:16:3e:99:02:51 brd ff:ff:ff:ff:ff:ff inet 193.203.0.1/24 scope global eth1 inet 193.203.0.2/24 scope global secondary eth1 inet 193.203.0.25/24 scope global secondary eth1 inet6 2001:7f8:30:0:1:1:0:1120/64 scope global valid_lft forever preferred_lft forever inet6 2001:7f8:30:0:1:1:0:1853/64 scope global valid_lft forever preferred_lft forever inet6 fe80::216:3eff:fe99:251/64 scope link valid_lft forever preferred_lft forever we see the first IP 193.203.0.1 is considered the 'primary' IP on linux. now I've setup BIRD to peer on the different source interfaces and from different ASes to simulate productive routers: protocol bgp R1 { debug all; local as 1120; neighbor 193.203.0.3 as 1267; import all; export none; table T1; password "xyz"; source address 193.203.0.1; route limit 15000; start delay time 1; } protocol bgp R2 { debug all; local as 1121; neighbor 193.203.0.3 as 1267; import all; export none; table T2; password "xyz"; source address 193.203.0.2; route limit 15000; start delay time 1; } ... nevertheless only the peering with source 193.203.0.1 - the primary IP - comes up, source 193.203.0.2 stays down, I see in the tcpdump log that MD5 can't be checked. This works on IPv6, but it seems that IPv4 somehow doesn't honour the source address field when generating the md5 hashes. Can you confirm this is a bug? Am I overseeing something? I am using linux 2.6.33.2 Wolfgang -- www.vix.at | www.aco.net wh@univie.ac.at | WH844-RIPE Vienna University Computer Center