- Bird-users - Mailing Lists

incorrect memory usage reporting
by Job Snijders 29 Jun '14

29 Jun '14

Hi all, I use a BIRD instance for route collection from ~ 50 full bgp feeds [1]. The 'show mem' command reports very ambitious results: job@lg01:~$ sudo birdc show mem BIRD 1.4.2 ready. BIRD memory usage Routing tables: 4294967294 GB Route attributes: 1540 MB ROA tables: 192 B Protocols: 311 kB Total: 0 GB job@lg01:~$ free -m total used free shared buffers cached Mem: 8759 4944 3815 0 187 366 -/+ buffers/cache: 4390 4369 Swap: 486 0 486 job@lg01:~$ Might there be a counter that wraps around? How can I help debug this? Kind regards, Job [1]: http://lg.ring.nlnog.net/summary/lg01/ipv4

2 2

Dynamic routes from OSPF disappear
by Gregor Kališnik 26 Jun '14

26 Jun '14

Hi. We have two routers and 7 machines with bird installed (7 machines <-> router <- Internet -> router <-> 8th machine) that work without problems. When I've added 8th machine with Ubuntu 14.04 and bird 1.4.3, everything was working for about one hour after all routes announced over OSPF disappeared, also own routes were not announced. By enabling debugging (debug ospf1 all in birdc) there are no messages that would indicate an error (just normal hello exchange and OSPF LSA announcements). By restarting the ospf1 protocol, the OSPF routes are exchanged and it works for another hour or so. Anybody experienced the same behavior? Best regards, Gregor Kališnik

2 8

Unnumbered interfaces and OSPF
by Vincent Bernat 26 Jun '14

26 Jun '14

Hi! I am trying to use unnumbered interfaces and OSPF. On one router: ip addr add 10.90.255.3/32 dev eth0 ip addr add 10.90.255.3/32 dev eth1 On the other: ip addr add 10.90.255.4/32 dev eth0 ip addr add 10.90.255.4/32 dev eth1 On both of them: protocol ospf INTERNAL { import all; export none; area 0.0.0.0 { networks { 10.90.255.3/32; 10.90.255.4/32; }; interface "eth0" { bfd yes; type ptp; }; interface "eth1" { bfd yes; type ptp; }; }; ecmp yes; } But: bird> show ospf INTERNAL: RFC1583 compatibility: disabled Stub router: No RT scheduler tick: 1 Number of areas: 1 Number of LSAs in DB: 2 Area: 0.0.0.0 (0) [BACKBONE] Stub: No NSSA: No Transit: No Number of interfaces: 2 Number of neighbors: 0 Number of adjacent neighbors: 0 Area networks: 10.90.255.4/32 Advertise Active 10.90.255.3/32 Advertise Active bird> show ospf interface INTERNAL: Interface eth0 (10.90.255.3/32) Type: ptp Area: 0.0.0.0 (0) State: ptp (stub) Priority: 1 Cost: 10 ECMP weight: 1 Hello timer: 10 Wait timer: 40 Dead timer: 40 Retransmit timer: 5 Interface eth1 (10.90.255.3/32) Type: ptp Area: 0.0.0.0 (0) State: ptp (stub) Priority: 1 Cost: 10 ECMP weight: 1 Hello timer: 10 Wait timer: 40 Dead timer: 40 Retransmit timer: 5 tcpdump shows me that no hello packets are tentatively transmitted. Why is the state of each interface marked as "stub"? I would expect each OSPF router to be able to discover itself through the PtP link. -- printk("What? oldfid != cii->c_fid. Call 911.\n"); 2.4.3 linux/fs/coda/cnode.c

2 2

ipv4 inside ipv6 for ospf
by Vasiliy Tolstov 25 Jun '14

25 Jun '14

Hi. Does bird supports http://tools.ietf.org/html/draft-ietf-ospf-ipv4-embedded-ipv6-routing-14 ? If yes, how can i configure it? -- Vasiliy Tolstov,

