- Bird-users - Mailing Lists

BIRD and RIP
by Schmidt, Bernhard 04 Jun '11

04 Jun '11

Hi, we are using RIP(v2|NG) with very low timers for the one hop between our routers and our Anycast cluster nodes for DNS, NTP and others due to its simplicity. Historically we are running either Quagga or a self-written Python daemon to announce the anycast cluster address. In order to get to use a modern software, I've tried to use BIRD in a new deployment and failed horribly. RIPv2 ===== protocol rip RIP { debug all; period 10; port 520; interface "eth0" { metric 3; mode multicast; }; honor neighbor; authentication none; import filter { print "importing"; accept; }; export filter { print "exporting"; accept; }; } Importing routes (which is the thing we don't need) seems to work. Exporting routes does not work at all. I get a single message at startup saying bird: RIP: Broadcasting routing table to eth0 bird: RIP: Unexpected error at rip transmit: Invalid argument bird: RIP: Unexpected error at rip transmit: Unknown error 18446744073709551615 and nothing more of that. RIPng ===== protocol rip RIPng { debug all; period 10; port 521; interface "eth0" { metric 3; mode multicast; }; honor neighbor; authentication none; import filter { print "importing"; accept; }; export filter { print "exporting"; accept; }; } Importing routes does not work at all, probably because it has bound the listening socket to the global address on eth0 udp 0 0 2001:4ca0:0:101::81:521 :::* 4895/bird6 Sending routes does not really work either. a) it completely ignores the period setting and sends every 30 seconds b) it speaks RIPng on port 520 by default, you have to set it in the config c) it sets version=2 in the RIPng header (probably because it thinks multicast=RIPv2), which makes all routers ignore the update anyway So, the big question is, am I doing something horribly wrong or is RIP just broken/untested in BIRD? Best Regards, Bernhard

2 1

bird 1.3.0 and 1.2.4 crash
by Denis Samsonov 04 Jun '11

04 Jun '11

