November 2013 - Bird-users

IS-IS
by kveri new 01 Jun '15

01 Jun '15

Hello, I would like to implement IS-IS as a part of my master thesis. Are there any apparent problems which would prevent successful implementation, political and/or technical? Also I would like to hear opinions of the authors. Implementation timeframe is 2013 (if we live past 21th). Regards, Martin Čechvala Faculty of Informatics and Information Technologies Slovak Technical University

7 8

OSFP LSA_MAXSEQNO problems
by Alexander V. Chernikov 23 Feb '14

23 Feb '14

Hello list! Currently bird performs LSA premature aging in very strange way which sometimes upsets quagga (up to SIGSEGV) and Cisco. Every time aging is done via setting seq number to LSA_MAXSEQNO. RFC 2328, on the opposite, shows us only 2 cases where MaxSequenceNumber is used in outgoing LSAs: 1) Self LSA originating with given seq num (very rare event) 2) [Premature] Aging of LSA from 1) because a) disappeared net and b) seq number increase (12.1.6) For all other cases seq number should be either increased or left intact. Bird, however, insist on setting LSA_MAXSEQNO while: 1) Receiving self-originating LSA which is not in local LSDB ( ospf_lsupd_receive ) which is not a special case according to 14.1 2) In all other places like handling if-down, external route disappear, etc... ( ospf_lsupd_flush_nlsa ) IT takes noticeable time (sometimes up to 5 seconds) for Cisco 65XX with ~40 neighbors to age given LSA (however it seems that problem is repeatable for ASR9k, too). And while such LSA is in database, every new update is ignored due to 13 step (8). (I've got full logs and pcap for given situation). Can we please consider applying attached patch to make it more compliant?

2 3

Using RAdv and trigger routes with multiple interfaces
by Tore Anderson 29 Nov '13

29 Nov '13

Hi, I'm trying to set up conditional RA transmission from BIRD 1.3.11 on a firewall pair running Keepalived for HA/failover. My goal is to start emitting RAs on an interface as soon as Keepalived adds an IPv6 address on it, and start suppressing the RAs (i.e., sending with router lifetime=0) as soon as Keepalived removes it. On first look, it would appear that the "trigger" option is exactly what I need. However, I ran into the a problem - it appears to be global for the entire radv protocol instead of being per-interface, and that I cannot seem to work around limitation that by setting up multiple (one per interface) instances of the protocol either. To be more specific, assume that I have two interfaces with the following virtual IPs controlled by Keepalived: vlan100 = 2001:db8:100::1/64 vlan200 = 2001:db8:200::1/64 I would have liked to do something like: protocol radv { interface "vlan100" { trigger 2001:db8:100::/64; # <-- syntax error on this line }; interface "vlan200" { trigger 2001:db8:200::/64; }; } ...but that only gives me a syntax error on the line marked. So I tried the following instead, which also resulted in a syntax error: protocol radv vlan100 { # <-- syntax error on this line interface "vlan100"; trigger 2001:db8:100::/64; } protocol radv vlan200 { interface "vlan200"; trigger 2001:db8:200::/64; } Am I missing something obvious here or is the trigger feature only useful on routers with a single network interface? Best regards, Tore Anderson

2 2

Feature Request: Bird should be able to find out the correct source address for next hop self automatically
by Dr. Christian Riede 29 Nov '13

29 Nov '13

Hello, with protocol bgp { local as 48175; import filter as12843in; export filter as12843out; enable as4 yes; hold time 600 ; keepalive time 10; neighbor 2A02:0788:0001:0008::1 as 12843; path metric 1; next hop self; } I get bird> show route export bgp12 all 2001:67c:39c::/48 via 2001:67c:39c:8000::8000:4 on eth0 [static1 09:39] * (2000) Type: static unicast univ BGP.origin: IGP BGP.as_path: 48175 BGP.next_hop: 2001:67c:39c:8002::8000:3 BGP.local_pref: 100 After configuring the source address manually, I get the correct next hop: protocol bgp { local as 48175; import filter as12843in; export filter as12843out; enable as4 yes; hold time 600 ; keepalive time 10; neighbor 2A02:0788:0001:0008::1 as 12843; path metric 1; source address 2a02:788:1:8::3; next hop self; } bird> show route export bgp12 all 2001:67c:39c::/48 via 2001:67c:39c:8000::8000:4 on eth0 [static1 09:39] * (2000) Type: static unicast univ BGP.origin: IGP BGP.as_path: 48175 BGP.next_hop: 2a02:788:1:8::3 BGP.local_pref: 100 According to the documentation, bird should be able to find out the correct source address automatically. But is does not ;-) This is bird 1.3.9 Mit freundlichen Grüßen Christian Riede -- _________________________________________ =C=O=N=N=E=C=T== Karlsruhe GmbH Computer und Netzwerktechnik Gebrüder-Himmelheber-Straße 7 D-76135 Karlsruhe Amtsgericht Mannheim HRB 110258 Geschäftsführer: Stefan Kratzer Telefon: +49 721 20120-0 Telefax: +49 721 20120-500 Internet: http://www.connect-ka.de E-Mail: christian.riede(a)it-connect.de _________________________________________

