April 2013 - Bird-users - Mailing Lists

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

BGP syslog
by Jimmy Halim 05 Sep '13

05 Sep '13

Hi guys, Can I confirm with you guys that syslog is only logging the event for BGP Notification errors only? I mean, it does not log the BGP session up and down event? Thanks in advance! Cheers, Jimmy

7 26

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

unnecessary and frequency kernel routing update
by Slawa Olhovchenkov 02 May '13

02 May '13

bird router got from BGP peer update don't change routing table: 26-04-2013 15:49:55 <TRACE> le2 > added [best] 209.142.140.0/24 via 10.90.90.92 on vlan1 and send unneeded routing update to kernel (old route is same): 26-04-2013 15:49:55 <TRACE> kernel1 < replaced 209.142.140.0/24 via 10.90.90.92 on vlan1

2 5

BGP is not coming up: Error: Invalid next hop
by Timur Irmatov 01 May '13

01 May '13

Hi. We have a pretty simple BGP configuration with bird: protocol static static_isp { import all; route <net1>/22 via <gw>; route <net2>/23 via <gw>; } protocol bgp isp { disabled on; import none; export where proto = "static_isp"; local as <X>; neighbor <nei> as <Y>; } Initially, we configured network interface with wrong ip address, then after fixing this, bird gives us this error after reconfiguration (Error: Invalid next hop). What's the problem? We could tried restarting bird but this is production router (we have replaced Cisco router with this Linux box) and we woudn't want to do that unless this is really needed. -- Timur Irmatov

2 2

Watchdog/Supervise?
by Joe Wooller 28 Apr '13

28 Apr '13

Hey All, Just wondering what people are using to monitor the bird process(es)? Has anyone configured Supervise or the like? I have set up a test BIRD VM and have managed to make it Segfault once… :P Cheers Joe

9 15

BGP password behaviour
by Dan Rimal 28 Apr '13

28 Apr '13

