- Bird-users - Mailing Lists

Socket error: TCP_MD5SIG: Cannot allocate memory
by 穴澤正恒 26 Dec '19

26 Dec '19

Dear all, My name is Masatsune Anazawa, an affiliate of JPIX. We are verifying the root server that is being considered for installation on JPIX. When MD5 authentication is performed on bird and 1000 peers are set, the following error occurs and only 150 to 300 peers can be established. Please let me know if there is a solution. I’m looking forward to your reply. /var/log/messages ------------------------------------------------------------------------------------------- Dec 18 16:23:28 rs-bird bird: AS2855_IPv6: Socket error: TCP_MD5SIG: Cannot allocate memory Dec 18 16:23:28 rs-bird bird: AS2854_IPv6: Socket error: TCP_MD5SIG: Cannot allocate memory Dec 18 16:23:28 rs-bird bird: AS2853_IPv6: Socket error: TCP_MD5SIG: Cannot allocate memory Dec 18 16:23:28 rs-bird bird: AS2852_IPv6: Socket error: TCP_MD5SIG: Cannot allocate memory Dec 18 16:23:28 rs-bird bird: AS2851_IPv6: Socket error: TCP_MD5SIG: Cannot allocate memory Dec 18 16:23:28 rs-bird bird: AS2850_IPv6: Socket error: TCP_MD5SIG: Cannot allocate memory Dec 18 16:23:28 rs-bird bird: AS2849_IPv6: Socket error: TCP_MD5SIG: Cannot allocate memory Dec 18 16:23:28 rs-bird bird: AS2848_IPv6: Socket error: TCP_MD5SIG: Cannot allocate memory Dec 18 16:23:28 rs-bird bird: AS2847_IPv6: Socket error: TCP_MD5SIG: Cannot allocate memory Dec 18 16:23:28 rs-bird bird: AS2846_IPv6: Socket error: TCP_MD5SIG: Cannot allocate memory Dec 18 16:23:28 rs-bird bird: AS2845_IPv6: Socket error: TCP_MD5SIG: Cannot allocate memory Dec 18 16:23:28 rs-bird bird: AS2844_IPv6: Socket error: TCP_MD5SIG: Cannot allocate memory Dec 18 16:23:28 rs-bird bird: AS2843_IPv6: Socket error: TCP_MD5SIG: Cannot allocate memory Dec 18 16:23:28 rs-bird bird: AS2842_IPv6: Socket error: TCP_MD5SIG: Cannot allocate memory Dec 18 16:23:28 rs-bird bird: AS2841_IPv6: Socket error: TCP_MD5SIG: Cannot allocate memory Dec 18 16:23:28 rs-bird bird: AS2840_IPv6: Socket error: TCP_MD5SIG: Cannot allocate memory Dec 18 16:23:28 rs-bird bird: AS2839_IPv6: Socket error: TCP_MD5SIG: Cannot allocate memory Dec 18 16:23:28 rs-bird bird: AS2838_IPv6: Socket error: TCP_MD5SIG: Cannot allocate memory ------------------------------------------------------------------------------------------- -- ----------------------------------------- 株式会社 Hoster-JP (HJP) Masatsune Anazawa (穴澤　正恒) http://www.hoster.jp Mail: ma-anazawa(a)hoster.jp TEL: 03-5977-0888 FAX：03-5977-0887 113-0021 東京都文京区本駒込6-5-3 ビューネ本駒込3F -----------------------------------------

2 2

Bgp: gr_time in configure file can change gr_flag
by cjt 24 Dec '19

24 Dec '19

