- Bird-users - Mailing Lists

bird remote control - socket unexpectedly closed
by Kenth Eriksson 29 Apr '19

29 Apr '19

Hi! We are remote controlling a bird daemon using a unix domain socket. We have stumbled into an issue where it looks as bird closes the socket (application gets POLLHUP). Any known issues around this area? The pplication and bird daemon continues to run after this happens, but the socket is down. Thanks, Kenth

2 3

Bird 1.6.3 path prepending ?
by Pieter De Wit 27 Apr '19

27 Apr '19

Hi Everyone, I have been fighting with this now for a while and I can’t seem to get my paths prepended. I am running 1.6.3 from the Ubuntu repo. Network wise, I have a VPN server that takes VPNs from remote sites. This VPN server exports the ranges to the rest of the network. It learns the connected sites from a Raspberry PI on site. These links are used as backup paths :) Here is the BGP config on the server, from a remote site: The filters basically just restrict it to RFC1918 addresses protocol bgp bgp_site_1 { description “site_1"; local as 65001; neighbor 10.255.255.101 as 65101; import filter remote_sites; export filter export_to_remote_sites; } Here is the config on the remote site: filter prepend_path { bgp_path.prepend(65101); bgp_path.prepend(65101); bgp_path.prepend(65101); accept; } protocol bgp itc_vpn { description "ITC VPN"; local as 65101; neighbor 10.255.255.1 as 65001; import all; export filter prepend_path; } What am I missing ? Thanks !

2 4

BIRD 2.0.4 segfaulting on ARM
by lorenz＠irmhil.de 26 Apr '19

26 Apr '19

Hello bird-users, bird crashes a few seconds after startup on my Hardkernel ODROID HC-2 running Ubuntu. Kernel version is 4.14.111-158. How can I debug this? I tried: $ bird -c bird.conf -d -D debug.log --> debug.log is 0 bytes. next try: $ bird -c bird.conf $ birdc # debug all all # echo all Last lines of output is: >>> MyOSPF: HELLO packet sent via eth0.1000 >>> MyOSPF: HELLO packet received from nbr 10.99.0.1 on eth0.1000 >>> MyOSPF: HELLO packet received from nbr 10.2.0.0 on eth0.1000 >>> MyOSPF: LSACK packet sent via eth0.1000 >>> MyOSPF: length 56 >>> MyOSPF: router 33.3.0.0 >>> MyOSPF: LSA Type: 4005, Id: 0.0.0.1, Rt: 10.99.0.1, Seq: 8000068a, Age: 1, Sum: 97a9 >>> MyOSPF: LSA Type: 0008, Id: 0.0.0.40, Rt: 10.99.0.1, Seq: 80000633, Age: 1, Sum: e252 Connection closed by server I would be glad helping fixing this bug. Thanks a lot, Lorenz

4 10

Re: BIRD 2.0.4 segfaulting on ARM
by Danny Wensley 25 Apr '19

25 Apr '19

Hi, Just done a bit of research - this closely relates to the main platform I use bird on - and the ODROID HC2 uses a Samsung Exynos5422 processer, which is ArmV7-A. Using qemu-system-arm with the raspi2 machine and a recent version of Raspbian would yield an emulated system with near identical architectural properties as the ODROID HC2. Danny. On Thu, Apr 25, 2019, 11:55 PM Maria Matějka <jan.matejka(a)nic.cz> wrote: > Or, probably what would be even better – could you please help me running > QEMU with this specific guest architecture? This is definitely an > architecture which we would like to include in our test suite. > > Thanks > Maria > > On April 25, 2019 11:36:11 PM GMT+02:00, "Maria Matějka" < > jan.matejka(a)nic.cz> wrote: >> >> Hello! >> >> ulimit -c unlimited >> bird ... >> (after it crashes) >> gdb bird core <<EOF >> backtrace full >> EOF >> >> Or, alternatively, try running it in Valgrind. >> Maria >> >> On April 25, 2019 7:50:32 PM GMT+02:00, lorenz(a)irmhil.de wrote: >>> >>> Hello bird-users, >>> >>> bird crashes a few seconds after startup on my Hardkernel ODROID HC-2 >>> running Ubuntu. Kernel version is 4.14.111-158. >>> >>> >>> How can I debug this? >>> >>> >>> I tried: >>> >>> >>> $ bird -c bird.conf -d -D debug.log >>> >>> --> debug.log is 0 bytes. >>> >>> >>> >>> next try: >>> >>> $ bird -c bird.conf >>> >>> $ birdc >>> >>> # debug all all >>> >>> # echo all >>> >>> Last lines of output is: >>> >>> MyOSPF: HELLO packet sent via eth0.1000 >>>>>> MyOSPF: HELLO packet received from nbr 10.99.0.1 on eth0.1000 >>>>>> MyOSPF: HELLO packet received from nbr 10.2.0.0 on eth0.1000 >>>>>> MyOSPF: LSACK packet sent via eth0.1000 >>>>>> MyOSPF: length 56 >>>>>> MyOSPF: router 33.3.0.0 >>>>>> MyOSPF: LSA Type: 4005, Id: 0.0.0.1, Rt: 10.99.0.1, Seq: >>>>>> >>>>> 8000068a, Age: 1, Sum: 97a9 >>> >>>> MyOSPF: LSA Type: 0008, Id: 0.0.0.40, Rt: 10.99.0.1, Seq: >>>>>> >>>>> 80000633, Age: 1, Sum: e252 >>> Connection closed by server >>> >>> >>> I would be glad helping fixing this bug. >>> >>> >>> Thanks a lot, >>> >>> Lorenz >>> >>> > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. >

1 0

BIRDv2 OSPF: Stub for loopback potentially broken: Invalid Prefix in LSA
by bauen1 25 Apr '19

25 Apr '19

Hello, I've been playing around with BIRD and OSPF for a while now and ran across an error I don't quite understand, while trying to get BIRD to advertise ip addresses on the loopback interface on a debian 10 server. # bird.conf: debug protocoll all; protocol device { scan time 10; }; protocol ospf v3 ospf_ip4 { ipv4 { export filter accept; import filter accept; import keep filtered; }; area 0.0.0.0 { interface "lo", "dummy*" { stub yes; }; }; }; # ip addr show dev lo 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet 10.50.0.1/32 scope global lo valid_lft forever preferred_lft forever inet6 fe80::1/128 scope link valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever Please note that loopback has a ipv6 link local address to get bird to recognize the interface. In theory, this should advertise 10.50.0.1/32 to other ospf routers, yet it doesn't and BIRD complains about LSAs with an invalid prefix This should advertise 10.50.0.1/32 to other routers and add the respective entries to the LSADB, yet bird starts complaing about an invalid LSA: "ospf_ip4: Invalid prefix in LSA (Type: 2001, Id: 0.0.0.0, Rt: 10.50.0.1)", I have attached the debug output of bird. Any help would be appreciated.

4 15

Unknown instruction 8574 in same (~) error when nesting if's
by Nico Schottelius 20 Apr '19

20 Apr '19

Hello, I am using bird 1.6.3 (from debian) and if I use the following filter, bird "crashes" when issueing the "conf" command: Apr 19 21:29:53 router1 bird: Reconfiguring Apr 19 21:29:53 router1 bird: Unknown instruction 8574 in same (~) filter: filter to_netstream { if(is_inside_ungleich()) then { if(net !~ net_prefer_netstream) then { bgp_path.prepend(myas); bgp_path.prepend(myas); bgp_path.prepend(myas); print "Policy: changed bgppath ", net, " ", bgp_path, " for init7"; } accept; } reject; } If I change the filter to filter to_netstream { if(is_inside_ungleich()) then { # if(net !~ net_prefer_netstream) then { # bgp_path.prepend(myas); # bgp_path.prepend(myas); # bgp_path.prepend(myas); # print "Policy: changed bgppath ", net, " ", bgp_path, " for init7"; # } accept; } reject; } this problem does not occur. Is this a bug in bird or am I using it "incorrectly"? Best, Nico Relevant context: version: -------------------------------------------------------------------------------- [17:14:30] router1.place5:/var/log# dpkg -l | grep bird ii bird 1.6.3-2 amd64 Internet Routing Daemon [17:18:49] router1.place5:/var/log# config: -------------------------------------------------------------------------------- define net_ungleich = [ 2a0a:e5c0::/29+, 2a09:2940::/29+ ]; define net_prefer_netstream = [ 2a09:2940::/29+ ]; define net_rickbakker = [ 2001:678:a10::/48+, 2a0d:1a44::/32+, 2a0d:1a47::/32+, 2a0d:2406::/39+, 2a0d:2406:e00::/39+, 2a07:a904:1000::/40+ ]; function is_ungleich() { if net ~ net_ungleich then return true; return false; } function is_from_rickbakker() { if net ~ net_rickbakker && bgp_path.first = 204526 then return true; return false; } # what we have inside dcl function is_inside_ungleich() { if(is_ungleich()) then return true; if(is_from_rickbakker()) then return true; return false; } protocol bgp netstream { local as 209898; neighbor 2a01:330:1000:1002::1 as 15517; password "xxx"; import filter from_netstream; export filter to_netstream; } -------------------------------------------------------------------------------- -- Your Swiss, Open Source and IPv6 Virtual Machine. Now on www.datacenterlight.ch.

2 2

BGP routing table update time
by Tom Petty 18 Apr '19

18 Apr '19

Hi all, I’m trying to parse birdc output to process routing tables. While each route entry has a timestamp associated with it, I can’t find a convenient way of determining when the contents of a table were last changed, other than parsing the entire table and checking the timestamps of each route. I’d like to avoid this, so is there a better way of determining when a route table was last updated that I’m missing? If not, would a patch adding a “time of last update” value to the table be of interest? Thanks, Tom P

2 2

BIRDv2: OSPFv3: vrf stub interface not recognized
by bauen1 18 Apr '19

18 Apr '19

Hi again, Now that OSPF stub networks work on loopback and dummy interfaces work again, I've run across another Issue, OSPFv3 refuses to recognize any networks on a vrf interface, even with a ipv6-ll adress added. I'm not entirely sure if I'm even supposed to add addresses to the vrf interface, but as far as I know, I can just use the vrf interface for the router ip (normally the job of loopback). BIRD v2.0.4-10-g6ff81197 ready. bird> show interfaces lo up (index=1) MultiAccess AdminUp LinkUp Loopback Ignored MTU=65536 127.0.0.1/8 (Preferred, scope host) 10.30.0.54/32 (scope site) ::1/128 (Preferred, scope host) fe80::1/128 (Preferred, scope link) enp1s0 up (index=2) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 10.30.0.54/24 (Preferred, scope site) fe80::5054:ff:fe01:ea75/64 (Preferred, scope link) fdde:e540:e627:0:5054:ff:fe01:ea75/64 (Preferred, scope site) enp7s0 up (index=3) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 169.254.169.2/32 (Preferred, opposite 169.254.169.254, scope univ) fe80::5054:ff:fe15:9119/64 (Preferred, scope link) dummy0 down (index=6) MultiAccess Broadcast Multicast AdminDown LinkDown MTU=1500 dn42 up (index=8) MultiAccess AdminUp LinkUp MTU=65536 172.20.18.226/32 (Preferred, scope site) 172.20.10.0/24 (scope site) fe80::1111:1111:1111:1111/64 (Preferred, scope link) enp8s0 up (index=4 master=dn42) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 169.254.254.1/32 (Preferred, opposite 169.254.254.2, scope univ) fe80::5054:ff:feec:af5/64 (Preferred, scope link) bird> show ospf interface ospf1 ospf1: Not a protocol bird> show ospf interface dn42_ospf_ip4 dn42_ospf_ip4: Interface enp8s0 (IID 64) Type: ptp Area: 0.0.0.0 (0) State: PtP Priority: 1 Cost: 10 ECMP weight: 1 Hello timer: 10 Wait timer: 40 Dead timer: 40 Retransmit timer: 5 bird> important part of bird.conf protocol ospf v3 dn42_ospf_ip4 { vrf "dn42"; ipv4 { table dn42 }; area 0.0.0.0 { interface "dn42" { stub yes; }; }; };

2 1

Learning BIRD source
by Brian Topping 17 Apr '19

17 Apr '19

Developer team: I’d like to get better with the source. Due to being an inferior specimen and/or too many other projects, I need help from tools like CLion to make sense of source trees within weeks instead of years. Are others working on BIRD source within IDEs? I know "real programmers use vim and emacs”, etc, but please refer to previous paragraph in that case… For all it matters, I am not a bush league developer, I have written code using bison and flex and am super stoked to get my hands dirty here. One option that presents itself to me is converting the build from Autotools to CMake. That’s sure to make someone’s blood boil. But if not (or there is a similarly worthy tool folks would accept), would such a transition be PR-worthy? Because it’s declarative vs. procedural, CMake is possible for IDEs to ingest and make sensible semantic presentations with. That leads to better productivity and more possible contributors in the long run. I’m just poking the bear here with ideas and being as lazy as possible, but not afraid of the work at the same time. Grateful for any and all ideas! B

6 10

Setting route destination for DNAT addresses
by Brian Topping 12 Apr '19

12 Apr '19

In this thread[1], I realize I created a new problem in the BIRD BGP configuration with `dest = RTD_BLACKHOLE`. Setting a destination to blackhole works great when the routes are being propagated (no ICMP unreachable is sent by the kernel) and an address being managed by Kubernetes DNAT facilities will be caught in the netfilter chains and sent to the proper container. That configuration: > router id UP.STREAM.143.113; > > protocol bgp bgp_metal_gw01 { > local as ASLOCAL; > neighbor 10.10.0.41 as ASLOCAL; > passive yes; > ipv4 { > next hop self; > import filter { > bgp_origin = ORIGIN_IGP; > dest = RTD_BLACKHOLE; # <=== DISCUSSION LINE > accept; > }; > export none; > }; > } The problem is when a service on the same host as the container needs to connect to the DNAT address presented for the container. Because the local kernel routing table is set to blackhole for an address, the traffic is immediately sunk instead of being offered to netfilter. Removing that dest line simply sets it to a default of RTD_UNREACHABLE, which does the same thing but politely tells the sender that it did so. What I thought would work is to change the line to `ifname = “eno2”`, but doing so generates a parse error. This seems to be a bug in the documentation as the `ifname` attribute is not listed as read-only. How can I set the route to a local interface in the filter? Thanks! Brian [1] https://marc.info/?l=bird-users&m=155458976221242&w=2

2 2