Re: Bird BFD is not compliant to RFC5881

[Clemens Schrimpe]

> On 17. Feb 2022, at 13:09, Christian Bruns  wrote:
> 
> providers like "Deutsche Telekom" apply strict filter for BFD and only allow 
> RFC5881 compliant ports,

Hahaha ... *tips hat to Rüdiger Volk¹ in retirement* 😂😂😂

¹) Oh! Just saw him on the Onsite registrant list for IETF-113 in Wien next 
month. Nice. Anyone else planning to show? 🤔

Clemens

Re: BIRD 2.0.8

[Clemens Schrimpe]

> The Debian package I have been using actually does put the configs in 
> /etc/bird which makes sense, as it's basically a normal Debian in the eyes of 
> the package.
> 
> 

You can make a package though, where everything lives under /config, preferably 
/config/opt - right?

Like I said: Not a good idea to have your routing-engine and -config wiped 
after a software update.

You can, however, put a "normal" BIRD install package into 
/config/data/firstboot/install-packages and have a script in 
/config/scripts/firstboot.d which may restore the config file (or a symlink to 
/config/bird.conf, which also survives the big culling). In that case the 
package gets re-installed early during the first boot after a FW update (and 
the script called).

If the BIRD distribution depends on other packages, those also need to go into 
/config/data/firstboot/install-packages.

And of course you need to have scripts updating the packages in 
/config/data/firstboot/install-packages, when you update them ...

-c

Re: BIRD 2.0.8

[Clemens Schrimpe]

Hej -

sorry for being late to the game (this thread), but $dayjob kept me busy - what 
else is new...


I have been an avid user of BIRD (1.x and 2.x) on the Ubiquiti platforms - on 
both major versions of "EdgeOS" and on both hardware platforms (Octeon → 
MIPS-BE and "the other" → MIPS-LE  (all EdgeRouter X models))

Yes, I am using the original EdgeOS, which is just-another-debian-distro, 
namely:

EdgeOS 1 → Debian 7.11 with "3.10.107-UBNT #1 SMP Fri Feb 21 09:19:25 UTC 2020 
mips64 GNU/Linux" kernel and

EdgeOS 2 → Debian 9.12 with "4.9.79-UBNT #1 SMP Thu Mar 5 16:48:40 UTC 2020 
mips64 GNU/Linux" kernel.

(on the Octeon platform → all EdgeRouters, except the "X" models, but versions 
are quite equal/similar/close)

I have not built my own distribution (incl. a kernel with the HW-offloading 
supplements, etc.), because I actually liked EdgeOS - with the exception of the 
Quagga-Version (the non-FRR variant from Japan, if I recall right) that comes 
with it. 

However, if you do not configure anything in the "protocol" section of the 
EdgeOS/Vyatta configuration and create a bird.conf file and fire up BIRD 
instead everything (almost) works just fine. Yes, you can't see the routing 
config in the GUI, but I disable it anyway because I don't use it and want the 
memory for important things. Of course, "show bgp neighbors" would also be 
replaced by "birdc show protocols", etc. but this is just fine!


I built my BIRDs directly on the routers themselves (just install 
"build-essential" and very few other packages), but since you talked about 
"distributions" here, be warned: A "firmware upgrade" wipes/reinstalls 
everything in the filesystem, except /config and below. Since you don't want to 
do a FW upgrade and have the box reboot without it's routing engine/daemon I 
compiled BIRD to live under /config/opt/bird1 or /config/opt/bird2 (or just 
/config/opt/bird ;-).

Put a proper startup-script for it into /config/scripts/post-config.d and the 
BIRD shall be woken by EdgeOS, once all interfaces are plumbed and addressed 
and everything works very well - even after a firmware upgrade. BIRD binaries 
built for EdgeOS 1 even survive a FW upgrade to EdgeOS 2 this way, btw.
(though you want BIRD 2 built on EdgeOS 2 to get the latest & gratest features 
→ RPKI, for example)

Just my 2¢ ...

Clemens

PS: We use this combination (among others) in parts of the IETF Meeting network 
for many years now. So if you have attended an IETF meeting (in person) since 
spring of 2014 (#89 → London) you are very likely to have been routed by it 😉  
(yes, including all recent meetings in Praha!)



> On 10. Apr 2021, at 14:23, Skyler Mäntysaari  wrote:
> 
> I'm not sure, how would I check if it's LE or BE?
> 
> CPU info on ER-12:
> ---
> system type : UBNT_E300
> machine : Unknown
> processor   : 0
> cpu model   : Cavium Octeon III V0.2  FPU V0.0
> BogoMIPS: 2000.00
> wait instruction: yes
> microsecond timers  : yes
> tlb_entries : 256
> extra interrupt vector  : yes
> hardware watchpoint : yes, count: 2, address/irw mask: [0x0ffc, 0x0ffb]
> isa : mips1 mips2 mips3 mips4 mips5 mips64r2
> ASEs implemented: vz
> shadow register sets: 1
> kscratch registers  : 4
> package : 0
> core: 0
> VCED exceptions : not available
> VCEI exceptions : not available
> --
> 
> P.S Did you also use the UBNT kernel modules for hardware acceleration?
> 
> On 10/04/2021 15.19, Ondrej Zajicek wrote:
>> On Sat, Apr 10, 2021 at 02:46:25PM +0300, Skyler Mäntysaari wrote:
>>> Please also keep in mind that they do not run normal Debian, but EdgeOS
>>> which is a fork of vyatta which uses Debian.
>> Several years ago, i run original Edgerouter (ERLite-3) with vanilla
>> Debian, just with kernel from EdgeOS.
>> 
>>> EdgeRouter-4 and EdgeRouter-12 run on mips64.
>> It is BE or LE? ERLite-3 was (AFAIK) mips (BE), Debian offers mips,
>> mipsel (LE) and mips64el (LE), but no mips64. It is possible (but
>> unlikely) that they build EdgeOS for a differench arch.
>> 

Re: Binary Bird2 for EdgeRouter (EdgeOS, Debian 9, mips)

[Clemens Schrimpe]

I compile them myself and I am happy to help. For which model do you seek
the binaries?

Clemend

Skyler Mäntysaari  schrieb am Fr. 31. Juli 2020 um 13:10:

> Dear list,
>
> Is there somewhere a repository where I can find a mips version of Bird2?
> SID debian repository does not support mips architecture.
>
> Best regards,
> Skyler Mäntysaari
>

Re: Static IPv6 fe80 route gets dormant

[Clemens Schrimpe]

> Yes static route was given as an immediate nexthop gateway ip. Why is
> it not possible to resolve the outgoing interface for that case?
> Neighbor table? 

It's not necessarily unique ... like everything "link-local". 🤷🏼‍♂️
(unless you explicitly name an interface, that is ...)

Greetings,

Clemens

Re: Filtering on Export-Protocol

[Clemens Schrimpe]

If I may chime in, briefly, here ...

This request relates to an "improvement suggestion" I made a few years back, 
but it was during the hot phase before 2.x was released, so I guess it was lost.

Back then I was asking for "context variables/constants", i.e. the peer's AS 
number in the context of a filter/function called from a BGP proto, etc.
One thing to solve with this approach would be, how to define these 
context-variables if you just wanted to manually execute a function/filter for 
testing, but that should be doable.

Ah ... just found the old mail, dubbed "Making a wish ... errr ... *four* 
wishes! 😳" from January 24th 2018 - I'll attach a copy of it to this one, just 
for reference. In it I already made a few suggestions re: potential candidates 
for such "context-variables".

Again, thanks for all the good work!

Clemens

PS: The whole thread, back then, had a number of suggestions you gave a 🤔-maybe 
rating to ... i.e., "ipset protocol" and others ... interesting to see all 
these again. 😉

 excerpt from previous mail exchange 

>>> As one of my many uses for BIRD is in large wireless environments (i.e., 
>>> IETF meetings) I am very interested in keeping the amount of multicast 
>>> traffic as low as possible. The standards allow for a router to 
>>> (immediately) respond with a unicast RA to an RS as an alternative to 
>>> sending out a multicast RA „some (short, random) time“ after receiving an 
>>> RS. Many others (Juniper, et.al.) have implemented this and I’d like to see 
>>> this in BIRD too. The code changes are apparently very simple, so I almost 
>>> did it myself, but then I didn’t want to interfere with ongoing 2.x 
>>> developments.
>>> (lame excuse, I know …)
>> 
>> Seems simple and makes perfect sense. Will do.
> 
> Thank you. That was easy.
> (the next IETF meeting, where this could become be very useful, will be in 
> mid-March … :-) :-) :-)

it didn’t make it into 2.0.2 and/or 1.6.4, though, right?

(I’m sitting here in London still emitting lots of multicast RAs … 😩😩😩)


