September 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

filters: strange protocol restarts
by Sergey Popovich 03 Oct '13

03 Oct '13

Hello community!! And again I need to spread some light on BIRD behavior: why bird restarts protocol instead of just reloading it when no filter changes in configuration when using prefix set constant? There is simple configuration and steps to reproduce this ------------------------------------------------------------------------- # Configure logging log syslog all; log stderr all; router id 172.16.1.1; protocol device devices { scan time 15; } ### KRT 10 table rt_10; # This function does not forces "kernel" protocol to reload. function f1(prefix pfx) { if pfx ~ [ 192.168.0.0/16+ ] then return false; return true; } protocol kernel kernel10 { table rt_10; persist no; scan time 15; learn yes; device routes yes; kernel table 10; import where f1(net); export none; } ### KRT 20 table rt_20; # And this does, "kernel" protocol restarts without changing PS_1. define PS_1 = [ 192.168.0.0/16+ ]; function f2(prefix pfx) { if pfx ~ PS_1 then return false; return true; } There is nothing difficult in config: 2 functions f1() and f2() that do same thing except f2() matches specified as parameter prefix to a defined constant of type prefix set (PS_1). Starting bird, and invoking three times on console command to reconfigure bird (birdc configure) without altering configuration file I get following in my syslog: -------------------------------------------------------------------------------- Aug 21 18:50:54 gw1 bird: Started Aug 21 18:50:59 gw1 bird: Reconfiguring Aug 21 18:50:59 gw1 bird: Reloading protocol kernel20 Aug 21 18:50:59 gw1 bird: Restarting protocol kernel20 Aug 21 18:50:59 gw1 bird: Reconfigured Aug 21 18:51:08 gw1 bird: Reconfiguring Aug 21 18:51:08 gw1 bird: Reloading protocol kernel20 Aug 21 18:51:08 gw1 bird: Restarting protocol kernel20 Aug 21 18:51:08 gw1 bird: Reconfigured Aug 21 18:51:08 gw1 bird: Reconfiguring Aug 21 18:51:08 gw1 bird: Reloading protocol kernel20 Aug 21 18:51:08 gw1 bird: Restarting protocol kernel20 Aug 21 18:51:08 gw1 bird: Reconfigured Same thing can be reproduced with other protocols. This is not wery good to restart protocol when no REAL things changed in its filter, as it purges all routes from kernel table, and reinstalls them again causing flap when huge number of routes needed to be reinstalled. Can some one explain to me this behavior of BIRD? Does this mean that usage of constats with type prefix set is not recommended? Thanks for your support. -- SP5474-RIPE Sergey Popovich

3 27

OSPF dont import routes from LSAdb
by 1 Игорь 30 Sep '13

30 Sep '13