3 5

Behavior during OSPF premature aging
by Lennard Klein 25 Jun '14

25 Jun '14

Hi, When premature aging an LSA, bird seems to increase the LSA sequence number to its maximum (proto/ospf/lsupd.c line 616, in 1.4.3). RFC 2328 14.1 (page 156) states "An LSA can be flushed from the routing domain by setting its LS age to MaxAge, while leaving its LS sequence number alone, and then reflooding the LSA." While I don’t see a valid technical reason this should break, I seem to have a device in my network which ignores this updates LSA, I suspect it is doing an unsigned int comparison instead of a signed comparison. While I think the main fault lies with the other vendor, my question at this time is: what is the reasoning behind updating the sequence number to its maximum, even though the RFC says to leave it as-is? Regards, Lennard Klein This email is from Equinix (EMEA) B.V. or one of its associated companies in the territory from where this email has been sent. This email, and any files transmitted with it, contains information which is confidential, is solely for the use of the intended recipient and may be legally privileged. If you have received this email in error, please notify the sender and delete this email immediately. Equinix (EMEA) B.V.. Registered Office: Luttenbergweg 4, 1101 EC Amsterdam-Zuidoost, The Netherlands. Registered in The Netherlands No. 57577889.

2 1

bird 1.4.3 ospfv3 issue on openbsd
by Job Snijders 25 Jun '14

25 Jun '14

Hi all, I just upgraded from 1.4.0 to 1.4.3 (compiled from -current ports) on OpenBSD 5.5, now OSPFv3 adjecencies don't establish any longer, they remain stuck in exstart. I saw a thread a while ago about IPv6 issues on FreeBSD with 1.4.1, maybe this is related but the bug fix does not work on OpenBSD? syslog is filled with these messages: Jun 23 15:34:14 dcg-1 bird6: ospf1: Socket error on bnx0: Invalid argument Jun 23 15:34:24 dcg-1 last message repeated 6 times Jun 23 15:34:24 dcg-1 bird6: ospf1: Socket error on bnx2: Invalid argument Jun 23 15:34:24 dcg-1 bird6: ospf1: Socket error on bnx0: Invalid argument Jun 23 15:34:28 dcg-1 last message repeated 3 times this is my config: [root@dcg-1 ~]# cat /etc/bird6.conf log syslog all; router id 94.142.247.1; protocol kernel { scan time 20; export all; } protocol device { scan time 2; } protocol direct { interface "lo1"; interface "bnx0"; interface "bnx2"; } protocol static { route 2a02:898::/32 blackhole; } filter only_loopbacks { if net ~ [ 2a02:898:0:300:0:0:0:0/64{128,128} ] then accept; reject; } protocol ospf ospf1 { tick 2; rfc1583compat yes; import filter only_loopbacks; export filter only_loopbacks; area 0.0.0.0 { interface "bnx0", "bnx2" { hello 10; retransmit 2; wait 10; dead 40; type pointopoint; }; }; } [root@dcg-1 ~]# birdc6 show ospf nei BIRD 1.4.3 ready. ospf1: Router ID Pri State DTime Interface Router IP 195.85.225.5 128 exstart/ptp 00:34 bnx0 fe80::21f:12ff:fe1c:3482 Kind regards, Job

2 3

Re: Segmentation fault on EOR
by Ondrej Zajicek 21 Jun '14

21 Jun '14

On Sat, Jun 21, 2014 at 01:59:16AM +0400, Artyom Gavrichenkov wrote: > Hello Ondrej, > > 21.06.2014 01:15, Ondrej Zajicek ??????????: > >> In fact, this bug is not related to IPv6. It may appear even if bird > >> is used only for IPv4 routing, because multiprotocol extensions may be > >> also used in this case. > > > > Well, BIRD does not support IPv4 NLRI in multiprotocol extensions. > > This doesn't mean it may crash when the latter is sent to it, does it? No, regardless of this bug, they are just ignored as unknown route attributes. -- 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."

