snar / bgpq3 Goto Github PK

On bgpq3 0.1.35, when the -s argument is passed and the prefix list ends up being empty, the fallback prefix list does not use sequence numbers.

For example with the command: $ bgpq3 -S RIPE,ARIN,APNIC,AFRINIC -4 -s -l AS714-IN AS714:

Expected:

no ip prefix-list AS714-IN
! generated prefix-list AS714-IN is empty
ip prefix-list AS714-IN seq 1 deny 0.0.0.0/0

Actual:

no ip prefix-list AS714-IN
! generated prefix-list AS714-IN is empty
ip prefix-list AS714-IN deny 0.0.0.0/0

RADb does not give data sometimes.
This happens very rarely (once a month) , so I can’t find the exact cause.

Is it possible not to print a standard template, if bgp3 got 0 networks?
Now I get (if the problem happened)

bgpq3 -J -S radb,ripe -l Client AS-CLIENT
  policy-options {
    replace:
      prefix-list Client {
      }
  }

And the client without networks :(

Freebsd 10.3, IPV6 disabled....
bgpq3-master (latest)
How to fix error when running:
ERROR:Unable to create socket: Address family not supported by protocol family

Hello

I think there is a small error when generating as-patch filter for Huawei: absent "_" in position ([0-9]+)*

Example:
#bgpq3 -f100 -3 -l"huawei_filter" -U as-eltel
undo ip as-path-filter huawei_filter
ip as-path-filter huawei_filter permit ^100([0-9]+)*_(20597|35357)$

Must be:
ip as-path-filter huawei_filter permit ^100(_[0-9]+)*_(20597|35357)$

My diff for file bgpq3_printer.c are given below.
Best regards.
Alexander.

be careful, stupid editing, special characters may not be displayed
------------------------------------------------------------------------
diff -u bgpq3_printer.c.ORIG bgpq3_printer.c
--- bgpq3_printer.c.ORIG 2021-06-10 17:31:33.000000000 +0500
+++ bgpq3_printer.c 2021-06-10 17:48:21.000000000 +0500
@@ -442,7 +442,7 @@
if(b->asnumber!=0 && b->asn32s[b->asnumber/65536] &&
b->asn32s[b->asnumber/65535][(b->asnumber%65536)/8]&
(0x80>>(b->asnumber%8))) {
- fprintf(f,"ip as-path-filter %s permit ^%u(%u)$\n",
+ fprintf(f,"ip as-path-filter %s permit ^%u(_%u)$\n",
b->name?b->name:"NN",b->asnumber,b->asnumber);
empty=0;
};
@@ -454,7 +454,7 @@
if(b->asnumber!=0 && k65536+i8+j==b->asnumber)
continue;
if(!nc && b->asnumber!=0) {
- fprintf(f,"ip as-path-filter %s permit ^%u([0-9]+)"
+ fprintf(f,"ip as-path-filter %s permit ^%u(_[0-9]+)"
"_(%u",
b->name?b->name:"NN",b->asnumber,k65536+i8+j);
empty=0;

htj@pyrite:$ bgpq3 -jf1 -S JPIRR AS-SINET
{"NN": [
2501,2503,2504,2505,2506,2508,2513,2523,
2907,3488,4707,4729,4730,7509,7531,7660,
9355,9367,9372,9591,9991,10014,17521,17523,
17532,17674,17687,17701,17932,17943,17944,17946,
17956,17960,18076,18087,18091,18123,18124,18125,
18127,18128,18148,18267,18276,18279,18286,23456,
23615,23623,23781,23793,23799,23800,23803,23807,
23826,24248,24254,24260,24261,24264,24268,24287,
24297,24470,37889,37895,37909,37910,37914,37917,
37918,37920,37984,38635,38641,45673,45685,45688,
55372,55373,55379,55380,55390,55904,55909,55910,
55911,55912,56218,58647,58652,58784,58785,59091,
59096,59100,59103,59104,59111,59115
]}
htj@pyrite:$ bgpq3 -jf1 -S RIPE AS-SINET
{"NN": [
6736,12880,15611,21341,25306,34918,42586,43135,
43343,43395,44889,49100,56796,59961,62367
]}
htj@pyrite:~$ bgpq3 -jf1 -S RIPE,JPIRR AS-SINET
{"NN": [
6736,12880,15611,21341,25306,34918,42586,43135,
43343,43395,44889,49100,56796,59961,62367
]}

Is this intentional? If I specify multiple sources, I'd expect the result from both to be included.

bgpq3 version is 0.1.31 (and same behaviour with .30)

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.

$ bgpq3 -X as234
no prefix-set NN
prefix-set NN
 192.131.22.0/24,
 204.212.44.0/22
end-set

should be:

$ bgpq3 -X as234
no prefix-set NN
prefix-set NN
  192.131.22.0/24,
  204.212.44.0/22
end-set

not a big deal, but it makes comparison harder

I have a use-case where I would need to expand an AS-Macro into AS-numbers but not further into prefixes, preferably with the JSON output mode.

This morning we noticed some RIPE prefixes are missing. The prefixes are all new, from 2023.
For example 80.96.110.0/24 is missing from AS20929.
bgpq3 version: 0.1.36.1

$ whois -h whois.ripe.net -T route -i origin AS20929 | grep route
route: 194.50.174.0/24
route: 217.156.52.0/24
route: 80.96.110.0/24

$ bgpq3 -S RIPE AS20929
no ip prefix-list NN
ip prefix-list NN permit 194.50.174.0/24
ip prefix-list NN permit 217.156.52.0/24

Hi there,

Could you please tag a new release in the near future? From what I can tell, there have been multiple new features and bugfixes added to bgpq3 since 2018 November, the last time a release was tagged.

It'd make it much easier for package / distribution maintainers to ship a newer, more feature-complete (and more stable) version of bgpq3 if a new release were to be tagged.

Thanks!

Hi!

I noticed that at least two files, strlcpy.c and sys_queue.h, have 3-clause BSD licences.

The third clause is missing from COPYING, making GitHub's licence guess also incorrect.

Hi

I seem to be getting the following errors when I do the following

~$ /usr/bin/bgpq3 -3b -l xxx -f 8359 AS-MTU
ERROR:Invalid symbol in AS number: '?' in AS271754 

~$ /usr/bin/bgpq3 -3b -l xxx -f 9002 AS-RETN
ERROR:Invalid symbol in AS number: 'â' in AS271754

~$ /usr/bin/bgpq3 -3b -l xxx -f 9498 AS9498:AS-BHARTI-IN
ERROR:Invalid symbol in AS number: '?' in AS271754 

~$ /usr/bin/bgpq3 -3b -l xxx -f 45474 AS45474:AS-NEXUSGUARD
ERROR:Invalid symbol in AS number: '?' in AS271754 

I spoke to RADB and they said it was an issue with BGPQ3. Have tested with versions 0.1.33 and 0.1.35 .

Any ideas if anyone can replicate this ? I have been able to over 5 different servers and if I choose a different source its pretty clean.

Thanks
Mo

Hey there!

When I was querying AS200070, it returned some prefixes, however it did not return all of the ones it should.

bgpq3 -S RIPE AS200070
no ip prefix-list NN
ip prefix-list NN permit 185.43.134.0/24
ip prefix-list NN permit 194.0.12.0/24
ip prefix-list NN permit 194.0.14.0/24
ip prefix-list NN permit 212.237.229.0/24

But as you can see in the image below, there is a prefix that RIPE says is advertised but BGPQ3 doesnt return.

Is this a known issue?

bgpq3 -Jl test AS54456 -A -E
policy-options {
 policy-statement test {
replace:
  from {
    route-filter 199.116.76.0/22 prefix-length-range /24-/24;
  }
 }
}

Shows wrong prefix length range. Should be /22 - /24. Same if I try to generate Cisco config:

bgpq3 -l test AS54456 -A
no ip prefix-list test
ip prefix-list test permit 199.116.76.0/22 ge 24 le 24

Should have been ge 22 le 24

Add support for Huawei devices (-H) to output Huawei as-path access-lists.

Eg.
./bgpq3 -f 39651 AS-COMHEM -H
ip as-path-filter NN permit ^39651(39651)*$
ip as-path-filter NN permit ^39651([0-9]+)*_(25037|28942|56563|59835)$

It seams if in an IP-network a leading zero is in the route object, an error is thrown,
this happens for me with this route object:

route: 02.51.252.0/22
descr: Proxy-registered route object
origin: AS4787
notify: [email protected]
mnt-by: MAINT-AS9304
changed: [email protected] 20080418
source: RADB

Resulting in the following error:

bgpq3 -d AS4787
DEBUG: bgpq_expander.c:352 bgpq_pipeline expander: sending '!gas4787
'
ERROR:Unable to parse prefix 02.51.252.0/22, af=2
ERROR:Unable to parse prefix 02.51.252.0/22
ERROR:Unable to parse prefix 02.51.252.0/22, af=2
ERROR:Unable to parse prefix 02.51.252.0/22

When the -M option is used, bgpq3 is significantly slower than without it. This even happens when building non-JUNOS filters, where -M actually becomes a no-op (i.e., the output is the same with or without it), as demonstrated here:

tore@echo:~/git/bgpq3$ time bgpq3 AS-TELENOR | md5sum 
578aff1c367b9d96fa0b57a4daafc709  -

real    0m0.847s
user    0m0.007s
sys 0m0.005s
tore@echo:~/git/bgpq3$ time bgpq3 -M foo AS-TELENOR | md5sum 
578aff1c367b9d96fa0b57a4daafc709  -

real    0m23.427s
user    0m0.009s
sys 0m0.021s

It seems odd to me that the -M option should have such a big effect on the program, after all it's just a string that should be included in Juniper-specific output, so the way I see it it shouldn't cause any additional heavy processing, network, traffic or anything else that could conceivably explain the observed slowdown.

Currently it is not possible to aggregate prefixes when prefix-lists are used:

sebastianw@sol:~ $ bgpq3 -J3Al as-example AS-EXAMPLE
FATAL ERROR:Sorry, aggregation (-A) does not work in Juniper prefix-lists
You can try route-filters (-E) instead of prefix-lists (-P, default)
[Exit 255] 

This would be an useful option to have when prefix-lists are used (as in our case) with prefix-list-filter like this:

[edit policy-options policy-statement bgp-example-filter term default]
set from prefix-list-filter as-example orlonger
set then accept

This will accept the prefixes in the prefix-list or longer prefixes. Using -A in that case would make the prefix-list much smaller.

Would you consider merging SpiderX's pull request that gives make DESTDIR support? To package bgpq3 for EPEL (and probably Debian, etc) requires a manual patch to the Makefile that would be better off handled upstream.

There seems to be some code in bgpq3 to deal with RIPE queries, but I have trouble following the logic and design behind it. In any regard bgpq3 currently does not handle RIPE queries correctly.

Vurt:bgpq3 job$ bgpq3 -d -h whois.ripe.net AS15562
DEBUG: bgpq_expander.c:378 bgpq_pipeline expander: sending '!gas15562
'
ERROR:Wrong reply: % Note: this output has been filtered.
 to !gas15562

no ip prefix-list NN
! generated prefix-list NN is empty
ip prefix-list NN deny 0.0.0.0/0

Vurt:bgpq3 job$ bgpq3 -6 -d -h whois.ripe.net AS15562
DEBUG: bgpq_expander.c:378 bgpq_pipeline expander: sending '-T route6 -i origin as15562
'
no ipv6 prefix-list NN
! generated prefix-list NN is empty
ipv6 prefix-list NN deny ::/0
Vurt:bgpq3 job$

$ bgpq3 -3f1 AS-HURRICANE |tail -n 3
ip as-path access-list NN permit ^1([0-9]+)*(525620|553259|559371|1973394)$
ip as-path access-list NN permit ^1([0-9]+)*(2629023|-94915195|-94914185)$

In as-dot:

$ bgpq3 -D3f1 AS-HURRICANE |tail -n 3
ip as-path access-list NN permit ^1([0-9]+)*(6.752|6.762|6.765|6.845)$
ip as-path access-list NN permit ^1([0-9]+)*(8.1332|8.28971|8.35083|30.7314)$
ip as-path access-list NN permit ^1([0-9]+)*(40.7583|64087.46469|64087.47479)$

$ grep 4200052101 *.db
radb.db:members: AS38883, AS38887, AS38900, AS38906, AS38911, AS4200052101
radb.db:members: AS393968, AS393978, AS394061, AS4200052101, AS4200053111
radb.db:members: AS393968, AS393978, AS394061, AS4200052101, AS4200053111

So AS-HURRICANE added private as numbers to their as-set AFAICT.

The set of private/special as number should probably be filtered out.
http://www.iana.org/assignments/iana-as-numbers-special-registry/iana-as-numbers-special-registry.xhtml

I guess that a signed int/long is used for as numbers. It should probably be an unsigned long.

Hello,
route-filter 38.35.64.0/18 prefix-length-range /19-/24; I think it should be 38.35.64.0/18 upto /24
Not sure why BGPQ make that prefix-length-range /19-/24

root@localhost:~/bgpq3# ./bgpq3 -AJEl ibgp-as32708-import-ipv4/from-as32708 -r 8 -R 24 AS-ROOTNETWORKS
policy-options {
 policy-statement ibgp-as32708-import-ipv4 {
  term from-as32708 {
replace:
   from {
    route-filter 23.191.192.0/24 exact;
    route-filter 23.247.5.0/24 exact;
    route-filter 23.247.9.0/24 exact;
    route-filter 23.247.44.0/24 exact;
    route-filter 23.247.48.0/24 exact;
    route-filter 23.247.56.0/24 exact;
    route-filter 23.247.62.0/24 exact;
    route-filter 23.247.103.0/24 exact;
    route-filter 23.247.111.0/24 exact;
    route-filter 38.18.152.0/21 upto /24;
    route-filter 38.21.16.0/20 upto /24;
    route-filter 38.35.64.0/18 prefix-length-range /19-/24;
    route-filter 38.106.9.0/24 exact;
    route-filter 38.145.224.0/19 upto /24;
    route-filter 38.240.128.0/21 upto /24;
    route-filter 45.65.44.0/22 upto /24;
    route-filter 85.92.100.0/22 upto /24;
    route-filter 102.140.80.0/20 upto /24;
    route-filter 103.91.56.0/22 upto /24;
    route-filter 103.108.188.0/23 upto /24;
    route-filter 103.115.204.0/23 upto /24;
    route-filter 103.143.86.0/23 upto /24;
    route-filter 103.211.0.0/22 upto /24;
    route-filter 103.213.244.0/22 upto /24;
    route-filter 104.148.0.0/24 exact;
    route-filter 104.148.10.0/24 exact;
    route-filter 104.148.46.0/24 exact;
    route-filter 123.253.104.0/22 upto /24;
    route-filter 123.253.108.0/24 exact;
    route-filter 154.27.128.0/19 upto /24;
    route-filter 156.0.76.0/22 upto /24;
    route-filter 181.214.226.0/23 upto /24;
    route-filter 181.214.232.0/22 upto /24;
    route-filter 181.215.245.0/24 exact;
    route-filter 191.96.35.0/24 exact;
    route-filter 191.96.72.0/23 upto /24;
    route-filter 191.96.78.0/24 exact;
    route-filter 191.96.92.0/24 exact;
    route-filter 191.96.114.0/24 exact;
    route-filter 191.101.204.0/22 upto /24;
   }
  }
 }
}

Feature request.

When -s is used in context of prefix-list generation, print as following example:

Vurt:bgpq3 job$ bgpq3 -s -6 AS15562
no ipv6 prefix-list NN
ipv6 prefix-list NN seq 1 permit 2001:67c:208c::/48
ipv6 prefix-list NN seq 2 permit 2001:67c:2980::/48
ipv6 prefix-list NN seq 3 permit 2001:728:1808::/48

ps. Arista does not have support for sequenced as-path lists, but it does help in some scenario's if sequence numbers are added when uploading a prefix-list.

Hello,

I have different results using -B and -b on the number of ASNs on the query, if I'm using the same AS and the same AS-SET this number should be the same, I'm right?

root@heimdall:# bgpq3 -T -h whois.radb.net -B -f 1299 AS-TELIANET | awk '{print $6}' | sort | uniq | wc -l
63725
root@heimdall:# bgpq3 -T -h whois.radb.net -b -f 1299 AS-TELIANET | tr ',' '\n' | sed 's/NN = [//' | sed 's/];//' | awk 'NF>0' | expand | sed 's/ //g' | sort | uniq | wc -l
44594

[]s

Nowadays IRRd has !6 as the counterpart of !g to expand AS(sets) into their respective IPv6 or IPv4 prefixes. The bgpq3 code would be simplified if RIPE-style queries are dropped in favor of IRRd-style queries.

Should !6 not work correctly, please file a bug at https://github.com/irrdnet/irrd/issues

This is broken in bgpq3-0.1.31

Expected output:

no ipv6 prefix-list NN
ipv6 prefix-list NN permit 2001:67c:1010::/47
ipv6 prefix-list NN permit 2001:67c:1010::/48
ipv6 prefix-list NN permit 2001:67c:1011::/48
ipv6 prefix-list NN permit 2001:7fe::/32
ipv6 prefix-list NN permit 2001:7fe::/33
ipv6 prefix-list NN permit 2001:dd8:10::/47
ipv6 prefix-list NN permit 2001:dd8:10::/48
ipv6 prefix-list NN permit 2001:dd8:11::/48
ipv6 prefix-list NN permit 2a01:3f1::/38
ipv6 prefix-list NN permit 2a01:3f1:3000::/38
ipv6 prefix-list NN permit 2a01:3f1:5000::/38
ipv6 prefix-list NN permit 2a01:3f1:8000::/38
ipv6 prefix-list NN permit 2a01:3f1:a000::/38
ipv6 prefix-list NN permit 2a01:3f1:c000::/38

Current output:

no ipv6 prefix-list NN
! generated prefix-list NN is empty
ipv6 prefix-list NN deny ::/0

Using the same function call on line 690 as the one on line 687 fixes it for this object (with pipeline disabled). It might break other things though.

Thanks!

Any hints? Seems broken since commit d787382

job@irime:/tmp/t/bgpq3$ ./configure && make
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for a BSD-compatible install... /usr/bin/install -c
checking for markdown_py... no
checking for markdown2... no
checking for markdown... markdown
checking for strlcpy... no
checking for socket in -lsocket... no
checking for getaddrinfo in -lnsl... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating config.h
gcc -g -O2 -DHAVE_CONFIG_H -g -Wall -I. -O0 -c bgpq3.c
gcc -g -O2 -DHAVE_CONFIG_H -g -Wall -I. -O0 -c sx_report.c
gcc -g -O2 -DHAVE_CONFIG_H -g -Wall -I. -O0 -c bgpq_expander.c
gcc -g -O2 -DHAVE_CONFIG_H -g -Wall -I. -O0 -c sx_slentry.c
gcc -g -O2 -DHAVE_CONFIG_H -g -Wall -I. -O0 -c bgpq3_printer.c
gcc -g -O2 -DHAVE_CONFIG_H -g -Wall -I. -O0 -c sx_prefix.c
sx_prefix.c: In function ‘sx_prefix_parse’:
sx_prefix.c:56:2: warning: implicit declaration of function ‘strlcpy’ [-Wimplicit-function-declaration]
  strlcpy(mtext, text, sizeof(mtext));
  ^
sx_prefix.c: In function ‘sx_prefix_range_parse’:
sx_prefix.c:198:2: warning: implicit declaration of function ‘isnumber’ [-Wimplicit-function-declaration]
  } else if (isnumber(d[1])) {
  ^
gcc -g -O2 -DHAVE_CONFIG_H -g -Wall -I. -O0 -c strlcpy.c
gcc -g -O2 -DHAVE_CONFIG_H -g -Wall -I. -O0 -c sx_maxsockbuf.c
gcc -g -O2 -DHAVE_CONFIG_H -g -Wall -I. -O0 -o bgpq3 bgpq3.o sx_report.o bgpq_expander.o sx_slentry.o bgpq3_printer.o sx_prefix.o strlcpy.o sx_maxsockbuf.o -lnsl
sx_prefix.o: In function `sx_prefix_range_parse':
/tmp/t/bgpq3/sx_prefix.c:198: undefined reference to `isnumber'
/tmp/t/bgpq3/sx_prefix.c:201: undefined reference to `isnumber'
collect2: error: ld returned 1 exit status
make: *** [bgpq3] Error 1

Hello,

we are running bgpq3 in a crontab and sometimes we get this error:
bgpq3 exit code is 255, stderr: b'FATAL ERROR:select timeout\n'

It happens randomly, not every time. Is there any reason why? How can I fix this? Do you need more info to see whats going on?

Hello,

Please tell me what happens when multiple Database Sources are specified with'-S flag'.

bgpq3 -S JPIRR,RIPE,RADB AS-IRR-NET

What kind of filter list will be generated if the following are registered in the IRR?

database sources : JPIRR
as-set           : AS-IRR-NET
members          : AS00001,AS00002,AS00003,AS00004

database sources : RIPE
as-set           : AS-IRR-NET
members          : AS00001,AS00003,AS00004

database sources : JPIRR
route            : 192.168.1.0/24
origin           : AS00001

database sources : RIPE
route            : 192.168.2.0/24
origin           : AS00002

database sources : RADB
route            : 192.168.3.0/24
origin           : AS00002

database sources : JPIRR
route            : 192.168.4.0/24
origin           : AS00003

database sources : RADB
route            : 192.168.4.0/24
origin           : AS00003

database sources : ARIN
route            : 192.168.5.0/24
origin           : AS00004

As far as I can see in the documentation and Issues, I expect the following filter to be generated:

no ip prefix-list NN
ip prefix-list NN permit 192.168.1.0/24
ip prefix-list NN permit 192.168.2.0/24
ip prefix-list NN permit 192.168.4.0/24

Since each object is searched in the order of JPIRR → RIPE → RADB specified in database sources, the operation is as follows in this case.

(1) Search AS-IRR-NET in the order of JPIRR → RIPE → RADB, and since AS-IRR-NET is registered in JPIRR, RIPE and RADB are not searched.AS-IRR-NET registered in RIPE is not searched.

(2) Search for a route whose origin is AS00001 of members registered in AS-IRR-NET of JPIRR in the order of JPIRR → RIPE → RADB.Since JPIRR has a route: 192.168.1.0/24 of origin: AS00001, generate a prefix-list. RIPE and RADB are not searched.

(3) Search for a route whose origin is AS00002 of members registered in AS-IRR-NET of JPIRR in the order of JPIRR → RIPE → RADB.Since RIPE has a route: 192.168.2.0/24 of origin: AS00002, a prefix-list is generated.Route: 192.168.3.0/24 registered in RADB is not generated.

(4) Search for a route whose origin is AS00003 of members registered in AS-IRR-NET of JPIRR in the order of JPIRR → RIPE → RADB.Since JPIRR has a route: 192.168.4.0/24 of origin: AS00003, a prefix-list is generated. RIPE and RADB are not searched.

(5) Search for a route whose origin is AS00004 of members registered in AS-IRR-NET of JPIRR in the order of JPIRR → RIPE → RADB. Prefix-list is not generated because there is no registration in JPIRR, RIPE, RADB.ARIN not specified in database sources will not be searched.

Is this perception correct?

I would appreciate it if you could provide a little more detail in the documentation.

Regards,
Anazawa

Has anyone managed to install this directly on ASR9K as hosted application?

https://www.cisco.com/c/en/us/td/docs/iosxr/asr9000/app-hosting/b-application-hosting-configuration-guide-asr9000/b-application-hosting-configuration-guide-asr9000_chapter_0101.html

Hi
I'm trying to install BGPQ3 directly on Arista EOS device.
The last version I could find for bgpq3 is 0.1.35 which requires the EOS to be 64 bit
If i'm trying to add this on the switch I get the following error

SW1EOS#extension bgpq3-0.1.35-0.el7.x86_64.rpm
% Error installing bgpq3-0.1.35-0.el7.x86_64.rpm: RPM install error: Transaction check failed: libc.so.6()(64bit) is needed by bgpq3-0.1.35-0.el7.x86_64
libc.so.6(GLIBC_2.14)(64bit) is needed by bgpq3-0.1.35-0.el7.x86_64
libc.so.6(GLIBC_2.15)(64bit) is needed by bgpq3-0.1.35-0.el7.x86_64
libc.so.6(GLIBC_2.2.5)(64bit) is needed by bgpq3-0.1.35-0.el7.x86_64
libc.so.6(GLIBC_2.3)(64bit) is needed by bgpq3-0.1.35-0.el7.x86_64
libc.so.6(GLIBC_2.3.4)(64bit) is needed by bgpq3-0.1.35-0.el7.x86_64
libc.so.6(GLIBC_2.4)(64bit) is needed by bgpq3-0.1.35-0.el7.x86_64
libc.so.6(GLIBC_2.7)(64bit) is needed by bgpq3-0.1.35-0.el7.x86_64
libnsl.so.1()(64bit) is needed by bgpq3-0.1.35-0.el7.x86_64

I did found a version that works on 32bit EOS but its missing some attributes - 0.1.31

SW1EOS#show extensions
Name Version/Release Status Extension

bgpq3-0.1.31-1.el6.i686.rpm 0.1.31/1.el6 A, I 1
A: available | NA: not available | I: installed | NI: not installed | F: forced

[admin@SW1EOS ~]$ bgpq3

Usage: bgpq3 [-h host] [-S sources] [-P|E|G |f ] [-2346AbDJjXd] [-R len] ...
-2 : allow routes belonging to as23456 (transition-as) (default: false)
-3 : assume that your device is asn32-safe
-4 : generate IPv4 prefix-lists (default)
-6 : generate IPv6 prefix-lists (IPv4 by default)
-A : try to aggregate Cisco prefix-lists or Juniper route-filters
as much as possible
-b : generate BIRD output (Cisco IOS by default)
-d : generate some debugging output
-D : use asdot notation in as-path (Cisco only)
-E : generate extended access-list(Cisco) or route-filter(Juniper)
-f number : generate input as-path access-list
-G number : generate output as-path access-list
-h host : host running IRRD software (whois.radb.net by default)
-J : generate config for JunOS (Cisco IOS by default)
-j : generate JSON output (Cisco IOS by default)
-M match : extra match conditions for JunOS route-filters
-m len : maximum prefix length (default: 32 for IPv4, 128 for IPv6)
-l name : use specified name for generated access/prefix/.. list
-P : generate prefix-list (default, just for backward compatibility)
-r len : allow more specific routes from masklen specified
-R len : allow more specific routes up to specified masklen
-S sources: use only specified sources (default: RADB,RIPE,APNIC)
-T : disable pipelining (experimental, faster mode)
-W len : specify max-entries on as-path line (use 0 for infinity)
-X : generate config for IOS XR (Cisco IOS by default)

bgpq3 version: 0.1.31
Copyright(c) Alexandre Snarskii [email protected] 2007-2015

I'm missing the -F attribute to use
bgpq3 -F "permit %n/%l le 24\n" AS-NV >/mnt/flash/pl-bgpq3/pl-cellcom-v4.txt
Or the -s to get this numbered for EOS as it requires it as a syntax

Is there any version newer than 0.1.31 that will work with 32bit EOS?

The Michaelson/Huston draft in README.md has expired, but it can be accessed via the Internet Draft archive at https://www.ietf.org/archive/id/draft-michaelson-4byte-as-representation-05.txt.

Currently bgpq3 makes address family selection mutually exclusive. I propose allowing generation of mixed lists.

I am not sure which underlying platforms support mixing address families, but it is supported in JunOS both with prefix-lists and route-filters, and would also be useful for external integration using e.g. JSON or user defined output to not have to merge the lists externally. For platforms that don't support combined lists, perhaps it could be implemented by generating the configuration for the two lists in one pass.

bgpq3 results are inconsistent for routes with SOURCE: RIPE-NONAUTH.

Observed behaviour (note that only the first output is correct):

$ bgpq3 -J AS-Z-IX
policy-options {
replace:
 prefix-list NN {
    44.190.1.0/24;
    44.190.20.0/24;
 }
}

$ bgpq3 -S RIPE -J AS-Z-IX
policy-options {
replace:
 prefix-list NN {
 }
}

$ bgpq3 -S RADB,RIPE -J AS-Z-IX
policy-options {
replace:
 prefix-list NN {
    44.190.1.0/24;
 }
}

WHOIS information for said routes:

$ whois -T route 44.190.1.0/24
route:          44.190.1.0/24
descr:          approved by Brian Kantor on 2017-12-03
origin:         AS202928
mnt-by:         Z-IX-MNT
created:        2017-12-03T20:32:47Z
last-modified:  2018-09-04T19:03:15Z
source:         RIPE-NONAUTH

$ whois -T route 44.190.20.0/24
route:          44.190.20.0/24
descr:          approved by Brian Kantor on 2018-08-23
origin:         AS202928
mnt-by:         Z-IX-MNT
created:        2018-08-24T18:08:10Z
last-modified:  2018-09-04T19:39:48Z
source:         RIPE-NONAUTH

$ whois AS-Z-IX
as-set:         AS-Z-IX
descr:          Z-IX AS-SET
members:        AS202928
tech-c:         ZNR2-RIPE
admin-c:        ZNR2-RIPE
mnt-by:         Z-IX-MNT
created:        2016-05-05T18:55:19Z
last-modified:  2016-05-05T18:55:19Z
source:         RIPE

role:           Z-IX NCC Role
org:            ORG-AF83-RIPE
address:        AUSTRIA
nic-hdl:        ZNR2-RIPE
mnt-by:         Z-IX-MNT
created:        2016-04-28T18:45:27Z
last-modified:  2016-04-28T18:51:24Z
source:         RIPE # Filtered

Hello,
I'm searching for a solution to filter the routes an AS sends me, and if they are originate from the right AS.

Principle:
when peering with 64500, it sends me its own routes, plus the routes of their customers.
Due to frequent configuration error, 64500 sends me route of Customer 64510 as their own.

This leads to potential routing problems, but also extended troubleshooting on my side, as this route is obviously filtered in some places.

Is there a possibility to output further filters, when querying for an as-set, to have the routes group by orgin AS?
This would immediately filter those wrong announcements.

From my current point of view (as I'm using JunOS), this could be easily accomplished with a configuration block a this:

# show | compare 
[edit policy-options]
+   policy-statement PERMIT-AS64500-IN {
+       term AS64500-ROUTES {
+           from {
+               as-path AS64500;
+               route-filter 192.0.2.0/24 exact;
+           }
+       }
+       term AS64500_AS64510-ROUTES {
+           from {
+               as-path AS64500_AS64510;
+               route-filter 10.0.0.0/23 upto /24;
+           }
+       }
+   }
[edit policy-options]
+   as-path AS64500 64500+;
+   as-path AS64500_64510 "64500+ 64510+";

When included as import filter, this allows both networks to prepend their path as needed, but disallows an origin not documented in the RADB.

I have multiple use cases for this filters, and I hope I'm not alone with this, as I would have to script it externally (due to lack of skills in C).

Could you clarify the Nokia classic CLI (-N) allowed option combinations?

While it is correct that aggregation and refine (-ARr) are not compatible with Nokia classic CLI [ip|ipv6]-prefix-list, they should be supported with standard prefix-lists.

In other words, only the -E flag is incompatible with -ARr for Nokia classic CLI (-N).

Valid:
./bgpq3 -h localhost -36AN -R 128 -l foo AS8218
prefix-list "foo"
prefix 2001:67c:25a8::/48 prefix-length-range 48-128
prefix 2001:1b48::/32 prefix-length-range 32-128
...

Invalid:
./bgpq3 -h localhost -36AEN -R 128 -l foo AS8218

Cli help text for standard prefix-list:
*A:sr7-1.eth>config>router>policy-options>prefix-list# prefix

• prefix <ip-prefix/prefix-length> [exact|longer|through |prefix-length-range ]

Thanks!

bgpq3 -j -4 RS-INTEROUTE

gdb suggests the issue is around here

Program received signal SIGSEGV, Segmentation fault.
0x000000000040644f in bgpq_expand_irrd (b=0x7ffffff7e170,
    callback=0x404c7c , udata=0x0, fmt=0x410b37 "!i%s,1\n")
    at bgpq_expander.c:645
645                             memcpy(recvbuffer, eon+1, off - ((eon+1)-response));

This might be an RADB server issue, but I thought I'd report it here anyway just in case. When expanding the IPv6 routes found inside AS-NORDUNET it consistently fails like this:

$ bgpq3 -d6 AS-NORDUNET
[...]
DEBUG: bgpq_expander.c:362 bgpq_pipeline expander: sending '-T route6 -i origin as51500
'
FATAL ERROR:Partial write to radb, only 25 bytes written: Connection reset by peer

The amount of bytes written change from time to time, so does the last ASN shown in the debugging output.

Expanding other as-sets work fine, including AS-NORDUNET when using IPv4.

Hello,

running this command:

bgpq3 -d -h rr.ntt.net -S RIPE,APNIC,AFRINIC,ARIN,NTTCOM,ALTDB,BBOI,BELL,JPIRR,LEVEL3,RADB,RGNET,TC -6 -A -j -r 16 -R 48 -l prefix_list AS-PCH

Gives me following error:
FATAL ERROR:EOF from RADB (dequeue, ripe)

So I tried it with the -d parameter and here are few lines before it seems to crash:

DEBUG: bgpq_expander.c:250 bgpq_pipeline_dequeue_ripe dequeuer(ripe): got route6 2001:1398:274::/48
DEBUG: bgpq_expander.c:250 bgpq_pipeline_dequeue_ripe dequeuer(ripe): got route6 2001:1398:121::/48
DEBUG: bgpq_expander.c:250 bgpq_pipeline_dequeue_ripe dequeuer(ripe): got route6 2001:1398:275::/48
DEBUG: bgpq_expander.c:250 bgpq_pipeline_dequeue_ripe dequeuer(ripe): got route6 2405:3780::/32
DEBUG: bgpq_expander.c:250 bgpq_pipeline_dequeue_ripe dequeuer(ripe): got route6 2620:95:8000::/48
DEBUG: bgpq_expander.c:250 bgpq_pipeline_dequeue_ripe dequeuer(ripe): got route6 2620:95:8000::/48
DEBUG: bgpq_expander.c:250 bgpq_pipeline_dequeue_ripe dequeuer(ripe): got route6 2a0d:e8c0::/29
FATAL ERROR:EOF from RADB (dequeue, ripe)

It starts with:

DEBUG: bgpq_expander.c:633 bgpq_expand Acquired sendbuf of 4608 bytes
DEBUG: bgpq_expander.c:524 bgpq_expand_radb expander: sending '!iAS-PCH,1
'

Then, i get this:

DEBUG: bgpq_expander.c:394 bgpq_pipeline expander: sending '-T route6 -i origin as27
' (queued 0 of 4608)

(This goes for few AS numbers)

Aaand then it does the "got route6" thing and then only at this certain line:
DEBUG: bgpq_expander.c:250 bgpq_pipeline_dequeue_ripe dequeuer(ripe): got route6 2a0d:e8c0::/29 it crashes.

Any idea how to fix this?

I'm running BGPQ3 on a CentOS7 machine, installed with "yum install bgpq3", the BGPQ3 version is 0.1.31.

USER-DEFINED FORMAT
If you want to generate configuration not for routers, but for some other programs/systems, you may use user-defined formatting, like in example below:

user@host:~>bgpq3 -F "ipfw add pass all from %n/%l to any\n" as3254
ipfw add pass all from 62.244.0.0/18 to any
ipfw add pass all from 91.219.29.0/24 to any
ipfw add pass all from 91.219.30.0/24 to any
ipfw add pass all from 193.193.192.0/19 to any
Recognized format characters: '%n' - network, '%l' - mask length, '%N' - object name, '%m' - object mask and '%i' - inversed mask. Recognized escape characters: '\n' - new line, '\t' - tabulation. Please note that no new lines inserted automatically after each sentence, you have to add them into format string manually, elsewhere output will be in one line (sometimes it makes sense):

Was looking at generating custom output, where I include the AS number for custom roa table with bird. bgpq3 -63 -F "roa %n/%l max %l as %a;\n" AS-CHOOPA This is at the moment not possible. Where I use an AS-SET as the data-input. And at the same time wanting to include the ASN in the custom-output.

!gas65551 must be used instead of !gas1.15

in the upcoming IRRd v4 the ASDOT format is not going to be supported.

Hey!

The documentation says the recommended sources are RIPE, RADB and APNIC. If I test what I get for AS-HURRICANE, which is a very large AS-set, I get:

$ bgpq3 -S RIPE,RADB,APNIC AS-HURRICANE | wc -l
712073

Without filtering, I get:

$ bgpq3 AS-HURRICANE | wc -l
875980

So, more routes than in a full-view. If I add more RIR, I get:

$ bgpq3 -S RIPE,RADB,APNIC,LACNIC,AFRINIC,ARIN AS-HURRICANE | wc -l
802259

Each of them contribute a bit (except LAPNIC which doesn't seem to export route objects, just inetnum with the wrong format). I can also add some random DB and get even more results:

$ bgpq3 -S RIPE,RADB,APNIC,LACNIC,AFRINIC,ARIN,LEVEL3,NTTCOM,ALTDB AS-HURRICANE | wc -l
856987

AS-HURRICANE may not be the best example but if the documentation could expand a bit on the recommended sources, it would be helpful. Even a link to a presentation explaining that. Why is AFRINIC not here for example? Why not ARIN?

Thanks.

Not quite sure if this is a specific problem to Ubuntu or not but make install with --prefix puts the files in wrong places for me and so I can't use GNU stow for keeping different versions.

# mkdir /usr/local/stow/bgpq3-07246c929b939be9ac44c4b8b23ea635114e33ac
$ ./configure --prefix=/usr/local/stow/bgpq3-07246c929b939be9ac44c4b8b23ea635114e33ac/
$ make
$ sudo make install
/usr/bin/install -c -c -s -m 755 bgpq3 /usr/local/stow/bgpq3-07246c929b939be9ac44c4b8b23ea635114e33ac/bin
if test ! -d /usr/local/stow/bgpq3-07246c929b939be9ac44c4b8b23ea635114e33ac/man/man8 ; then mkdir -p /usr/local/stow/bgpq3-07246c929b939be9ac44c4b8b23ea635114e33ac/man/man8 ; fi
/usr/bin/install -c -m 644 bgpq3.8 /usr/local/stow/bgpq3-07246c929b939be9ac44c4b8b23ea635114e33ac/man/man8

Can't stow because it needs 'man' inside 'share'.
Works when I create it like this:
# /usr/local/stow/bgpq3-07246c929b939be9ac44c4b8b23ea635114e33ac/share/man/man8/bgpq3.8

Binary is installed as 'bin' instead of 'bin/bgpq3'.

$ find /usr/local/stow/bgpq3-07246c929b939be9ac44c4b8b23ea635114e33ac/ -type f
/usr/local/stow/bgpq3-07246c929b939be9ac44c4b8b23ea635114e33ac/bin
/usr/local/stow/bgpq3-07246c929b939be9ac44c4b8b23ea635114e33ac/man/man8/bgpq3.8
$ file /usr/local/stow/bgpq3-07246c929b939be9ac44c4b8b23ea635114e33ac/bin
/usr/local/stow/bgpq3-07246c929b939be9ac44c4b8b23ea635114e33ac/bin: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=d8144dad429c5cab2bc5c2fd531d4d54d8c39cd8, stripped

If more details are needed please let me know.

Example:

tom@foohost# bgpq3 -6 AS7342
ERROR:Invalid masklen in prefix 2620:74:14::/48
ERROR:Unable to parse prefix 2620:74:14::/48
ERROR:Invalid masklen in prefix 2620:74:15::/48
ERROR:Unable to parse prefix 2620:74:15::/48
no ipv6 prefix-list NN
ipv6 prefix-list NN permit 2001:500:4431::/48
ipv6 prefix-list NN permit 2620:0:5050::/48
ipv6 prefix-list NN permit 2620:74:14::/48
ipv6 prefix-list NN permit 2620:74:15::/48
ipv6 prefix-list NN permit 2620:74:19::/48

as reported by @job this is broken since adding d787382 - in particular strlcpy, which is a Theoism. Should libbsd be included for linux distributions or the more risky strncpy?

4:18 netmon1-r10-sfo2:~/bgpq3% make
gcc -std=gnu99 -DHAVE_CONFIG_H -g -Wall -I. -O0 -c bgpq3.c
gcc -std=gnu99 -DHAVE_CONFIG_H -g -Wall -I. -O0 -c sx_report.c
gcc -std=gnu99 -DHAVE_CONFIG_H -g -Wall -I. -O0 -c bgpq_expander.c
gcc -std=gnu99 -DHAVE_CONFIG_H -g -Wall -I. -O0 -c sx_slentry.c
gcc -std=gnu99 -DHAVE_CONFIG_H -g -Wall -I. -O0 -c bgpq3_printer.c
gcc -std=gnu99 -DHAVE_CONFIG_H -g -Wall -I. -O0 -c sx_prefix.c
sx_prefix.c: In function ‘sx_prefix_parse’:
sx_prefix.c:56:2: warning: implicit declaration of function ‘strlcpy’ [-Wimplicit-function-declaration]
  strlcpy(mtext, text, sizeof(mtext));
  ^
gcc -std=gnu99 -DHAVE_CONFIG_H -g -Wall -I. -O0 -c strlcpy.c
gcc -std=gnu99 -DHAVE_CONFIG_H -g -Wall -I. -O0 -c sx_maxsockbuf.c
gcc -std=gnu99 -DHAVE_CONFIG_H -g -Wall -I. -O0 -o bgpq3 bgpq3.o sx_report.o bgpq_expander.o sx_slentry.o bgpq3_printer.o sx_prefix.o strlcpy.o sx_maxsockbuf.o -lnsl
4:18 netmon1-r10-sfo2:~/bgpq3%

I have ran into an issue, with specifing data sources.

I know that AS-FIBERBY is registered in RIPE, and have put RIPE::AS-FIBERBY[1] in PeeringDB.

I use bgpq3 -4 -S RIPE AS-FIBERBY since I know the source.

However AS42541 is occasionally announcing 23.128.24.0/24 (originated by AS12654 aka. RIPE RIS).

Since AS-RIS is a member of AS-FIBERBY, and both are in RIPE, I use AS-RIS from now on.

$ bgpq3 -4 -S RIPE AS-RIS | grep 23.128.24.0/24
$ bgpq3 -4 -S RIPE,ARIN AS-RIS | grep 23.128.24.0/24
ip prefix-list NN permit 23.128.24.0/24

It turns out that the issue is that 23.128.24.0/24 is registered in ARIN, and hence doesn't satisfy the source argument. I would like to be able to control the source of the requested object, while allowing more sources to be used for expanding it.

I have few suggestions to improve the situation:

1. Would it be possible to add source to the prefixes in the JSON format:

$ bgpq3 -4 -j -S RIPE,ARIN AS-RIS | grep 23.128.24.0
    { "prefix": "23.128.24.0\/24", "exact": true, "source": "ARIN" },

2. Be able to specify a specific source for the request objects, while using -S for the expansion, eg. using the wide-spread PeeringDB syntax: bgpq3 -4 -S RIPE,ARIN RIPE::AS-FIBERBY.
3. With the combination of above, I can control the source of requested object, and see which sources different route objects came from, but I can't see which sources intermediate as-set and aut-num came from, so maybe add a new tree-like JSON format.

I can produce patches, if any of these ideas sounds interesting.

[1] If anyone knows the origin of the IRR::OBJECT syntax, please tell.

This is broken since commit d787382

Expected output:

Vurt:bgpq3 job$ ./bgpq3 -h rr.ntt.net -6 AS30132
no ipv6 prefix-list NN
ipv6 prefix-list NN permit 2001:500:60::/48

Current bad output (IOS + BIRD):

Vurt:bgpq3 job$ ./bgpq3 -h rr.ntt.net -6 -b AS30132
ERROR:Unable to parse prefix 2001:500:60::/48, af=30
ERROR:Unable to parse prefix 2001:500:60::/48
NN = [
];

Vurt:bgpq3 job$ ./bgpq3 -h rr.ntt.net -6 AS30132
ERROR:Unable to parse prefix 2001:500:60::/48, af=30
ERROR:Unable to parse prefix 2001:500:60::/48
no ipv6 prefix-list NN
! generated prefix-list NN is empty
ipv6 prefix-list NN deny 0.0.0.0/0

Hello,

I'm facing an issue when passing a source list longer than 124 chars; it seems the program hangs, both when the -S option or the IRRD_SOURCES env var are used.

Maybe something wrong happens here?

125 chars, -S:

$ bgpq3 -d -S "1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234_" -3 -j -f 1 -l asn_list AS3333
DEBUG: bgpq_expander.c:742 bgpq_expand Acquired sendbuf of 4608 bytes
DEBUG: bgpq_expander.c:771 bgpq_expand Requesting sources !s1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234_^C

125 chars, IRRD_SOURCES:

$ IRRD_SOURCES="1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234_" bgpq3 -d -3 -j -f 1 -l asn_list AS3333
DEBUG: bgpq_expander.c:742 bgpq_expand Acquired sendbuf of 4608 bytes
DEBUG: bgpq_expander.c:771 bgpq_expand Requesting sources !s1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234_^C

124 chars, -S:

$ bgpq3 -d -S "1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234" -3 -j -f 1 -l asn_list AS3333
DEBUG: bgpq_expander.c:742 bgpq_expand Acquired sendbuf of 4608 bytes
DEBUG: bgpq_expander.c:771 bgpq_expand Requesting sources !s1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234
DEBUG: bgpq_expander.c:775 bgpq_expand Got answer F source(s) unavailable
ERROR:Invalid source(s) '1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234': F source(s) unavailable

124 chars, IRRD_SOURCES:

$ IRRD_SOURCES="1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234" bgpq3 -d -3 -j -f 1 -l asn_list AS3333
DEBUG: bgpq_expander.c:742 bgpq_expand Acquired sendbuf of 4608 bytes
DEBUG: bgpq_expander.c:771 bgpq_expand Requesting sources !s1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234
DEBUG: bgpq_expander.c:775 bgpq_expand Got answer F source(s) unavailable
ERROR:Invalid source(s) '1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234': F source(s) unavailable

Credits to @benerudolph and the other guys that participated in the Euro-IX route server workshop for helping me out to analyze this.

Vurt:~ job$ bgpq3

Usage: bgpq3 [-h host[:port]] [-S sources] [-P|E|G <num>|f <num>] [-2346ABbDJjXd] [-R len] <OBJECTS>...
...
 -3        : assume that your device is asn32-safe

Perhaps it is time to make -3 the default?