While working as a bird route server arises srash. Failure observed in versions 1.3.0 and 1.2.4 and occurs when scanning the routing table .. How do I fix this? OS where working bird - freebsd 7.3 Last messages in log file 03-06-2011 06:57:30 <TRACE> xxxx1: Got KEEPALIVE 03-06-2011 06:57:30 <TRACE> xxxx2: Got KEEPALIVE 03-06-2011 06:57:31 <TRACE> xxxx3: Got KEEPALIVE 03-06-2011 06:57:33 <TRACE> xxxx4: Sending KEEPALIVE 03-06-2011 06:57:33 <TRACE> xxxx5: Got KEEPALIVE 03-06-2011 06:57:33 <TRACE> xxxx6: Got KEEPALIVE 03-06-2011 06:57:33 <TRACE> xxxx7: Connecting to xx.xx.xx.xx from local address xxx.xxx.xxx.xxx 03-06-2011 06:57:33 <TRACE> device1: Scanning interfaces 03-06-2011 06:57:33 <TRACE> kernel1: Scanning routing table 03-06-2011 06:57:33 <FATAL> RT scan 2 kernel protocol config protocol kernel { #persist; # Don't remove routes on bird shutdown scan time 20; # Scan kernel routing table export all; # Default is export none import none; } Unfortunately I can not find a coredump, apparently was not made at crash P.S. Sorry, my english is bad

3 3

BGP Confederation support?
by Jann Traschewski 02 Jun '11

02 Jun '11

Hi, are there any plans to implement the BGP Confederation feature (rfc3065) into bird? http://www.ietf.org/rfc/rfc3065.txt Thank you, Jann -- Jann Traschewski, Drosselstr.1, D-90513 Zirndorf, Germany Tel.: +49-911-696971, Mobile: +49-170-1045937, E-Mail: jann(a)gmx.de

1 0

Troubleshooting "Optional attribute error"
by Ruben Laban 31 May '11

31 May '11

Hi, After having been down for some time, I decided to bring up an old test session (IPv6 full table). However, the session doesn't come up fully. I do see a fair amount of UPDATE packets coming in, but then at a certain point the connection gets closed and the routes purged again. All I can find in the logs is "Optional attribute error", even with "debug all all". Is there some other trick to find out what the actual problem is with this session? Regards, Ruben Laban

3 5

Segmentation fault caused by malformed BGP packet
by Ivo Smits 31 May '11

31 May '11

After running into trouble with bird 1.2.3 trying to display 32 bit AS numbers (show route all resulted in a segmentation fault), we decided to upgrade to 1.3.1. Unfortunately 1.3.1 crashed even sooner than 1.2.3. One of the logs looks like this: bird: UFO_4_0_bgp > added 1.0.49.0/24 via 1.82.98.2 on ppp-UFO_4-0 Segmentation fault Disabling this peer fixed the crashes, enabling the peer brought them back. After some investigation, it turned out that this BGP peer sends an ORIGIN attribute even with BGP packets that only withdraw a route; bird does not do this. Changing the peer's sourcecode to not send the ORIGIN attribute for withdrawn routes, fixed the crashes in bird. The segmentation fault suggests that there is a security issue in bird's BGP update handling. Attached is a pcap dump file containing a BGP session. 1.82.98.27 is the bird router. Frame 30 contains a withdrawl update sent by bird, frame 31 contains the first withdrawl received by bird (offset 0x0525), which also happens to be the next UPDATE after an update regarding 1.0.49.0/24, which is shown in the log just before bird crashes. -- Ivo

2 3

BIRD at MSK-IX
by Mikhail A. Grishin 27 May '11

27 May '11

Hi, We successfully finished the process of adaptation BIRD to MSK-IX network. Currently BIRD is running on both IPv4 Route Servers (version 1.2.0 with some patches from Ondrej Zajicek). Also we modified our public Looking Glass service. It's available via: http://www.msk-ix.ru/eng/lookingglass.html Thank you for help and cooperation! -- Mikhail A. Grishin E-mail: magr(a)ripn.net

4 4

Problem with OSPF NBMA and MikroTik
by Marek Wajdzik 27 May '11

27 May '11

Hi. I've some troubles with bird running this config: router id 10.0.0.1; filter FromOSPF { if proto="OSPF" then accept; reject; } protocol kernel KRT { learn; persist; scan time 20; import all; export filter FromOSPF; } protocol device Ifaces { scan time 10; } protocol static DefaultGW { route 0.0.0.0/0 reject; } filter DefaultOriginate { if proto = "DefaultOriginate" then accept; reject; } protocol ospf OSPF { import all; export filter DefaultOriginate; area 0.0.0.0 { interface "vlan2000" { hello 10; retransmit 5; cost 10; priority 30; dead 40; wait 40; type nbma; authentication none; strict nonbroadcast yes; neighbors { 172.30.0.120; }; }; }; } 172.30.0.1 - compiled from fresh sources: bird 1.3.1 running debian with kernel 2.6.38.6 x64 172.30.0.120 - It is a mikrotik routeros version 5.2 node with configured ospf. When I restart the ospf in bird (birdc restrart OSPF) :P Mikrotik says: 00:59:09 route,ospf,debug RECV: Hello <- 172.30.0.1 on vlan2000 (172.30.0.120) 00:59:09 route,ospf,debug,raw PACKET: 00:59:09 route,ospf,debug,raw 45 C0 00 44 74 DA 00 00 40 59 AC 11 AC 1E 00 01 00:59:09 route,ospf,debug,raw AC 1E 00 78 02 01 00 30 0A 00 00 01 00 00 00 00 00:59:09 route,ospf,debug,raw 3B E5 00 00 30 E3 E5 01 00 00 00 00 FF FF FF 00 00:59:09 route,ospf,debug,raw 00 0A 02 1E 00 00 00 28 AC 1E 00 01 00 00 00 00 00:59:09 route,ospf,debug,raw 0A 00 00 78 00:59:09 route,ospf,info Discarding packet: wrong chekcsum 00:59:09 route,ospf,info source=172.30.0.1 00:59:11 route,ospf,debug RECV: Database Description <- 172.30.0.1 on vlan2000 (172.30.0.120) 00:59:11 route,ospf,debug,raw PACKET: 00:59:11 route,ospf,debug,raw 45 C0 00 34 74 DB 00 00 40 59 AC 20 AC 1E 00 01 00:59:11 route,ospf,debug,raw AC 1E 00 78 02 02 00 20 0A 00 00 01 00 00 00 00 00:59:11 route,ospf,debug,raw 12 9C 00 00 30 E3 E5 01 00 00 00 00 05 DC 02 07 00:59:11 route,ospf,debug,raw BB 69 1D F4 00:59:11 route,ospf,info Discarding packet: wrong chekcsum 00:59:11 route,ospf,info source=172.30.0.1 00:59:19 route,ospf,debug RECV: Hello <- 172.30.0.1 on vlan2000 (172.30.0.120) 00:59:19 route,ospf,debug,raw PACKET: 00:59:19 route,ospf,debug,raw 45 C0 00 40 74 DC 00 00 40 59 AC 13 AC 1E 00 01 00:59:19 route,ospf,debug,raw AC 1E 00 78 02 01 00 2C 0A 00 00 01 00 00 00 00 00:59:19 route,ospf,debug,raw 46 61 00 00 30 E3 E5 01 00 00 00 00 FF FF FF 00 00:59:19 route,ospf,debug,raw 00 0A 02 1E 00 00 00 28 AC 1E 00 01 00 00 00 00 00:59:19 route,ospf,info Discarding packet: wrong chekcsum 00:59:19 route,ospf,info source=172.30.0.1 bird lsa db: bird> show ospf lsadb Global Type LS ID Router Age Sequence Checksum 0005 0.0.0.0 10.0.0.1 544 80000001 a1f0 Area 0.0.0.0 Type LS ID Router Age Sequence Checksum 0001 10.0.0.1 10.0.0.1 467 80000001 4224 Here is tcpdump: http://consi.jest.pro/ospf.dump Similar problem here: http://www.mail-archive.com/bird-users@atrey.karlin.mff.cuni.cz/msg01037.ht… Please help! :(

3 4

Re: Feature requests
by Ondrej Filip 16 May '11

16 May '11

On 5.5.2011 10:57, Oleg wrote: > On Tue, May 03, 2011 at 04:03:20PM +0200, Ondrej Filip wrote: >> On 2.5.2011 21:53, Ondrej Zajicek wrote: >>> Hello >>> >> >> A few weeks ago I had presentation about BIRD at Netnod meeting. I >> asked very similar question and surprisingly a lot of people requested >> IS-IS. Is here somebody also interested in this protocol? > > Our organization doesn't use IGP now. But we plan to use it in the near > future and we prefer IS-IS over OSPF as IGP for it simplicity and scalability > features. OK. I raised the issue also on EIX WG at RIPE meeting and I also got some request for IS-IS. Ondrej

2 1

Re: [OSPF] BIRD <> Mikrotik checksum
by Adrian Czapek 13 May '11

13 May '11

>On Thu, Sep 02, 2010 at 11:36:22AM +0200, Maciej Drobniuch wrote: >> Hi! >> I have a problem with binding bird with mikrotik router os. >> The RouterOS says: >> Discarding packet: wrong checksum. > >Strange. I will check that. Did you find anything? I've experienced the same problem last evening. Suddenly I've found my routeros logs flooded by: mar/16 23:32:31 route,ospf,info Discarding packet: wrong chekcsum mar/16 23:32:31 route,ospf,info source=78.31.143.69 this is backup link, with cost set to 100 on both sides - main link, between the same bird and the same routeros has been working perfectly. I first tried to reload ospf1 from bird console and guess what happened... main link went dead too... wrong checksums on both links. Then I did reload ospf1 again, main link went up, backup link stayed dead, but suddenly, other routeros in this area went dead: mar/16 23:37:27 route,ospf,info Discarding packet: wrong chekcsum mar/16 23:37:27 route,ospf,info source=78.31.136.169 I started to freak out and pullled bigger cannon: restart ospf1 - result: those 2 routeros went up (besides backup link - source=78.31.143.69), but heh, 3rd routeros went down mar/16 23:39:57 route,ospf,info Discarding packet: wrong chekcsum mar/16 23:39:57 route,ospf,info source=78.31.139.21 well, that was to much, I shutdown whole bird and started it again... all went up except the first mentioned backup link (which never went up btw). So I decided to go back to quagga and check it there with the same config. Disabled ospf in bird, started quagga and everything went up, even that backup link. I've left it for about an hour and stopped quagga, enabled ospf on bird, and everyting works fine, all links are up, backup link too. What may be wrong? Regards -- Adrian

2 4

BIRD: route selection question
by Mikhail A. Grishin 13 May '11

13 May '11

Hi, Why in the example below, the route via 194.226.100.51 is the best? According http://bird.network.cz/?get_doc&f=bird-6.html#ss6.1 Route selection rules ... "Prefer the lowest value of the Multiple Exit Discriminator." And at both peers we have commented string --- # default bgp_med 0; # MED value we use for comparison when none is defined --- and the default value is 0. Probably, for the route via 194.226.100.45 , the MED should be counted as zero, and this route should win? BIRD 1.2.5 ready. bird> show route 194.105.192.0/19 all 194.105.192.0/19 via 194.226.100.51 on em0 [R20632x1 2011-03-22 21:37:36] * (100) [AS6820i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 20632 6820 BGP.next_hop: 194.226.100.51 BGP.med: 160 BGP.local_pref: 100 via 194.226.100.45 on em0 [R3277x1 2011-03-16 12:47:37] (100) [AS6820i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 3277 6820 BGP.next_hop: 194.226.100.45 BGP.local_pref: 100

3 5