2 1

New release 1.4.0
by Ondrej Filip 26 Nov '13

26 Nov '13

Hi Bird users, a premature Christmas gift is here. We have a new version of your popular routing daemon. Since this version could potentially break some of you current installation and since it adds a new protocol - BFD, this version has number 1.4.0. The branch 1.4.0 is meant to be stable for production environment. Ondrej Version 1.4.0 (2013-11-25) o BFD protocol (RFC 5880). o BFD support for OSPF and BGP. o New 'allow local as' option for BGP. o Filters allows setting gw, ifname and ifindex. o Filter operator 'delete/filter' extended to bgp_paths. o Filter operator 'len' extended to [e]clists. o BIRD client now allows shorthands for noninteractive commands. o Flag -P for PID file support. o Flag -f added to force BIRD to run in foreground. o Protocol exp/imp/recv limits are checked during reconfiguration o Several bugfixes and minor improvements. o Several minor but incompatible changes: - IBGP is multihop by default. - Changes primary address selection on BSD to the first one. - Integers in filters are handled as unsigned. - ISO 8601 time formats used by default. - Import of device routes from kernel protocol allowed. - Last state change now tracks just protocol state change. - Minor changes to default router ID calculation.

3 5

Importing MRT files into bird
by Daniel Gomez 26 Nov '13

26 Nov '13

