On Fri, Apr 23, 2010 at 10:13:32AM +0200, Wolfgang Hennerbichler wrote:
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
These two procool sections are a part of one BIRD config? Regardless of MD5 password, such config would not probably work as intended, 'source address' is used for source address of outgoing connections and for next-hops, but it is not used for a separation of incoming connections. (The neighbor IP is the same in both cases, which is a problem.) One possibility is to run two BIRD instances and use 'listen bgp address' global option to bind them to different addresses, but such configuration is probably a can of worms. For experiments, i would suggest virtual networks using Netkit software. Unfortunately, their kernel does not contain MD5 support, but it would be possible to build another with MD5 support enabled. Another problem is that the kernel interface for MD5 checksum does not specify local address, only remote address and remote port. Therefore it is not possible to set two such sessions with a different MD5 password. -- 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."