Hello I find that the graceful restart time number configuration can accept 32bits. bgp_proto GRACEFUL RESTART TIME expr ';' { BGP_CFG->gr_time = $5; } While in the RFC 4724 section 3 it says the graceful restart time is 12bits and restart flags is 4bits. +--------------------------------------------------+ | Restart Flags (4 bits) | +--------------------------------------------------+ | Restart Time in seconds (12 bits) | +--------------------------------------------------+ | Address Family Identifier (16 bits) | +--------------------------------------------------+ | Subsequent Address Family Identifier (8 bits) | +--------------------------------------------------+ | Flags for Address Family (8 bits) | +--------------------------------------------------+ so ,when I set the graceful restart time like 32768.，it will cover the gr_flag. Becasue ,in the bgp_write_capabilites() function ，it first put the gr_time in. Then use "|" to put gr_flags. This will casue the value in gr_time first four bits keep in the gr_flags。 put_u16(buf, caps->gr_time); buf[0] |= caps->gr_flags; Also ，I have find in RFC 4724，it required gr_flag expect the first bit ,the remaining bits are reserved and MUST be set to zero by the sender and ignored by the receiver. gr_time in the configure also can change the remaining bits. Meanwhile, in the bgp_read_capabilites() function, it use "& 0xf0" will remain the wrong 4 bits. caps->gr_flags = pos[2] & 0xf0; caps->gr_time = get_u16(pos + 2) & 0x0fff; I try this on the bird 2.0.7 Thanks Jingting Chen

1 0

Long io loop / missing netlink messages
by Nico Schottelius 22 Dec '19

22 Dec '19

Good morning, on a fresh new router running the full routing table, with Alpine, Linux 4.19.80-0-vanilla, bird-2.0.7 I see a lot of these messages: Dec 21 12:37:15 router1 daemon.warn bird: Kernel dropped some netlink messages, will resync on next scan. Dec 21 12:37:34 router1 daemon.warn bird: I/O loop cycle took 5000 ms for 1 events Dec 21 12:38:14 router1 daemon.warn bird: Kernel dropped some netlink messages, will resync on next scan. Dec 21 12:38:35 router1 daemon.warn bird: I/O loop cycle took 5328 ms for 1 events Dec 21 12:38:54 router1 daemon.warn bird: I/O loop cycle took 5013 ms for 1 events Dec 21 12:39:07 router1 daemon.warn bird: Kernel dropped some netlink messages, will resync on next scan. Dec 21 12:39:14 router1 daemon.warn bird: I/O loop cycle took 5053 ms for 1 events Dec 21 12:39:34 router1 daemon.warn bird: Kernel dropped some netlink messages, will resync on next scan. Dec 21 12:40:14 router1 daemon.warn bird: I/O loop cycle took 5041 ms for 1 events [12:49] router1.place6:~# ip -6 r | wc -l; ip r | wc -l 78212 779342 With "debug latency;" I get the following additional messages: Dec 21 12:54:31 router1 daemon.warn bird: Event 0x000055a21afb8144 0x0000000000000000 took 4449 ms Dec 21 12:54:52 router1 daemon.warn bird: Event 0x000055a21afb8144 0x0000000000000000 took 5608 ms The system is overall idle with bird spiking to 50-100% cpu usage every couple of seconds. I first thougt they are only logged after stating bird (where it might make sense), but the events continue to be logged around every 30s: Dec 21 13:04:11 router1 daemon.warn bird: Event 0x000055a21afb8144 0x0000000000000000 took 4596 ms Dec 21 13:04:32 router1 daemon.warn bird: Event 0x000055a21afb8144 0x0000000000000000 took 5096 ms Dec 21 13:04:52 router1 daemon.warn bird: Event 0x000055a21afb8144 0x0000000000000000 took 5102 ms Dec 21 13:05:11 router1 daemon.warn bird: Event 0x000055a21afb8144 0x0000000000000000 took 4676 ms Dec 21 13:05:31 router1 daemon.warn bird: Event 0x000055a21afb8144 0x0000000000000000 took 4645 ms Which might loosely correlate to the scan time "20" that is setup for device and kernel protocols. How do I best debug this issue? Best, Nico -- Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch

2 2

bird2 package for debian broken
by Christoph 19 Dec '19

19 Dec '19