Good Morning, I am looking for a direct way to import a full bgp table into bird using the RIS Raw Data from RIPE NCC (http://www.ripe.net/data-tools/stats/ris/ris-raw-data) This page links to the raw data collected by the RRCs using Quagga routing software, stored in MRT format. This format is described in an IETF draft. These files can be read using libbgpdump, a library written in C by Dan Ardelean, currently maintained by the RIPE NCC. A Python library also exists, PyBGPdump which provides access to MRT files via Python. Actually, I can import the routes via bgpsimple/bgpdump into bird stablishing a bgp connection, but I would like to know, if there is a way for bird to directly import MRT File and the routes. Have someone tried it before? Regards, Daniel Gomez

1 0

Routes in kernel table not being imported
by Iain 25 Nov '13

25 Nov '13

Hi, I posted a while ago with some problems that I thought were probably due my IPSEC set-up, so I switched to StrongSWAN to try and simplify things. I now get my IPSEC routes appearing in kernel table 220, and I’d like to import these routes into Bird. As a first step, If I start Bird up with the config file below on Machine B: log syslog all; debug protocols all; protocol kernel { learn; persist; scan time 10; import all; export none; kernel table 220; } protocol device { scan time 10; } # Not sure this stuff is relevant for this question protocol ospf myOSPF { import all; export all; area 0 { interface “tunnelAB" { cost 5; type ptp; hello 5; retransmit 2; wait 10; dead 20; }; }; } I see messages in my /var/log/syslog saying “Received route … with strange next-hop …” as it picks up my table 220 routes. If I then run “birdc” and do a “show route” I get nothing output. Is this expected? Iain

1 0

Route Servers and Secondary Routes (bird 1.3.10 and debian kernel 3.2-amd64)
by Daniel Gomez 25 Nov '13

25 Nov '13

Hi Everyone, I have used both examples from Ondrej "Simple Route Server" and "Router server with community based filtering and single RIB", from the gitlabs.labs.nic.cz, to configure 2 Route Servers that need to tranfer to each other via iBGP all the routes they have learned. I thought that the most important parameters, when coupling both Router Servers, where the "table master sorted" and the "secondary" parameter for the iBGP configuration, but my routing table is just showing the Best Route and not all of them. I am pushing to one of the servers via iBGP and "bgpdump/bgpsimple" around 775775 prefixes (www.ripe.net/cata-tools/stats/ris/ris-raw-data) I do not know why but the route server is receiving the 775775 prefixes, filtering them and just showing the preferred ones. I have tried with "show route all filtered", but the command does not show anything. R65500x1 BGP master up 14:11 Established Description: 192.168.0.1 Preference: 100 Input filter: ACCEPT Output filter: ACCEPT Routes: 47423 imported, 0 exported, 47423 preferred <<<---- Route change stats: received rejected filtered ignored accepted Import updates: 775775 0 0 17521 758254 <<<---- Import withdraws: 6 0 --- 2 4 Export updates: 758255 758254 2 --- 0 Export withdraws: 4 --- --- --- 0 BGP state: Established Neighbor address: 192.168.0.1 Neighbor AS: 65500 Neighbor ID: 192.168.0.1 Neighbor caps: Session: internal Source address: 192.168.0.2 Hold timer: 1905/2400 Keepalive timer: 339/800 // CONFIGURATION log "/var/log/bird.log" all; log syslog all; router id 192.168.0.2; define myas = 65500; #### # Protocol template template bgp PEERS { local as myas; source address 192.168.0.2; secondary; import all; export all; route limit 10000; } table master sorted; #### # Configuration of BGP peer follows ### AS65500 - Member1 protocol bgp R65500x1 from PEERS { description "192.168.0.1"; gateway direct; neighbor 192.168.0.1 as 65500; } // LOGS Nov 25 17:06:12 bird: R65500x1 > added [best] 1.0.4.0/24 via 192.168.0.1 on eth2 Nov 25 17:06:12 bird: kernel1 < added 1.0.4.0/24 via 192.168.0.1 on eth2 Nov 25 17:06:12 bird: R65500x1 < rejected by protocol 1.0.4.0/24 via 192.168.0.1 on eth2 Nov 25 17:06:12 bird: R65500x1 > added [best] 1.0.4.0/24 via 192.168.0.1 on eth2 Nov 25 17:06:12 bird: kernel1 < replaced 1.0.4.0/24 via 192.168.0.1 on eth2 Nov 25 17:06:12 bird: R65500x1 < rejected by protocol 1.0.4.0/24 via 192.168.0.1 on eth2 Nov 25 17:06:12 bird: R65500x1 > added [best] 1.0.4.0/24 via 192.168.0.1 on eth2 Nov 25 17:06:12 bird: kernel1 < replaced 1.0.4.0/24 via 192.168.0.1 on eth2 Nov 25 17:06:12 bird: R65500x1 < rejected by protocol 1.0.4.0/24 via 192.168.0.1 on eth2 Nov 25 17:06:12 bird: R65500x1 > added [best] 1.0.4.0/24 via 192.168.0.1 on eth2 Any idea? Thanks in advance, Daniel Gomez

2 2

BIRD on FreeBSD 9.2 (amd64) - OSPF is not putting routes in the routing table
by Claude Marinier 21 Nov '13

21 Nov '13

Hi, I am running BIRD 1.3.11 on FreeBSD 9.2 (amd64). It establishes full adjacency with its three neighbours (Cisco routers) and its routing table is correct. BIRD knows about the routers behind its neighbours. The problem is that the kernel does not know any of the learned routes, i.e. 'netstat -rnf inet' shows only routes for the interfaces. I suspect that I am missing something basic but have not found it yet after many hours of searching. Could someone point me in the right direction? Thank you. The configuration file follows. -- C Marinier # Configure logging log syslog { debug, trace, info, remote, warning, error, auth, fatal, bug }; # Override router ID router id 131.140.113.14; protocol kernel { persist; # leave routes in kernel table on exit import all; # import routes into kernel routing table scan time 10; # look for new interfaces every 10 seconds } protocol device { scan time 10; # look for changes every 10 seconds } # make sure routes for directly connected sub-networks # are not disturbed (BSD's are susceptible to this) protocol direct { interface "bce0", "bce1", "em0"; } protocol ospf WANemu { area 0.0.0.0 { stub no; networks { x.x.113.8/29; x.x.113.184/29; x.x.113.104/29; }; interface "bce0" { authentication cryptographic; password "xxxxxx"; }; interface "bce1" { authentication cryptographic; password "xxxxxx"; }; interface "em0" { authentication cryptographic; password "xxxxxx"; }; }; }

3 3

I failed to compile the BFD branch
by 三ツ木　賢一 21 Nov '13

21 Nov '13

Hello all. I have compiled a BFD Branch. It is following hash. Commit 1ec522538fb81a56b068c087d0a842faf7aa7869 However, it was not possible and it is said that there is no "nest/bfd.h" Is there a solution? .

2 1