possible bug: bgp md5 authentication and multiple source ip addresses
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
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."
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.)
I the same true for OSPF? Can one have several IP aliases on one interface and just run OSPF on some IP aliases of them? Jocke
On Fri, Apr 23, 2010 at 01:11:36PM +0200, Joakim Tjernlund wrote:
I the same true for OSPF?
No, OSPF works completely different.
Can one have several IP aliases on one interface and just run OSPF on some IP aliases of them?
From the last version (1.2.2) this is possible on Linux (but not on BSD). -- 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."
On Apr 23, 2010, at 11:39 , Ondrej Zajicek wrote:
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?
yes.
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.)
oh. maybe I misunderstood it in this case. thank you for the clarification.
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.
well, it's just a quarantine-setup, it could break without destroying anything. it could be a can of worms. I will think about it... or maybe I'll do some more virtualization, don't know.
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.
thanks. the route servers are virtualized anyways.
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.
I thought so :( thanks a lot. Wolfgang
-- 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."
-- www.vix.at | www.aco.net wh@univie.ac.at | WH844-RIPE Vienna University Computer Center
participants (3)
-
Joakim Tjernlund -
Ondrej Zajicek -
Wolfgang Hennerbichler