- Bird-users - Mailing Lists

key/value structure
by Pavlos Parissis 09 May '15

09 May '15

Hi, For each ip_prefix I advertize I need to add a BGP community in the form of (ASN,<RouterID>). I have the following mapping between IPs and RouterIDs ip_prefix, RouterID 10.10.10.1, 1 10.10.10.2, 2 10.10.10.3, 3 10.10.10.4, 1 10.10.10.5, 2 10.10.10.6, 3 ..... So, inside a function I need to express the following lookup_community_router_id() { return some_kind_of_dict_structure(net.ip) } and the use it in a filter/function filter { bgp.community((1111, lookup_community_router_id(net))); accept; } Is this possible? Thanks, Pavlos

2 2

Re: Bird IRC channel
by Hans van Kranenburg 04 May '15

04 May '15

Hi, On 05/04/2015 08:06 PM, Tom Wesley wrote: > > As noone piped up saying what a bad idea this I've made all three of > your channel founders so you can set the channel up as you wish. Thank you, Tom! Hans van Kranenburg

1 0

no rc files with bird on ubuntu ?
by Kai 03 May '15

03 May '15

Hello everybody! We are running bird and bird6 on an ubuntu server. I just noticed that /etc/init.d/bird and .../bird6 are not linked to any of the /etc/rc?.d directories on our three systems. Furthermore update-rc.d wouldn't create the links but just fail silently (that is with a succinct "System start/stop links for /etc/init.d/bird do not exist."). I'm stuck right now. Does anyone else observe the same behaviour? Am I mistaken in thinking there should be rd.c-files? Best regards, Kai -- "Das ist Demokratie, wenn man sich aussuchen darf, wer einen verarscht." (Hagen Rether) D-55118 Meenz fast: kai_pf (aT] web(dot)de ++ PGP Key fingerprint B567 C43E 99D1 7709 7D64 3BF8 2DE8 1092 0EEF D58E ++ -----BEGIN GEEK CODE BLOCK----- VERSION: 3.12 GCS/IT/CM d- s:- a+>-----(?) C++$ UL++(++++$) P+++ L++ E-(+) W--(+) N !w---($) !O !M V? PS+ PE-() Y+ PGP(+) t R*@ tv--@ b+>++ DI++ G e+++(*) h? y? ------END GEEK CODE BLOCK------

3 3

Version 1.5.0 in Ubuntu PPA
by Clint Armstrong 28 Apr '15

28 Apr '15

Will packages be going into the official Ubuntu PPA soon? https://launchpad.net/~cz.nic-labs/+archive/ubuntu/bird

1 0

bird6 1.4.5 OSPFv3 LSA checksum failures
by Chris Boot 28 Apr '15

28 Apr '15

