missing some prefixes about bgpq3 HOT 11 CLOSED

I faced this issue today too.
As an example, "bgpq3 -S RIPE AS35530" does not list 93.126.64.0/22, 93.126.68.0/22 and some other routes created a month ago:

$ bgpq3 -S RIPE AS35530
no ip prefix-list NN
ip prefix-list NN permit 93.126.64.0/18
ip prefix-list NN permit 93.126.64.0/19
ip prefix-list NN permit 93.126.64.0/20
ip prefix-list NN permit 93.126.80.0/20
ip prefix-list NN permit 93.126.96.0/19
ip prefix-list NN permit 93.126.96.0/20
ip prefix-list NN permit 93.126.112.0/20

% Information related to '93.126.64.0/22AS35530'

route:          93.126.64.0/22
descr:          Proline TM LTD
origin:         AS35530
mnt-by:         DZHUVA-MNT
created:        2023-10-19T15:42:16Z
last-modified:  2023-10-19T15:42:16Z
source:         RIPE

MB there is some glitch on the RIPE side?

from bgpq3.

I ask RIPE and I received the following answer:

Thank you for your message.
From what I can see, is that AS20929 is announcing 3 prefixes at this moment https://stat.ripe.net/app/launchpad/S1_20929_C16eC4eC33C9eC13C31C34C22C28C20C6C7C26C29C30C14C17C2C21C10
We do not control what bgpq3 reports, please contact them if they are showing the wrong data for AS20929.

from bgpq3.

Seeing the same here:

$ bgpq3 -S RIPE AS59811                                                                                                                                                                                                                                                                                                                                                                                                                                                     no ip prefix-list NN
ip prefix-list NN permit 185.66.206.0/24

versus

$ whois -h whois.ripe.net -- "-i origin AS59811" | grep route:
route:          185.149.208.0/24
route:          185.149.210.0/23
route:          185.66.206.0/24
route:          193.162.44.0/24

So we're confident the data is in RIPE, but that's not where the query goes to. Doing a tcpdump (even with -S RIPE specified) bgpq3 makes a connection to 198.108.0.18 and the conversation looks like:

!!
!sRIPE
C
!nbgpq3 0.1.35
C
!gas59811
A16
185.66.206.0/24
C
!q

So the problem is actually with whois.radb.net!

from bgpq3.

Good point !
Using '-h riswhois.ripe.net' everything seems ok.

$bgpq3 -h riswhois.ripe.net AS59811
no ip prefix-list NN
ip prefix-list NN permit 185.66.206.0/24
ip prefix-list NN permit 185.149.208.0/24
ip prefix-list NN permit 185.149.210.0/23
ip prefix-list NN permit 185.149.210.0/24

from bgpq3.

Looks like something went wrong during RADB migration that happened yesterday:
https://www.radb.net/support/informational/irrdv4-migration-faq.html

from bgpq3.

Somebody on NANOG has another opinion:
https://mailman.nanog.org/pipermail/nanog/2023-November/224021.html
If this is true we may need an workaround.
Using '-h riswhois.ripe.net' seems to be an option.

from bgpq3.

Somehow initial seed from RIPE ftp archive seems to have gotten a stale snaphot. Not sure what the exact issue was, but db has now been reseeded and missing objects look to be present.

from bgpq3.

Yes, you are right, now it works.
It seems that we are not affected by the RPKI filter.

from bgpq3.

from bgpq3.

I had an email back from the RADB team at merit.edu saying this issue is fixed.

from bgpq3.

There is a problem of other kind. If as-set exists in some IRR databases, and -S flag is supplied to bgpq3, RADB whois server returns data only from first matched DB, for example:
# bgpq3 -S RADB,RIPE AS-GOOGLE -- works

# bgpq3 -S RIPE,RADB AS-GOOGLE -- does not work, returns empty list

Before RADB migration these commands returned the same result.

from bgpq3.