0.1.32-rc5 fails on large sets?

[Job Snijders]

job@scarlett:~/src/bgpq3-0.1.32-rc5$ ./bgpq3 | grep version
bgpq3 version: 0.1.32-rc5

job@scarlett:~/src/bgpq3-0.1.32-rc5$ ./bgpq3 -d -b -A -4 -h rr.ntt.net AS2914:AS-GLOBAL
DEBUG: bgpq_expander.c:734 bgpq_expand Acquired sendbuf of 4608 bytes
DEBUG: bgpq_expander.c:763 bgpq_expand Requesting sources !sripe,radb,apnic
DEBUG: bgpq_expander.c:767 bgpq_expand Got answer C
DEBUG: bgpq_expander.c:589 bgpq_expand_irrd expander: sending '!iAS2914:AS-GLOBAL,1
'
DEBUG: bgpq3_printer.c:627 bgpq3_print_bird_prefixlist skip empty prefix-list in BIRD format

With version 0.1.31 this does work.

[Alexandre Snarskii]

On Tue, Jul 28, 2015 at 12:01:08AM -0700, Job Snijders wrote:

job@scarlett:~/src/bgpq3-0.1.32-rc5$ ./bgpq3 | grep version
bgpq3 version: 0.1.32-rc5

job@scarlett:~/src/bgpq3-0.1.32-rc5$ ./bgpq3 -d -b -A -4 -h rr.ntt.net AS2914:AS-GLOBAL
DEBUG: bgpq_expander.c:734 bgpq_expand Acquired sendbuf of 4608 bytes
DEBUG: bgpq_expander.c:763 bgpq_expand Requesting sources !sripe,radb,apnic
DEBUG: bgpq_expander.c:767 bgpq_expand Got answer C
DEBUG: bgpq_expander.c:589 bgpq_expand_irrd expander: sending '!iAS2914:AS-GLOBAL,1
'
DEBUG: bgpq3_printer.c:627 bgpq3_print_bird_prefixlist skip empty prefix-list in BIRD format

With version 0.1.31 this does work.

AS2914:AS-GLOBAL registered with NTTCOM souce:

snar@fri:~>whois -h rr.ntt.net AS2914:AS-GLOBAL | grep source:
source: NTTCOM
source: NTTCOM

and since 0.1.32-rc2 this source is not trusted by default:

0.1.32-rc2 (2015-07-01)
- bugfix: when no sources provided in command line and via IRRD_SOURCES env,
no source limitation were sent to IRRd. Thanks to Mikhail A. Grishin.

So you have either add -S ripe,radb,apnic,nttcom (and whatever other
registries you trust) to command line or export enviroinment variable
IRRD_SOURCES containing trusted registries:

snar@fri:/compile/bgpq3>export IRRD_SOURCES=ripe,radb,apnic,nttcom
snar@fri:/compile/bgpq3>echo $IRRD_SOURCES
ripe,radb,apnic,nttcom

PS: yeah, this is major change and that's why 0.1.32 got into -rc stage
instead of new release. Still considering shall this bugfix make its
way to 0.1.32 or is it better to split bgpq3 into -stable (with old
behaviour of trusting all the sources) and -devel versions with new
behaviour and all the bugfixes/features since 0.1.31.

[Job Snijders]

fixed in d5036d1