August 2012 - Bird-users

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

Repeated log OSPF LSA disappeared
by Internet Expert s.r.o. - Žichovský Pavel 09 Oct '12

09 Oct '12

Hi, I'm new with Bird. Currently we have deployed it on one router for OSPF. Everything works fine, until one interface on other router in OSPF network went down.

4 3

bird 1.3.8 vs 1.3.6
by fredrik danerklint 10 Sep '12

10 Sep '12

Hi! Is there something with these versions that is not compatibly with each other for the ospf to work in ipv6? Right now I have a bird 1.3.8 instance neither announce nor getting an routes in a area. It is stuck in the exchange state. The ip4 versions also get stuck in the loading state for a while and then continue. (during the loading state the routes are announced to the others - so it's working somewhat). -- //fredan

2 3

Re: BIRD v1.3.8 - some notes and hamradio requests
by Ondrej Zajicek 31 Aug '12

31 Aug '12

On Tue, Aug 28, 2012 at 02:33:44PM +0200, Gustavo Ponza wrote: > Eureka! that patch *definitively* solved the above problem, too :) > The BIRD behavior is now *perfectly* equal to that of quagga and > the Mikrotik and so, for me, no other limitations to run exclusively > the BIRD program. > Then, that patch *MUST* definitively enter on the official BIRD > release. It probably will. >> 1) your only activated interfaces in config file were ppp0, tap0 and eth0, >> therefore no reason to propagate 44.134.33.71/32, which is just on sl0. >> You probably want to activate these ifaces as stub ifaces ('stub' option >> for them). > > My tests confirm that: declaring an 'iface' as a 'stub' is perfectly > equal to *not activate* that 'iface', at least this happens on the OSPF > environment. As result I obtained no OSPF activity and no prefix > prefix propagation. Not true. Interface as stub propagate its addresses to OSPF (at least if it is normal broadcast iface with normal IP prefix, ptp ifaces are a bit special), while not active iface is just ignored. >> ifaces. BTW, from the log i see that BIRD misdetected AX.25 interfaces - >> ifconfig says that they can't support multicast while BIRD says the can. > > About the disagreement between the BIRD detection and the ifconfig > output that should be a good question for the AX.25 linux developers > so, as time permits, I'll try to contact one of them. It is probably a bug in BIRD. >> Note that you can also simply add local IP or prefix for propagation >> using 'stubnet' option. The simplest way to see what your router >> is propagating is to find it in 'show ospf state'. > > I was not able to setup a 'stubnet' command to test that feature :( > no examples found on the documentation and so any setup attempts got > the reply: errors on configuration file... You can use it like: area 0.0.0.0 { stubnet 192.168.11.0/24; stubnet 192.168.12.0/24 { hidden; summary; }; }; It is documented here: http://bird.network.cz/?get_doc&f=bird-6.html#ss6.5 > But, in the meantime, since I can monitor the exported routes also > on the Mikrotik router, I discovered that my LAN prefix 192.168.1.0/ > /24 results propagated by the OSPF (FYI on quagga it does not), so, > how can I stop the propagation of such a prefix? (and naturally for > any other prefix I do not want to export). Yes, it is propagated because it is on eth0, which is activated for OSPF. You can either activate eth0 just for some of its addresses: interface "eth0" 192.168.2.0/24 { ... } see examples in here: http://bird.network.cz/?get_doc&f=bird-3.html#dsc-iface or you could suppress that prefix for propagation using stubnet option: stubnet 192.168.1.0/24 { hidden; } But this will not work if there is some other OSPF router connected through 192.168.1.0/24, but that is probably not an issue here. -- 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

bird 1.3.7 setting incorrect nexthop on FreeBSD
by Виталий Туровец 31 Aug '12

31 Aug '12

Hello there, people! I have a strange moment with bird's behaviour on FreeBSD 9.0-RC3 (FreeBSD 9.0-RC3 i386 GENERIC): It establishes BGP sessions, succesfully exchanges routes and when exporting them to kernel sets 127.0.0.1 via lo0 as next hop. An example: bird> show route all 192.168.2.0/24 192.168.2.0/24 unreachable [Cisco 22:11 from 172.16.0.252] * (100/-) [AS65002i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 65002 BGP.next_hop: 172.16.0.252 BGP.med: 0 BGP.local_pref: 100 BGP.community: (65001,252) bird> show route all export kernel1 192.168.2.0/24 192.168.2.0/24 unreachable [Cisco 22:11 from 172.16.0.252] * (100/-) [AS65002i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 65002 BGP.next_hop: 172.16.0.252 BGP.med: 0 BGP.local_pref: 100 BGP.community: (65001,252) [22:11][border][~] # netstat -rn -f inet | grep 192.168.2.0 192.168.2.0/24 127.0.0.1 UR1 0 8 lo0 [22:15][border][~] # route get 192.168.2.1 route to: 192.168.2.1 destination: 192.168.2.0 mask: 255.255.255.0 interface: lo0 flags: <UP,REJECT,DONE,PROTO1> recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 16384 1 0 And from the other side there's Cisco's router (the problem also persists on BGP between bird and quagga): OfficeCisco#show ip bgp neighbors 172.16.0.253 advertised-routes | in 192.168.2 *> 192.168.2.0 172.16.0.38 0 0 65002 i OfficeCisco#show ip route 192.168.2.0 255.255.255.0 Routing entry for 192.168.2.0/24 Known via "bgp 65001", distance 20, metric 0 Tag 65002, type external Last update from 172.16.0.38 3d02h ago Routing Descriptor Blocks: * 172.16.0.38, from 172.16.0.38, 3d02h ago Route metric is 0, traffic share count is 1 AS Hops 1 This same route with exactly same settings is also advertised to another FreeBSD box running quagga and the route is correctly handled and installed with correct nexthop: [22:21][db][~] $ netstat -rn -f inet | grep 192.168.2.0 192.168.2.0/24 172.16.0.252 UG1 0 1475392 LAN [22:21][db][~] $ s vtysh -c 'sh ip bgp 192.168.2.0/24' BGP routing table entry for 192.168.2.0/24 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 65002 172.16.0.252 (metric 1) from 172.16.0.252 (192.168.0.2) Origin IGP, metric 0, localpref 100, valid, internal, best Last update: Thu Aug 30 10:56:20 2012 My BGP neighbors and kernel configuration here: protocol kernel { learn; persist; scan time 10; import all; export where source = RTS_BGP; } protocol static AS65001 { description "Nets that we export"; route 192.168.0.0/24 reject; route 192.168.1.0/24 reject; route 172.16.0.248/29 reject; route 95.158.3.122/32 reject; route 0.0.0.0/0 reject; } filter bgp_from_db{ if net = 0.0.0.0/0 then { reject; }else{ bgp_community=add(bgp_community,(65001,253)); accept; } } filter bgp_from_cisco{ if net = 0.0.0.0/0 then { reject; }else{ bgp_community=add(bgp_community,(65001,252)); accept; } } filter bgp_to_db { if proto="AS65001" then { bgp_community=add(bgp_community,(65001,254)); accept; } else reject; } filter bgp_to_cisco { if net ~ 192.168.1.0/24 then reject; if proto="AS65001" then { bgp_community=add(bgp_community,(65001,254)); accept; } else reject; } protocol bgp DB { description "DB Server"; local as 65001; neighbor 172.16.0.253 as 65001; import filter bgp_from_db; export filter bgp_to_db; } protocol bgp Cisco { description "Office<->Service 2620"; local as 65001; neighbor 172.16.0.252 as 65001; import filter bgp_from_cisco; export filter bgp_to_cisco; } And this is what bird shows in log: 30-08-2012 22:25:35 <TRACE> kernel1: 192.168.2.0/24: seen 30-08-2012 22:25:35 <TRACE> kernel1: Pruning table master 30-08-2012 22:25:35 <TRACE> kernel1: Pruning inherited routes 30-08-2012 22:25:45 <TRACE> device1: Scanning interfaces 30-08-2012 22:25:45 <TRACE> kernel1: Scanning routing table 30-08-2012 22:25:45 <TRACE> Setting fib to 0 for route dump 30-08-2012 22:25:45 <TRACE> kernel1: 0.0.0.0/0: [alien] seen 30-08-2012 22:25:45 <TRACE> kernel1: 95.158.3.120/29: ignored 30-08-2012 22:25:45 <TRACE> kernel1: 95.158.3.122/32: [alien] seen 30-08-2012 22:25:45 <TRACE> kernel1: 95.158.3.123/32: seen 30-08-2012 22:25:45 <TRACE> kernel1: 172.16.0.0/27: seen 30-08-2012 22:25:45 <TRACE> kernel1: 172.16.0.36/30: seen 30-08-2012 22:25:45 <TRACE> kernel1: 172.16.0.248/29: ignored 30-08-2012 22:25:45 <TRACE> kernel1: 172.16.0.254/32: [alien] seen 30-08-2012 22:25:45 <TRACE> kernel1: 192.168.0.0/24: ignored 30-08-2012 22:25:45 <TRACE> kernel1: 192.168.0.1/32: [alien] seen 30-08-2012 22:25:45 <TRACE> kernel1: 192.168.0.4/32: seen 30-08-2012 22:25:45 <TRACE> kernel1: 192.168.1.0/24: ignored 30-08-2012 22:25:45 <TRACE> kernel1: 192.168.1.1/32: [alien] seen 30-08-2012 22:25:45 <TRACE> ... 30-08-2012 22:25:45 <TRACE> kernel1: 192.168.2.0/24: seen 30-08-2012 22:25:45 <TRACE> kernel1: Pruning table master 30-08-2012 22:25:45 <TRACE> kernel1: Pruning inherited routes Thank you guys for help! -- ~~~ WBR, Vitaliy Turovets Systems Administrator Corebug.Net +38(093)265-70-55 VITU-RIPE

2 2

bird and OSPF on p2p
by Eugene M. Zheganin 30 Aug '12

30 Aug '12

Hi, guys ! I'm trying to use bird/OSPF on a bunch of gre tunnels. Though I'm using it successfully with ipv6 on same tunnels, I have no clue why it doesn't announce the networks when on ipv4. My typical setup is as follows: VPN HUB <-----WAN/gre/OSPF-----> branch router <--local-network--> At this time VPN HUB runs quagga/ospfd (due to this problem I'm talking about). I receive all the routing updates from HUB on a branch router, but HUB doesn't get anything from a branch router: HUB: # ifconfig gre14 gre14: flags=b051<UP,POINTOPOINT,RUNNING,LINK0,LINK1,MULTICAST> metric 0 mtu 1476 tunnel inet 192.168.3.24 --> 192.168.6.191 inet 172.16.3.134 --> 172.16.3.135 netmask 0xffffffff inet6 fe80::21a:64ff:fe21:8e80%gre14 prefixlen 64 scopeid 0x2b nd6 options=3<PERFORMNUD,ACCEPT_RTADV> # vtysh [...] sh ip ospf nei [...] 192.168.6.191 1 Full/DROther 38.434s 172.16.3.135 gre14:172.16.3.134 0 0 0 # route -n get 192.168.9.0/27 route: writing to routing socket: No such process Branch: # birdc -s /var/run/bird.ctl BIRD 1.3.8 ready. bird> show ospf neighbors ospfv4: Router ID Pri State DTime Interface Router IP 192.168.3.24 1 full/ptp 00:33 gre0 172.16.3.134 bird> sh route protocol direct1 192.168.6.128/25 dev vr2 [direct1 14:02] * (240) 192.168.9.0/27 dev bridge0 [direct1 14:02] * (240) 172.16.3.134/32 dev gre0 [direct1 14:02] * (240) bird> sh route filter exportospfv4 192.168.9.0/27 dev bridge0 [direct1 14:02] * (240) 172.16.3.134/32 dev gre0 [direct1 14:02] * (240) gre0: flags=b051<UP,POINTOPOINT,RUNNING,LINK0,LINK1,MULTICAST> metric 0 mtu 1476 tunnel inet 192.168.6.191 --> 192.168.3.24 inet 172.16.3.135 --> 172.16.3.134 netmask 0xffffffff inet6 fe80::20d:b9ff:fe20:d980%gre0 prefixlen 64 tentative scopeid 0x9 nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> Thanks. Eugene.