>>> Context dependent (global) „variables“ for functions/filters
>>> 
>>> I (and probably others too) would really enjoy having more global variables 
>>> defined for use inside filters & functions, depending on the context within 
>>> which the respective filter/function is being called. The most obvious ones 
>>> would be the peer’s (and our own) AS number (in the context of BGP 
>>> protocols), the filtering direction, the protocol (type and name), the next 
>>> hop’s address (where applicable), and so on.
>>> 
>>> Yes, I know, most of these could be explicitly given (at least to a 
>>> function) when calling it as the import/export filter for a protocol with a 
>>> „where“ clause, but that would defeat the purpose of using templates (which 
>>> I really do like and use a lot).
>>> 
>>> The general concept of having „globals“ inside functions/filters is already 
>>> there - just presently only in the context of the route that is being 
>>> evaluated. I’d like to see this expanded into other contexts as described 
>>> above. 
>> 
>> That is an interesting idea and also seems simple, although there are
>> some caveats, e.g. filters using such context-dependent-constants would
>> probably work for 'show route filter'.
> 
> Yes, I had forgotten about this (very useful) feature. However, the syntax 
> for this could be easily amended to allow the definition of such variables 
> via the command line, i.e.,
> 
>   show route filter foo(a=1, b="bla", ...)
> 
>> It may be useful if you could make
>> a list of suggested constants.
> 
> Well ... here is what comes to mind easily:
> (NB: these are not the "names" of the variables I propose; we should come up 
> with a good naming scheme once we settled on an initial list of variables)
> 
> router id
> protocol name
> protocol type
> address family / channel-type
> local as
> remote as
> local interface name (outbound interface)
> local address (outbound interface)
> remote address 
> external variables (see below)
> 
> Variables, of course, only have values inside "useful" contexts, i.e, AS 
> number inside BGP, etc. and are otherwise "undefined".
> 
> I'l also like to propose the introduction of global variables (vs. existing 
> constants), which can be set in the configuration file, via the command-line 
> (i.e., "bird -D foo=42" and at runtime via birdc. Again, naming conventions 
> have to be observed, etc. and the manual must emphasize on when exactly 
> filters are evaluated and such.
> 
> But this would allow to build a config, whose behavior could be altered at 
> runtime, i.e., start-up in "test-mode" and then later be switched over to 
> "production-mode" through birdc (or any other tool using the API), among many 
> other possibilities. It would also be nice, if variables could hold lists, 
> most notably prefix-lists of all sorts and AS/community lists. In this case 
> the birdc interface would require add, remove, list functions in 

Re: Build for Debian MIPS

[Clemens Schrimpe]

Hallo all -

I built BIRD (1.x and 2.x) for the EdgeRouter platforms(!) myself for many 
years now and I still do. At first I used a "proot" environment with QEMU on a 
Ubuntu environment, but I have moved on to compiling it directly on the 
machines in question a while ago. EdgeRouters (especially the "XG" or 
"Infinity" types) have more than enough CPU and RAM to do it there, it's just 
the "local storage" and the way their firmware is updated, which prevents you 
from "just doing it".

The solution is simple, though: Current EdgeOS versions support the USB-Port on 
those routers and you can just plug in a cheap thumb drive or even a real 
SSD/HD with a USB-Interface. Format it with ext3/ext4, mount it to /mnt for 
example, clone the current OS onto it, like so:

rsync -aAXv 
--exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found","/root.dev/*"}
 / /mnt/

create shadow-mounts for the special kernel filesystems:

mount --rbind /dev  /mnt/dev
mount --rbind /proc /mnt/proc
mount --rbind /sys  /mnt/sys

and now you can chroot into your development environment:

chroot /mnt /bin/bash --login

and (bonus track) even start an sshd within this environment for easier access 
later:

mkdir /var/run/sshd /run/sshd   # may fail on either

/usr/sbin/sshd -p 222 -o Protocol=2

which runs on port 222 now (vs. the "normal" sshd, running on port 22).

Depending on the EdgeOS Version (1.x or 2.x) you install additional packages 
need for development. Here are some suggestions (non-comprehensive):

Packages for 2.x:

wget
git
build-essential
autoconf
locales-all
cscope
ncurses-dev
libssl-dev
libev-dev
liblzo2-dev
libpam-dev
minizip
flex
bison
libperl-dev
libreadline-dev
libpcre3-dev
libpcap-dev
libldap-dev
libtalloc-dev
libcap2-dev
libmemcached-dev
libjson-c-dev
libgdbm-dev
libsqlite3-dev
libssh-dev
libssh2-1-dev

binutils manuell nachinstallieren! (dpkg -i ...)


--

Packages for 1.x:


autoconf
locales-all
cscope
ncurses-dev
libssl-dev
libev-dev
liblzo2-dev
libpam-dev
flex
bison
libperl-dev
libreadline-dev
libpcre3-dev
libpcap-dev
libldap-dev
libtalloc-dev
libcap2-dev
libmemcached-dev
libgdbm-dev
libsqlite3-dev
libssh-dev
libssh2-1-dev

Why am I doing this on this "shadow root" again? Because every EdgeOS update 
wipes everything, except for /config (which is why I place my compiled 
"modules" (binaries), like BIRD, into /config/opt/bird/... for example → 
./configure -prefix=/config/opt/bird .

This has been working very well for me in a while and I am compiling all sorts 
of tools all the time within this "Build jail". 

Tools needed to start this off (mkfs, rsync, etc.) are either already on the 
platform or can be installed through the officially supported "apt-get" 
mechanism.

The above was quickly copy&pasted together from what I have on my terminal 
windows right now and and is surely lacking a step or two along the way, sorry. 
Please feel free to ask for more detailed instructions if you get stuck 
somewhere.

Greeting,

Clemens

PS: If you want to cover the whole EdgeRouter platform you'll need to do this 
twice - once on an ER-Pro/ER-Infinity and once on an ER-10X (the only X-router 
with an open USB port), as the former is MIPS-BE and the latter is MIPS-LE ... 
yes, all of these can somehow be "emulated", but I just found it much easier to 
create/operate/maintain those build environments on their respective native 
platforms - besides: They are incredibly cheap - even the Infinity router (8 x 
SFP+, 116 CPUs - 16G RAM - bored beyond belief) is comparatively cheap.

> We've not been able to build ourselves on MIPS yet, we went into some strange 
> problems last time (don't remember exactly). Were you so kind please and 
> could you please help us setting up Debian for MIPS in QEMU if I fail to 
> manage it once more?
> The main issue was, what hardware to choose and how to boot it. But I'll try 
> once more before asking any detailed question. Then we can replicate your 
> issue and probably even build and test for MIPS.

Re: RPKI support without SSH transport

[Clemens Schrimpe]

> On 25. Mar 2020, at 13:37, Ondrej Zajicek  wrote:
> 
> Yes, current code in git should be OK, all code in ssh_transport.c is
> commented out.

Confirmed. Thank you very much for the great work (not only this patch ... :-)

Greetings,

Clemens

Re: RPKI support without SSH transport

[Clemens Schrimpe]

> On 25. Mar 2020, at 13:37, Ondrej Zajicek  wrote:
> 
> Yes, current code in git should be OK, all code in ssh_transport.c is
> commented out.

I'll git pull and try it out asap. Thanks,

Clemens

Re: RPKI support without SSH transport

[Clemens Schrimpe]

Hello and sorry for the late feedback ... lots of things going on ... 


> On 14. Jan 2020, at 16:45, Maria Matějka  wrote:
> 
>> however, attempts to build it without /--disable-libssh/ result in a linking 
>> error:
> 
> Oops, sorry, I missed one include. Here is the fixed patch, now it compiles 
> both with and without libSSH.
> 
> Maria
> 

No, unfortunately it does not - not any more, at least:

Configured with

./configure --disable-libssh

it doesn't compile proto/rpki/ssh_transport.c because it references "struct 
ssh_sock" and "SK_SSH_CONNECT", whose definitions are excluded in lib/socket.h 
unless HAVE_LIBSSH is defined →

CC -o obj/proto/rpki/ssh_transport.o -c proto/rpki/ssh_transport.c
proto/rpki/ssh_transport.c: In function 'rpki_tr_ssh_open':
proto/rpki/ssh_transport.c:29:40: error: invalid application of 'sizeof' to 
incomplete type 'struct ssh_sock'
   sk->ssh = mb_allocz(sk->pool, sizeof(struct ssh_sock));
^~
proto/rpki/ssh_transport.c:30:10: error: dereferencing pointer to incomplete 
type 'struct ssh_sock'
   sk->ssh->username = ssh_cf->user;
  ^~
proto/rpki/ssh_transport.c:34:20: error: 'SK_SSH_CONNECT' undeclared (first use 
in this function)
   sk->ssh->state = SK_SSH_CONNECT;
^~

Again: Thanks for your great support!

Clemens

Re: RPKI support without SSH transport

[Clemens Schrimpe]

> Please try the attached patch. It has not been tested, yet it compiles
> with no LibSSH available.

This appears to work nicely. After running autoreconf and ./configure 
--disable-libssh it builds a bird with RPKI support, which is still "lean":

DEV 2.x MIPS:~/bird-patch> ldd bird
linux-vdso.so.1 (0x771ed000)
libpthread.so.0 => /lib/mips-linux-gnu/libpthread.so.0 (0x770a2000)
libc.so.6 => /lib/mips-linux-gnu/libc.so.6 (0x76f2)
/lib/ld.so.1 => /lib64/ld.so.1 (0x771bc000)

however, attempts to build it without --disable-libssh result in a linking 
error:

/tmp/ccz8W8kL.ltrans12.ltrans.o: In function `rpki_init_cache':
/home/csch/bird-patch/proto/rpki/rpki.c:583: undefined reference to 
`rpki_tr_ssh_init'
/home/csch/bird-patch/proto/rpki/rpki.c:583: undefined reference to 
`rpki_tr_ssh_init'
collect2: error: ld returned 1 exit status

It still works without the patch, but (as mentioned) yields a bird with many 
external dependencies:

DEV 2.x MIPS:~/bird> ldd bird
linux-vdso.so.1 (0x7755a000)
libssh.so.4 => /usr/lib/mips-linux-gnu/libssh.so.4 (0x773bb000)
libpthread.so.0 => /lib/mips-linux-gnu/libpthread.so.0 (0x7738e000)
libc.so.6 => /lib/mips-linux-gnu/libc.so.6 (0x7720c000)
librt.so.1 => /lib/mips-linux-gnu/librt.so.1 (0x771f4000)
libcrypto.so.1.0.2 => /usr/lib/mips-linux-gnu/libcrypto.so.1.0.2 
(0x77034000)
libz.so.1 => /lib/mips-linux-gnu/libz.so.1 (0x7700b000)
libgssapi_krb5.so.2 => /usr/lib/mips-linux-gnu/libgssapi_krb5.so.2 
(0x76fb8000)
/lib/ld.so.1 => /lib64/ld.so.1 (0x77529000)
libdl.so.2 => /lib/mips-linux-gnu/libdl.so.2 (0x76fa5000)
libkrb5.so.3 => /usr/lib/mips-linux-gnu/libkrb5.so.3 (0x76ed6000)
libk5crypto.so.3 => /usr/lib/mips-linux-gnu/libk5crypto.so.3 
(0x76e91000)
libcom_err.so.2 => /lib/mips-linux-gnu/libcom_err.so.2 (0x76e7d000)
libkrb5support.so.0 => /usr/lib/mips-linux-gnu/libkrb5support.so.0 
(0x76e62000)
libkeyutils.so.1 => /lib/mips-linux-gnu/libkeyutils.so.1 (0x76e4e000)
libresolv.so.2 => /lib/mips-linux-gnu/libresolv.so.2 (0x76e28000)

To summarize → your patch works fine in "the forward direction" (towards 
solving the problem), but apparently creates another problem when building with 
libssh now.

🤷🏼‍♂️

Thanks for your efforts!

Clemens

Template sans "channels"

[Clemens Schrimpe]

Ahoj (again) :-)

While in the process of cleaning up "ancient" configs (basically rewriting them 
from scratch) I came across an odd discovery:

A template definition (for a kernel protocol) demands the specification of one 
(and only one) channel - which, in my case, defeats the whole purpose of having 
a kernel template in the first place.

I attempted to have a template with all the "standard behaviour" I wanted 
(persist, metric, table #, ...) for both IPv6 and legacy-IPv4 kernel tables and 
then tried to apply it like so:

template kernel KERNEL {
persist;
learn;
metric 20;

kernel table 10;
}

protocol kernel KERNEL6 from KERNEL {
ipv6;
}

protocol kernel KERNEL4 from KERNEL {
ipv4;
}

... because I thought the templating mechanism was "just" some syntactic sugar, 
similar to an "include" statement?!

As the kernel template demands a (single) channel statement, which could then, 
upon invocation, not be "negated" again, i.e., by a 

no ipv4;

statement I can only have two templates - one pre-destined for IPv6 and another 
for IPv4.

What is the intention behind this? I do understand, that -in the end- the 
actual protocol defined through a template must have one (and only one in the 
case of a "kernel" protocol) channel definition and in my example this 
requirement would be fulfilled.

Thoughts? Hints?

Thanks again -

Clemens

RPKI support without SSH transport

[Clemens Schrimpe]

Ahoj BIRD Parents -

I was wondering if there is a reason, why BIRD 2.0.x can't be built for RPKI 
support without libssh, although RPKI-RTR would also work on an unencrypted 
transport (as documented in the BIRD user documentation).

I am asking, because I am building BIRD for a hardware router platform 
(Ubiquiti's EdgeRouters) and including libssh is, although doable, a real 
pain-in-the-rear, depending on the OS version and hardware architecture (4 
variants in the EdgeOS world at the moment).

Without libssh, which drags a whole slew of other library-crap behind it 🙄, 
BIRD is pretty lightweight and very easy to deploy.

Just curious ...

Thanks a lot (again) for this great piece of software!

Clemens

Re: BIRD 2.0.6 and 1.6.8

[Clemens Schrimpe]

> Well, we do not plan to backport new features to 1.6.x, only bugfixes.
> 
> Any reason why this feature should be an exception and why not just
> migrate to 2.0.x?

Quite some work, $people afraid of change and too lazy to test ... the usual. 
But technically: No, not really. You are right that we should!


> OTOH, it seems simple to backport, it applies cleanly and probably all
> what is necessary is to change current_time() wit 'now'.

Well ... ;-)

Thanks,

Clemens

Re: BIRD 2.0.6 and 1.6.8

[Clemens Schrimpe]

What would it take to get this

> Version 2.0.6
>  o RAdv: Solicited unicast RAs

"backported" to 1.6.x ?

Thanks,

Clemens

Re: sets in bgpmasks ?

[Clemens Schrimpe]

> On 6. Aug 2019, at 17:04, Ondrej Zajicek  wrote:
> 
> I just added support for integer sets in bgpmasks (see attached patch).

Using this syntax:

[= 123 [234, 345] * =]

?

Thanks!

Clemens

Re: sets in bgpmasks ?

[Clemens Schrimpe]

I like this sentiment ... 👍🏻😊

Thanks!

C

--
Von einem Mobiltelefon gesendet. Bitte die Kürze entschuldigen.
Sent from a mobile phone. Please excuse brevity. 

> Am 06.08.2019 um 11:51 schrieb Maria Jan Matejka :
> 
> It anyway seems reasonable to be implemented.

sets in bgpmasks ?

[Clemens Schrimpe]

Hello all -

I wonder: Is there a "nice" syntax to have sets (lists of ASs) inside of 
bgpmasks?

I.e.,

[= 123 [234, 345] * =]

does not work (syntax error). Any other ideas?

Thanks,

Clemens

Re: IETF-104 and Netdev 0x13

[Clemens Schrimpe]

PS: we are already here 😉

C

--
Von einem Mobiltelefon gesendet. Bitte die Kürze entschuldigen.
Sent from a mobile phone. Please excuse brevity. 

> Am 18.03.2019 um 17:28 schrieb Ondrej Zajicek :
> 
> Hi
> 
> In following days IETF 104 and Netdev 0x13 conferences will be held in
> Prague and we will be present, if anyone wants to meet us.
> 
> -- 
> Elen sila lumenn' omentielvo
> 
> Ondrej 'Santiago' Zajicek (email: santi...@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."

Re: 1.6.5 and 2.0.3 packages?

[Clemens Schrimpe]

You do know that it really(!) compiles very easily and right out of the box?

Just sayin‘ …

Clemens 

Re: How to make BIRD use the kernel routing metric?

[Clemens Schrimpe]

> Not sure how to achieve the same in BIRD.

While you are at it … (sorry for riding along on your thread)

It raises the general question of „how does one extract certain data from 
different protocols“, i.e. into a variable so it can be „mathed“ with and then 
re-used in an im- or export filter to be translated into another protocol’s 
metric.

So in your case: Can the krt_metric attribute of routes „learned“ from the 
kernel be read and stored in a variable?

In my case: How can I read the contents of each part of the tuplets/triplets 
from BGP communities? So far I only know of ways to test for the existence of 
particular values. (i.e. get the third part of a BGP large community with known 
first & second parts into a variable)

Thanks for any hints provided -

Clemens

Re: BIRD 2.0.2 segfaulting

[Clemens Schrimpe]

> You can use filters: show route table r4 where net.asn = 4711

That indeed works. And now I also found what I was looking for in the 
documentation:

> NET_ROA4 and NET_ROA6 prefixes hold an IP prefix range together with an ASN. 
> They support the same special operators as IP prefixes, and also .maxlen 
> which extracts maximal prefix length, and .asnwhich extracts the ASN.

Thanks for the pointer!

Clemens

PS: Any of your crew here at IETF-103 in Bangkok?

Re: BIRD 2.0.2 segfaulting

[Clemens Schrimpe]

>> In my attempts to examine ROA tables more closely I entered „show route 
>> table r4 all“ into birdc and bird immediately segfaulted and died.
> 
> Hello
> 
> Does it crash without 'all'? Works for me:

No. It’s just the „all“ keyword bringing it to its knees.


> Attached patch should fix the crash.

Thanks. Will try that sometime this week.


> Currently ROA has to be specified as a whole, including maxlen and ASN,
> not just its prefix. Confusingly, it uses slightly different syntax
> to enter ROAs and to print ROAs:
> 
> bird> show route 212.1.128.0/19 max 19 as 9105 table rtab4
> Table rtab4:
> 212.1.128.0/19-19 AS9105  [rpki1 13:28:00.854] * (150)

Hmmm … good to know. But stuff like „show route table r4 as 4711“ would be 
useful too - at some point … *hint*hint*

:-)

Clemens

BIRD 2.0.2 segfaulting

[Clemens Schrimpe]

Hello -

just wanted to report a little (easily reproducable) problem: I’m experimenting 
with BIRD 2.0.2 on a lab-router (Ubiquiti Edgerouter, MIPS platform) and RPKI. 

In my attempts to examine ROA tables more closely I entered „show route table 
r4 all“ into birdc and bird immediately segfaulted and died.

Is there any „official“ way to examine the contents of ROA tables other than 
„eval roa_check(r4, 186.255.72.0/24, 204777)“?

I would have assumed „show route table r4 all 186.255.72.0/24“ or something 
like that would work, but it doesn’t (gives empty output). At least „show route 
table r4 count“ gives useful information, though.

Thanks,

Clemens

Re: OSPF generate default route - again

[Clemens Schrimpe]

> The key question is - how to make Bird announcing 0/0 for OSPF ALWAYS? 

Create a static, low-preference „Unreachable“ route for 0/0. If there’s a 
„real“ (functioning) route it’ll override this one and otherwise „unreachable“ 
is always there („reachable“ … [sic]) so you *always* have a 0/0 in your system.

Clemens

bug or documentation bug

[Clemens Schrimpe]

Hello -

the manual explains a global protocol option:

description "text"
This is an optional description of the protocol. It is displayed as a part of 
the output of 'show route all' command.


But it doesn’t work (any more?).

Tiny thing, just wanted to mention it.

Greetings,

Clemens

Re: seemless configuration change

[Clemens Schrimpe]

sudo birdc[6] conf

😉

C



--
Von einem Mobiltelefon gesendet. Bitte die Kürze entschuldigen.
Sent from a mobile phone. Please excuse brevity. 

> Am 03.08.2018 um 14:49 schrieb Kurt Wauters :
> 
> Hello, 
> 
> I've got BIRD running for v4 and v6 but i was wondering if there is a way to 
> switch between configurations without shutting down bird in order to avoid 
> BGP flaps. 
> 
> I basically add regularly neighbors to the RS and i don't want my allready 
> active bgp sessions to flap. Initially i thought I would be able to load the 
> new configuration files but he complains that there is already a process 
> running. 
> 
> Anyone an idea?
> 
> Kurt

Re: OpenVPN-Server as Bird-Router

[Clemens Schrimpe]

Ensure the MTU is set correctly on the tunX interfaces. Verify with „ping -M do 
-s  “ that your tunnels can carry the „promised“ amount of 
bytes as indicated by interface MTU.

😉☝🏻🤓

Clemens 

PS:  = Interface-MTU -28

--
Von einem Mobiltelefon gesendet. Bitte die Kürze entschuldigen.
Sent from a mobile phone. Please excuse brevity. 

> Am 02.08.2018 um 20:46 schrieb Dawid Kulesza <4002...@ba-glauchau.de>:
> 
> Hello,
> I have some issues runinng a few Bird-instances, where two border PC's are 
> connected over a VPN-Connection. The image below shows the setting:
> 
> clientA
> 192.168.30.2 (eth)
> |
> |
> 192.168.30.1 (eth)
> routerA
> 192.168.21.5 (eth)
> |
> |
> 192.168.21.1 (eth)
> clientB
> 10.29.0.8 (tun)
> |
> |
> 10.29.0.1 (tun)
> Server
> 10.29.0.1 (tun)
> |
> |
> 10.29.0.4 (tun)
> clientC
> 192.168.21.17 (eth)
> 
> Now running route -n on ClientC gives following result:
> 
> route -n (routes with metric 12 are set by bird)
> 
> Destination   Gateway Genmask Flags Metric RefUse
> Iface
> 10.29.0.0  0.0.0.0 255.255.252.0   U 0  00
> tun0
> W0.0.0.0 255.255.255.252 U 0  00 eth1
> XXX0.0.0.0 255.255.255.255 UH1024   00 eth1
> 192.168.21.010.29.0.8 255.255.255.240 UG12 00 tun0
> 192.168.21.16  0.0.0.0 255.255.255.240 U 0  00 eth0
> 192.168.30.010.29.0.8 255.255.255.240 UG12 00 tun0
> 
> 
> 
> On Server:
> ZielRouter  Genmask Flags Metric RefUse
> Iface
> 192.168.21.16   10.29.0.4   255.255.255.240 UG17 00 tun0
> 192.168.21.010.29.0.8   255.255.255.240 UG17 00 tun0
> 192.168.30.010.29.0.8   255.255.255.240 UG17 00 tun0
> 192.168.20.00.0.0.0 255.255.255.0   U 0  00 eth0
> 10.29.0.0   0.0.0.0 255.255.252.0   U 0  00 tun0
>  0.0.0.0 255.255.0.0 U 1002   00 eth0
> 
> 
> With 
> 
> birdc show ospf neighbors
> 
> 
> I can see on each router everyone else, so the initialization is done 
> correctly but somehow data packages aren't transferred correctly. There are 
> no invalid iptables rules nor any other firewall is set. 
> 
> Regards
> 
> Dawid

Re: Making a wish ... errr ... *four* wishes! 😳

[Clemens Schrimpe]

… and yet another followup … 

>>> As one of my many uses for BIRD is in large wireless environments (i.e., 
>>> IETF meetings) I am very interested in keeping the amount of multicast 
>>> traffic as low as possible. The standards allow for a router to 
>>> (immediately) respond with a unicast RA to an RS as an alternative to 
>>> sending out a multicast RA „some (short, random) time“ after receiving an 
>>> RS. Many others (Juniper, et.al.) have implemented this and I’d like to see 
>>> this in BIRD too. The code changes are apparently very simple, so I almost 
>>> did it myself, but then I didn’t want to interfere with ongoing 2.x 
>>> developments.
>>> (lame excuse, I know …)
>> 
>> Seems simple and makes perfect sense. Will do.
> 
> Thank you. That was easy.
> (the next IETF meeting, where this could become be very useful, will be in 
> mid-March … :-) :-) :-)

it didn’t make it into 2.0.2 and/or 1.6.4, though, right?

(I’m sitting here in London still emitting lots of multicast RAs … 😩😩😩)


>>> Context dependent (global) „variables“ for functions/filters
>>> 
>>> I (and probably others too) would really enjoy having more global variables 
>>> defined for use inside filters & functions, depending on the context within 
>>> which the respective filter/function is being called. The most obvious ones 
>>> would be the peer’s (and our own) AS number (in the context of BGP 
>>> protocols), the filtering direction, the protocol (type and name), the next 
>>> hop’s address (where applicable), and so on.
>>> 
>>> Yes, I know, most of these could be explicitly given (at least to a 
>>> function) when calling it as the import/export filter for a protocol with a 
>>> „where“ clause, but that would defeat the purpose of using templates (which 
>>> I really do like and use a lot).
>>> 
>>> The general concept of having „globals“ inside functions/filters is already 
>>> there - just presently only in the context of the route that is being 
>>> evaluated. I’d like to see this expanded into other contexts as described 
>>> above. 
>> 
>> That is an interesting idea and also seems simple, although there are
>> some caveats, e.g. filters using such context-dependent-constants would
>> probably work for 'show route filter'.
> 
> Yes, I had forgotten about this (very useful) feature. However, the syntax 
> for this could be easily amended to allow the definition of such variables 
> via the command line, i.e.,
> 
>   show route filter foo(a=1, b="bla", ...)
> 
>> It may be useful if you could make
>> a list of suggested constants.
> 
> Well ... here is what comes to mind easily:
> (NB: these are not the "names" of the variables I propose; we should come up 
> with a good naming scheme once we settled on an initial list of variables)
> 
> router id
> protocol name
> protocol type
> address family / channel-type
> local as
> remote as
> local interface name (outbound interface)
> local address (outbound interface)
> remote address 
> external variables (see below)
> 
> Variables, of course, only have values inside "useful" contexts, i.e, AS 
> number inside BGP, etc. and are otherwise "undefined".
> 
> I'l also like to propose the introduction of global variables (vs. existing 
> constants), which can be set in the configuration file, via the command-line 
> (i.e., "bird -D foo=42" and at runtime via birdc. Again, naming conventions 
> have to be observed, etc. and the manual must emphasize on when exactly 
> filters are evaluated and such.
> 
> But this would allow to build a config, whose behavior could be altered at 
> runtime, i.e., start-up in "test-mode" and then later be switched over to 
> "production-mode" through birdc (or any other tool using the API), among many 
> other possibilities. It would also be nice, if variables could hold lists, 
> most notably prefix-lists of all sorts and AS/community lists. In this case 
> the birdc interface would require add, remove, list functions in addition to 
> set and delete.
> (yeah, I know ... way more things to specify here, like uniqueness, order, 
> etc. -- I'll hold back until you promise not to shoot down this idea 
> completely ;-)
> Also: Can filters/functions set,add,remove,delete variables too ... oh, my 
> /o\ ...) - would be nice, so one could easily implement one's own status 
> counters ...
> 

Anything I can do from my side to help this along? ;-)


Aaaand, of course, here is another „thing“ I would like to see in future BIRD 
version:

As the times where one would have proper link-state on circuits carrying up- or 
downstream BGP are clearly over these days, one would/should consider using BFD 
instead to determine reachability of one’s peer. However: Many ISPs 
(„Carriers“) do not support thus due to lameness, stupidness or other means of 
inability. 

So: Can we have a very simple „ping“ functionality, which could fulfill BFD’s 
role in such cases? Like „ping every second, if three pings in a row went 
missing consider the link down!“.

That would also

Re: Routing via device, not via next hop?

[Clemens Schrimpe]

> Is it possible to configure bird that it exports the route to the kernel
> with "dev ", not with "via "?

I think 

via "" 

works.

Grüße,

Clemens

Re: Making a wish ... errr ... *four* wishes! 😳

[Clemens Schrimpe]

So, to follow up on this ... sorry for the long time it took for this response, 
but the "other life" called and demanded time.
(hence the full inclusion of the original texts to allow for easier re-sync on 
the topics)

> On 24. Jan 2018, at 14:51, Ondrej Zajicek  wrote:
> 
> On Wed, Jan 24, 2018 at 09:15:36AM +0100, Clemens Schrimpe wrote:
>> Gentlepeople (especially those from the BIRD development team) -
>> 
>> being an avid BIRD user for some time now I always kept a small list of
>> „it would be nice, if …“-things for BIRD 1.x, which I kept for myself, as
>> I knew BIRD 2.x was in the works (and thus people were busy already…),
>> but now I get the feeling, that 2.x is slowly stabilizing and I’d like to
>> put them on the table for open discussion:
> 
> Hello
> 
> First, i am glad for such feedback and feature suggestions. It is nice to
> get more user feedback than just bugreports (although i do not want to
> downplay importance of bugreports ;-)).

Oh. You shouldn't have said that. I have *tons* of wild ideas, but see below ;-)


>> Simple things, a.k.a. low hanging fruits:
>> 
>> (Optional) unicast replies to IPv6 RS
>> 
>> As one of my many uses for BIRD is in large wireless environments (i.e., 
>> IETF meetings) I am very interested in keeping the amount of multicast 
>> traffic as low as possible. The standards allow for a router to 
>> (immediately) respond with a unicast RA to an RS as an alternative to 
>> sending out a multicast RA „some (short, random) time“ after receiving an 
>> RS. Many others (Juniper, et.al.) have implemented this and I’d like to see 
>> this in BIRD too. The code changes are apparently very simple, so I almost 
>> did it myself, but then I didn’t want to interfere with ongoing 2.x 
>> developments.
>> (lame excuse, I know …)
> 
> Seems simple and makes perfect sense. Will do.

Thank you. That was easy.
(the next IETF meeting, where this could become be very useful, will be in 
mid-March ... :-) :-) :-)


>> Context dependent (global) „variables“ for functions/filters
>> 
>> I (and probably others too) would really enjoy having more global variables 
>> defined for use inside filters & functions, depending on the context within 
>> which the respective filter/function is being called. The most obvious ones 
>> would be the peer’s (and our own) AS number (in the context of BGP 
>> protocols), the filtering direction, the protocol (type and name), the next 
>> hop’s address (where applicable), and so on.
>> 
>> Yes, I know, most of these could be explicitly given (at least to a 
>> function) when calling it as the import/export filter for a protocol with a 
>> „where“ clause, but that would defeat the purpose of using templates (which 
>> I really do like and use a lot).
>> 
>> The general concept of having „globals“ inside functions/filters is already 
>> there - just presently only in the context of the route that is being 
>> evaluated. I’d like to see this expanded into other contexts as described 
>> above. 
> 
> That is an interesting idea and also seems simple, although there are
> some caveats, e.g. filters using such context-dependent-constants would
> probably work for 'show route filter'.

Yes, I had forgotten about this (very useful) feature. However, the syntax for 
this could be easily amended to allow the definition of such variables via the 
command line, i.e.,

show route filter foo(a=1, b="bla", ...)

> It may be useful if you could make
> a list of suggested constants.

Well ... here is what comes to mind easily:
(NB: these are not the "names" of the variables I propose; we should come up 
with a good naming scheme once we settled on an initial list of variables)

router id
protocol name
protocol type
address family / channel-type
local as
remote as
local interface name (outbound interface)
local address (outbound interface)
remote address 
external variables (see below)

Variables, of course, only have values inside "useful" contexts, i.e, AS number 
inside BGP, etc. and are otherwise "undefined".

I'l also like to propose the introduction of global variables (vs. existing 
constants), which can be set in the configuration file, via the command-line 
(i.e., "bird -D foo=42" and at runtime via birdc. Again, naming conventions 
have to be observed, etc. and the manual must emphasize on when exactly filters 
are evaluated and such.

But this would allow to build a config, whose behavior could be altered at 
runtime, i.e., start-up in "test-mode" and then later be switched over to 
"production-mode" through birdc (or any other tool using the API), among many 
ot

Making a wish ... errr ... *four* wishes! 😳

[Clemens Schrimpe]

Gentlepeople (especially those from the BIRD development team) -

being an avid BIRD user for some time now I always kept a small list of „it 
would be nice, if …“-things for BIRD 1.x, which I kept for myself, as I knew 
BIRD 2.x was in the works (and thus people were busy already…), but now I get 
the feeling, that 2.x is slowly stabilizing and I’d like to put them on the 
table for open discussion:

Simple things, a.k.a. low hanging fruits:

(Optional) unicast replies to IPv6 RS

As one of my many uses for BIRD is in large wireless environments (i.e., IETF 
meetings) I am very interested in keeping the amount of multicast traffic as 
low as possible. The standards allow for a router to (immediately) respond with 
a unicast RA to an RS as an alternative to sending out a multicast RA „some 
(short, random) time“ after receiving an RS. Many others (Juniper, et.al.) have 
implemented this and I’d like to see this in BIRD too. The code changes are 
apparently very simple, so I almost did it myself, but then I didn’t want to 
interfere with ongoing 2.x developments.
(lame excuse, I know …)


Context dependent (global) „variables“ for functions/filters

I (and probably others too) would really enjoy having more global variables 
defined for use inside filters & functions, depending on the context within 
which the respective filter/function is being called. The most obvious ones 
would be the peer’s (and our own) AS number (in the context of BGP protocols), 
the filtering direction, the protocol (type and name), the next hop’s address 
(where applicable), and so on.

Yes, I know, most of these could be explicitly given (at least to a function) 
when calling it as the import/export filter for a protocol with a „where“ 
clause, but that would defeat the purpose of using templates (which I really do 
like and use a lot).

The general concept of having „globals“ inside functions/filters is already 
there - just presently only in the context of the route that is being 
evaluated. I’d like to see this expanded into other contexts as described 
above. 

Discuss! 😉😜


More „controversial“ things:

Maintain interface addresses (Linux et.al.)

It would be nice, if BIRD could be „enhanced“ [sic] to take care of addresses 
assigned to interfaces, i.e. establish them in the first place and afterwards 
maintain them, i.e., re-install static, global IPv6 addresses on interfaces, 
which have suffered a link-state bounce.
The latter is particularly interesting, since Linux -by design- removes global 
IPv6 addresses from an interface during a link-down state transition.

Rationale: The various Linux distributions have all sorts of (different and 
sometimes „funky“) implementations of how to establish addresses to interfaces 
in the first place and then „deal with them“ during link-state state changes. I 
would like to have BIRD take care of this relatively simple task as well as the 
way more complicated task of maintaining millions of routes. If only to have a 
clean way to define „a router“ within one system (BIRD) as opposed to „get the 
addresses onto the interfaces with a bunch of iproute2 commands and then start 
BIRD to take care of the rest“-approach I’ll have to use now. A simple „boot 
the machine and fire up BIRD - done“ one-stop-shopping solution, if you may. 😉

This is particularly interesting to smaller, dedicated routers, like (former) 
OpenWRT platforms, Raspberry Pis - or (my application) Ubiquiti routers of all 
shapes and sizes, where I presently replace the built-in Quagga Version with 
BIRD. Speaking of Quagga: It takes care of interface addresses too, you know … 
;-)


An „ipset“ protocol for Linux

It would be tremendously helpful to have a protocol, which would maintain given 
(named) „ipset “ tables on Linux. This would allow 
for very easy interactions with iptables-based ACLs on Linux platforms. It 
should/could be treated like a Linux route-table, just with less/different 
attributes. So it should „sync“, could possibly „import“ items from the ipset, 
could be made „persistent“, etc.

Applications are numerous: From fully automatic BCP38 handling at border 
interfaces to (again, fully automated) suppression of bogon traffic, to 
statistical analysis, to … whatever. It would be a single, well defined tool to 
interact with the whole world of capabilities the iptables/ipsets world offers.

If there is any interest in discussing the latter two any further I’d be very 
happy to spec them out in more detail, of course. 

Looking forward to hear what people think about these … 😳

Clemens

Re: BIRD v2.0.0-11-gc36a298 segmentation fault

[Clemens Schrimpe]

The fix came from Ondrej Zajicek, who also -I think- put it back upstream?!

Ondrej?

Hälsningar -

Clemens 

--
Von einem Mobiltelefon gesendet. Bitte die Kürze entschuldigen.
Sent from a mobile phone. Please excuse brevity. 

> Am 27.12.2017 um 18:17 schrieb Mike Neo :
> 
> is working properly - thx a lot :)
> 
> 2017-12-27 18:08 GMT+01:00 Clemens Schrimpe :
>> Build it like so:
>> 
>> make CLIENT_LIBS="-lreadline -ltinfo“
>> 
>> Greetings,
>> 
>> Clemens
>> 
>> --
>> Von einem Mobiltelefon gesendet. Bitte die Kürze entschuldigen.
>> Sent from a mobile phone. Please excuse brevity. 
>> 
>>> Am 27.12.2017 um 17:28 schrieb Mike Neo :
>>> 
>> 
>>> The problem is with birdc so I run birdc with strace, ok? :)
>>> 
>>> rt_sigprocmask(SIG_BLOCK, [HUP INT QUIT ALRM TERM TSTP TTIN TTOU], [], 8) = >>> 0
>>> rt_sigaction(SIGINT, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
>>> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
>>> rt_sigaction(SIGTERM, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
>>> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
>>> rt_sigaction(SIGHUP, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
>>> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
>>> rt_sigaction(SIGQUIT, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
>>> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
>>> rt_sigaction(SIGALRM, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
>>> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
>>> rt_sigaction(SIGTSTP, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
>>> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
>>> rt_sigaction(SIGTTOU, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
>>> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
>>> rt_sigaction(SIGTTIN, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
>>> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
>>> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
>>> rt_sigaction(SIGWINCH, {0x7f0889e45110, [], SA_RESTORER|SA_RESTART, 
>>> 0x7f08899e9390}, {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
>>> read(0, "[", 1) = 1
>>> rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 
>>> {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
>>> rt_sigaction(SIGTERM, {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 
>>> {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
>>> rt_sigaction(SIGHUP, {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 
>>> {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
>>> rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 
>>> {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
>>> rt_sigaction(SIGALRM, {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 
>>> {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
>>> rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 
>>> {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
>>> rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 
>>> {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
>>> rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 
>>> {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
>>> rt_sigaction(SIGWINCH, {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 
>>> {0x7f0889e45110, [], SA_RESTORER|SA_RESTART, 0x7f08899e9390}, 8) = 0
>>> select(4, [0 3], NULL, NULL, NULL)  = 1 (in [0])
>>> rt_sigprocmask(SIG_BLOCK, [HUP INT QUIT ALRM TERM TSTP TTIN TTOU], [], 8) = >>> 0
>>> rt_sigaction(SIGINT, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
>>> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
>>> rt_sigaction(SIGTERM, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
>>> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
>>> rt_sigaction(SIGHUP, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
>>> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
>>> rt_sigaction(SIGQUIT, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
>>> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
>>> rt_sigaction(SIGALRM, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
>>> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
>>> rt_sigaction(SIGTSTP, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
>>> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
>>> rt_sigaction(SIGTTOU, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
>>&g

Re: BIRD v2.0.0-11-gc36a298 segmentation fault

[Clemens Schrimpe]

Build it like so:

make CLIENT_LIBS="-lreadline -ltinfo“

Greetings,

Clemens

--
Von einem Mobiltelefon gesendet. Bitte die Kürze entschuldigen.
Sent from a mobile phone. Please excuse brevity. 

> Am 27.12.2017 um 17:28 schrieb Mike Neo :
> 
> The problem is with birdc so I run birdc with strace, ok? :)
> 
> rt_sigprocmask(SIG_BLOCK, [HUP INT QUIT ALRM TERM TSTP TTIN TTOU], [], 8) = 0
> rt_sigaction(SIGINT, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGTERM, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGHUP, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGQUIT, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGALRM, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGTSTP, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGTTOU, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGTTIN, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
> rt_sigaction(SIGWINCH, {0x7f0889e45110, [], SA_RESTORER|SA_RESTART, 
> 0x7f08899e9390}, {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> read(0, "[", 1) = 1
> rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 
> {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGTERM, {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 
> {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGHUP, {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 
> {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 
> {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGALRM, {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 
> {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 
> {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 
> {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 
> {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGWINCH, {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 
> {0x7f0889e45110, [], SA_RESTORER|SA_RESTART, 0x7f08899e9390}, 8) = 0
> select(4, [0 3], NULL, NULL, NULL)  = 1 (in [0])
> rt_sigprocmask(SIG_BLOCK, [HUP INT QUIT ALRM TERM TSTP TTIN TTOU], [], 8) = 0
> rt_sigaction(SIGINT, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGTERM, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGHUP, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGQUIT, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGALRM, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGTSTP, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGTTOU, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGTTIN, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
> rt_sigaction(SIGWINCH, {0x7f0889e45110, [], SA_RESTORER|SA_RESTART, 
> 0x7f08899e9390}, {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> read(0, "A", 1) = 1
> --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x8} ---
> +++ killed by SIGSEGV (core dumped) +++
> Segmentation fault (core dumped)
> 
> 
> 
> 2017-12-27 17:20 GMT+01:00 Michael McConnell :
>> Try running
>> 
>> strace -f bird -f -u bird -g bird
>> 
>> and providing the last 20 or 30 lines of the output.
>> 
>> --
>> Michael McConnell
>> WINK Streaming;
>> email: mich...@winkstreaming.com
>> toll free: 877-GO-4-WINK x 7400
>> direct: +1 312 281-5434
>> cell: +506 8706-2389
>> skype: wink-michael
>> web: http://winkstreaming.com
>> 
>>> On Dec 27, 2017, at 10:01 AM, Mike Neo  wrote:
>>> 
>>> Hi,
>>> 
>>> using up arrow in birdc causes segmentation fault:
>>> 
>>> 
>>> 
>>> syslog:
>>> 
>>> Dec 27 16:55:56 r1 kernel: [331700.979873] birdc[15259] segfa

Re: BIRD v2.0.0-11-gc36a298 segmentation fault

[Clemens Schrimpe]

You need to build it differently on Ubuntu.

Look further back on this mailing list and you‘ll find the solution. 
(Sending this from my phone, so tough to look up for me at the moment, sorry)

Clemens

--
Von einem Mobiltelefon gesendet. Bitte die Kürze entschuldigen.
Sent from a mobile phone. Please excuse brevity. 

> Am 27.12.2017 um 17:28 schrieb Mike Neo :
> 
> The problem is with birdc so I run birdc with strace, ok? :)
> 
> rt_sigprocmask(SIG_BLOCK, [HUP INT QUIT ALRM TERM TSTP TTIN TTOU], [], 8) = 0
> rt_sigaction(SIGINT, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGTERM, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGHUP, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGQUIT, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGALRM, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGTSTP, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGTTOU, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGTTIN, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
> rt_sigaction(SIGWINCH, {0x7f0889e45110, [], SA_RESTORER|SA_RESTART, 
> 0x7f08899e9390}, {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> read(0, "[", 1) = 1
> rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 
> {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGTERM, {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 
> {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGHUP, {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 
> {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 
> {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGALRM, {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 
> {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 
> {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 
> {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 
> {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGWINCH, {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 
> {0x7f0889e45110, [], SA_RESTORER|SA_RESTART, 0x7f08899e9390}, 8) = 0
> select(4, [0 3], NULL, NULL, NULL)  = 1 (in [0])
> rt_sigprocmask(SIG_BLOCK, [HUP INT QUIT ALRM TERM TSTP TTIN TTOU], [], 8) = 0
> rt_sigaction(SIGINT, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGTERM, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGHUP, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGQUIT, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGALRM, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGTSTP, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGTTOU, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigaction(SIGTTIN, {0x7f0889e45b60, [], SA_RESTORER, 0x7f08899e9390}, 
> {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
> rt_sigaction(SIGWINCH, {0x7f0889e45110, [], SA_RESTORER|SA_RESTART, 
> 0x7f08899e9390}, {SIG_DFL, [], SA_RESTORER, 0x7f08899e9390}, 8) = 0
> read(0, "A", 1) = 1
> --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x8} ---
> +++ killed by SIGSEGV (core dumped) +++
> Segmentation fault (core dumped)
> 
> 
> 
> 2017-12-27 17:20 GMT+01:00 Michael McConnell :
>> Try running
>> 
>> strace -f bird -f -u bird -g bird
>> 
>> and providing the last 20 or 30 lines of the output.
>> 
>> --
>> Michael McConnell
>> WINK Streaming;
>> email: mich...@winkstreaming.com
>> toll free: 877-GO-4-WINK x 7400
>> direct: +1 312 281-5434
>> cell: +506 8706-2389
>> skype: wink-michael
>> web: http://winkstreaming.com
>> 
>>> On Dec 27, 2017, at 10:01 AM, Mike Neo  wrote:
>>> 
>>> Hi,
>>> 
>>> using up arrow in birdc 

Re: Bird 2.0.0 and (filter) code deduplication

[Clemens Schrimpe]

> You can use ‘net.type = NET_IP4', 'net.type = NET_IP6'.

Nice …

And you can also „just“ mix IPv6 and legacy IPv4 matches in prefix-lists, etc.:

if net ~ [
2001:db8::/32+, # doc

fc00::/15+, # ULAs
fe80::/16+  # link locals

192.168.0.0/16+,# RFC1918
172.16.0.0/24+, # RFC1918
10.0.0.0/8+,# RFC1918
] then {


Works just fine with 2.0.0 …

-c

Re: Bird 2.0.0 and reconfiguring

[Clemens Schrimpe]

> Why bird restart all sessions when I type 'configuration soft' in birdc after 
> add one definition of protocol bgp? CPU usage is 100%, bird console hang for 
> 2-3mins.
> 
> With version 1.6.3 bird doesn't restart all sessions.

Saw this too when changing global logging options…

Clemens

(unfortunately) more BIRD-2.0.0 woes ...

[Clemens Schrimpe]

Hello again -

a couple of days ago I converted one of my test route-server setups from „dual 
BIRD-1.6.3“ to „single BIRD-2.0.0“ by simply „merging“ bird6.conf and bird.conf 
into a single (unified) new bird.conf - also observing the guidelines laid out 
in https://gitlab.labs.nic.cz/labs/bird/wikis/transition-notes-to-bird-2 
 . 

The results of this simple approach are between weird and stunning:

I now have a bird process which is consuming 100% of one CPU. It is still 
talking to me through birdc, but is very sluggish, i.e. bringing up peers or 
tearing them down takes a long time - you even see states, like „flushing“ in 
„show proto all XXX“ for quite some time, which you normally don’t even notice, 
because they are usually very transitive :-)

I haven’t gotten deeper into the problem, yet, but there appears to be a loop 
involving the affected peer’s Export Updates:

Route change stats: received   rejected   filteredignored   accepted
  Import updates: 670962  0  0  0 670962
  Import withdraws:  216  0---  0216
  Export updates:  317034802  159525749  157509053---  0
  Export withdraws:  468---------  0

(those numbers are increasing fast)

Some of my peers were/are already MP-BGP capable and so some IPv6 peers now 
came up with „Hey, you speak IPv4 too? Cool! Here are some 700.000 routes for 
your, my friend!“, which is totally explicable, yet it surprised my a teeny 
bit, anyway :-)

It should be made clear in the documentation, that BGP protocol definitions 
without explicit address-family → „channel“ definitions my eventually (see 
below) ending up MP-BGP sessions with the above effect!?

Most surprising: My multiple-inheritance approach, using multiple, chained 
template definitions for my BGP „protocols“/sessions/peers broke in the 
weirdest way: I now have multiple IPv6 and IPv4 channels on some of my 
protocols with different parameterizations:

bird> show protocols all BOGONS6
Name   Proto  Table  State  Since Info
BOGONS6BGP---up 17:04:11.929  Established   
  BGP state:  Established
Neighbor address: 2620:0:6b0::26e5:4207
Neighbor AS:  65332
Neighbor ID:  38.229.66.20
Local capabilities
  Multiprotocol
AF announced: ipv4 ipv4 ipv6 ipv6
  Route refresh
  Graceful restart
Restart time: 120
AF supported: ipv4 ipv6
AF preserved:
  4-octet AS numbers
  ADD-PATH
RX: ipv4 ipv6
TX: ipv4 ipv6
  Enhanced refresh
Neighbor capabilities
  Multiprotocol
AF announced: ipv6
  Route refresh
  4-octet AS numbers
Session:  external multihop AS4
Source address:   2001::2c9b
Hold timer:   120.187/240
Keepalive timer:  2.682/80
  Channel ipv6
State:  UP
Table:  master6
Preference: 100
Input filter:   ACCEPT
Output filter:  REJECT
Routes: 0 imported, 0 filtered, 0 exported
Route change stats: received   rejected   filteredignored   accepted
  Import updates:  0  0  0  0  0
  Import withdraws:0  0---  0  0
  Export updates:  49787  0  49787---  0
  Export withdraws:  261---------  0
BGP Next hop:   2001::2c9b
IGP IPv6 table: master6
  Channel ipv4
State:  DOWN
Table:  master4
Preference: 100
Input filter:   ACCEPT
Output filter:  REJECT
IGP IPv4 table: master4
  Channel ipv6
State:  UP
Table:  master6
Preference: 100
Input filter:   no_defaults
Output filter:  REJECT
Routes: 0 imported, 0 exported
Route change stats: received   rejected   filteredignored   accepted
  Import updates:  0  0  0  0  0
  Import withdraws:0  0---  0  0
  Export updates:  49787  0  49787---  0
  Export withdraws:  261---------  0
BGP Next hop:   2001:XXX:2c9b
IGP IPv6 table: master6
  Channel ipv4
State:  DOWN
Table:  master4
Preference: 100
Input filter:   no_defaults
Output filter:  REJECT
IGP IPv4 table: master4

This appears to be the result of 

template bgp ALL_BGP {
local as MY_AS;
ipv6 {
add paths on;
graceful restart on;
import keep filtered on;
};
ipv4 {
add paths on;
gracefu

Re: (unfortunately) more BIRD-2.0.0 woes ...

[Clemens Schrimpe]

I forgot:

4. „dest = RTD_BLACKHOLE“ does appear to no longer be functioning as well … ;-(

Clemens

Re: birdc 2.0.0 crashes

[Clemens Schrimpe]

> Could you try to build bird/birdc (without any patches i sent before) using:
> 
>  make CLIENT_LIBS="-lreadline -ltinfo"
> 
> ?

And indeed, this fixes it and persistent history still works! 

\o/

Clemens

PS: for your records (again) - this machine run Ubuntu 16.04.3 LTS in a 
(mostly) vanilla fashion. I just installed libreadline6-dbg to help with this 
case. So the same problem/solution *should* apply on other machines as well!?
 

Re: birdc 2.0.0 crashes

[Clemens Schrimpe]

> On 14.12.2017, at 14:18, Ondrej Zajicek  wrote:
> 
> What is output of ldd birdc for 1.6.3?

# for 2.0.0
newnoc:~/builds/bird-2.0.0# ldd birdc
linux-vdso.so.1 =>  (0x7ffeb07dd000)
libhistory.so.6 => /lib/x86_64-linux-gnu/libhistory.so.6 
(0x7fcab708d000)
libreadline.so.6 => /lib/x86_64-linux-gnu/libreadline.so.6 
(0x7fcab6e47000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 
(0x7fcab6c1d000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7fcab6a0)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fcab6636000)
/lib64/ld-linux-x86-64.so.2 (0x55a00f20b000)

# for 1.6.3
newnoc:~/builds/bird-2.0.0# ldd /usr/local/sbin/birdc
linux-vdso.so.1 =>  (0x7ffcbb5d2000)
libreadline.so.6 => /lib/x86_64-linux-gnu/libreadline.so.6 
(0x7f8e4bd8c000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 
(0x7f8e4bb63000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f8e4b945000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f8e4b57b000)
/lib64/ld-linux-x86-64.so.2 (0x557f92c5)

Salutations -

Clemens

Re: birdc 2.0.0 crashes

[Clemens Schrimpe]

> And "p history_offset"? Should be 0.

Nope - it is 2:

Program received signal SIGSEGV, Segmentation fault.
0x779b6a0b in previous_history () at 
/build/readline6-RKA9OI/readline6-6.3/history.c:185
185 /build/readline6-RKA9OI/readline6-6.3/history.c: No such file or 
directory.
(gdb) p history_offset
$1 = 2
(gdb) p *(the_history[2])
Cannot access memory at address 0x10

We are up to something! :-)

-c

PS: I did: Invoke birdc, „show proto\n“, either ^P or ↑ → 💣

Re: birdc 2.0.0 crashes

[Clemens Schrimpe]

> Use "bt full".
> 
> What’s "p the_history" and "p the_history[0]"?

Looks legit:

Program received signal SIGSEGV, Segmentation fault.
0x779b6a0b in previous_history () at 
/build/readline6-RKA9OI/readline6-6.3/history.c:185
185 /build/readline6-RKA9OI/readline6-6.3/history.c: No such file or 
directory.
(gdb) bt full
#0  0x779b6a0b in previous_history () at 
/build/readline6-RKA9OI/readline6-6.3/history.c:185
No locals.
#1  0x779b65e5 in rl_get_previous_history (count=, 
key=) at /build/readline6-RKA9OI/readline6-6.3/misc.c:609
old_temp = 0x0
temp = 0x0
key = 
count = 1
#2  0x7799b990 in _rl_dispatch_subseq (key=65, map=, 
got_subseq=0) at /build/readline6-RKA9OI/readline6-6.3/readline.c:832
r = 0
newkey = 
func = 
cxt = 
#3  0x7799c202 in _rl_dispatch_callback (cxt=0x61cb10) at 
/build/readline6-RKA9OI/readline6-6.3/readline.c:736
nkey = 
r = 
#4  0x779b27ff in rl_callback_read_char () at 
/build/readline6-RKA9OI/readline6-6.3/callback.c:188
line = 
eof = 
jcode = 
olevel = {{__jmpbuf = {6319136, 7997659007791416985, -1, 0, 4212971, 
6319559, 7997659007814485657, 7997676843090331289}, __mask_was_saved = 0, 
__saved_mask = {__val = {0 
#5  0x00403885 in input_read () at client/birdc.c:219
No locals.
#6  0x004020d3 in select_loop () at client/client.c:375
select_fds = {__fds_bits = {1, 0 }}
rv = 
#7  main (argc=, argv=) at client/client.c:447
No locals.
(gdb) p the_history
$1 = (HIST_ENTRY **) 0x609470
(gdb) p the_history[0]
$2 = (HIST_ENTRY *) 0x609630
(gdb) p *(the_history[0])
$3 = {line = 0x609650 „show protocols „, timestamp = 0x609610 "", data = 0x0}


Double-plus-weird!

I keep digging … 

Clemens

Re: birdc 2.0.0 crashes

[Clemens Schrimpe]

>> Yes, works fine. And it also appears to be read when I restart birdc, 
>> because now I can crash it with ^P or ↑ without having typed a command 
>> before.
>> (strace confirmed: .birdc_history is read successfully)
> 
> You can try attached patch (disables reading of history).

... to no avail ... still crashes the same way.


> You can also try to build BIRD 1.6.3 in the same way like 2.0.0 and see
> if it by chance does not express the same problem.

No, it doesn't (I built the 2.0.0 the same way as the 1.6.3 - and all the 
others).

Running the 2.0.0 client inside gdb yields: (I installed libreadline6-dbg 
before testing)

bird> 
Program received signal SIGSEGV, Segmentation fault.
0x779b6a0b in previous_history () at 
/build/readline6-RKA9OI/readline6-6.3/history.c:185
185 /build/readline6-RKA9OI/readline6-6.3/history.c: No such file or 
directory.
(gdb) bt
#0  0x779b6a0b in previous_history () at 
/build/readline6-RKA9OI/readline6-6.3/history.c:185
#1  0x779b65e5 in rl_get_previous_history (count=, 
key=)
at /build/readline6-RKA9OI/readline6-6.3/misc.c:609
#2  0x7799b990 in _rl_dispatch_subseq (key=65, map=, 
got_subseq=0)
at /build/readline6-RKA9OI/readline6-6.3/readline.c:832
#3  0x7799c202 in _rl_dispatch_callback (cxt=0x61cb10) at 
/build/readline6-RKA9OI/readline6-6.3/readline.c:736
#4  0x779b27ff in rl_callback_read_char () at 
/build/readline6-RKA9OI/readline6-6.3/callback.c:188
#5  0x00403885 in input_read () at client/birdc.c:219
#6  0x004020d3 in select_loop () at client/client.c:375
#7  main (argc=, argv=) at client/client.c:447

Maybe this provides a hint?!


And here's another interesting datapoint: Since I use BIRD to replace the 
dreadful Quagga-derivate Ubiquiti delivers with their EdgeRouters I compiled 
BIRD-2.0.0 for the MIPS platform and there it does not exhibit the observed 
behavior! 

Same libreadline version, though:

csch# ldd ./birdc-2.0.0 
librt.so.1 => /lib/mips-linux-gnu/librt.so.1 (0x77118000)
libhistory.so.6 => /lib/mips-linux-gnu/libhistory.so.6 (0x770ff000)
libreadline.so.6 => /lib/mips-linux-gnu/libreadline.so.6 (0x770b5000)
libtinfo.so.5 => /lib/mips-linux-gnu/libtinfo.so.5 (0x77087000)
libpthread.so.0 => /lib/mips-linux-gnu/libpthread.so.0 (0x7705c000)
libc.so.6 => /lib/mips-linux-gnu/libc.so.6 (0x76ee1000)
/lib/ld.so.1 (0x77136000)

Maybe I should download the src for libreadline6 to look at history.c, line 185 
;-)

Hälsningar -

Clemens

Re: birdc 2.0.0 crashes

[Clemens Schrimpe]

> Note that .birdc_history is created during exit from birdc, not during
> start of birdc. Do you get .birdc_history if you use new birdc, do some
> commands and exit from it without crashing it?

Yes, works fine. And it also appears to be read when I restart birdc, because 
now I can crash it with ^P or ↑ without having typed a command before.
(strace confirmed: .birdc_history is read successfully)

> What version of readline and history libraries do you have?

~/builds/bird-2.0.0> ldd birdc
linux-vdso.so.1 =>  (0x7fff445fa000)
libhistory.so.6 => /lib/x86_64-linux-gnu/libhistory.so.6 
(0x7f41f2bfd000)
libreadline.so.6 => /lib/x86_64-linux-gnu/libreadline.so.6 
(0x7f41f29b7000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 
(0x7f41f278d000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f41f257)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f41f21a6000)
/lib64/ld-linux-x86-64.so.2 (0x55d339f07000)

/var/log/syslog has:

Dec 12 16:45:37 kernel: birdc[6756]: segfault at 10 ip 7f0243394a0b sp 
7ffec5ef7df8 error 4 in libreadline.so.6.3[7f0243366000+3d000]

Groetjes,

Clemens

birdc 2.0.0 crashes

[Clemens Schrimpe]

Hello all -

I just compiled and installed BIRD 2.0.0 on a x86_64 Ubuntu 16.04.3 LTS (with 
ZFS root) test-machine and (most) things look pretty dandy so far.

Though ... birdc crashes inside lib-readline when I attempt to go back in the 
command history (^P or ↑), but only if there already is something to go back 
to. It also fails to create the .birdc_history file in the first place. 
Thankfully the 1.6.3 birdc still works fine, so I can continue playing for now.

Has anyone else found this as well already? Otherwise I'd dig deeper (would 
have to install debug tools on the target machine, etc.)

Thanks,

Clemens

PS: Great Work, Team!!! I really appreciate your efforts!

Re: Bird - hardware, vm.

[Clemens Schrimpe]

Just FYI: I use BIRD very successfully on Ubiquiti’s Edgerouters - from ER-X 
(€40) to EdgeRouter-Infitity (10Gbps → €1100).

Greetings,

Clemens

Re: Limit on how many neighbors

[Clemens Schrimpe]

RIPNG/RIPv2 could carry a handful (or two :-) for your purposes. 

Clemens

--
Von einem Mobiltelefon gesendet. Bitte die Kürze entschuldigen.
Sent from a mobile phone. Please excuse brevity. 

> Am 14.10.2017 um 19:27 schrieb Magnus Löfqvist :
> 
> Hi again,
> 
> Just a throught, we dont need our endpoints to know about each other, in 
> fact, we do firewalling not to allow traffic between them.
> 
> Are there any better solutions, instead of ospf, where we can have more than 
> 100 endpoints getting there routes from a central server, and where we dont 
> need to specify evry neigboor at the system?
> 
> / Magnus
> 
> Från: Magnus Löfqvist
> Sänt: 13 okt. 2017 23:31
> Till: Ondrej Zajicek
> Kopia: bird-users@network.cz 
> Ämne: Re: Limit on how many neighbors
> 
> Hi,
> 
> I agree with you, it should not be the case here.
> But,  we are running over mobile networks, and the openvpn adds some overhead.
> 
> Running some tcpdump shows that the packet lenght of the hello packet is just 
> about 480, and that should be ok.
> 
> If we change to another openvpn instance/interface and change over to that it 
> works directly.
> 
> I have also updated bird on our mainrouter to 1.6.3 (latest), but the issue 
> still exist. 
> 
> I have attached our config files (bird.conf (mainrouter), bird_client.conf 
> (from one of the end router)). 
> My OSPF knowlege are limited, so I guess that I have made some errors :)
> 
> The main feature we need is to distribute some external routes (10.3.50.0/24, 
> 10.3.60.0/24), and distribute back the endpoints IP networks (10.98.x.x/30)
> 
> / Magnus
> 
> Från: Ondrej Zajicek 
> Sänt: 13 okt. 2017 13:13
> Till: Magnus Löfqvist
> Kopia: bird-users@network.cz 
> Ämne: Re: Limit on how many neighbors
> 
> On Thu, Oct 12, 2017 at 11:43:03AM +, Magnus Löfqvist wrote:
> > Hi,
> > 
> > We are running Bird with OSPF between embedded routers (openwrt) (mobile 
> > routers).
> > The routers are connected to our main server with openvpn, and we are using 
> > bird ontop on openvpn to deliver routes to the end routers.
> > 
> > This have worked quite well, but today we notice some glitches.
> > We had some routers that did not finish election (ie, stand in init instead 
> > of being full).
> > When we count, there are exactly 100 devices that are in "full", and 3 in 
> > init.
> > 
> > Are there any limit on how many neighbors/routers?
> 
> Hi
> 
> There is AFAIK no hard limit, but there is an issue that if you have too
> many neighbors, you end with Router-LSA that does not fit into MTU and
> will be sent using fragmented IP packets. Which usually works, but may be
> problematic. But that is probably not relevant, as if there were such
> problem, they would stuck in later stage of exchange and not in 'init'.
> 
> So i have no idea why they stuck in 'init'. Isn't there any
> misconfiguration? Is there anything in logs? Did they corrected after
> restart?
> 
> -- 
> Elen sila lumenn' omentielvo
> 
> Ondrej 'Santiago' Zajicek (email: santi...@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."

IETF-99

[Clemens Schrimpe]

Hi -

will any of the core developers be present at IETF99 in Praha this week and if 
so: Where could I meet you?

Thanks -

Clemens
IETF Meeting NOC (yes, we do use BIRD in the IETF meeting network! :-)

Re: ospf networks IPv4 IPv6

[Clemens Schrimpe]

> A constant prefix set would be helpful to have the same OSPF
> configuration for IPv4 and IPv6 where the constant itself would be
> defined in specific files separate for IPv4 and IPv6.

Similar situation re: interface names - those as well cannot come out of a 
defined constant at present.

Would be a "nice to have" for the exact same reason: Having a common config 
file for bird and bird6, just with different constants.

Greetings,

Clemens

Re: [Feature request] DHCPv6 protocol

[Clemens Schrimpe]

I also agree that a full DHCPv6-Server would be a bit of an "overload", what 
with keeping persistent state and all …

But for bird6 I'd appreciate another (small!) addition: The ability to respond 
to RSs with unicast RAs instead of the (usual) multicast. RAs.
(Scenario: Large L2s with wireless devices)

Unsolicited RAs (if enabled) should still be issued as multicast, of course…

Thanks for considering! 😉👍🏻

Clemens 

Re: BLACKHOLE community RFC7999

[Clemens Schrimpe]

>> Just FYI: https://www.rfc-editor.org/rfc/rfc7999.txt
>> I guess this feature deserves to be implemented.
> 
> Oh, sure. We plan to implement it.

It would be nice if export filters for the Kernel protocol could set a route 
type, as in iproute(8):

TYPE := [ unicast | local | broadcast | multicast | throw |
  unreachable | prohibit | blackhole | nat ]

That would probably make more versatile than a static RFC7999 hack, while 
allowing to easily implement RFC7999 and others.

Greetings,

Clemens

OSPF "hack translation" sought

[Clemens Schrimpe]

Gentlepeople -

I was wondering what the "translation" of the usual hack on Quagga/JunOS/etc. 
for OSPF into a proper BIRD config was to allow OSPF to propagate routes to 
directly connected networks, which are not really part of an OSPF area. In 
those other systems I would make those interfaces just "passive" members, but 
BIRD doesn't know "passive interfaces". Making them stubs has obvious other 
side effects, which is why I just want the "passive" hack to work under BIRD. 

So what's the equivalent to do this in BIRD? 

Thanks,

Clemens Schrimpe



smime.p7s
Description: S/MIME cryptographic signature