- Bird-users - Mailing Lists

import OSPF external routes
by Roman Romanyak 14 Jun '16

14 Jun '16

Hello bird users, I ran into the issue with importing OSPF external route. Maybe someone can point me in the right direction. This is the OSPF filter: filter OSPF_IN { if source = RTS_OSPF then accept; # reject; accept; } And this is a route in question - a loopback interface of another router/OSPF neighbor: bird> show route for 10.120.0.55 all 10.120.0.55/32 via x.x.x.x on bond1 [EDGE_OSPF 19:49:20] * E1 (150/10) [10.2.55.2] Type: OSPF-E1 unicast univ OSPF.metric1: 10 OSPF.metric2: 16777215 OSPF.tag: 0x00000000 OSPF.router_id: 10.2.55.2 bird> bird> show ospf state router 10.2.55.1 distance 10 ...[some output is omitted ] external 10.120.0.55/32 metric 0 When I replace 'accept' with 'reject' in the filter, I'm not able to see 10.120.0.55/32 route in the FIB. Thanks, Roman.

2 2

routing using kernel fibs
by Angel 04 Jun '16

04 Jun '16

Hello, We are configuring a BSDRP server (FreeBSD router.bsdrp.net 10.3-RELEASE-p2 FreeBSD 10.3-RELEASE-p2 #0 r299108M). We have two fullrouting bgp carriers, some bgp members and some ospf members. To isolate OSPF members we want to use kernel fibs. But we do not understand how it works. What we need is a diferent table for each ospf member, so for example ospf1member will use carrier1 routes, and ospf2member will use carrier2 routes. Which is the best way to get this? If we configure kernel fib 1 with carrier1 routes, but ospf1 doesn't use it, how we can to configure because ospf1 use kernel fib 1? How to do the same for ospf2 with kernel fib 2? We have to configure interfaces in these fibs? What about carriers interface? Could you give us some example to get above configuration? Regards, Angel.

4 4

Empty lists
by Stefan Plug 03 Jun '16

03 Jun '16

Hi guys, Using Bird 1.5.0 Is is somehow possible to have an empty list? define AllowedExportAsList = []; This gives me a syntax error. Greetings, Stefan

2 2

Version 1.6.0
by Ondrej Filip 31 May '16

31 May '16

Dear Bird users, the long expected version is out: Version 1.6.0 (2016-04-29) o Major RIP protocol redesign o New Babel routing protocol o BGP multipath support o KRT: Add support for plenty of kernel route metrics o KRT: Allow more than 256 routing tables o Static: Allow to specify attributes for static routes o Static: Support for BFD controlled static routes o FreeBSD: Setup password for BGP MD5 authentication o IO: Remove socket number limit o Plenty of bug fixes Upgrade notes: For RIP, most protocol options were moved to interface blocks. Enjoy! Ondrej

17 53

Bird very slow and not importing all routes
by noc＠dolphin-it.de 30 May '16

30 May '16

Hi, I set up bird and bird6 to replace my quagga-setup. I get full-tables for IPv4 and IPv6 but bird fails to import most of them. Example: Quagga needs a maximum of 10 seconds to import 500k routes into main table where bird needs 20 minutes to reach this state: bgp_peer1 BGP master up 19:07:10 Established Preference: 100 Input filter: ACCEPT Output filter: (unnamed) Routes: 226754 imported, 1 exported, 226754 preferred Route change stats: received rejected filtered ignored accepted Import updates: 226754 0 0 0 226754 Import withdraws: 0 0 --- 0 0 Export updates: 226755 226754 0 --- 1 Export withdraws: 0 --- --- --- 0 BGP state: Established Neighbor address: X Neighbor AS: X Neighbor ID: X Neighbor caps: refresh restart-aware AS4 Session: external AS4 Source address: X Hold timer: 72/90 Keepalive timer: 10/30 My config (AS and Net anonymized): # Set local AS define myas=13456; protocol device { scan time 10; } protocol kernel { import all; export all; persist; scan time 15; } protocol static static_bgp { import all; # My net - Set prefixes to be announced (anonymized) route 1.1.1.0/24 reject; } protocol bgp bgp_peer1 { import all; export where proto = "static_bgp"; interpret communities no; missing lladdr ignore; local as myas; neighbor 8.8.8.8 as 1234; password "xxxxxxxxxxxx"; } ------------------ I don't see what is going wrong. Also I don't get why routes are re-exported to bgp_peer1 while "static_bgp" only lists one network. Any ideas? Thanks, Kevin

1 0

Re: Help on customizing BIRD- getting community value
by Martin Mares 26 May '16

26 May '16

Hello! > I am a PhD student at Roma Tre University of Rome, Italy and I am > working on implementation of route server at IXP with BIRD. I want > to have access to community values inside BIRD which are sent by > ASes. Based on received community values I want to customize BIRD > code. > > I found that inside attrs.c file I should decode the data to get > community value, but I do not know how. With sniffing incoming > packets I can see the community values, but not inside BIRD. > > I was wondering may I ask you to help about this. I do not maintain BIRD any longer, but I am forwarding your mail to the bird-users mailing list. Have a nice fortnight -- Martin `MJ' Mares <mj(a)ucw.cz> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Quote of the day: '

1 0

multiple kernel routing tables
by Angel 24 May '16

24 May '16

Hello, In BSDRP how could we activate and work with multiple kernel tables? Regards, Angel.

1 0

reject debug messages
by Angel 23 May '16

23 May '16

Hello, We are configuring a new bird router, and after configure a carrier, we can see following messages on debug every minute: ------------ >>> AS174transit > added [best] 193.148.120.0/24 via 149.6.130.137 on ix0 >>> AS174transit < rejected by protocol 193.148.120.0/24 via 149.6.130.137 on ix0 >>> AS174transit > added [best] 193.148.126.0/24 via 149.6.130.137 on ix0 >>> AS174transit < rejected by protocol 193.148.126.0/24 via 149.6.130.137 on ix0 >>> AS174transit > added [best] 193.148.125.0/24 via 149.6.130.137 on ix0 >>> AS174transit < rejected by protocol 193.148.125.0/24 via 149.6.130.137 on ix0 >>> AS174transit > added [best] 193.148.121.0/24 via 149.6.130.137 on ix0 >>> AS174transit < rejected by protocol 193.148.121.0/24 via 149.6.130.137 on ix0 >>> AS174transit > added [best] 81.17.142.0/24 via 149.6.130.137 on ix0 >>> AS174transit < rejected by protocol 81.17.142.0/24 via 149.6.130.137 on ix0 >>> AS174transit > added [best] 91.198.226.0/24 via 149.6.130.137 on ix0 >>> AS174transit < rejected by protocol 91.198.226.0/24 via 149.6.130.137 on ix0 >>> AS174transit > added [best] 85.140.116.0/22 via 149.6.130.137 on ix0 >>> AS174transit < rejected by protocol 85.140.116.0/22 via 149.6.130.137 on ix0 >>> AS174transit > added [best] 195.128.159.0/24 via 149.6.130.137 on ix0 >>> AS174transit < rejected by protocol 195.128.159.0/24 via 149.6.130.137 on ix0 >>> AS174transit > added [best] 46.225.128.0/19 via 149.6.130.137 on ix0 >>> AS174transit < rejected by protocol 46.225.128.0/19 via 149.6.130.137 on ix0 >>> AS174transit > added [best] 46.225.96.0/19 via 149.6.130.137 on ix0 >>> AS174transit < rejected by protocol 46.225.96.0/19 via 149.6.130.137 on ix0 >>> AS174transit > added [best] 46.224.7.0/24 via 149.6.130.137 on ix0 >>> AS174transit < rejected by protocol 46.224.7.0/24 via 149.6.130.137 on ix0 >>> AS174transit > added [best] 46.225.224.0/19 via 149.6.130.137 on ix0 >>> AS174transit < rejected by protocol 46.225.224.0/19 via 149.6.130.137 on ix0 >>> AS174transit > added [best] 46.225.0.0/19 via 149.6.130.137 on ix0 >>> AS174transit < rejected by protocol 46.225.0.0/19 via 149.6.130.137 on ix0 >>> AS174transit > added [best] 46.224.96.0/19 via 149.6.130.137 on ix0 >>> AS174transit < rejected by protocol 46.224.96.0/19 via 149.6.130.137 on ix0 >>> AS174transit > added [best] 46.225.32.0/19 via 149.6.130.137 on ix0 >>> AS174transit < rejected by protocol 46.225.32.0/19 via 149.6.130.137 on ix0 >>> AS174transit > added [best] 46.224.128.0/19 via 149.6.130.137 on ix0 >>> AS174transit < rejected by protocol 46.224.128.0/19 via 149.6.130.137 on ix0 >>> AS174transit > ignored 109.72.148.0/22 via 149.6.130.137 on ix0 >>> AS174transit > ignored 109.72.147.0/24 via 149.6.130.137 on ix0 >>> AS174transit > ignored 109.72.146.0/24 via 149.6.130.137 on ix0 >>> AS174transit > ignored 109.72.145.0/24 via 149.6.130.137 on ix0 >>> AS174transit > ignored 109.72.144.0/24 via 149.6.130.137 on ix0 >>> AS174transit > ignored 37.46.114.0/24 via 149.6.130.137 on ix0 >>> AS174transit > ignored 109.248.240.0/22 via 149.6.130.137 on ix0 >>> AS174transit > ignored 109.248.242.0/24 via 149.6.130.137 on ix0 >>> AS174transit > ignored 109.248.241.0/24 via 149.6.130.137 on ix0 >>> AS174transit > ignored 109.248.240.0/24 via 149.6.130.137 on ix0 >>> AS174transit > ignored 109.248.225.0/24 via 149.6.130.137 on ix0 >>> AS174transit > ignored 109.248.224.0/24 via 149.6.130.137 on ix0 ------------ We understand that added messages is because carrier sent us new routes, ignored looks like that we know this route, so we do not need to add to our table, but what about rejected messages? How could we fix it? What could be our misconfiguration? Regards,

2 3

Lots of Loglines "Pipe loop detected when sending ..." with 1.6
by Robert Wein 19 May '16

19 May '16

Hello bird community, I upgraded on of our VIX Routeservers from 1.5 to 1.6 recently. When running 1.6 I receive a lot of loglines: ------- May 19 07:33:10 rs1 bird: Pipe loop detected when sending x.y.z.a/b to table Tcxd root@rs1:/var/log# grep "Pipe loop detected" daemon.log | wc -l 1914110 root@rs1:/var/log# ------- (log rotated on a daily base) I guess there exists a kind of race condition when accessing the table for updating. Running 1.5 I didn't find a single line like those. Config remained the same +/- different prefix-lists, install base is Debian 8.4, .debs from bird.network.cz/debian/ any hints? Thank you best regards Robert -- www.vix.at | www.aco.net robert.wein(a)univie.ac.at | RW2586-RIPE Vienna University Computer Center Tel: +43 1 4277-14046 | Fax: -14338

1 0

Babel in Bird
by Ondrej Zajicek 12 May '16

12 May '16

Hi During testing of Babel we noticed a strange behavior and we are not sure if it is a problem in the implementation or in the specification. The sequence of events is like: 1) Router A is running, originated some routes with seqno old_seqno and propagated them to a router B. 2) If router A (or Babel protocol) is restarted, the seqno counter used for originating routes is also reset to 1. 3) Then routes are originated with seqno 1 and propagated to router B. 4) Router B already has these routes with old high seqno, so the update is considered unfeasible and for selected entries, so it is ignored (3.5.4). 5) The routes in the router B's table slowly expire. 6) When routes expire, router B sends seqno request (3.8.2.1) with old_seqno+1. 7) Router A receives seqno request, increases seqno to 2 (3.8.1.2), originates routes with seqno 2 and sends them to router B. 8) Router B still ignores them as 2 < old_seqno. 9) Subsequent updates are still ignored as router B holds old timeouted entry as a selected entry with unreachable metric (as there is no other one) until GC time. I have two questions w.r.t. this sequence of events: 1) How is router restart and seqnos supposed to be handled without waiting for route timeout? 2) If a route is selected, then becomes unreachable/retracted, and there is no other route to be selected, is it still considered selected? I would say that no as the selection process (3.6) forbids retracted routes to be selected, but the BIRD implementation keeps the old selected route (now unreachable) in this case. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago(a)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."

3 11