Hello, today i have had very strange experience with bird. Few days ago (approx 6 days) i have established bgp session with bgp password attribute. Since established this session, i have got messages in system log like this: kernel: [2956936.985539] MD5 Hash failed for (195.81.xxx.yy, 179)->(195.81.xxx.yy, 46595) kernel: [2956936.985761] huh, entered softirq 3 NET_RX ffffffff814e7060 preempt_count 00000100, exited with 00000101? But peer was UP, routes was installed, everything seemed OK. I didn't notice this messages for few days althoug messages was added very often. After few days, it changes to: Apr 28 00:33:59 r1 kernel: [3432467.222576] BUG: scheduling while atomic: bird/6356/0x00000001 Apr 28 00:33:59 r1 kernel: [3432467.222656] Modules linked in: binfmt_misc ip_vs nf_conntrack libcrc32c 8021q garp stp llc dummy ipmi_devintf ipmi_si ipmi_msghandler mlx4_en mlx4_core joydev i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support ixgbe i7core_edac ioatdma mdio eda c_core igb dca raid1 [last unloaded: scsi_wait_scan] Apr 28 00:33:59 r1 kernel: [3432467.223323] Pid: 6356, comm: bird Not tainted 3.3.1-3.fc16.x86_64 #1 Apr 28 00:33:59 r1 kernel: [3432467.223423] Call Trace: Apr 28 00:33:59 r1 kernel: [3432467.223510] [<ffffffff815eaec3>] __schedule_bug+0x68/0x6c Apr 28 00:33:59 r1 kernel: [3432467.223582] [<ffffffff815f2b52>] __schedule+0x6f2/0x7b0 Apr 28 00:33:59 r1 kernel: [3432467.223658] [<ffffffff815f2f2f>] schedule+0x3f/0x60 Apr 28 00:33:59 r1 kernel: [3432467.223746] [<ffffffff815f20dc>] schedule_hrtimeout_range_clock+0x12c/0x170 Apr 28 00:33:59 r1 kernel: [3432467.223928] [<ffffffff8107da00>] ? update_rmtp+0x70/0x70 Apr 28 00:33:59 r1 kernel: [3432467.224052] [<ffffffff8107e724>] ? hrtimer_start_range_ns+0x14/0x20 Apr 28 00:33:59 r1 kernel: [3432467.224132] [<ffffffff815f2133>] schedule_hrtimeout_range+0x13/0x20 Apr 28 00:33:59 r1 kernel: [3432467.224251] [<ffffffff81193cc9>] poll_schedule_timeout+0x49/0x70 Apr 28 00:33:59 r1 kernel: [3432467.224367] [<ffffffff81194656>] do_select+0x586/0x6d0 Apr 28 00:33:59 r1 kernel: [3432467.224494] [<ffffffff8107f8bf>] ? up+0x2f/0x50 Apr 28 00:33:59 r1 kernel: [3432467.224583] [<ffffffff81193dd0>] ? poll_freewait+0xe0/0xe0 Apr 28 00:33:59 r1 kernel: [3432467.224663] [<ffffffff81193ec0>] ? __pollwait+0xf0/0xf0 Apr 28 00:33:59 r1 kernel: [3432467.224743] [<ffffffff81193ec0>] ? __pollwait+0xf0/0xf0 Apr 28 00:33:59 r1 kernel: [3432467.224813] [<ffffffff81193ec0>] ? __pollwait+0xf0/0xf0 Apr 28 00:33:59 r1 kernel: [3432467.224911] [<ffffffff81193ec0>] ? __pollwait+0xf0/0xf0 Apr 28 00:33:59 r1 kernel: [3432467.224991] [<ffffffff81193ec0>] ? __pollwait+0xf0/0xf0 Apr 28 00:33:59 r1 kernel: [3432467.225066] [<ffffffff81193ec0>] ? __pollwait+0xf0/0xf0 Apr 28 00:33:59 r1 kernel: [3432467.225136] [<ffffffff81193ec0>] ? __pollwait+0xf0/0xf0 Apr 28 00:33:59 r1 kernel: [3432467.225206] [<ffffffff81193ec0>] ? __pollwait+0xf0/0xf0 Apr 28 00:33:59 r1 kernel: [3432467.225311] [<ffffffff81193ec0>] ? __pollwait+0xf0/0xf0 Apr 28 00:33:59 r1 kernel: [3432467.225405] [<ffffffff8119498c>] core_sys_select+0x1ec/0x370 Apr 28 00:33:59 r1 kernel: [3432467.225491] [<ffffffff8101b6f9>] ? read_tsc+0x9/0x20 Apr 28 00:33:59 r1 kernel: [3432467.225567] [<ffffffff810a4edd>] ? ktime_get_ts+0xad/0xe0 Apr 28 00:33:59 r1 kernel: [3432467.225728] [<ffffffff81194bd0>] sys_select+0xc0/0x100 Apr 28 00:33:59 r1 kernel: [3432467.225866] [<ffffffff815fbfe9>] system_call_fastpath+0x16/0x1b "MD5 hash failed" and "huh, entered.." message was completely replaced by BUG message with high frequency. After another three hours bird received signal HUP (logrotate) and it was deadly for bird, see two last lines: Apr 28 03:32:01 r1 kernel: [3443133.541261] BUG: scheduling while atomic: bird/6356/0x00000001 Apr 28 03:32:01 r1 kernel: [3443133.541341] Modules linked in: binfmt_misc ip_vs nf_conntrack libcrc32c 8021q garp stp llc dummy ipmi_devintf ipmi_si ipmi_msghandler mlx4_en mlx4_core joydev i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support ixgbe i7core_edac ioatdma mdio eda c_core igb dca raid1 [last unloaded: scsi_wait_scan] Apr 28 03:32:01 r1 kernel: [3443133.541697] Pid: 6356, comm: bird Not tainted 3.3.1-3.fc16.x86_64 #1 Apr 28 03:32:01 r1 kernel: [3443133.541768] Call Trace: Apr 28 03:32:01 r1 kernel: [3443133.541838] [<ffffffff815eaec3>] __schedule_bug+0x68/0x6c Apr 28 03:32:01 r1 kernel: [3443133.541913] [<ffffffff815f2b52>] __schedule+0x6f2/0x7b0 Apr 28 03:32:01 r1 kernel: [3443133.542003] [<ffffffff815f2f2f>] schedule+0x3f/0x60 Apr 28 03:32:01 r1 kernel: [3443133.542081] [<ffffffff815f20dc>] schedule_hrtimeout_range_clock+0x12c/0x170 Apr 28 03:32:01 r1 kernel: [3443133.542224] [<ffffffff8107da00>] ? update_rmtp+0x70/0x70 Apr 28 03:32:01 r1 kernel: [3443133.542294] [<ffffffff8107e724>] ? hrtimer_start_range_ns+0x14/0x20 Apr 28 03:32:01 r1 kernel: [3443133.542367] [<ffffffff815f2133>] schedule_hrtimeout_range+0x13/0x20 Apr 28 03:32:01 r1 kernel: [3443133.542441] [<ffffffff81193cc9>] poll_schedule_timeout+0x49/0x70 Apr 28 03:32:01 r1 kernel: [3443133.542534] [<ffffffff81194656>] do_select+0x586/0x6d0 Apr 28 03:32:01 r1 kernel: [3443133.542608] [<ffffffff8151f330>] ? ip_forward_options+0x1f0/0x1f0 Apr 28 03:32:01 r1 kernel: [3443133.542681] [<ffffffff81193dd0>] ? poll_freewait+0xe0/0xe0 Apr 28 03:32:01 r1 kernel: [3443133.542754] [<ffffffff81193ec0>] ? __pollwait+0xf0/0xf0 Apr 28 03:32:01 r1 kernel: [3443133.542826] [<ffffffff81193ec0>] ? __pollwait+0xf0/0xf0 Apr 28 03:32:01 r1 kernel: [3443133.542897] [<ffffffff81193ec0>] ? __pollwait+0xf0/0xf0 Apr 28 03:32:01 r1 kernel: [3443133.542986] [<ffffffff81193ec0>] ? __pollwait+0xf0/0xf0 Apr 28 03:32:01 r1 kernel: [3443133.543064] [<ffffffff81193ec0>] ? __pollwait+0xf0/0xf0 Apr 28 03:32:01 r1 kernel: [3443133.543134] [<ffffffff81193ec0>] ? __pollwait+0xf0/0xf0 Apr 28 03:32:01 r1 kernel: [3443133.543201] [<ffffffff81193ec0>] ? __pollwait+0xf0/0xf0 Apr 28 03:32:01 r1 kernel: [3443133.543285] [<ffffffff81193ec0>] ? __pollwait+0xf0/0xf0 Apr 28 03:32:01 r1 kernel: [3443133.543354] [<ffffffff81193ec0>] ? __pollwait+0xf0/0xf0 Apr 28 03:32:01 r1 kernel: [3443133.543431] [<ffffffff8119498c>] core_sys_select+0x1ec/0x370 Apr 28 03:32:01 r1 kernel: [3443133.543503] [<ffffffff811be1a4>] ? fsnotify+0x1e4/0x290 Apr 28 03:32:01 r1 kernel: [3443133.543579] [<ffffffff8101b6f9>] ? read_tsc+0x9/0x20 Apr 28 03:32:01 r1 kernel: [3443133.543650] [<ffffffff810a4edd>] ? ktime_get_ts+0xad/0xe0 Apr 28 03:32:01 r1 kernel: [3443133.543728] [<ffffffff81194bd0>] sys_select+0xc0/0x100 Apr 28 03:32:01 r1 kernel: [3443133.543797] [<ffffffff815fbfe9>] system_call_fastpath+0x16/0x1b Apr 28 03:32:01 r1 kernel: [3443133.620802] bird[6356]: segfault at 7fb756e54000 ip 00007fb7566f0319 sp 00007fffaf69c350 error 6 Apr 28 03:32:01 r1 kernel: [3443133.620970] note: bird[6356] exited with preempt_count 1 I don't know exactly if this bug is kernel related or bird related, i don't know if BUG message is related to his precedesor "MD5 hash failed" message. I read a little bit about "BUG: scheduling while atomic".. always was related to kernel code, not userspace.. it is a bit confusing. After that, i have disabled md5 auth from affected BGP session and messages are completely gone. Environment: Fedora 16 / 3.3.1-3.fc16.x86_64, BIRD 1.3.9 with this patch: http://marc.info/?l=bird-users&m=136172837801057&w=2 Regards, Daniel