1 0

Re: Segmentation fault on EOR
by Ondrej Zajicek 20 Jun '14

20 Jun '14

On Fri, Jun 20, 2014 at 08:32:29PM +0400, Evgeny Uskov wrote: > Hello, > > No, the bug I'm talking about was not fixed. It can be easily > reproduced on any of the versions 1.4.1, 1.4.2, 1.4.3 (by sending the > UPDATE message from my previous letter). You are right, i conflated two different bugs. This one is already fixed but only in git: https://gitlab.labs.nic.cz/labs/bird/commit/66370eac1f88ec74b3017f1c39038d7… > In fact, this bug is not related to IPv6. It may appear even if bird > is used only for IPv4 routing, because multiprotocol extensions may be > also used in this case. Well, BIRD does not support IPv4 NLRI in multiprotocol extensions. -- 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."

1 0

Segmentation fault on EOR
by Evgeny Uskov 20 Jun '14

20 Jun '14

Hello, bird with version >= 1.4.1 has the following bug: it falls with segmentation fault when it receives certain BGP UPDATE messages. In particular, the problem is triggered by a message with attributes but without NLRI section. An example of such message is End-of-RIB marker (an empty UPDATE) with additional multiprotocol extension attributes (such as MP_UNREACH_NLRI): 0000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0010 00 1e 02 00 00 00 07 90 0f 00 03 00 01 01 The problem is caused by null pointer reference in the function bgp_set_next_hop: struct eattr *nh = ea_find(a->eattrs, EA_CODE(EAP_BGP, BA_NEXT_HOP)); ip_addr *nexthop = (ip_addr *) nh->u.ptr->data; If the case of the UPDATE message above, a->eattrs field is NULL, and hence nh is NULL too, resulting in SIGSEGV. In bird <= 1.4.0 this function is called in bgp_do_rx_update only when nlri_len != 0 (I'm not sure it's safe enough, but at least it doesn't cause this problem). However, in v1.4.1 this behavior has been changed, and now bgp_set_next_hop is called for every UPDATE message with positive attr_len + nlri_len.

2 1

about lo:0 interface
by 曾小小 20 Jun '14

20 Jun '14

hi My system is Ubuntu 13.04, kernel version is 3.8.0-21-generic, bird version is 1.3.10. I want to achieve lo: 0 (eg: 192.168.1.1/32) address as the route-id of the device, while learning through ospf routing protocol ip address to manage the device through this ip address. Configured as follows: 1: I'm on a device configured lo:0 interface address: ifconfig lo:0 192.168.1.1/32 root @ sr1 :/ usr / local / bird # ifconfig lo:0 lo: 0 Link encap: Local Loopback inet addr: 192.168.1.1 Mask: 0.0.0.0 UP LOOPBACK RUNNING MTU: 65536 Metric: 1 2: The bird in the configuration is as follows: In direct proto configured lo: 0 Interface protocol direct { interface "eth1", 192.168.1.1/32; } In the kernel configuration is as follows: protocol kernel { # Learn; # Learn all alien routes from the kernel # Persist; # Don't remove routes on bird shutdown device routes; scan time 15; # Scan kernel routing table every 15 seconds import none; # Default is import all export all; # Default is export none # Kernel table 5; # Kernel table to synchronize with (default: main) } The problem is found in bird default route pointing to the interface, and the interface address lo not found in the routing table, and why? bird> show interfaces 1001-lo up (index = 1) 1004 - MultiAccess AdminUp LinkUp Loopback Ignored MTU = 65536 1003 - 192.168.1.1 / 0 (Primary, scope univ) 127.0.0.1 / 8 (Unselected, scope host) root @ sr1 :/ usr / local / bird # birdc-v 0001 BIRD 1.3.10 ready. bird> show route 1007-0.0.0.0 / 0 dev lo [direct1 16:55] * (240) thanks.

2 1