- Bird-users - Mailing Lists

strange behaviour with direct protocol if two interface has the same ip address
by csszep 25 Jul '11

25 Jul '11

Hello! Openswan with klips stack use ipsec* interface which is configured to the same ip address as the physical interface. If i use the direct protocol and starting ipsec daemon the physical interface's connected route disappears. If i stopping ipsec daemon any connected route is missing from direct protocol. Simple test: bird.conf: debug protocols all; protocol direct { } protocol kernel { learn; persist; scan time 20; export all; } protocol device { scan time 10; } protocol static { } Ipsec stopped and after that bird started: BIRD 1.3.2 ready. bird> show interfaces lo up (index=1) MultiAccess AdminUp LinkUp Loopback Ignored MTU=16436 127.0.0.1/8 (Primary, scope host) eth0 up (index=2) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 10.0.2.15/24 (Primary, scope site) eth1 up (index=3) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 192.168.56.3/24 (Primary, scope site) ipsec0 DOWN (index=7) MultiAccess AdminDown LinkDown MTU=16260 ipsec1 DOWN (index=8) MultiAccess AdminDown LinkDown MTU=0 mast0 DOWN (index=9) MultiAccess AdminDown LinkDown MTU=0 bird> sho route 0.0.0.0/0 via 10.0.2.2 on eth0 [kernel1 16:16] * (10) 10.0.2.0/24 dev eth0 [direct1 16:16] * (240) 192.168.56.0/24 dev eth1 [direct1 16:16] * (240) Ipsec started: bird> show interfaces lo up (index=1) MultiAccess AdminUp LinkUp Loopback Ignored MTU=16436 127.0.0.1/8 (Primary, scope host) eth0 up (index=2) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 10.0.2.15/24 (Primary, scope site) eth1 up (index=3) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 192.168.56.3/24 (Primary, scope site) ipsec0 up (index=7) MultiAccess AdminUp LinkUp MTU=16260 10.0.2.15/24 (Primary, scope site) ipsec1 DOWN (index=8) MultiAccess AdminDown LinkDown MTU=0 mast0 DOWN (index=9) MultiAccess AdminDown LinkDown MTU=0 bird> sho route 0.0.0.0/0 via 10.0.2.2 on eth0 [kernel1 16:16] * (10) 10.0.2.0/24 dev ipsec0 [direct1 16:19] * (240) <-------- connected route changed to ipsec0 192.168.56.0/24 dev eth1 [direct1 16:16] * (240) Ipsec stopped again: bird> show interfaces lo up (index=1) MultiAccess AdminUp LinkUp Loopback Ignored MTU=16436 127.0.0.1/8 (Primary, scope host) eth0 up (index=2) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 10.0.2.15/24 (Primary, scope site) eth1 up (index=3) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 192.168.56.3/24 (Primary, scope site) ipsec0 DOWN (index=7) MultiAccess AdminDown LinkDown MTU=16260 ipsec1 DOWN (index=8) MultiAccess AdminDown LinkDown MTU=0 mast0 DOWN (index=9) bird> show route 0.0.0.0/0 via 10.0.2.2 on eth0 [kernel1 16:16] * (10) 192.168.56.0/24 dev eth1 [direct1 16:16] * (240) Connected route from eth0 is missing. Log: Jul 23 16:31:19 debianvm1 ipsec_setup: Starting Openswan IPsec 2.6.28... Jul 23 16:31:19 debianvm1 ipsec_setup: Using KLIPS/legacy stack Jul 23 16:31:20 debianvm1 ipsec_setup: KLIPS debug `none' Jul 23 16:31:20 debianvm1 ipsec_setup: KLIPS ipsec0 on eth0 10.0.2.15/255.255.255.0 broadcast 10.0.2.255 Jul 23 16:31:20 debianvm1 bird: static1 < interface ipsec0 goes up Jul 23 16:31:20 debianvm1 bird: direct1 < primary address 10.0.0.0/8 on interface ipsec0 added Jul 23 16:31:20 debianvm1 bird: direct1 > added [best] 10.0.0.0/8 dev ipsec0 Jul 23 16:31:20 debianvm1 bird: kernel1 < rejected by protocol 10.0.0.0/8 dev ipsec0 Jul 23 16:31:20 debianvm1 bird: direct1 < primary address 10.0.0.0/8 on interface ipsec0 removed Jul 23 16:31:20 debianvm1 bird: direct1 > removed [sole] 10.0.0.0/8 dev ipsec0 Jul 23 16:31:20 debianvm1 bird: static1 < interface ipsec0 goes down Jul 23 16:31:20 debianvm1 ipsec_setup: ...Openswan IPsec started Jul 23 16:31:20 debianvm1 ipsec__plutorun: adjusting ipsec.d to /etc/ipsec.d Jul 23 16:31:20 debianvm1 ipsec__plutorun: 003 NAT-Traversal: Trying new style NAT-T Jul 23 16:31:22 debianvm1 bird: device1: Scanning interfaces Jul 23 16:31:22 debianvm1 bird: static1 < interface ipsec0 goes up Jul 23 16:31:22 debianvm1 bird: direct1 < primary address 10.0.2.0/24 on interface ipsec0 added Jul 23 16:31:22 debianvm1 bird: direct1 > added 10.0.2.0/24 dev ipsec0 Jul 23 16:31:22 debianvm1 bird: kernel1 < rejected by protocol 10.0.2.0/24 dev ipsec0 Jul 23 16:31:32 debianvm1 bird: device1: Scanning interfaces Jul 23 16:31:32 debianvm1 bird: kernel1: Scanning routing table Jul 23 16:31:32 debianvm1 bird: kernel1: 0.0.0.0/0: [alien] seen Jul 23 16:31:32 debianvm1 bird: kernel1: Pruning table master Jul 23 16:31:32 debianvm1 bird: kernel1: Pruning inherited routes Jul 23 16:31:35 debianvm1 ipsec_setup: Stopping Openswan IPsec... Jul 23 16:31:37 debianvm1 bird: direct1 < primary address 10.0.2.0/24 on interface ipsec0 removed Jul 23 16:31:37 debianvm1 bird: direct1 > removed [sole] 10.0.2.0/24 dev ipsec0 Jul 23 16:31:37 debianvm1 bird: static1 < interface ipsec0 goes down Jul 23 16:31:37 debianvm1 ipsec_setup: ...Openswan IPsec stopped Jul 23 16:31:41 debianvm1 bird: device1: Scanning interfaces Jul 23 16:31:51 debianvm1 bird: device1: Scanning interfaces Jul 23 16:31:51 debianvm1 bird: kernel1: Scanning routing table Jul 23 16:31:51 debianvm1 bird: kernel1: 0.0.0.0/0: [alien] seen Jul 23 16:31:51 debianvm1 bird: kernel1: Pruning table master Jul 23 16:31:51 debianvm1 bird: kernel1: Pruning inherited routes thx Csszep