4 12

OSPFv3: link-local address required on loopback interface?
by Tore Anderson 29 Aug '12

29 Aug '12

I've run across a rather weird behaviour in BIRD 1.3.8 regarding the interaction between address(es) on the loopback interface and the OSPFv3 protocol. It seems that if there's no link-local address on the interface, BIRD fails to run OSPF in stub mode on it: $ birdc6 show interfaces BIRD 1.3.8 ready. lo up (index=1) MultiAccess AdminUp LinkUp Loopback Ignored MTU=16436 ::1/128 (Primary, scope host) 2001:db8:1::3/128 (Unselected, scope univ) [...] $ birdc6 show ospf interface \"lo\" BIRD 1.3.8 ready. ospf1: $ ip -6 address add fe80::/64 scope link dev lo $ birdc6 show ospf interface \"lo\" BIRD 1.3.8 ready. ospf1: Interface lo (IID 0) Type: nbma Area: 47.4.0.0 (788791296) State: waiting (stub) Priority: 1 Cost: 10 Hello timer: 10 Poll timer: 20 Wait timer: 40 Dead timer: 40 Retransmit timer: 5 Designed router (ID): 0.0.0.0 Designed router (IP): :: Backup designed router (ID): 0.0.0.0 Backup designed router (IP): :: $ birdc6 show interfaces BIRD 1.3.8 ready. lo up (index=1) MultiAccess AdminUp LinkUp Loopback Ignored MTU=16436 2001:db8:1::3/128 (Primary, scope univ) ::1/128 (Unselected, scope host) fe80::/64 (Unselected, scope link) [...] Question: What does «Ignored» imply here? Also, why did the «Primary» address change as a result of fe80:: being added? In any case, this means that without a link-local address being manually added to the loopback interface, the primary address of the router won't be reachable from the rest of the network, in turn causing problems for monitoring and possibly other protocols like iBGP. This must be a bug, right? Being able to import the loopback interface of a router as a stub network into the IGP is pretty fundamental functionality. Also, link-local addresses aren't typically seen on loopback interfaces, so expecting them to be there doesn't make much sense to me. My configuration is as follows: protocol device { scan time 10; } protocol kernel { scan time 10; learn; export all; import all; } protocol ospf { area 47.4.0.0 { interface "bond0" { type broadcast; }; interface "*" { stub yes; }; }; } -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com

