- Bird-users - Mailing Lists

export all
by Guillaume Marcais 21 Nov '02

21 Nov '02

I have the following configuration (testing for now): ... protocol direct { table testtable; interface "gre1"; } protocol kernel { table testtable; kernel table 200; export all; } /* Some other ospf configuration */ ... Then, we get: # birdc BIRD 1.0.5 ready. bird> show route table testtable 192.168.0.0/30 dev gre1 [direct1 18:36] (240) 192.168.4.0/24 via 192.168.1.2 on gre2 [testOSPF 18:46] I (150/30) bird> Great, that is what we want. On the other end: # ip route list table 200 192.168.4.0/24 via 192.168.1.2 dev gre1 proto bird # The ospf stuff has been exported, not the rest... Any reason? Guillaume.

2 1

Error during compilation
by Guillaume Marcais 13 Nov '02

13 Nov '02

I tried to compile the latest snapshots, 1.0.5, I got the following error: make[2]: Entering directory `/mnt/lfs/kernel/bird-1.0.5/obj/conf' gcc -I../ -I../.. -g -O2 -Wall -W -Wstrict-prototypes -Wno-parentheses -Wno-unused -o cf-parse.tab.o -c cf-parse.tab.c cf-parse.y: In function `cf_parse': cf-parse.y:331: `FILE' undeclared (first use in this function) cf-parse.y:331: (Each undeclared identifier is reported only once cf-parse.y:331: for each function it appears in.) cf-parse.y:331: `f' undeclared (first use in this function) cf-parse.y:331: invalid lvalue in assignment cf-parse.y:336: `stderr' undeclared (first use in this function) make[2]: *** [cf-parse.tab.o] Error 1 make[2]: Leaving directory `/mnt/lfs/kernel/bird-1.0.5/obj/conf' make[1]: *** [subdir] Error 2 make[1]: Leaving directory `/mnt/lfs/kernel/bird-1.0.5/obj' make: *** [all] Error 2 FILE and stderr not declared??? Is there an include missing here or my lex/yacc installation is completly broken. My platform is Linux Mandrake 8.2. With flex-2.5.4a-18mdk and bison-1.32-2mdk (rpm binary distribution). Any idea? Cheers, Guillaume.

2 1

Bird active?
by Terje Malmedal 04 Nov '02

04 Nov '02

Is Bird still being worked on? I'm playing around a bit with it, and it seems to forget the nexthop part of the routes it gets: bird> show route 10.2.6.0/24 via 10.2.7.1 on eth1 [kernel1 12:16] (10) 10.2.7.0/24 dev eth1 [direct1 Nov02] (240) 10.1.7.0/24 dev eth2 [direct1 Nov02] (240) 10.3.8.0/24 dev eth0 [gaustad 12:16] I (150/20) 10.4.8.0/24 via 0.0.0.0 on eth0 [gaustad 12:16] E2 (150/20/20) 10.5.8.0/24 via 0.0.0.0 on eth0 [gaustad 12:16] E2 (150/20/20) 10.9.8.0/24 dev eth0 [direct1 Nov02] (240) dev eth0 [gaustad 12:16] I (150/10) 62.70.74.192/27 dev eth0 [gaustad 12:16] I (150/11) 127.0.0.0/8 dev lo [direct1 Nov02] (240) 62.70.74.224/28 dev eth0 [gaustad 12:16] I (150/20) # ip route 62.70.74.224/28 dev eth0 proto bird 62.70.74.192/27 dev eth0 proto bird 10.2.6.0/24 via 10.2.7.1 dev eth1 10.2.7.0/24 dev eth1 proto kernel scope link src 10.2.7.26 10.3.8.0/24 dev eth0 proto bird 10.9.8.0/24 dev eth0 proto bird 10.1.7.0/24 dev eth2 proto kernel scope link src 10.1.7.26 127.0.0.0/8 dev lo scope link Both Zebra and Cisco gets it right. Any ideas? -- - Terje malmedal(a)usit.uio.no

3 4

[ADMIN] Anti-SPAM measures for this list
by Martin Mares 05 Jul '02

05 Jul '02

Hello! I've added more anti-spam checks to the list server (now we're using SpamAssassin to detect spam) and each suspicious mail is automatically sent to the moderator of the list for approval. I hope this will reduce the amount of junk in our lists to minimum. If you encounter any problems, please let me know. Have a nice fortnight -- Martin `MJ' Mares <mj(a)ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "This is an object-oriented system. If we change anything, the users object."

1 0

BIRD current status
by Vladimir Ivaschenko 01 Jul '02

01 Jul '02

Hi, Is BIRD still being developed? Are there are archives of the mailing list somewhere? I'd like to try BIRD, but its OSPF does not support MD5 authentication. As well as MD5 with RIPv2 seems to be not fully working: while BIRD receives and parses MD5 RIPv2 packets from Cisco, Cisco rejects them due to incorrect password. -- Best Regards, Vladimir Systems Engineer (RHCE)