Hello, the bird2 package from bird.network.cz for debian buster appears to be broken: > apt install bird2 > Reading package lists... Done > Building dependency tree > Reading state information... Done > The following NEW packages will be installed: > bird2 > 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. > Need to get 0 B/640 kB of archives. > After this operation, 1,327 kB of additional disk space will be used. > Selecting previously unselected package bird2. > (Reading database ... 35407 files and directories currently installed.) > Preparing to unpack .../bird2_2.0.6-1+0~20190916.13+debian10~1.gbp14a7a6_amd64.deb ... > Unpacking bird2 (2.0.6-1+0~20190916.13+debian10~1.gbp14a7a6) ... > Setting up bird2 (2.0.6-1+0~20190916.13+debian10~1.gbp14a7a6) ... > Error: The new file /usr/share/doc/bird2/examples/bird.conf does not exist! > dpkg: error processing package bird2 (--configure): > installed bird2 package post-installation script subprocess returned error exit status 1 > Processing triggers for man-db (2.8.5-2) ... > Processing triggers for systemd (241-7~deb10u1) ... > Errors were encountered while processing: > bird2 > E: Sub-process /usr/bin/dpkg returned an error code (1)

3 4

Route preference for one address
by kc atgb 17 Dec '19

17 Dec '19

Hello, I started using bird some days ago from zero knowledge. With the different docs I found all around I understand a little bit more how that works. My configuration is made of 2 sites connected by 2 seperated links. Each link have a dedicated vpn connection for internal routing. One nominal link and one backup. In case of failure, the switch from one link to the other is working. What I want to do now, is to force the routing for one specific address (/32) via the backup link whereas the rest of the /24 is using the first one. And in case of failure of the backup link, the /32 should use the first one. I tried different things and from what I have found, my configuration is working partially. I mean there is no fallback to the first link if the second is in failed state. I tried with static routing and export filter. With static: protocol static s_special { import all; route 192.168.1.78/32 via 10.194.11.2 { preference = 250; }; } The route stays active when the link is down so the traffic can not go back to source. With filter: filter export2kernel { if net = 192.168.1.78/32 then ifname = "tun1"; accept; } The same thing happens. I took a look also to preference/cost/... but I am unable to achieve what I am looking to do. So my question, what should I look for to have this working like explained ? What information should I provide if it is not clear ? Thanks in advance, Kay

2 5

Best practices for redundant iBGP/eBGP route distribution? [bird 2.0.7]
by Nico Schottelius 16 Dec '19

16 Dec '19

Good morning, I was wondering, what is the best practice is for running 2 data centers, each with one uplink and a dark fiber in between them? I think it's pretty much a standard situation, but will show our setup and assumptions as well: upstream 1 upstream 2 | | dc1--darkfiber----dc 2 Additional each DC has 2 routers: dc1: dc2: |---router1 ------- router 1 | / | / | /--------/ | router2---------router2 | | |---------------------| (both routers are connected to each other and both routers are connected to each upstream) The objective is to stay online in each DC as long as possible, so in theory: - upstream 1 can die or - upstream 2 can die or - the darkfiber can die And in each of the situations, both DCs should still be reachable from outside and both be reaching itself. Question 1: Is "direct;" is the right protocol for all links? As all links are layer 2 connections, we have configured all links to be direct. However this causes the "Invalid NEXT_HOP attribute" in various situations. Question 2: Is "next hop self ebgp;" the correct answer to the Invalid NEXT_HOP attribute? This way we rewrote routes from upstreams and generally speaking it seems to work. However, this still fails iBGP routes: router1.dc1 cannot reach a network in dc2 that is configured to be statically routed to another host in dc2. My assumption is that this is the problem of the "gateway direct" resolution, even though the documentation kind of indicates that this should be resolved via the next hop of the dc2. Originally I'd have thought that not even "next hop self ebgp" is required, as the next hop attribute is coming from the peering router, so the route should be directly reachable. Question 3: Is "not direct" (aka multiphop) the right thing for iBGP? So our dcs are directly connected vi layer 2, but the default for iBGP is multihop. If we omit the "direct" keyword, the result is that no routes are in the end imported from the other DC and that we get various warnings like the following in syslog: Dec 16 00:58:35 router2 daemon.warn bird: Next hop address 2a0a:e5c0:1:8::5 resolvable through recursive route for 2a0a:e5c0:1:8::/64 So at this stage it's a bit unclear to me, how proper iBGP redistribution / next hop resolution should work with bird. Question 4: How to (not) announce umbrella networks? So both data centers are reachable within the 2a0a:e5c0::/29 prefix and all routers have a statement route 2a0a:e5c0::/29 unreachable; in the static protocol. However if the dark fiber goes down, it is not clear that / how the upstreams should / will propagate the smaller (per DC) /48s. If we remove the full /29 announcement, we might run into the problem that a packet is being sent out through one upstream and returns back to us and thus creates a routing loop. While the last question is eBGP specific, the main question of this thread still is: how do you correctly distribute internal and external routes via iBGP in your DCs? Thanks for any hints in the right direction. Best regards, Nico -- Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch

2 10

Prefix not making it through two iBGP sessions
by Brooks Swinnerton 14 Dec '19

14 Dec '19

Hello, I'm having trouble understanding why certain routes aren't making it through to an iBGP session on BIRD 2.0.7. My network layout looks something like below. I have three BIRD instances running, *Router 1* is connected to *Upstream 1*, *Router 2* is connected to *Upstream 2*, and *Router 1* and *Router 2* are connected to each other via iBGP. This all works great. Upstream 1 Upstream 2 ▲ ▲ | | eBGP eBGP | | Router 1 ◀--iBGP--▶ Router 2 | iBGP | ▼ Router 3 The problem comes with *Router 3* not receiving routes from *Router 2*. The iBGP export filter on router1 looks like this: export filter { if is_v4_bogon() then reject; if is_v4_default() then reject; if is_v4_peering_net() then reject; if is_v4_own_net() then accept; if source = RTS_BGP then accept; reject; }; And if I test each of these functions out manually I can see the prefix should be allowed through: bird> show route filter { if is_v4_bogon() then reject; } 174.202.0.0/16 bird> show route filter { if is_v4_default() then reject; } 174.202.0.0/16 bird> show route filter { if is_v4_peering_net() then reject; } 174.202.0.0/16 bird> show route filter { if is_v4_own_net() then accept; } 174.202.0.0/16 bird> show route filter { if source = RTS_BGP then accept; } 174.202.0.0/16 Table master4: 174.202.0.0/16 unicast [cologuard4 21:17:56.850 from 169.254.3.3] * (100) [AS22394?] dev bdr-cologuard Unfortunately if I look at the session from *Router 1* to *Router 3* (core_nyiix_14), it is not let through: bird> show route export core_nyiix_14 174.202.0.0/16 bird> I've added all of the relevant configuration in this Gist <https://gist.github.com/bswinnerton/6b7527bc9d78215275c1ae75e64d34cd>. Any help would be much appreciated.

1 1

Making bulk CLI queries / CLI performance / bird-bulk tool in Python
by Baptiste Jonglez 12 Dec '19

12 Dec '19

Hi, For a research project, I need to query routes through the Bird CLI around 10k times per second. To do this, I wrote a small Python tool that talks to the Bird CLI over its Unix socket and parses CLI replies. For anyone interested, the first version of the code is here: https://github.com/jonglezb/bird-bulk The parsing code is not terribly efficient and it would be much faster in C or Go, but it's fast enough for my needs: it can perform 17k queries per second on a Bird daemon with a full BGP view. Out of curiosity, I started several instances of my benchmark script in parallel, and Bird maxed out at 50k queries per second. This is quite impressive considering that it is loaded with almost 800k routes. Conclusion: Bird *is* efficient :) Let me know if you are interested in re-using this code, I can package it properly in pip. Regards, Baptiste

1 0

rejected by protocol <prefix> unicast
by wax xitau 11 Dec '19

11 Dec '19

