Hi! New version is ready. This version includes many changes and bugfixes. We are working on packaging and other stuff. Changes: Version 1.3.0 (2011-03-31) o Proper iBGP (can be used with IGP). o Multipath support (OSPF and static). o L2 link state detection. o IPv6 router advertisements. o Much improved OSPF reconfiguration. o Point-to-MultiPoint interfaces (OSPF). o Minor changes and improvements in config file grammar. o Better community list matching o Changes default behavior of BGP IPv6 socket to v6only. Use 'listen bgp dual' for the old behavior. o Changes default for handling missing link-local addresses on route servers. Use 'missing lladdr drop' for the old behavior. o Important bugfix for OSPF. o Several minor bugfixes. Ondrej
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/31/11 10:27, Ondrej Filip wrote:
New version is ready. This version includes many changes and bugfixes. We are working on packaging and other stuff.
In Gentoo now, thank you: http://cia.vc/stats/author/chainsaw/.message/1e3992 My apologies for missing 1.2.5; it wasn't planned for production use in LINX. Regards, - -- Tony Vroon UNIX systems administrator London Internet Exchange Ltd, Trinity Court, Trinity Street, Peterborough, PE1 1DA Registered in England number 3137929 E-Mail: tony@linx.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2UTuIACgkQp5vW4rUFj5qYpQCdF8i5lL+RTnOl9vp2oefIeWzn bTYAniGuKTswJf0wnbJG58BA5VNMrWIz =4zi0 -----END PGP SIGNATURE-----
On 31.3.2011 11:52, Tony Vroon wrote:
On 03/31/11 10:27, Ondrej Filip wrote:
New version is ready. This version includes many changes and bugfixes. We are working on packaging and other stuff.
In Gentoo now, thank you: http://cia.vc/stats/author/chainsaw/.message/1e3992
My apologies for missing 1.2.5; it wasn't planned for production use in LINX.
That is fine. Thank you! Ondrej
Regards,
Great work to all involved :) We have looked through the notes in the git repository etc however we are still confused as to whether multi-path support can be 'made to work' with RIP or not? Currently our BIRD configuration defines a unique RIP protocol instance on each of our Linux routers edge interfaces to listen for RIP messages from our edge firewalls (which host and advertise many IPSec VPN routes via RIP); This means that birds internal route table contains many multipath routes. bird> show route 10.131.0.0/16 via 192.168.214.1 on eth2 [EDGE1RIP 11:07] * (120/4) via 192.168.215.1 on eth3 [EDGE2RIP 11:07] (120/4) 10.0.0.0/24 via 192.168.214.1 on eth2 [EDGE1RIP 11:07] * (120/4) 10.1.20.0/24 via 192.168.214.1 on eth2 [EDGE1RIP 11:07] * (120/4) via 192.168.215.1 on eth3 [EDGE2RIP 11:07] (120/4) 192.168.64.0/24 via 192.168.215.1 on eth3 [EDGE2RIP 11:07] * (120/4) via 192.168.214.1 on eth2 [EDGE1RIP 11:07] (120/4) 192.168.65.0/24 via 192.168.215.1 on eth3 [EDGE2RIP 11:07] * (120/4) via 192.168.214.1 on eth2 [EDGE1RIP 11:07] (120/4) 10.10.0.0/24 via 192.168.214.1 on eth2 [EDGE1RIP 11:07] * (120/4) 192.168.68.0/24 via 192.168.215.1 on eth3 [EDGE2RIP 11:07] * (120/4) via 192.168.214.1 on eth2 [EDGE1RIP 11:07] (120/4) In version 1.3.0, will these multipath routes that we have in our bird routing table now be exported to the kernel routing table? Please, please say yes :o/ Thank you for your help. Andy. # cat /etc/bird.conf #log syslog { error, fatal, bug }; protocol kernel { # Protocol pipe to kernel table learn; # Learn static routes in main kernel table scan time 10; # Scan kernel routing table every 20 seconds import none; # Do Not import main kernel routing table into BIRD table export filter {if net ~ [10.0.0.0/8+, 172.16.0.0/12+, 192.168.0.0/16+] then { accept; } reject; }; } protocol device { # Protocol pipe to network interfaces table scan time 10; # Scan interfaces every 10 seconds } protocol rip EDGE2RIP { # Create RIP protocol instance called EDGE2RIP timeout time 65; # specifies how old route has to be to be considered unreachable. Default is 4*period (period default is 30) garbage time 70; # specifies how old route has to be to be discarded. Default is 10*period (period default is 30) honor always; export none; # Do not transmit BIRD table to RIP peers import filter {if net ~ [10.0.0.0/8+, 172.16.0.0/12+, 192.168.0.0/16+] then { accept; } reject; }; interface "eth3" { mode quiet; }; } protocol rip EDGE1RIP { # Create RIP protocol instance called EDGE1RIP timeout time 65; # specifies how old route has to be to be considered unreachable. Default is 4*period (period default is 30) garbage time 70; # specifies how old route has to be to be discarded. Default is 10*period (period default is 30) honor always; export none; # Do not transmit BIRD table to RIP peers import filter {if net ~ [10.0.0.0/8+, 172.16.0.0/12+, 192.168.0.0/16+] then { accept; } reject; }; interface "eth2" { mode quiet; }; } -----Original Message----- From: owner-bird-users@atrey.karlin.mff.cuni.cz [mailto:owner-bird-users@atrey.karlin.mff.cuni.cz] On Behalf Of Tony Vroon Sent: 31 March 2011 10:53 To: Ondrej Filip Cc: bird-users@network.cz Subject: Re: New release 1.3.0! -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/31/11 10:27, Ondrej Filip wrote:
New version is ready. This version includes many changes and bugfixes.
We are working on packaging and other stuff.
In Gentoo now, thank you: http://cia.vc/stats/author/chainsaw/.message/1e3992 My apologies for missing 1.2.5; it wasn't planned for production use in LINX. Regards, - -- Tony Vroon UNIX systems administrator London Internet Exchange Ltd, Trinity Court, Trinity Street, Peterborough, PE1 1DA Registered in England number 3137929 E-Mail: tony@linx.net<mailto:tony@linx.net> -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2UTuIACgkQp5vW4rUFj5qYpQCdF8i5lL+RTnOl9vp2oefIeWzn bTYAniGuKTswJf0wnbJG58BA5VNMrWIz =4zi0 -----END PGP SIGNATURE----- ________________________________ Monitor Computer Systems Limited Company Registration Number: NI 17805 Registered Office: 3 Pine Crest, Holywood, North Down, Northern Ireland BT18 9ED
On Thu, Mar 31, 2011 at 11:09:54AM +0100, Andrew Lemin wrote:
Great work to all involved J
We have looked through the notes in the git repository etc however we are still confused as to whether multi-path support can be 'made to work' with RIP or not?
No, sorry. Current RIP was not ready for simple integrating multipath like in OSPF. I will probaly rewrite it in a near future. I thought about your case and i found a crazy hack, that should bring multipath routes to your particular case (two RIP neighbors with a fixed number of routes, just import from RIP): table tn; table te; table t1; table t2; protocol static st_null { table tn; export all; preference 80; # lower than RIP route 10.131.0.0/16 reject; ... (other routes) } protocol static st_ecmp { table te; export all; route 10.131.0.0/16 multipath via 192.168.214.1 via 192.168.215.1; ... (other routes) } protocol rip EDGE1RIP { table t1; ... (like in your config) } protocol rip EDGE2RIP { table t2; ... (like in your config) } protocol pipe pn1 { table tn; peer table t1; export all; import none; } protocol pipe pr1 { table t1; peer table master; export where proto = "EDGE1RIP"; import none; } protocol pipe pg1 { table t1; peer table te; mode opaque; # this is important preference 300; # higher than static export where proto = "st_null"; import none; } protocol pipe pn2 { table tn; peer table t2; export all; import none; } protocol pipe pr2 { table t2; peer table master; export where proto = "EDGE2RIP"; import none; } protocol pipe pg2 { table t2; peer table te; mode opaque; # this is important preference 300; # higher than static export where proto = "st_null"; import none; } protocol pipe pe { table te; peer table master; mode opaque; # this is important preference 150; # higher than RIP export where proto = "st_ecmp"; import none; } The idea is simple: routes from RIP1 came to t1 together with reject route from st_null (through pn1). if route from RIP1 exists, it will be preferred, because it has higher priority than route from st_null. Pipe pg1 would push preferred route (opaque pipe push just a preferred route) from t1 to te, but only if it is from st_null (filter). If the preferred route is RIP1, nothing is pushed. such route in table te would block ecmp route to be propagated to master (beacuse it has higher priority, 300). So if there are routes from both RIPs, nothing is propagated to table te and ecmp route will win. RIP routes are already pushed to master through pr1, pr2. So to use this, for each prefix from RIP you have to configuure one (reject) static route in st_null and one ECMP route in st_ecmp. You should see something like: 10.131.0.0/16 multipath [pe 16:35] * (150) via 78.128.195.198 on eth0 weight 1 via 78.128.195.199 on eth0 weight 1 via 78.128.195.198 on eth0 [EDGE1RIP 16:35] (120) via 78.128.195.199 on eth0 [EDGE2RIP 16:35] (120) (if both routes from RIP are present - so these are three routes, two from RIP and one multipath from pe) -- 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."
Hi Ondrej, Thank you for your time considering this, it is greatly appreciated. I understand how this works, very clever. This is indeed quite an inventive hack :) I will have a play and see if we can get it to work. Our edge firewalls actually advertise around 80 RIP routes at the moment (we have an awful lot of VPNs here in the head office) and so this would be a lot to program but not unfeasible. The limitation is that approximately once a month we have to add more VPNs as we take on more remote locations and so I would need to continually update the BIRD configuration every time we add more VPNs to gain multipath access for the newly added tunnels etc. I will definitely let you know how we get on. Please, please do consider rewriting RIP with emcp. We would be in your debt and after all, whilst RIP is archaic (I wish we could use a newer protocol) it is still the most widely used routing protocol in SMB network devices. Obviously high end devices from Cisco, Juniper etc support OSPF but Netgear, Draytek, Firebox etc etc only support RIP. I would love to install some Cisco VPN concentrators however we like many other SMB companies simply do not have the in-house skills to manage these properly, and so we are forced to use basic kit which I can train others (non-networking staff) to program/manage in my absence. Thanks again for your time and kind help. Andy. -----Original Message----- From: Ondrej Zajicek [mailto:santiago@crfreenet.org] Sent: 31 March 2011 15:42 To: Andrew Lemin Cc: Tony Vroon; Ondrej Filip; bird-users@network.cz Subject: Re: New release 1.3.0! On Thu, Mar 31, 2011 at 11:09:54AM +0100, Andrew Lemin wrote:
Great work to all involved J
We have looked through the notes in the git repository etc however we are still confused as to whether multi-path support can be 'made to work' with RIP or not?
No, sorry. Current RIP was not ready for simple integrating multipath like in OSPF. I will probaly rewrite it in a near future. I thought about your case and i found a crazy hack, that should bring multipath routes to your particular case (two RIP neighbors with a fixed number of routes, just import from RIP): table tn; table te; table t1; table t2; protocol static st_null { table tn; export all; preference 80; # lower than RIP route 10.131.0.0/16 reject; ... (other routes) } protocol static st_ecmp { table te; export all; route 10.131.0.0/16 multipath via 192.168.214.1 via 192.168.215.1; ... (other routes) } protocol rip EDGE1RIP { table t1; ... (like in your config) } protocol rip EDGE2RIP { table t2; ... (like in your config) } protocol pipe pn1 { table tn; peer table t1; export all; import none; } protocol pipe pr1 { table t1; peer table master; export where proto = "EDGE1RIP"; import none; } protocol pipe pg1 { table t1; peer table te; mode opaque; # this is important preference 300; # higher than static export where proto = "st_null"; import none; } protocol pipe pn2 { table tn; peer table t2; export all; import none; } protocol pipe pr2 { table t2; peer table master; export where proto = "EDGE2RIP"; import none; } protocol pipe pg2 { table t2; peer table te; mode opaque; # this is important preference 300; # higher than static export where proto = "st_null"; import none; } protocol pipe pe { table te; peer table master; mode opaque; # this is important preference 150; # higher than RIP export where proto = "st_ecmp"; import none; } The idea is simple: routes from RIP1 came to t1 together with reject route from st_null (through pn1). if route from RIP1 exists, it will be preferred, because it has higher priority than route from st_null. Pipe pg1 would push preferred route (opaque pipe push just a preferred route) from t1 to te, but only if it is from st_null (filter). If the preferred route is RIP1, nothing is pushed. such route in table te would block ecmp route to be propagated to master (beacuse it has higher priority, 300). So if there are routes from both RIPs, nothing is propagated to table te and ecmp route will win. RIP routes are already pushed to master through pr1, pr2. So to use this, for each prefix from RIP you have to configuure one (reject) static route in st_null and one ECMP route in st_ecmp. You should see something like: 10.131.0.0/16 multipath [pe 16:35] * (150) via 78.128.195.198 on eth0 weight 1 via 78.128.195.199 on eth0 weight 1 via 78.128.195.198 on eth0 [EDGE1RIP 16:35] (120) via 78.128.195.199 on eth0 [EDGE2RIP 16:35] (120) (if both routes from RIP are present - so these are three routes, two from RIP and one multipath from pe) -- 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." Monitor Computer Systems Limited Company Registration Number: NI 17805 Registered Office: 3 Pine Crest, Holywood, North Down, Northern Ireland BT18 9ED
Hi, I was just looking at updating the OpenBSD port and noticed that bird is sending a zero BGPID, so OpenBGP refuses to talk to it. The router ID of my test box is correctly being shown here: bird> show status BIRD 1.3.0 Router ID is 85.158.44.149 Current server time is 31-03-2011 23:12:59 Last reboot on 31-03-2011 23:06:47 Last reconfiguration on 31-03-2011 23:06:47 Daemon is up and running ...but it doesn't make it into the BGP OPEN. Capture/decode of the OPEN message below, this is running on -current OpenBSD/amd64 (i.e. in 64-bit mode). This did work without additional config in 1.2.5. (Also noticed a minor unrelated nit that doesn't really warrant a separate mail, the sample config still lists the old format "multihop 20 via 62.168.0.13;") regards, Stuart Border Gateway Protocol OPEN Message Marker: 16 bytes Length: 45 bytes Type: OPEN Message (1) Version: 4 My AS: 61006 Hold time: 240 BGP identifier: 0.0.0.0 Optional parameters length: 16 bytes Optional parameters Capabilities Advertisement (16 bytes) Parameter type: Capabilities (2) Parameter length: 14 bytes Multiprotocol extensions capability (6 bytes) Capability code: Multiprotocol extensions capability (1) Capability length: 4 bytes Capability value Address family identifier: IPv4 (1) Reserved: 1 byte Subsequent address family identifier: Unicast (1) Route refresh capability (2 bytes) Capability code: Route refresh capability (2) Capability length: 0 bytes Support for 4-octet AS number capability (6 bytes) Capability code: Support for 4-octet AS number capability (65) Capability length: 4 bytes Capability value AS number: 61006 0000 00 0c 29 30 0d 61 00 1b 21 2d f7 0c 08 00 45 c0 ..)0.a..!-....E. 0010 00 61 77 75 40 00 0a 06 f3 fe 55 9e 2c 95 55 9e .awu@.....U.,.U. 0020 2c 92 5d 2a 00 b3 0b 3f 80 f8 49 50 cb a1 80 18 ,.]*...?..IP.... 0030 08 00 e6 5e 00 00 01 01 08 0a ac 6b 48 b4 ae b7 ...^.......kH... 0040 79 43 ff ff ff ff ff ff ff ff ff ff ff ff ff ff yC.............. 0050 ff ff 00 2d 01 04 ee 4e 00 f0 00 00 00 00 10 02 ...-...N........ 0060 0e 01 04 00 01 00 01 02 00 41 04 00 00 ee 4e .........A....N
On Thu, Mar 31, 2011 at 11:23:34PM +0100, Stuart Henderson wrote:
Hi, I was just looking at updating the OpenBSD port and noticed that bird is sending a zero BGPID, so OpenBGP refuses to talk to it.
Did you specify router id in config file, or you rely on automatic generation from IP address? -- 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 2011/04/01 01:30, Ondrej Zajicek wrote:
On Thu, Mar 31, 2011 at 11:23:34PM +0100, Stuart Henderson wrote:
Hi, I was just looking at updating the OpenBSD port and noticed that bird is sending a zero BGPID, so OpenBGP refuses to talk to it.
Did you specify router id in config file, or you rely on automatic generation from IP address?
Automatic. If I specify it manually the correct ID is sent.
On Fri, Apr 01, 2011 at 12:21:22AM +0100, Stuart Henderson wrote:
On 2011/04/01 01:30, Ondrej Zajicek wrote:
On Thu, Mar 31, 2011 at 11:23:34PM +0100, Stuart Henderson wrote:
Hi, I was just looking at updating the OpenBSD port and noticed that bird is sending a zero BGPID, so OpenBGP refuses to talk to it.
Did you specify router id in config file, or you rely on automatic generation from IP address?
Automatic. If I specify it manually the correct ID is sent.
Perhaps BIRD does found iface with some strange address. Could you send me output of 'show interfaces' ? -- 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 2011/04/01 01:42, Ondrej Zajicek wrote:
On Fri, Apr 01, 2011 at 12:21:22AM +0100, Stuart Henderson wrote:
On 2011/04/01 01:30, Ondrej Zajicek wrote:
On Thu, Mar 31, 2011 at 11:23:34PM +0100, Stuart Henderson wrote:
Hi, I was just looking at updating the OpenBSD port and noticed that bird is sending a zero BGPID, so OpenBGP refuses to talk to it.
Did you specify router id in config file, or you rely on automatic generation from IP address?
Automatic. If I specify it manually the correct ID is sent.
Perhaps BIRD does found iface with some strange address. Could you send me output of 'show interfaces' ?
bird> show interfaces lo0 up (index=4) MultiAccess AdminUp LinkUp Loopback Ignored MTU=33160 127.0.0.1/8 (Primary, scope host) em0 DOWN (index=1) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1550 bge0 DOWN (index=2) MultiAccess Broadcast Multicast AdminUp LinkDown MTU=1500 enc0 DOWN (index=3) MultiAccess AdminDown LinkUp MTU=0 lo1 DOWN (index=5) MultiAccess AdminDown LinkUp Loopback Ignored MTU=33160 trunk0 up (index=6) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 85.158.44.149/28 (Primary, scope univ) gif9 up (index=7) PtP Multicast AdminUp LinkUp MTU=1280 10.100.0.1/32 (Primary, opposite 10.100.0.2, scope site) gre0 up (index=8) PtP Multicast AdminUp LinkUp MTU=1476 10.1.1.1/30 (Primary, opposite 10.1.1.2, scope site) pfsync0 DOWN (index=9) MultiAccess AdminDown LinkUp MTU=1500 pflog0 DOWN (index=10) MultiAccess AdminUp LinkUp MTU=33160 vlan456 DOWN (index=12) MultiAccess AdminDown LinkUp MTU=1500 And it does pick up a valid router ID here: bird> show status BIRD 1.3.0 Router ID is 85.158.44.149 ^^^^^^^^^^^^^
On Fri, Apr 01, 2011 at 12:35:30AM +0100, Stuart Henderson wrote:
On 2011/04/01 01:42, Ondrej Zajicek wrote:
On Fri, Apr 01, 2011 at 12:21:22AM +0100, Stuart Henderson wrote:
On 2011/04/01 01:30, Ondrej Zajicek wrote:
On Thu, Mar 31, 2011 at 11:23:34PM +0100, Stuart Henderson wrote:
Hi, I was just looking at updating the OpenBSD port and noticed that bird is sending a zero BGPID, so OpenBGP refuses to talk to it.
Did you specify router id in config file, or you rely on automatic generation from IP address?
Automatic. If I specify it manually the correct ID is sent.
Perhaps BIRD does found iface with some strange address. Could you send me output of 'show interfaces' ? ... And it does pick up a valid router ID here:
bird> show status BIRD 1.3.0 Router ID is 85.158.44.149 ^^^^^^^^^^^^^
Thanks, fixed. There was a problem that BGP copied router ID value before it was chosen. -- 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 Thursday 31 of March 2011, Ondrej Filip wrote:
Hi! New version is ready. This version includes many changes and bugfixes. We are working on packaging and other stuff.
Please tag git tree when releasing (and best add this to release procedure document if such exits). -- Arkadiusz Miśkiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/
On 4.4.2011 19:23, Arkadiusz Miskiewicz wrote:
On Thursday 31 of March 2011, Ondrej Filip wrote:
Hi! New version is ready. This version includes many changes and bugfixes. We are working on packaging and other stuff.
Please tag git tree when releasing (and best add this to release procedure document if such exits).
OK, I will. Ondrej
participants (6)
-
Andrew Lemin -
Arkadiusz Miskiewicz -
Ondrej Filip -
Ondrej Zajicek -
Stuart Henderson -
Tony Vroon