2 1

(OSPF) some connected networks not distributed as such
by Pim van Riezen 24 May '02

24 May '02

Good Day, This may be a cause of my newfound ignorance on the subject of OSPF routing, but it has had me boggled for a good part of the last two days. I have a linux 2.4 machine running bird on a non-broadcast connection to a Cisco 1600. The linux machine has the following configuration: ----- (interface connected to area 0) ---------------------------------- eth0 Link encap:Ethernet HWaddr 00:60:97:C2:36:47 inet addr:213.196.8.130 Bcast:213.196.8.135 Mask:255.255.255.248 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 ----- (interface that is the target of exchanged routes) --------------- eth2 Link encap:Ethernet HWaddr 00:50:04:02:3B:91 inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 eth2:0 Link encap:Ethernet HWaddr 00:50:04:02:3B:91 inet addr:202.36.147.1 Bcast:202.36.147.255 Mask:255.255.255.0 eth2:1 Link encap:Ethernet HWaddr 00:50:04:02:3B:91 inet addr:202.36.148.1 Bcast:202.36.148.255 Mask:255.255.255.0 eth2:2 Link encap:Ethernet HWaddr 00:50:04:02:3B:91 inet addr:202.50.64.1 Bcast:202.50.71.255 Mask:255.255.248.0 ----- (bird configuration on the machine) ------------------------------ router id 213.196.8.130; filter outroute_filter { if net ~ 213.196.8.136/29 then accept; if net ~ 202.36.147.0/24 then accept; if net ~ 202.36.148.0/24 then accept; if net ~ 202.50.64.0/21 then accept; else reject; }; protocol static { preference 1; route 202.36.147.0:255.255.255.0 via "eth2"; route 202.36.148.0:255.255.255.0 via "eth2"; route 202.50.64.0:255.255.248.0 via "eth2"; } protocol ospf MyOSPF { area 0 { tick 1; interface "eth1" { type nonbroadcast; stub yes; }; interface "eth0" { hello 30; retransmit 5; cost 10; type nonbroadcast; authentication none; neighbors { 213.196.8.133 eligible; }; strict nonbroadcast yes; }; interface "eth2" { cost 5; type nonbroadcast; }; interface "eth2:0" { cost 5; type nonbroadcast; }; interface "eth2:1" { cost 5; type nonbroadcast; }; interface "eth2:2" { cost 5; type nonbroadcast; }; interface "*" { stub yes; }; }; import filter { reject; }; export filter outroute_filter; }; -----( cisco configuration )------------------------------------------ interface Ethernet0 description vlan2 ip address 213.196.8.133 255.255.255.248 ip access-group 101 out no ip redirects ip nat inside ip ospf network non-broadcast ! router ospf 31338 network 202.36.147.0 0.0.0.255 area 6 network 202.36.148.0 0.0.0.255 area 6 network 202.50.64.0 0.0.7.255 area 6 neighbor 213.196.8.131 priority 1 neighbor 213.196.8.130 priority 1 ! -----------( the problem )---------------------------------------------- gw-vlan2#sho ip route ospf O E2 202.36.148.0/24 [110/10000] via 213.196.8.130, 00:00:25, Ethernet0 O 202.36.147.0/24 [110/15] via 213.196.8.130, 00:00:25, Ethernet0 O E2 202.50.64.0/21 [110/10000] via 213.196.8.130, 00:00:25, Ethernet0 gw-vlan2# sho ip ospf database router 213.196.8.130 OSPF Router with ID (213.196.8.133) (Process ID 31338) Router Link States (Area 0) Routing Bit Set on this LSA LS age: 399 Options: (No TOS-capability, No DC) LS Type: Router Links Link State ID: 213.196.8.130 Advertising Router: 213.196.8.130 LS Seq Number: 80000002 Checksum: 0x6342 Length: 72 AS Boundary Router Number of Links: 2 Link connected to: a Transit Network (Link ID) Designated Router address: 213.196.8.130 (Link Data) Router Interface address: 213.196.8.130 Number of TOS metrics: 0 TOS 0 Metrics: 10 Link connected to: a Stub Network (Link ID) Network/subnet number: 202.36.147.0 (Link Data) Network Mask: 255.255.255.0 Number of TOS metrics: 0 TOS 0 Metrics: 5 So... Which of the two (cisco or bird) made the decision that somehow 202.36.147.0/24 is a connected link whereas 202.36.148.0/24 is an external route, even though it is connected to the same interface? My head is hurting :) Cheers, Pi -- This could have been your donkey.

2 1

Very strange thing?!?
by Damjan 15 May '02

15 May '02