Hi everyone. I have a problem with OSPF. In my topology Core router (Area0) connected to 2 routers (Area1), which intrconnected with their own link. Core redistributes 0/0 and things works normal. Core router ID is 10.0.0.0, R1 - 10.0.1.1, R2 - 10.0.1.2. But, when I drop one of links between Core router and Area1 router, I expect that 0/0 route pass through second Area 1 router and all reveal on first, on wich i drop link to core. In LSA DB I see LSA Type 5, wich generates from core router: bird> show ospf lsadb Global Type LS ID Router Age Sequence Checksum 0005 0.0.0.0 10.0.0.0 616 80000002 72f0 Area 0.0.0.0 Type LS ID Router Age Sequence Checksum 0001 10.0.1.2 10.0.1.2 0 80000002 594e 0003 10.16.0.0 10.0.1.2 29 80000001 e258 Area 0.0.0.1 Type LS ID Router Age Sequence Checksum 0003 10.0.0.0 10.0.1.1 943 80000001 6d75 0004 10.0.0.0 10.0.1.1 943 80000001 5f82 0001 10.0.1.1 10.0.1.1 23 8000000a 2103 0003 10.0.1.1 10.0.1.1 962 80000001 6cd8 0003 10.2.1.3 10.0.1.1 962 80000001 1ac5 0002 10.31.12.1 10.0.1.1 23 80000001 847a 0002 10.31.21.1 10.0.1.1 23 80000001 21d4 0001 10.0.1.2 10.0.1.2 13 80000009 3be5 0003 10.0.1.2 10.0.1.2 29 80000001 5ce6 0003 10.2.1.4 10.0.1.2 29 80000001 0ad3 But in master table I have no this route: bird> show route 10.0.1.2/32 dev lo [C1 11:46] * I (150/0) [10.0.1.2] 10.2.1.4/30 dev bond0.4002 [C1 11:46] * I (150/100) [10.0.1.2] 10.31.21.0/24 dev bond0.4021 [C1 11:47] * I (150/10) [10.0.1.1] 10.31.12.0/24 dev bond0.4012 [C1 11:47] * I (150/10) [10.0.1.1] (bond0.4012 and bond0.4021 - links which interconnect R1 and R2, bond0.4002 - link to Core, which disabled there) Config of R1 and R2 is same (exept Router ID): # Configure logging #log syslog { debug, trace, info, remote, warning, error, auth, fatal, bug }; log stderr all; log "/var/log/bird.log" { info,remote,warning,error,auth,fatal,bug}; #log "/var/log/debug_bird.log" all; filter OSPF_in { if ( net=0.0.0.0/0 || net ~ 10.0.0.0/8 ) then accept; else reject; }; filter OSPF_out { if (net ~ 10.16.0.0/12 ) then accept; else reject; }; # This pseudo-protocol performs synchronization between BIRD's routing # tables and the kernel. If your kernel supports multiple routing tables # (as Linux 2.2.x does), you can run multiple instances of the kernel # protocol and synchronize different kernel tables with different BIRD tables. protocol kernel { # learn; # Learn all alien routes from the kernel debug {states,routes,filters,interfaces}; persist; # Don't remove routes on bird shutdown scan time 20; # Scan kernel routing table every 20 seconds import all; # Default is import all export all; # Default is export none # kernel table 5; # Kernel table to synchronize with (default: main) } # This pseudo-protocol watches all interface up/down events. protocol device { scan time 10; # Scan interfaces every 10 seconds } protocol ospf C1{ # rfc1583compat yes; router id 10.0.1.2; ecmp; import keep filtered yes; # import filter OSPF_in; import all; # export filter OSPF_out; # export none; # debug {states,routes,filters,interfaces}; debug all; area 0{ stub no; interface "bond0.4002"{ type bcast; cost 100; hello 1; dead count 3; retransmit 6; transmit delay 5; wait 30; authentication cryptographic; password "xxx"; }; interface 10.0.1.2/32 { stub 1; }; }; area 1{ stub no; interface "bond0.4012", "bond0.4021" { rx buffer large; type bcast; cost 10; hello 1; dead count 3; retransmit 6; transmit delay 5; wait 30; authentication cryptographic; password "aaa"; }; interface 10.16.0.0/12 { stub 1; cost 10; }; }; } Config of Core router: # Configure logging #log syslog { debug, trace, info, remote, warning, error, auth, fatal, bug }; #log stderr all; #log "tmp" all; filter OSPF_in { if (net ~ 10.0.0.0/8 ) then accept; else reject; }; # Redistribute 0/0 only from BRAS!!! filter OSPF_redistribute { if ( net = 0.0.0.0/0) then { #ospf_metric1=200; ospf_metric2=100; accept; } else reject; }; # This pseudo-protocol performs synchronization between BIRD's routing # tables and the kernel. If your kernel supports multiple routing tables # (as Linux 2.2.x does), you can run multiple instances of the kernel # protocol and synchronize different kernel tables with different BIRD tables. protocol kernel { learn; # Learn all alien routes from the kernel persist; # Don't remove routes on bird shutdown scan time 10; # Scan kernel routing table every 20 seconds import all; # Default is import all export all; # Default is export none # kernel table 5; # Kernel table to synchronize with (default: main) } # This pseudo-protocol watches all interface up/down events. protocol device { scan time 10; # Scan interfaces every 10 seconds } # Static routes (again, there can be multiple instances, so that you # can disable/enable various groups of static routes on the fly). protocol static { # disabled; # Disable by default route 123.123.123.0/24 via "eth0"; } protocol ospf CORE{ tick 2; ecmp; # rfc1583compat yes; router id 10.0.0.0; import filter OSPF_in; export filter OSPF_redistribute; # export none; area 0 { stub no; interface "eth0.4001", "eth0.4002" { # "To corp1"; hello 1; retransmit 6; cost 10; transmit delay 5; dead count 3; wait 50; type broadcast; authentication cryptographic; password "corp1_pass"; }; interface "lo" { stub yes; }; }; }

