February 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

Bird RIP does not send some packages
by Aleksey Chudov 13 May '13

13 May '13

Hello, I ran into a situation that Bird RIP does not send some packages. Bird configuration file /etc/bird.conf log syslog all; debug protocols all; protocol device { scan time 5; } protocol direct { interface "*"; } protocol kernel { persist; scan time 5; export filter { if source = RTS_RIP then { if rip_metric > 15 then reject; if net ~ 10.0.0.0/8 then accept; if net ~ 192.168.0.0/16 then accept; } reject; }; } protocol rip { period 5; timeout time 20; garbage time 30; interface "gre*" { mode multicast; }; export filter { if net ~ 10.64.0.0/20 then accept; reject; }; } Log messages from Bird daemon Feb 19 18:25:00 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:03 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:06 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:12 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:13 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:15 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:20 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:26 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:28 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:33 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:36 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:38 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:44 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:48 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:50 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:56 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:58 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:00 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:03 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:05 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:06 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:07 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:13 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:16 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:19 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:21 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:25 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:31 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:33 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:39 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:42 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:45 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:46 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:49 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:51 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:52 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:57 srvc1 bird: rip1: Broadcasting routing table to gre1 And tcpdump for the same period 18:25:00.479028 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24 18:25:03.482132 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184 18:25:15.639027 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24 18:25:26.478329 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184 18:25:48.476297 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184 18:26:05.639030 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184 18:26:13.473560 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24 18:26:16.639029 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24 18:26:21.473055 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184 18:26:31.473049 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24 18:26:33.472083 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 44 18:26:39.638030 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24 18:26:45.471432 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184 18:26:57.637236 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24 Are there any ideas why this is happening? Best regards, Aleksey

3 14

bird 1.3.9 - show bgp summary command
by Javor Kliachev 24 Mar '13

24 Mar '13

2 1

Latency based path selection
by Ryan Whelan 01 Mar '13

01 Mar '13

Is it possible to make route selection based on path latency? (or even delegate path selection to an external app/program/api?) I'm currently using ospf (but can really use any igp) to manage routing in a system with many end nodes all connected together via a handful of servers (via vpn links) which are spread across the country. The problem is, the 'end nodes' are always moving/relocating and currently have to be manually updated to use which ever server(s) are closest / quickest. It would be nice if there was a method or protocol that could make path selection based on lowest avg latency. The applications that transverse the network aren't bandwidth intensive, but are very latency sensitive so detecting and using the lowest latency path would ideal. Any input / suggestions would be greatly appreciated!

5 5

OSPF: network mask for PtP links
by Alexander V. Chernikov 28 Feb '13

28 Feb '13

Hello list! Currently bird uses '0.0.0.0' network mask in OSPF hello messages for ptp links. This is (at least originally) done to catch possible misconfiguration at the other end. RFC 2328 sec 10.5 tells us that this is perfectly OK and network mask should be ignored for p2p and virtual links. However, Juniper interprets RFC more formally and their point is that Ethernet is not real point-to-point interface, so network mask is checked anyway. See http://kb.juniper.net/InfoCenter/index?page=content&id=KB23533 for more detailed explanation. This check kills bird ability to establish p2p link with Juniper boxes. Cisco and Huawei (at least some models) ignores netmask as they should, but sends real network mask in hello messages. Maybe it will be useful to make bird behavior configurable: patch adding 'real mask <switch>' interface option is attached.

1 0

bird: show route behaviour
by Dan Rimal 25 Feb '13

25 Feb '13

