missing some prefixes

Question

missing some prefixes

adrimt opened this issue 8 months ago · comments

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

Pavel · Answer 1 · Tue Nov 14 2023 18:00:50 GMT+0800 (China Standard Time)

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?

adrimt · Answer 2 · Tue Nov 14 2023 18:11:11 GMT+0800 (China Standard Time)

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.

Marek Isalski · Answer 3 · Tue Nov 14 2023 18:13:15 GMT+0800 (China Standard Time)

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!

adrimt · Answer 4 · Tue Nov 14 2023 18:34:38 GMT+0800 (China Standard Time)

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

Alexandre Snarskii · Answer 5 · Tue Nov 14 2023 18:41:49 GMT+0800 (China Standard Time)

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

adrimt · Answer 6 · Wed Nov 15 2023 01:36:43 GMT+0800 (China Standard Time)

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.

Larry Blunk · Answer 7 · Wed Nov 15 2023 01:57:42 GMT+0800 (China Standard Time)

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.

adrimt · Answer 8 · Wed Nov 15 2023 02:19:27 GMT+0800 (China Standard Time)

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

Alexandre Snarskii · Answer 9 · Wed Nov 15 2023 17:37:59 GMT+0800 (China Standard Time)

On Tue, Nov 14, 2023 at 09:57:53AM -0800, Larry Blunk wrote: 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.

Thanks, RIPE mirror looks good now. However, in APNIC mirror I'm still observe stale objects: :~>whois -h whois.apnic.net as-retn-hk | grep last | head -1 last-modified: 2023-10-24T15:09:58Z :~>whois -h whois.radb.net as-retn-hk | grep last | head -1 last-modified: 2023-05-11T12:00:25Z

…

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.*Message ID: <snar/bgpq3/issues/75 ***@***.***>

Marek Isalski · Answer 10 · Wed Nov 15 2023 22:34:54 GMT+0800 (China Standard Time)

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

amshikov · Answer 11 · Sat Nov 18 2023 17:59:46 GMT+0800 (China Standard Time)

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.