2 3

Several ptmp OSPF sessions over a single interface
by Ruben Laban 29 Aug '12

29 Aug '12

Hello, I'm currently performing some experiments to find the "best" way to inter-connect a bunch of routers using a shared medium. A common scenario would be a set of 4 routers, for instance a pair of border routers and a pair of core routers. I'd like either a full-mesh or circle topology. Putting all nodes in a /29 isn't ideal because of the DR/BDR/etc stuff. I want all nodes and links to be treated equally. Using point-to-multipoint sounds like a decent solution. I can configure several sessions on a single link without interference, up to the point where the circle is created. Like this: A - B | | D - C However, if I try to add a link between A and C, things start to go not as expected. A already has 192.168.255.2/31 (towards B) and 192.168.255.4/31 (towards D) configured. If I add 192.168.255.10/31 (towards C) and 192.168.255.11/31 on C (towards A), A and C can't ping each other using those addresses. This is because A will announce 192.168.255.10/32 throughout the area and thus "overriding" the 192.168.255.10/31 route on C (traffic will would be sent to either B or D, and not directly to A). What would be the cleanest solution for this? Regards, Ruben Laban

2 8

BIRD cpu usage overload - question
by Javor Kliachev 24 Aug '12

24 Aug '12

3 3

Re: Bird and OpenBSD
by Miłosz Oller 24 Aug '12

24 Aug '12

Configure is OK. When I try to run make, I have: # make "Rules", line 44: Need an operator "Rules", line 48: Need an operator "Rules", line 50: Need an operator "Rules", line 55: Need an operator "Rules", line 64: Need an operator "Rules", line 73: Need an operator "Rules", line 81: Missing dependency operator "Rules", line 82: Could not find depend "Rules", line 83: Need an operator "Rules", line 85: Need an operator Fatal errors encountered - cannot continue -- Miłosz Oller Dnia 2012-08-24, pią o godzinie 00:35 +0200, Crest pisze: > On 24.08.2012 00:26, Miłosz Oller wrote: > > Hi > > > > How can I install BIRD on OpenBSD? In ports is only version 1.3.6. > > In FreeBSD Ports is 1.3.8. > > > Install the dependecies and compile BIRD from source without the ports > infrastructure.

2 2