Hello all, I make some testbed and testing some scenarios and i found weird "show route" behaviour. I have 2 bgp peers without filter. First router, called testr1, has 3 tables: master, t_nix and t_tranzit. Second router called "nix1_nix" has quite default settings. Conf file from testr1 is attached. To every single table on testr1 is imported 1 different static route via protocol static. Tables t_nix and t_tranzit are "piped" to master table, opposite direction is filtered. BGP peer nix1_nix is defined with "table t_nix". This is "show protocols" on tesr1: device1 Device master up 00:29 kernel1 Kernel master up 00:29 k_nix Kernel t_nix up 00:29 k_tranzit Kernel t_tranzit up 00:29 p_nix Pipe t_nix up 00:29 => master p_tranzit Pipe t_tranzit up 00:29 => master s_master Static master up 00:29 s_nix Static t_nix up 00:29 s_tranzit Static t_tranzit up 00:29 nix1_nix BGP t_nix up 00:29 Established There is route tables print. Table t_nix has imported default route from nix1_nix and table master has the same default route imported through pipe from t_nix (this is correct, just explanation): bird> show route table master 0.0.0.0/0 via 192.168.1.3 on eth1 [nix1_nix 00:29] ! (100) [AS65000i] 4.4.4.0/24 via 172.17.1.1 on eth0 [s_master 00:29] * (200) 5.5.5.0/24 via 172.17.1.1 on eth0 [s_nix 00:29] * (200) 6.6.6.0/24 via 172.17.1.1 on eth0 [s_tranzit 00:29] * (200) bird> show route table t_nix 0.0.0.0/0 via 192.168.1.3 on eth1 [nix1_nix 00:29] * (100) [AS65000i] 5.5.5.0/24 via 172.17.1.1 on eth0 [s_nix 00:29] * (200) bird> show route table t_tranzit 6.6.6.0/24 via 172.17.1.1 on eth0 [s_tranzit 00:29] * (200) Weird show behaviour comes now: bird> show route export nix1_nix 4.4.4.0/24 via 172.17.1.1 on eth0 [s_master 00:29] * (200) 5.5.5.0/24 via 172.17.1.1 on eth0 [s_nix 00:29] * (200) 6.6.6.0/24 via 172.17.1.1 on eth0 [s_tranzit 00:29] * (200) It show all routes from all tables, although table t_nix is defined on this peer. But, nix1_nix receive only one route, correct route from t_nix table: bird> show protocols name proto table state since info device1 Device master up 00:28 kernel1 Kernel master up 00:28 r1 BGP master up 00:29 Established bird> show route protocol r1 5.5.5.0/24 via 192.168.1.1 on eth1 [r1 00:29] * (100) [AS64000i] I tryid simplify scenario and delete pipes to master table temporarily and situation looks this way: testr1: bird> show protocols name proto table state since info device1 Device master up 00:31 kernel1 Kernel master up 00:31 k_nix Kernel t_nix up 00:31 k_tranzit Kernel t_tranzit up 00:31 s_master Static master up 00:31 s_nix Static t_nix up 00:31 s_tranzit Static t_tranzit up 00:31 nix1_nix BGP t_nix up 00:31 Established bird> bird> show route table master 4.4.4.0/24 via 172.17.1.1 on eth0 [s_master 00:31] * (200) bird> show route table t_nix 0.0.0.0/0 via 192.168.1.3 on eth1 [nix1_nix 00:31] * (100) [AS65000i] 5.5.5.0/24 via 172.17.1.1 on eth0 [s_nix 00:31] * (200) bird> show route table t_tranzit 6.6.6.0/24 via 172.17.1.1 on eth0 [s_tranzit 00:31] * (200) and now, command show route from master table only bird> show route export nix1_nix 4.4.4.0/24 via 172.17.1.1 on eth0 [s_master 00:31] * (200) although peer receive correct route: bird> show route protocol r1 5.5.5.0/24 via 192.168.1.1 on eth1 [r1 00:31] * (100) [AS64000i] It looks like "show" command bug only, which is good, but it is pretty confusing :) Both peers is: Linux testr1 3.4.4-5.fc17.x86_64 #1 SMP Thu Jul 5 20:20:59 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux running latest: bird> show status BIRD 1.3.9 Regards, Dan

3 11

How the prefix sets are implemented?
by 3.listas＠adminlinux.com.br 25 Feb '13

25 Feb '13

Hi, To filter the routes that my router gets in my BGP session, I implemented a filter like this: filter ebgp_in prefix set IMPORT_BLACKLIST; { IMPORT_BLACKLIST = [ 0.0.0.0/8+, 10.0.0.0/8+, 14.0.0.0/8+, 24.0.0.0/8+, 39.0.0.0/8+, 127.0.0.0/8+, 128.0.0.0/16+, 169.254.0.0/16+, 172.16.0.0/12+, 191.255.0.0/16+, 192.0.0.0/24+, 192.0.2.0/24+, 192.88.99.0/24+, # Disabled only in the testing environment #192.168.0.0/16+, 198.18.0.0/15+, 223.255.255.0/24+, 224.0.0.0/4+, 240.0.0.0/4+ ]; if net ~ IMPORT_BLACKLIST then { printn "Discarding received route to "; print net; reject; } accept; } filter ebgp_out { if source = RTS_STATIC then { bgp_med = BGP_MED; accept; } reject; } protocol bgp eBGP { description "eBGP"; local as 65000; source address 192.168.101.1; neighbor 192.168.100.1 as 65111; multihop 2; default bgp_local_pref 200; export filter ebgp_out; import filter ebgp_in; } As you can see, I use the variable "prefix set IMPORT_BLACKLIST" to store a blacklist. My doubt is about the implementation of the type "set". Which data structure is used in the implementation of the "set" type (linked list, tree, hash ...)? Thanks -- Thiago Henrique www.adminlinux.com.br

3 3

print BGP AGGREGATOR attribute?
by Job Snijders 25 Feb '13

25 Feb '13

Dear all, I want to inject information into syslog when certain magic prefixes are announced or withdrawn. So far I have this snippet of configuration, but I'd also like to print the BGP AGGREGATOR ip address, and the AGGREGATOR AS number. How can I do this? filter collector_in { if (net ~ [ 84.205.64.0/24, 84.205.65.0/24 ]) then { print "MAGIC PREFIX SIGNALLED: " , net, "' from AS", bgp_path.last, " via AS", bgp_path.first, " [", proto, "]"; accept; } else accept; } How can I get BIRD to print something when a prefix is withdrawn? Kind regards, Job

2 2

ASK about BPG multiple routing table
by Ika Kushati 25 Feb '13

25 Feb '13

Hello,, I have a project using BIRD on Debian. It's my first time using BIRD and actually I don't really understand how to use it. The project is: There are 3 routers using Debian. R1----R2---R3 I must configure prefix from R1 will be updated on T100 table on R2 and prefix from R3 to T200 table. I have finished to make all routers connecting each other. But then i dont know what next step is. Should I configure iproute first or BIRD first? And how to configure it? I hope you can help me. Thank you.Sorry for bad english.

3 9

Maximum variable length
by Stanislav Datskevich 23 Feb '13

23 Feb '13

Hi! Have BIRD a restriction in prefix set variable length? I.E. my peer announce me upto 5000 prefixes - can I put all prefixes in one prefix set variable?

2 1