- Bird-users - Mailing Lists

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

TAP Interface UP but bird shows it down
by Jigar Mehta 22 Apr '15

22 Apr '15

Newbie trying to play around with bird. I have a setup with tap interfaces and when I do a ifconfig , the interfaces are up and running. However from BIRD's documentation : The interface module keeps a `soft-up' state for each *iface* which is a conjunction of link being up, the interface being of a `sane' type and at least one IP address assigned to it. There is no - ip adress assigned and I have a custom forwarding plane that uses the interfaces and some smarts to tie them up into interface group and etc. Is there a work around to treat these interfaces as "UP" using the config (I mean it should just look for link up and admin up flags ? ) and have ospf protocol use them to import/export routes. I am avoiding attaching dummy addresses. Tried reading documentation and some older threads but could not find relevant info. -- Jigar Mehta

1 0

OSPF stability
by Tom Harbert 21 Apr '15

21 Apr '15

Hi, I have two Ubuntu 14.04 physical machines running BIRD 1.4.5. I am noticing the OSPF neighbor relationship is dieing. it appears that keepalives are not being received and the dead timer expires. They are directly connected to each other using LACP. There is no issue with the physical connection and layer 3 connectivity remains up over the interconnect when the problem occurs. The problem is that OSPF is advertising the loopback addresses used by iBGP which drop when the OSPF fails. 2015-04-20 09:44:17 <TRACE> OSPF_1: Inactivity timer fired on interface bond0 for neighbor x.x.x.x. 2015-04-20 09:44:17 <TRACE> OSPF_1: Neighbor x.x.x.x changes state from " full" to " down". 2015-04-20 09:44:17 <TRACE> OSPF_1: Scheduling router-LSA origination for area 0.0.0.0 2015-04-20 09:44:17 <TRACE> OSPF_1: Scheduling network-LSA origination for iface bond0 2015-04-20 09:44:17 <TRACE> OSPF_1: Deleting neigbor. 2015-04-20 09:44:17 <TRACE> OSPF_1: New neighbor found: x.x.x.x on bond0 2015-04-20 09:44:17 <TRACE> OSPF_1: Neighbor x.x.x.x changes state from " down" to " init". 2015-04-20 09:44:17 <TRACE> OSPF_1: Neighbor x.x.x.x changes state from " init" to " 2way". 2015-04-20 09:44:17 <TRACE> OSPF_1: Neighbor x.x.x.x changes state from " 2way" to " exstart". 2015-04-20 09:44:19 <TRACE> OSPF_1: Originating router-LSA for area 0.0.0.0 2015-04-20 09:44:19 <TRACE> OSPF_1: Scheduling routing table calculation 2015-04-20 09:44:19 <TRACE> OSPF_1: Starting routing table calculation 2015-04-20 09:44:19 <TRACE> OSPF_1: Starting routing table calculation for area 0.0.0.0 2015-04-20 09:44:19 <TRACE> OSPF_1: Starting routing table calculation for inter-area (area 0.0.0.0) 2015-04-20 09:44:19 <TRACE> OSPF_1: Starting routing table calculation for ext routes 2015-04-20 09:44:19 <TRACE> OSPF_1: Starting routing table synchronisation 2015-04-20 09:44:24 <TRACE> OSPF_1: Neighbor x.x.x.x changes state from " exstart" to "exchange". 2015-04-20 09:44:26 <TRACE> OSPF_1: Neighbor x.x.x.x changes state from "exchange" to " loading". 2015-04-20 09:44:27 <TRACE> OSPF_1: Neighbor x.x.x.x changes state from " loading" to " full". 2015-04-20 09:44:27 <TRACE> OSPF_1: Scheduling router-LSA origination for area 0.0.0.0 2015-04-20 09:44:27 <TRACE> OSPF_1: Scheduling network-LSA origination for iface bond0 2015-04-20 09:44:27 <TRACE> OSPF_1: Scheduling routing table calculation Configuration: # OSPF process 1 protocol ospf OSPF_1 { description "OSPF area 0"; area 0 { interface "bond0" { # To x-x-x-01 hello 1; dead count 4; type ptp; cost 1; }; stubnet x.x.x.x/29 { # bond2.51 cost 0; }; stubnet x.x.x.x/32 { # lo:1 cost 0; }; stubnet x.x.x.x/31 { # bond1.31 cost 0; }; stubnet x.x.x.x/31 { # bond1.33 cost 0; }; }; #import filter import_OSPF; #export filter export_OSPF; } Am I doing anything out of the ordinary here? Has anyone else had problems with OSPF dropping, this happens 5-10 times a day. I see no issues with the CPU utilisation on either of these hosts. I have used workarounds such as temporary static routes and also found that adjusting the dead count from 4 to 8 has kept it stable for ~2 days. 2015-04-20 10:26:53 <TRACE> OSPF_1: Changing dead interval on interface bond0 from 4 to 8 Thanks, Tom.

1 0

Information about Preferred route
by Alexandre Corso 20 Apr '15

20 Apr '15

Hello, I was looking into BIRD 1.4.5. I have one BGP session established but I don’t understand all the argument, especially about preferred route? Here my show protocol : birdc "show protocol all R12345_1” L1 name proto table state since info L2 R12345_1 BGP T12345_my_bgp up 2015-04-01 16:27:57 Established L3 Preference: 100 L4 Input filter: ACCEPT L5 Output filter: ACCEPT L6 Import limit: 20 L7 Action: disable L8 Routes: 1 imported, 21745 exported, 263 preferred L9 Route change stats: received rejected filtered ignored accepted 10 Import updates: 1 0 0 0 1 11 Import withdraws: 0 0 --- 0 0 12 Export updates: 21758 1 0 --- 21757 13 Export withdraws: 7 --- --- --- 7 14 BGP state: Established 15 Neighbor address: 10.10.10.100 16 Neighbor AS: 12345 17 Neighbor ID: 192.168.0.1 18 Neighbor caps: refresh AS4 19 Session: external AS4 20 Source address: 10.10.10.250 21 Route limit: 1/20 22 Hold timer: 150/240 23 Keepalive timer: 9/23 Can you help me about the line L8 : My peer import 1 route I export 21745 routes I don’t know about preferred Thank you Alexandre Corso Network Engineer acorso(a)franceix.net

4 6

Bird and aggregates
by Joel Brunenberg 17 Apr '15

17 Apr '15

Hi bird list, I am thinking about this for some time now, reading documentation and all but I did not find a solution until now, so I am turining to you: Does bird (1.4.5) support aggregate routes in any way? The Scenario is as follows. I have a VPN consisting of around 20-40 ptp-links, an OSPF area that spans these links and several larger subnets that are connected to the nodes that interconnect using the named ptp links. So far so good. I would not want to interfere with the Prefixes in the OSPF. I however have a BGP-session to another network and I am exporting most of my routes to that session. I'd like to replace all the /32 routes for ptp links with the /24 they are taken from while exporting routes for that BGP session. Since it is totally irrelevant for the peer, which parts of the /24 are available, I would just like to attract traffic to the networks I manage as long as there are any contributing routes. I had several ideas on how to do that, one being an export filter that replaces every /32 with the according /24, but that would lead to a lot of /24 routes and seems to be impossible with bird since the prefix attribute is immutable. Another idea was a static route for the containing /24 that would be exported via BGP while the /32 were filtered away. That however leaves the /24 route in place even if there are no more /32 routes left. If there is a way to change that, that would be great. If anyone has any idea how to accomplish this, it would be very much appreciated. Thanks in advance, Joel /jbn -- Joel Brunenberg - Troisdorf PGP: 0xAD25981C

3 5

OSPF anycast prefix being filtered
by Patrik Lundin 11 Apr '15

11 Apr '15

Hello, I am trying to use BIRD for anycasting a /32 prefix via OSPF and I am not able to get the announcement to work. My idea is to have the server use the normal default gw for routing packets. Because of this I see no reason for importing routes from OSPF into the kernel routing table, I am only interested in exporting the anycast address that is configured on the loopback interface. I configure a /32 prefix on the loopback interface like so: === # ip address add yyy.yyy.yyy.yyy/32 dev lo === My bird.conf looks like this: === router id xxx.xxx.xxx.xxx; debug protocols all; protocol device {} protocol ospf { import none; # Default is import all export all; area 0.0.0.0 { interface "eth*" { authentication cryptographic; password "pass"; }; interface "lo" {}; }; } === It seems however that the address on lo (as well as eth0) is being "filtered out" by BIRD, as seen in debug mode: === # bird -d bird: device1: Initializing bird: ospf1: Initializing bird: device1: Starting bird: device1: Scanning interfaces bird: device1: Connected to table master bird: device1: State changed to feed bird: ospf1: Starting bird: ospf1: Adding area 0.0.0.0 bird: ospf1: Connected to table master bird: ospf1: State changed to feed bird: Started bird: device1: State changed to up bird: ospf1 < interface lo goes up bird: ospf1 < primary address yyy.yyy.yyy.yyy/32 on interface lo added bird: ospf1: Adding interface lo (yyy.yyy.yyy.yyy/32) to area 0.0.0.0 bird: ospf1 < secondary address 127.0.0.0/8 on interface lo added bird: ospf1 < interface eth0 goes up bird: ospf1 < primary address zzz.zzz.zzz.zzz/30 on interface eth0 added bird: ospf1: Adding interface eth0 (zzz.zzz.zzz.zzz/30) to area 0.0.0.0 bird: ospf1: State changed to up bird: ospf1: Changing state of iface eth0 from down to ptp bird: ospf1: Scheduling router-LSA origination for area 0.0.0.0 bird: ospf1: HELLO packet sent via eth0 bird: ospf1: Changing state of iface lo from down to waiting bird: ospf1: Scheduling router-LSA origination for area 0.0.0.0 bird: ospf1: Originating router-LSA for area 0.0.0.0 bird: ospf1: Scheduling routing table calculation bird: ospf1: Starting routing table calculation bird: ospf1: Starting routing table calculation for area 0.0.0.0 bird: ospf1: Starting routing table calculation for inter-area (area 0.0.0.0) bird: ospf1: Starting routing table calculation for ext routes bird: ospf1: Starting routing table synchronisation bird: ospf1 > filtered out zzz.zzz.zzz.zzz/30 dev eth0 bird: ospf1 > filtered out yyy.yyy.yyy.yyy/32 dev lo [...] === I guess I am missing something obvious, any pointers would be much appreciated! -- Patrik Lundin

4 8

High CPU load
by Simone Morandini 09 Apr '15

09 Apr '15

Hello list, we are running BIRD on our IXP peering platform with no problems since quite a while now. We need to activate a new peer which is expected to announce a considerable amount of prefixes (~100k), and the first try resulted in having nearly 100% cpu load, ~60-70% for BIRD and the remaining for syslog. The machine was hardly manageable, so after a few minutes we had to disable the peer and restart the deamon. The current settings actually make BIRD log everything: log "/var/log/bird.log" all; log syslog all; so I guess we could start by modifying it: any advice on this? Would you suggest something more, in order to avoid having again a high cpu load? Thanks in advance, Simone.

4 3

Best external route on iBGP
by Apollon Oikonomopoulos 09 Apr '15

09 Apr '15

Hi all, I've noticed that BIRD doesn't advertise the best external route to iBGP peers (as it "should" according to RFC 1771) if there is already an iBGP route for the same destination. I realize this is a point where most BGP implementations deviate from the standard, although many of them offer knobs to enable best external route propagation[1][2]. Still, this is a useful behaviour, especially in active-backup setups where backup paths are completely hidden from the rest of the AS. In essence, it looks as if BIRD can do this with sorted tables and the secondary BGP option, but unfortunately sorted tables are incompatible with iBGP's multihop operation due to the recursive gateway calculation strategy. Another option is of course add-paths, but then BIRD advertises all received paths, leading to a larger memory consumption than necessary. So, in case I'm missing something, is there another way to achieve best external route propagation over iBGP? Regards, Apollon [1] http://www.juniper.net/documentation/en_US/junos13.2/topics/example/policy-… [2] http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/…

2 2