2 1

bird configure error
by Ryan Whelan 19 Jul '11

19 Jul '11

Im getting the error "configure: error: The client requires GNU readline library 2.1 or newer. Either install the library or use --disable-client to compile without the client." from the configure script on a CentOS 5.6 64bit machine. I have the the readline RPM from the distribution repository as well as the distributions development package: # rpm -qa | grep readline readline-devel-5.1-3.el5 readline-5.1-3.el5 searching the readline header files returns what I think the configure script is checking for: # grep rl_callback_read_char /usr/include/readline/* /usr/include/readline/readline.h:extern void rl_callback_read_char PARAMS((void)); Adding '-I/usr/include/readline' to the CFLAGS doesn't help. I feel like I'm missing something obvious but not sure where to turn. Google has not proven very fruitful. Thanks ryan

1 0

Slow static reconfigure
by Neil Wilson 14 Jul '11

14 Jul '11

Hi all, Loading a large set of prefixes into the static protocol is pretty quick, but reconfiguring is really slow. The current implementation uses linked lists which are traversed lots of times during the reconfiguration. I was wondering if these could be indexed and sorted in some way with one of the existing bird data structures - perhaps with a FIB - which would allow the use of a faster merge algorithm. Any other suggestions as to how the static reconfigure could be made faster? Rgs Neil

3 5

ibgp bird
by Gianluigi Salerno 14 Jul '11

14 Jul '11

Hi, I've a problem using IBGP, it seems that next hop attribute is lost. If I use version 1.2.5 it works fine but with 1.3.0, 1.3.1 and 1.3.2 the problem persist. Here it is the configuration on cisco side: neighbor 195.36.1.7 remote-as 5392 neighbor 195.36.1.7 next-hop-self neighbor 195.36.1.7 maximum-prefix 10 and bird: router id 195.36.1.7; protocol kernel { persist; scan time 20; export all; } protocol device { scan time 10; } protocol static { } protocol bgp milano3 { import all; local as 5392; next hop self; neighbor 195.36.1.3 as 5392; } Any hint ? Thank you. Regards. -- Gianluigi Salerno - TELNET S.r.L. Phone: +39-0382-529751 TELNET e' associata ad AIIP, MIX, RIPE Fax: +39-0382-528074 I-27100 V. Buozzi, 5 - Pavia, Italy e-mail: gsalerno(a)telnetwork.it