1 1

"gw" attribute assignment in filter invalidates routes learned via BGP, static, and possibly others?
by Sergey Popovich 27 Sep '13

27 Sep '13

Hello! Another issue I spot last time: assigning value in protocol export filter invalidates route and prevents its from being installed in KRT. Simple config to test this issue: ---------------------------------------- ### SYSTEM # ip link add dev lo255 type dummy # ip link set up dev lo255 # ip -4 addr add 192.0.2.254/24 dev lo255 # ip -4 addr add 172.16.2.254/24 dev lo255 # ip link set up dev eth0 # ip -4 addr add 192.168.1.2/24 dev eth0 ### BIRD router id 10.10.10.10; protocol device devices { scan time 120; } # Main routing table (master), mapped to ipt_main kernel table. # ipt_main == 254 (see /etc/iproute2/rt_tables) protocol kernel kernel254 { persist no; scan time 120; learn no; device routes no; kernel table ipt_main; import none; export all; } protocol direct direct254 { interface "lo255", "eth0"; } protocol static static254_test { # If "via" is one from "lo255" subnets (172.16.2.5 for example: # everything is correct and route installed by "kernel254" route 10.0.0.0/24 via 192.168.1.1; import filter { # This causes route invalidation, "gw" points to 192.0.2.5, # but interface is still "eth0" (see birdc output below). gw = 192.0.2.5; accept; }; export none; }; protocol static static254 { # rs1, rs2 route 192.168.254.1/32 via 192.168.1.1; route 192.168.254.2/32 via 192.168.1.1; } # AS65001, peering with Route Server(s), RS template bgp tl_bgp254_as65001 { start delay time 10; connect retry time 60; startup hold time 30; keepalive time 10; hold time 30; capabilities yes; advertise ipv4 yes; enable route refresh yes; enable as4 yes; gateway recursive; multihop 4; local 192.168.1.2 as 65010; import filter { # This causes route invalidation, "gw" points to 192.0.2.5, but # interface is still "eth0" (see birdc output below). gw = 192.0.2.5; accept; }; export none; } protocol bgp bgp254_as65001_rs1 from tl_bgp254_as65001 { neighbor 192.168.254.1 as 65001; } protocol bgp bgp254_as65001_rs2 from tl_bgp254_as65001 { neighbor 192.168.254.2 as 65001; } Here is output from birdc and ip-route(8): ---------------------------------------------------- ### common ## 192.0.2.0/24, lo255 $ birdc 'show route for 192.0.2.5 all' BIRD 1.3.11 ready. 192.0.2.0/24 dev lo255 [direct254 12:45] * (240) Type: device unicast univ $ ip -4 route show match 192.0.2.5/32 192.0.2.0/24 dev lo255 proto kernel scope link src 192.0.2.254 ## 172.16.2.0/24, lo255 $ birdc 'show route for 172.16.2.5 all' BIRD 1.3.11 ready. 172.16.2.0/24 dev lo255 [direct254 13:00] * (240) Type: device unicast univ $ ip -4 route show match 172.16.2.5/32 172.16.2.0/24 dev lo255 proto kernel scope link src 172.16.2.254 ## 192.168.1.0/24, eth0 $ birdc 'show route for 192.168.1.0/24 all' BIRD 1.3.11 ready. 192.168.1.0/24 dev eth0 [direct254 12:45] * (240) Type: device unicast univ $ ip -4 route show match 192.168.1.2/32 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.254 ### static ## 10.0.0.0/24 $ birdc 'show route for 10.0.0.0/24 all' BIRD 1.3.11 ready. 10.0.0.0/24 via 192.0.2.5 on eth0 [static254_test 13:19] ! (200) Type: static unicast univ $ ip -4 route show exact 10.0.0.0/24 ### BGP $ birdc 'show route for 10.0.0.0/8 all' BIRD 1.3.11 ready. 10.0.0.0/8 via 192.0.2.5 on eth0 [bgp254_as65001_rs1 13:00 from 192.168.254.1] ! (100/0) [AS1011i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 65001 1011 BGP.next_hop: 192.168.1.1 BGP.local_pref: 100 BGP.community: (1001,65010) (1001,1001) via 192.0.2.5 on eth0 [bgp254_as65001_rs2 13:00 from 192.168.254.2] (100/0) [AS1011i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 65001 1011 BGP.next_hop: 192.168.1.1 BGP.local_pref: 100 BGP.community: (1001,65010) (1001,1001) $ ip -4 route show exact 10.0.0.0/8 --------------------------------------------------------------------------------------- This is probably due to not updating iface, nexthops (multihop config) and other fields of "rta" struct. Provided patch in attachment tries to address this issue by calling rta_set_recursive_next_hop() in filter/filter.c to properly assign to "gw" attribute. Special cases for bgp and static protocols was taken to use "igp table" configuration parameter if present (tested, and found working with static protocol, probably some with bgp). Patch tested in my configuration and works wery well for both static and bgp protocols. --------------------------------------------------------------------------------------- Brief explanation why "gw" attribute might be wery important (at least in my case). There is common technique to stop DDoS in large ISP network: blackholing. However implementations of this might wary from vendor to vendor. In BIRD simplest way to implement this is to set "dest" attribute to something like RTD_BLACKHOLE, and all other route attributes gets deleted (gw, iface, ...). Route installed in KRT as blackhole. Everything is ok with this setup, but sometimes searching blackhole route might give some surprises: you trace path to blackholed destination and gets nothing(???) from your gateway, as it drops packets destined to blackhole route without any notification (in case of trace path without sending ICMP Time To Live Exceeded). And what if you trace from some core router? And heres another blackholing technique comes: use looped back interface to drop packets. In this case we setup some system looped back interface (in Linux this is dummy interface type), configure some network on it (say something 192.0.2.0/24), And instead of setting blackholed route type to RTD_BLACKHOLE we change its "gw" to any address within subnet assigned on looped back interface. Thats servers same as route with blackhole type, but behaves differently on trace paths: router sends ICMP Time To Live Exceeded messages from its incoming interface address indicating last hop before dropping blackholed traffic. This has no impact on DDoS traffic, except it transmitted to looped back interface instead of being dropped immediately after matching route and wasting few CPU cycles. -- SP5474-RIPE Sergey Popovich