Hi folks, I’m running bird6 1.4.5-1 (from Debian jessie) on my home network. Quite regularly I see floods of "Received bad lsa checksum” message in my syslog on the two routers that run BIRD, which causes connectivity interruptions. The network is made up of a variety of devices running different OSPF stacks. The network is fully dual-stacked with the same devices running OSPFv2 and OSPFv3 with a mostly identical configuration. The network contains two Quagga (0.99.23.1-1 from Debian Jessie) routers, one Dell PowerConnect 8024F (fw 5.1.7.5), and several MikroTik RouterOS (6.28) routers. The problem *only* occurs on OSPFv3; OSPFv2 is unaffected. The messages always follow a very specific pattern. Here are the last 10 received on one of my routers: Apr 25 16:17:36 clemens bird6: Received bad lsa checksum from fe80::290:7fff:fe3c:502a: de00 deff Apr 25 16:17:37 clemens bird6: Received bad lsa checksum from fe80::5e26:aff:feb8:34ad: de00 deff Apr 25 16:17:41 clemens bird6: Received bad lsa checksum from fe80::290:7fff:fe3c:502a: de00 deff Apr 25 16:17:42 clemens bird6: Received bad lsa checksum from fe80::5e26:aff:feb8:34ad: de00 deff Apr 25 16:17:46 clemens bird6: Received bad lsa checksum from fe80::290:7fff:fe3c:502a: de00 deff Apr 25 16:17:47 clemens bird6: Received bad lsa checksum from fe80::5e26:aff:feb8:34ad: de00 deff Apr 25 16:17:51 clemens bird6: Received bad lsa checksum from fe80::290:7fff:fe3c:502a: de00 deff Apr 25 16:17:52 clemens bird6: Received bad lsa checksum from fe80::5e26:aff:feb8:34ad: de00 deff Apr 25 16:17:56 clemens bird6: Received bad lsa checksum from fe80::290:7fff:fe3c:502a: de00 deff Apr 25 16:18:01 clemens bird6: Received bad lsa checksum from fe80::290:7fff:fe3c:502a: de00 deff If I grep my logs looking for unique entries, I see the following: Received bad lsa checksum from $PEER: 1800 18ff Received bad lsa checksum from $PEER: 30 ff30 Received bad lsa checksum from $PEER: 3500 35ff Received bad lsa checksum from $PEER: 40 ff40 Received bad lsa checksum from $PEER: 5000 50ff Received bad lsa checksum from $PEER: 6600 66ff Received bad lsa checksum from $PEER: 6e00 6eff Received bad lsa checksum from $PEER: 86 ff86 Received bad lsa checksum from $PEER: 9800 98ff Received bad lsa checksum from $PEER: 9c00 9cff Received bad lsa checksum from $PEER: 9e ff9e Received bad lsa checksum from $PEER: 9f ff9f Received bad lsa checksum from $PEER: bc ffbc Received bad lsa checksum from $PEER: cc ffcc Received bad lsa checksum from $PEER: cd ffcd Received bad lsa checksum from $PEER: cf00 cfff Received bad lsa checksum from $PEER: dc ffdc Received bad lsa checksum from $PEER: dd ffdd Received bad lsa checksum from $PEER: de00 deff Received bad lsa checksum from $PEER: e600 e6ff Received bad lsa checksum from $PEER: ee00 eeff Received bad lsa checksum from $PEER: fe fffe Thus, the problem occurs when (AIUI) the checksum sent by the peer has a zero octet, which doesn’t agree with how lsasum_check() calculates the checksum where the octet is always 0xff instead. This happens either when the first octet is zero or the second octet is zero. Looking through my logs, it seems I have yet to run into a situation where the values are reversed, e.g. the checksum in the LSA always includes a zero octet and BIRD always calculates 0xff, never the other way around. I have yet to look in much detail whether the problem is likely to be in BIRD’s lsasum_check() implementation or in the checksum generated by one of my other devices, and I don’t yet know which device(s) generate the LSAs that BIRD complains about. Has anyone here run into this before? Thanks, Chris -- Chris Boot bootc(a)bootc.net

2 4

Bird IRC channel
by Hans van Kranenburg 26 Apr '15

26 Apr '15

Hi all, As you might probably, or more probably not know, a sub-official bird IRC channel exists, which is #bird on freenode. The current inhabitants have no idea who ever started the channel, or how to be able to change any attributes of the channel, like setting topic or anything... Cycling the channel is not really an option, since 99% of the inhabitants seem just to be lurking around, never saying anything. (Yeah, if you're reading this, say something! :D ) 00:24 <Knorrie> access #bird list 00:24 -ChanServ(ChanServ@services.)- Entry Nickname/Host Flags 00:24 -ChanServ(ChanServ@services.)- ----- ---------------------- ----- 00:24 -ChanServ(ChanServ@services.)- 1 freenode-staff +AFRefiorstv [modified 2y 44w 5d ago] 00:24 -ChanServ(ChanServ@services.)- ----- ---------------------- ----- 00:24 -ChanServ(ChanServ@services.)- End of #bird FLAGS listing. 00:27 <Knorrie> flags #bird 00:27 -ChanServ(ChanServ@services.)- You are not authorized to perform this operation. From time to time we have really interesting conversations on this IRC channel, and I would really like it to become a little more active. Let's hang around and just share a bit about what we're doing with bird in an informal way. If you have ever started this channel, or have any idea how to get control of it back again, join! -- Hans van Kranenburg - System / Network Engineer T +31 (0)10 2760434 | hans.van.kranenburg(a)mendix.com | www.mendix.com

1 1

password for BGP in clear-text in bird.conf file?
by Christopher Jay Manders 25 Apr '15

25 Apr '15