After runnig for some time, a very strange thing happened to my Bird daemon. I'm using Bird to do BGP anouncing to my 2 peers. At one moment the BGP session with one of the peers was lost, and when Bird tried to reconect it tried on a wrong IP address. The IP address is totaly unknown to me. I had luck I was at the place when this happened and I restarted BIRD, and everything went fine. What can be the reason for this behaviour? Is it a bug in BIRD. I'm using Bird-1.0.5, kernel 2.2.18, glibc-2.1, redhat-6.2 This is the relevant part of the log file: 15-05-2002 02:45:01 <TRACE> SMSnet: Sending KEEPALIVE 15-05-2002 02:45:32 <TRACE> SMSnet: Got KEEPALIVE 15-05-2002 02:45:32 <RMT> SMSnet: Received error notification: Hold timer expired 15-05-2002 02:45:32 <TRACE> SMSnet: State changed to flush 15-05-2002 02:45:32 <TRACE> SMSnet: State changed to down 15-05-2002 02:45:32 <TRACE> SMSnet: Starting 15-05-2002 02:45:32 <TRACE> SMSnet: State changed to start 15-05-2002 02:45:32 <TRACE> SMSnet: Connect delayed by 5 seconds 15-05-2002 02:45:36 <TRACE> device1: Scanning interfaces 15-05-2002 02:45:36 <TRACE> SMSnet: Connecting to 8.7.113.112 from local address x.x.x.x 15-05-2002 02:45:36 <ERR> sk_open: IP_TTL: Invalid argument 15-05-2002 02:45:36 <TRACE> SMSnet: Connection closed -- Damjan Georgievski | Дамјан Георгиевски Skopje, Macedonia | Скопје, Македонија

1 0

Problemy s bird-em 1.0.4 a 1.0.5
by Jan Marek 03 Apr '02

03 Apr '02

Dobry den, pokousim se rozbehat bird-a 1.0.4 nebo 1.0.5 na jadre 2.4.17 s usagi patchem. Birda jsem kompiloval s --enable-ipv6 a bez OSPF. Pokud ho spustim a sleduju tcpdump-em provoz na siti, tak bird neposila zadne pakety a v logu hlasi toto: bird: Netlink: File exists Kdyz jsem se na nej dival strace-m, tak se zda, ze po pokusu o odeslani paketu dostane chybu "-1 EAGAIN"... Ma s timto nekdo zkusenosti? BTW: bird 1.0.5 se mi vubec nechtel prelozit, protoze neznal FILE, stderr apod, tak jsem do conf/confbase.Y dal jako posledni include <stdio.h>, pak se mi uz prelozil... Zdravi Honza Marek P.S. Jsem tu novy, tak nevim, zda se tu nema psat anglicky... -- Ing. Jan Marek University of South Bohemia Academic Computer Centre

1 0

A bug??
by Damjan 10 Mar '02

10 Mar '02

Anyone knows what is this: 02-03-2002 14:48:14 <TRACE> SMSnet: State changed to feed 02-03-2002 14:48:14 <TRACE> SMSnet: Connected to table master 02-03-2002 14:48:14 <TRACE> SMSnet < added xxx.xx.xx.x/20 via xxx.xx.xx.x on eth2 02-03-2002 14:48:14 <TRACE> SMSnet: Sending UPDATE 02-03-2002 14:48:14 <BUG> sk_maybe_write: unknown socket type 134766456 it crashed my bird daemon. Bird is 1.0.5 -- Damjan Georgievski | Дамјан Георгиевски Skopje, Macedonia | Скопје, Македонија

2 1

Re: broadcast and multicast RIP on the same interface?
by noc＠clouddancer.com 08 Mar '02

08 Mar '02

In broadcast and multicast RIP on the same interface?, you wrote: > >Is there any reason why broadcast and multicast RIP can't be run on the >same interface? I haven't read the RFCs, but we'd only be using this in >a student lab setting with the multicast interface in mode "quiet", so I >think it should be okay. Well, don't waste too much time on RIP. It's pretty worthless in today's enviroment, subnetting/CIDR is too common. OSPF in bird can use this sort of debugging/experimenting. About every 5-6 hours, I lose all routing for 10 minutes. Usually I chain login to the remote machine (via all the intermediate machines), restart the protocol and get connectivity back quickly. The only clue I have is: Feb 20 12:47:00 rudder bird: Netlink: Network is unreachable Feb 20 12:47:38 rudder last message repeated 6 times I suspect it is a recent 2.4 kernel change somehow, or that bird does not have a robust 'maintain the link' technique. I ran bird before in a 2.0/2.2 kernel enviroment on a T1, no problems. The above outage occurs in 2.4 kernels on a 28k modem link (the desert does not have good telephone lines). Surely the decision to declare a dead link should depend on the link speed/bandwidth? OSPF/BGP4 cover all routing needs. When someone talks about IPv6, just smile and move away slowly, it will be years before it's prime time. Upstreams have simply raised the costs of retaining IPv4 addresses, which causes customers to divest their surplus and switch to NAT systems -- classic market actions, reduced supply causes smarter demand.

1 0