2 5

filters: Implement "ifname" and "ifindex" route attributes
by Sergey Popovich 27 Sep '13

27 Sep '13

Hello, BIRD developers! Currently there is no way in filter rules to match routes by interface name and interface index. However string comparison (=,!=,>,<,... operations), and pattern matching (using ~ operator) already implemented in filters, so expressions like: if "eth0" ~ "eth*" || "eth1" = "eth1" then print "This pattern matches!"; already works. Only one thing that is really needed is exposing attribute with name to filter which references route outgoing interface name and index. Of course all of these variables must be readonly. Interface indexes are taken from kernel (at least on Linux, and FreeBSD) and represents interface number in system. Matching to indexes is not such reliable as matching with interface names, as indexes might change on interface addition/removal. Currently only sink (blackhole, unreachable and prohibit) routes in BIRD have no interface associated. Return an empty string and index equal to zero (no real index in kernel) for such routes. -- SP5474-RIPE Sergey Popovich

2 2

kernel: BIRD kernel syncer protocol issues on Linux
by Sergey Popovich 26 Sep '13

26 Sep '13

Helo, BIRD developers! I have found few issues with kernel syncer on Linux with enabled route learning. There are few problems in sysdep/linux/rtnetlink.c with netlink code: * Use after free when accessing nl_table_map[] in nl_parse_route(). * Possible race condition between rx buffer allocation nl_async_rx_buffer in for async socket and nl_open_async() and it's usage in nl_async_hook(). * Socket descriptor leakage in error path in nl_open_async() when bind(2) call fails. These problems addressed with patch bird-1.3.11-fix-shutdow~ath-in-rtnetlink.patch Additionaly, patch bird-1.3.11-fix-building-with-DBG-on.patch fixes building when -DGLOBAL_DEBUG or -DLOCAL_DEBUG enabled (enables building lots of debugging code available with DBG() macro). Information to reproduce problem with use after free in nl_parse_route(). ========================================== BIRD configuration ------------------------ # Configure logging log stderr all; # More chances to trigger crash. log syslog all; router id 172.16.1.1; protocol device devices { scan time 120; } protocol kernel kernel10 { debug all; persist no; scan time 120; learn yes; device routes no; kernel table 10; import all; export none; } Start BIRD, compiled with "-DGLOBAL_DEBUG" in debugging mode ------------------------------------------------------------------------------------ # bird -d olock: init Parsing configuration file `/etc/bird.conf' Protocol preconfig: Direct Static Pipe BGP Kernel Device Protocol postconfig: devices kernel10 sysdep_commit global_commit rt_commit rt_commit: master: created Allocating FIB hash of order 10: 1024 entries, 0 low, 4096 high done protos_commit protos_commit: 26-09-2013 10:57:45 <TRACE> kernel10: Initializing done Protocol start ... Kicking kernel10 up 26-09-2013 10:57:45 <TRACE> kernel10: Starting Allocating FIB hash of order 10: 1024 entries, 0 low, 4096 high kernel10 reporting state transition HUNGRY/DOWN -> */UP kernel10: Scheduling meal Connecting protocol kernel10 to table master 26-09-2013 10:57:45 <TRACE> kernel10: Connected to table master 26-09-2013 10:57:45 <TRACE> kernel10: State changed to feed do_commit finished with 0 obstacles remaining 26-09-2013 10:57:45 <INFO> Started Entering I/O loop. Feeding protocol devices Feeding protocol devices continued Announcing routes to new protocol devices Protocol devices up and running Feeding protocol kernel10 Feeding protocol kernel10 continued Announcing routes to new protocol kernel10 26-09-2013 10:57:45 <TRACE> kernel10: State changed to up Protocol kernel10 up and running KRT: Scanning routing table 26-09-2013 10:57:45 <TRACE> kernel10: Scanning routing table KRT: Got 192.168.10.0/24, type=6, oif=-1, table=10, prid=3, proto=kernel10 26-09-2013 10:57:45 <TRACE> kernel10: 192.168.10.0/24: [alien] created KRT: Got 192.168.20.0/24, type=6, oif=-1, table=20, prid=3, proto=(none) ... KRT: Pruning table master 26-09-2013 10:57:45 <TRACE> kernel10: Pruning table master KRT: Pruning inherited routes 26-09-2013 10:57:45 <TRACE> kernel10: Pruning inherited routes 192.168.10.0/24: announcing (metric=0) 26-09-2013 10:57:45 <TRACE> kernel10 > added [best] 192.168.10.0/24 blackhole 26-09-2013 10:57:45 <TRACE> kernel10 < rejected by protocol 192.168.10.0/24 blackhole After startup BIRD learns route from KRT 10 -------------------------------------------------------- # birdc 'show route table master all' BIRD 1.3.11 ready. 192.168.10.0/24 blackhole [kernel10 10:57] * (10) Type: inherit unicast univ Kernel.source: 3 Kernel.metric: 0 Change KRT ID to 10 ("kernel table 10" configuration option) and tell bird about configuration changes ---------------------------------------------------- # birdc configure BIRD 1.3.11 ready. Reading configuration from /etc/bird.conf Reconfiguration in progress Debug output after reconfiguration --------------------------------------------- Parsing configuration file `/etc/bird.conf' Protocol preconfig: Direct Static Pipe BGP Kernel Device Protocol postconfig: devices kernel10 26-09-2013 10:57:54 <INFO> Reconfiguring sysdep_commit global_commit rt_commit rt_commit: master: same done protos_commit protos_commit: devices: same 26-09-2013 10:57:54 <INFO> Restarting protocol kernel10 +++ adding obstacle 1 Kicking kernel10 down 26-09-2013 10:57:54 <TRACE> kernel10: Shutting down KRT: Flushing kernel routes 26-09-2013 10:57:54 <TRACE> kernel10: Flushing kernel routes kernel10 reporting state transition HAPPY/UP -> */DOWN kernel10: Scheduling flush 26-09-2013 10:57:54 <TRACE> kernel10: State changed to flush Pruning neighbors done Protocol start do_commit finished with 1 obstacles remaining Pruning route table master 26-09-2013 10:57:54 <TRACE> kernel10 > removed [sole] 192.168.10.0/24 blackhole Pruning route table master Flushing protocol kernel10 26-09-2013 10:57:54 <TRACE> kernel10: State changed to down Protocol kernel10 down kernel10 has shut down for reconfiguration +++ deleting obstacle 1 26-09-2013 10:57:54 <TRACE> kernel10: Initializing Kicking kernel10 up 26-09-2013 10:57:54 <TRACE> kernel10: Starting Allocating FIB hash of order 10: 1024 entries, 0 low, 4096 high kernel10 reporting state transition HUNGRY/DOWN -> */UP kernel10: Scheduling meal Connecting protocol kernel10 to table master ... KRT: Scanning routing table 26-09-2013 10:57:54 <TRACE> kernel10: Scanning routing table KRT: Got 192.168.10.0/24, type=6, oif=-1, table=10, prid=3, proto=kernel10 26-09-2013 10:57:54 <TRACE> kernel10: 192.168.10.0/24: [alien] created KRT: Got 192.168.20.0/24, type=6, oif=-1, table=20, prid=3, proto=kernel10 26-09-2013 10:57:54 <TRACE> kernel10: 192.168.20.0/24: [alien] created ************************************************************************** And route from KRT ID 10 is seen and accepted in nl_parse_route() at sysdep/linux/rtnetlink.c. ************************************************************************** ... KRT: Pruning table master 26-09-2013 10:57:54 <TRACE> kernel10: Pruning table master KRT: Pruning inherited routes 26-09-2013 10:57:54 <TRACE> kernel10: Pruning inherited routes 192.168.10.0/24: announcing (metric=0) 26-09-2013 10:57:54 <TRACE> kernel10 > added [best] 192.168.10.0/24 blackhole 26-09-2013 10:57:54 <TRACE> kernel10 < rejected by protocol 192.168.10.0/24 blackhole 192.168.20.0/24: announcing (metric=0) 26-09-2013 10:57:54 <TRACE> kernel10 > added [best] 192.168.20.0/24 blackhole 26-09-2013 10:57:54 <TRACE> kernel10 < rejected by protocol 192.168.20.0/24 blackhole 26-09-2013 10:57:54 <INFO> Reconfigured Feeding protocol kernel10 Feeding protocol kernel10 continued Announcing routes to new protocol kernel10 26-09-2013 10:57:54 <TRACE> kernel10 < rejected by protocol 192.168.10.0/24 blackhole 26-09-2013 10:57:54 <TRACE> kernel10 < rejected by protocol 192.168.20.0/24 blackhole 26-09-2013 10:57:54 <TRACE> kernel10: State changed to up Protocol kernel10 up and running After reconfiguration finishes, we see route from KRT ID 10 in BRT "master" table, to which syncer is attached. ------------------------------------------------------------------------------------------------ # birdc 'show route table master all' BIRD 1.3.11 ready. 192.168.10.0/24 blackhole [kernel10 10:57] * (10) Type: inherit unicast univ Kernel.source: 3 Kernel.metric: 0 192.168.20.0/24 blackhole [kernel10 10:57] * (10) Type: inherit unicast univ Kernel.source: 3 Kernel.metric: 0 And adding routes to KRT ID 10 when BIRD uses KRT ID 20 causes them to be stored in "master" table: --------------------------------------------------------------------------------------------------- # ip -4 route add blackhole 192.168.30.0/24 table 10 # birdc 'show route table master all' BIRD 1.3.11 ready. 192.168.10.0/24 blackhole [kernel10 10:57] * (10) Type: inherit unicast univ Kernel.source: 3 Kernel.metric: 0 192.168.20.0/24 blackhole [kernel10 10:57] * (10) Type: inherit unicast univ Kernel.source: 3 Kernel.metric: 0 192.168.30.0/24 blackhole [kernel10 10:58] * (10) Type: inherit unicast univ Kernel.source: 3 Kernel.metric: 0 And debugging output from BIRD ------------------------------------------ KRT: Received async route notification (24) KRT: Got 192.168.30.0/24, type=6, oif=-1, table=10, prid=3, proto=kernel10 26-09-2013 11:15:24 <TRACE> kernel10: 192.168.30.0/24: [alien async] created krt_learn_async: distributing change 26-09-2013 11:15:24 <TRACE> kernel10 > added [best] 192.168.30.0/24 blackhole 26-09-2013 11:15:24 <TRACE> kernel10 < rejected by protocol 192.168.30.0/24 blackhole There also possible to trigger crash, infinite loop (spot on bird 1.3.9 on the other system), but I have no instructions to reproduce this reliable. At least logging to syslog or to a file among with logging to stderr and changing name of the protocol (kernel10->kernel20 etc.) after route learned from other KRT, or wait for periodic KRT scan, possibly followed by protocol name change). -- SP5475-RIPE Sergey Popovich