Hi, I am not sure if this has been brought up before, but it is very sad that the password for BGP AUTH is in clear-text. Is there anything in progress to rectify or discussion about this? Encoding or encryption of the password would be a very welcome thing. Thanks! Christopher

5 5

Re: Deprecated 'route limit'
by Jonathan Stewart 22 Apr '15

22 Apr '15

Aris, On Wed, Apr 22, 2015 at 1:46 PM, Aris Lambrianidis <effulgence(a)outlook.com> wrote: > > “Import limit" supersedes “route limit”: > > http://bird.network.cz/?get_doc&f=bird-3.html#import-limit > Thanks for the link, this explains it perfectly. I've just updated my configs on Bird 1.4.5, and no errors. Cheers, -- Jonathan

1 0

Deprecated 'route limit'
by Jonathan Stewart 22 Apr '15

22 Apr '15

Hi, In the release notes for Bird 1.5.0, it's noted that the 'route limit' configuration is deprecated. Is there another command I should use instead? Is there a reason why this option is a bad idea to use? I'm using it now on a large IXP peer, rather than a specific route filter, since their route list would be far too long. I'm thinking that the route limit option is almost like having no limit at all, so maybe I can just remove it and fully trust the ISP (HE.net at MBIX) Thanks, -- Jonathan

3 2

Version 1.5.0
by Ondrej Filip 22 Apr '15

22 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dear Bird users, the new version is out: Version 1.5.0 (2015-04-20) o Major OSPF protocol redesign. o OSPFv2 multi-instance extension (RFC 6549). o BGP AS-wide unique router ID (RFC 6286). o BGP enhanced route refresh (RFC 7313). o Link state support in BGP. o Latency tracking and internal watchdog. o Uses high port range for BFD on BSD. o Increase max symbol length to 64. o Allows to define unnamed protocols from templates. o Fixes two serious bugs in BGP. o Several bugfixes and minor improvements. o Several minor option changes: - OSPF: Protocol-wide 'instance id' option added. - BGP: Parameters to option 'neighbor' extended. - BGP: Separate option 'interface' added. - BGP: Option 'start delay time' renamed to 'connect delay time'. - BGP: Option 'route limit' deprecated. Upgrade notes: For OSPF, there are deep internal changes, but user-visible changes are limited to log messages and minor changes in formatting of command output. For BGP, version 1.5.0 is essentially a minor release. There are two deprecated options ('start delay time' and 'route limit') and some minor formatting changes. Ondrej -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVN7TgAAoJED82D4RIDoWPZYIP/3XOnFk+URxox99hID7RloaP ECOxxSxDH3w2R+RrxqEcG6lt+k5aXATqADGAYVyEMFlUuMMt0Bc2H84UbOFBbX4Z DLvexVJOKdNU253JLjdac+44ouLonE07IhuRL39ANV9tmVM6Fgvb+vVt/tQRmBLV PMFNHOfQab4gvsXr3EiWahanLxh46uVtH4DBa1VKas9nvZc3354DaseTIUH9V79Z UYIaJyp/HlzytjG6CQcbdfiqNhbigo01WF/0EbglMsGvc4Z5t/C4VZEalBU6CnKQ NoDI/WXHYwHmj6j5p2KoW5xmv62/raiDMyRzi3HBCPn72P7056eg5DT+6Fgnpakv 6lKujWvnhnRRrHujTpo8o3yPo+MxNctHAeJCcRsG1QOEFhIaafBCvjlP2X5aFZ59 JC7X9p5zm9KlUjH/sE9vbuN6LWnaIpgbs7vF6r71sVdrsacuyFxJ3r/Uv5OmInnG 7onBeclweu1DK3lLqfbJhS1MgzIIJdk5aMc6t9qH0PXHvhtC2KFrKWgRTfnPPQAD rwmaR1YODtIjRk6kBBdHY1BOEuzo6xTfFuiNi7ZRnaPZHfqV0AWBBdsQeshIykhB PYUXkGTA6dlDxaYUkn5NTR/naebOKs39hoy0w0s/tNJOq24qYvy9uCnbE0Rj3MDg zI8cSe6dCm0mJEQImpOJ =TQPR -----END PGP SIGNATURE-----

1 0