2 1

show protocols all output
by Marcin Kurek 12 Jul '11

12 Jul '11

Hello, I wonder if there is a simple way to force bird to display informations like ASN, neighbor address even if the session is down? Currently I use "show protocols all" but maybe there is a better way? -- Kind regards, Marcin Kurek

2 2

bird 1.3.1 protocol radv issue
by Bogdan Besliu 11 Jul '11

11 Jul '11

Hello, I'm testing bird 1.3.1 protocol radv . The configuration is: router-id 1.1.1.1; protocol device { scan time 10; }; protocol radv { interface "ppp*" prefix 2001:1111:1111::/64 { autonomous on; }; }; most of the time it works ok but from time to time it happens something like this: un 17 18:19:41 ppp-test pppd[8032]: No response to 3 echo-requests Jun 17 18:19:41 ppp-test pppd[8032]: Serial link appears to be disconnected. Jun 17 18:19:41 ppp-test pppd[8032]: Connect time 436.5 minutes. Jun 17 18:19:41 ppp-test pppd[8032]: Sent 1307925176 bytes, received 252750 bytes. Jun 17 18:19:41 ppp-test bird6: radv1: Socket error: Network is unreachable Jun 17 18:19:41 ppp-test bird6: radv1: Socket error: Network is unreachable Jun 17 18:19:41 ppp-test bird6: radv1: Socket error: Network is unreachable Jun 17 18:19:41 ppp-test bird6: radv1: Socket error: Network is unreachable ........... and the last messages repeats itself until hdd is full; or bird6 daemon stop working. it looks like the problems appear when radv tries to send RA and at the same time ppp interface goes down. any ideas ? thx, Bogdan Besliu

2 2

Notabiliy references for BIRD
by Ondrej Zajicek 11 Jul '11

11 Jul '11

Hello It seems that Wikipedia article about BIRD [*] lacks reliable references from secondary sources to establish notability of BIRD. Do you now any such references? [*] http://en.wikipedia.org/wiki/Bird_Internet_routing_daemon -- 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."

2 1

Feature requests
by Ondrej Zajicek 11 Jul '11

11 Jul '11

Hello We (BIRD developers) would like to know which major features you miss in BIRD and would like to be implemented. If you have some opinions on that issue, please write suggested features together with several sentences about why you think that is the feature we should implement or why you need that. This inquiry is oriented on long-term, major features, but if you have some minor requests, you are also welcome. Our current short-term plan is to fix RIP (and multipath for RIP) and implement Route Origin Authorization / RPKI drafts for BGP. Some examples: OSPF NSSA OSPF opaque LSAs .. or some other OSPF extensions BGP confederations BGP extended communities .. or some other BGP extensions MRT routing table dumps Some monitoring/statistics integration (SNMP, collectd ...) Route aggregation engine Static routes depedent on ping reachability BFD (Bidirectional Forwarding Detection) IS-IS Some ad-hoc wireless routing like OSPF MANET or OLSR Multicast routing? .. or perhaps no new big features, just some more work to already implemented areas? BTW, from these examples, my personal preference is currently on BFD. -- 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."

19 33

Open socket on OSPF Stub interfaces
by Neil Wilson 05 Jul '11

05 Jul '11

Hi, Is there a way of turning off the socket listen for OSPF interfaces marked as 'stub'? At the moment I'm running up against the 1024 open file limit on servers (such as VM hosts) with lots of interfaces. I could alter the ulimit but it seems a bit of a waste to have all those open sockets doing nothing. Could the code be altered to open the socket if the interface is reconfigured away from being a stub, or is there another reason for the listen being there on stub interfaces? Rgs Neil

4 10

as_path question
by Mikhail A. Grishin 05 Jul '11

05 Jul '11

Hi, Ordinary as_path from 'show route all' output usually looks like: ------------------------- 78.153.135.0/24 via 193.232.244.186 on bce1 [R48467x1 2011-07-04 16:16:21] (100) [AS44116i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 48467 44116 44116 BGP.next_hop: 193.232.244.186 BGP.local_pref: 100 ------------------------- Here is unusual as_path example: ------------------------- 94.228.160.0/20 via 193.232.244.186 on bce1 [R48467x1 2011-07-05 01:28:04] * (100) [i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 48467 { 49245 50448 } BGP.next_hop: 193.232.244.186 BGP.local_pref: 100 BGP.aggregator: 178.236.240.1 AS48467 What purpose of '{' and '}' at BGP.as_path output? Why at 'show route' we see only '[i]'? (expected to see the first AS in as_path)

4 5