2 1

BGP Extended Communities
by Joe Wooller 24 Apr '13

24 Apr '13

Hey All, Just wondering if anyone in the IXP world would care to share how they do their Communities/Extended Communities and if most of the IXP actually conform to the same standard? BIRD examples appreciated too! Regards Joe

2 3

asynchronous interface updates on CentOS 6.4
by Rob Greenwood 17 Apr '13

17 Apr '13

Hi, I currently have the following bird configuration setup; # Configure logging log syslog { info, remote, auth, error, fatal, bug }; # Set the IPv4 router ID router id <%= router_id %>; # Configure the kernel protocol (for kernel routes) protocol kernel { persist no; # Do not persist routes when bird is stopped learn no; # Do not learn alient routes from the kernel export all; # Export all learnt routes to the kernel import none; # Do not import routes from the kernel } # Configure the direct protocol (for device routes) protocol direct { import all; # Import all directly connected routes into the table export none; # Do not export } # Configure the device protocol device { scan time 120; # Scan the list of interfaces every 120 seconds } When deleting an IP address from an interface (using ip addr del), the route is immediately withdrawn (presumably via asynchronous calls to bird). However, when adding an IP address back to the interface, the route doesn't appear in bird until the scan time kicks in. Should this not be asynchronous also? Thanks, Rob

1 0

a simple scenario using bird
by Nomad Esst 17 Apr '13

17 Apr '13

Hi Sorry for multiple questions. Are there any simple scenarios or tutorials about bird configurations and how mpls can be set? Please help Thanks

1 0