2 1

build: Fix building without BGP protocol
by Sergey Popovich 26 Sep '13

26 Sep '13

Hello, BIRD developers! Currently BIRD fails to build without BGP protocol, due to missing keyword definitions in parser sources *.Y Simple patch, addressing this issue attached. -- SP5474-RIPE Sergey Popovich

2 1

Re: OSPF segfault
by 1 Игорь 25 Sep '13

25 Sep '13

> Could you also send me the binary? http://yadi.sk/d/P8wCizig9rsys Its compiled from sources taken from here: ftp://bird.network.cz/pub/bird/bird-1.3.11.tar.gz core file generated from it. But the same segfaults is for Debian 7u1 repository ( version 1.3.7) and .deb from bird.network.cz. > Well, there is no simple way to do it. You can use 'stubnet' option > with hidden and/or summary attribute to eliminate these, like: > > stubnet 10.16.a.254/32 { hidden; }; > > or > > stubnet 10.16.a.128/25 { summary; hidden; }; > The problem that the amount of /32 prefixes is too large (about 250 /32 addresses - one for each VLAN), and wrote stubnet option for each /32 is madness (.

1 0

Fwd: OSPF segfault
by 1 Игорь 24 Sep '13

24 Sep '13

> I guess that OSPF iface option 'rx buffer large' should also fix this. > Could you try it? But definitely, it shouldn't crash even without this. Thank you. Of course it's helps. The only thing i could do is http://bit.ly/1alMqek Just one question: do i need to add this option on interfaces to core? Now i have no problem with them. > Could you get core dump of crashed BIRD for me? (i.e. run BIRD with > ulimit -c unlimited get it crashed.) core : http://yadi.sk/d/eRv1MON09qKHx In gdb i have seen http://pastebin.com/kqsAM01L What about /32 secondaries? Can I avoid OSPF from learning them.

1 0