Hi, Prefixes sent over a eBGP session are getting rejected "by protocol" as can be seen in the logs below. The prefixes are "added" and then get "rejected" by protocol. This means that they are visible using the "show route protocol <protocol>" but not "show route all" (and therefore impossible to push them to the kernel routing table). // logs 2019-12-10 21:15:00.774 <TRACE> pe1: BGP session established 2019-12-10 21:15:00.774 <TRACE> pe1: State changed to up 2019-12-10 21:15:00.774 <TRACE> pe1: Sending END-OF-RIB 2019-12-10 21:15:00.984 <TRACE> pe1: Got UPDATE 2019-12-10 21:15:00.984 <TRACE> pe1 > *added [best] 10.2.34.0/24 <http://10.2.34.0/24> unicast* 2019-12-10 21:15:00.984 <TRACE> pe1 < *rejected by protocol 10.2.34.0/24 <http://10.2.34.0/24> unicast* 2019-12-10 21:15:00.984 <TRACE> pe1: Got UPDATE 2019-12-10 21:15:00.984 <TRACE> pe1 > *added [best] 10.1.12.0/24 <http://10.1.12.0/24> unicast* 2019-12-10 21:15:00.984 <TRACE> pe1 < *rejected by protocol 10.1.12.0/24 <http://10.1.12.0/24> unicast* 2019-12-10 21:15:00.984 <TRACE> pe1: Got UPDATE 2019-12-10 21:15:00.984 <TRACE> pe1: Got END-OF-RIB Tcp dump of the corresponding update message(s): // tcpdump 21:18:59.652705 IP (tos 0xc0, ttl 1, id 7035, offset 0, flags [none], proto TCP (6), length 177) *192.168.254.1*.bgp > 192.168.254.0.41073: Flags [P.], cksum 0x4356 (correct), seq 83:208, ack 73, win 16384, options [nop,nop,TS val 2249949122 ecr 1355158152], length 125: BGP Update Message (2), length: 51 Origin (1), length: 1, Flags [T]: IGP 0x0000: 00 AS Path (2), length: 10, Flags [T]: 65001 65500 0x0000: 0202 0000 fde9 0000 ffdc Next Hop (3), length: 4, Flags [T]: 192.168.254.1 0x0000: c0a8 fe01 Updated routes: 10.1.12.0/24 Update Message (2), length: 51 Origin (1), length: 1, Flags [T]: Incomplete 0x0000: 02 AS Path (2), length: 10, Flags [T]: 65001 65500 0x0000: 0202 0000 fde9 0000 ffdc Next Hop (3), length: 4, Flags [T]: *192.168.254.1* 0x0000: c0a8 fe01 Updated routes: 10.2.34.0/24 Update Message (2), length: 23 End-of-Rib Marker (empty NLRI) The bgp session is over directly connected interfaces and the NLRI prefix next hops are therefore directly connected. // Configuration: protocol bgp pe1 { debug all; description "ebgp"; hold time 90; local 192.168.254.0 as my_asn; neighbor 192.168.254.1 as peer_asn; direct; interpret communities off; ipv4 { table t_pe1; import all; export none; gateway direct; }; } protocol device { scan time 10; }; protocol direct { ipv4; }; protocol kernel { scan time 10; learn; persist; ipv4 { import filter { if net ~ [0.0.0.0/0, 192.168.255.0/24] then reject; }; }; } // relevant show results bird> *show route protocol pe1* Table t_pe1: *10.2.34.0/24 <http://10.2.34.0/24>* unicast [pe1 21:46:13.530] * (100) [AS65500?] via 192.168.254.1 on ens5 *10.1.12.0/24 <http://10.1.12.0/24>* unicast [pe1 21:46:13.530] * (100) [AS65500i] via 192.168.254.1 on ens5 bird> bird> *show route all* Table master4: 172.16.0.11/32 unicast [rt_nh 20:25:25.379] * (200) via 192.168.254.1 on ens5 Type: static univ 192.168.254.2/31 unicast [direct1 20:56:03.498] * (240) dev ens6 Type: device univ 192.168.254.0/31 unicast [direct1 20:56:03.498] * (240) dev ens5 Type: device univ 192.168.255.0/24 unicast [direct1 20:56:03.498] * (240) dev ens4 Type: device univ 172.16.0.33/32 unicast [rt_nh 20:25:25.379] * (200) via 192.168.254.3 on ens6 Type: static univ Thanks,

4 7

Show route across multiple route tables
by Logan Rawlins 09 Dec '19

09 Dec '19

Is there a way to utilize show route where statements to look for routes across many routing tables and return all matches ? Sent from my iPhone

3 2