May 2011 - Bird-users - Mailing Lists

upgrade 1.2.4 - 1.3.1 reverted
by Arjan Filius 24 Oct '12

24 Oct '12

Hello, upgraded from bird 1.2.4 to bird 1.3.1 last weekend, but needed to revert due to complaints from high bgp traffic to bgpmon.net and 100% cpu load on a 2x bird bgp routers setup connected with iBGP. Did some research, and noticed a high bgp traffic situation on the iBGP sessions (about 10.000 bgp packets in 1.7 second) Based on graph statistics, i noticed a irregular traffic on the trans-ip's as well (noticed after rollback in statistical graphs) In the logging (mostly on the first bgp router) , i noticed quite some messages (33414 in ~12h) like: 29-05-2011 10:57:49 <WARN> Next hop address X.X.X.242 resolvable through recursive route for X.X.X.0/24 29-05-2011 10:57:49 <WARN> Next hop address Y.Y.35.194 resolvable through recursive route for Y.Y.32.0/19 29-05-2011 10:57:52 <WARN> Next hop address X.X.X.241 resolvable through recursive route for X.X.X.0/24 29-05-2011 10:57:52 <WARN> Next hop address X.X.X.242 resolvable through recursive route for X.X.X.0/24 29-05-2011 10:57:55 <WARN> Next hop address Y.Y.35.194 resolvable through recursive route for Y.Y.32.0/19 29-05-2011 10:57:55 <WARN> Next hop address X.X.X.241 resolvable through recursive route for X.X.X.0/24 29-05-2011 10:57:55 <WARN> Next hop address X.X.X.242 resolvable through recursive route for X.X.X.0/24 These are the subnets of the upstream trans-ip links of it's neigbor router On the second (neighbor) bgp router, noticed only such 15 recursive messages I had those upstream trans-ip interface IP's manually added once to the bird.conf with a "protocol static" definition with a subnet of /32. I thought this might be the problem, and wel, disabled those static trans-ip interface routes, except i forgot one. Noticed a lower CPU afterwards, but problem persisted, and i reverted to 1.2.4. Later i noticed i missed one static route to disable, but no time left to upgrade and test again. I think i should have looked at the recursive routes in bird, but i didn't. Does one know what was going on here, and what to do to prevent it when executing another upgrade? I created a 10.000 packet tcpdump capture (full size) of an iBGP session, in case somone would like to look at it. Regards, Arjan Filius -- Arjan Filius mailto:iafilius@xs4all.nl

4 7

how to confirm which capabilities have been negotiated
by Eiichiro Watanabe 24 Oct '11

24 Oct '11

Hello, Do we have an appropriate command to show which BGP capabilities have been negotiated on bird after a peer has been established? Of course, I known I can recognize when I look into packets captured, or confirm it on the neighbor router by using "show ip bgp neighbor x.x.x.x" command (in the case of CiscoIOS). it wouldn't be smart. Thanks, eiichiro -- ################################################### Eiichiro Watanabe Internet Multifeed Co.

4 5

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

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