missing some prefixes

[adrimt]

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

[pgul]

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]

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.

[maznu]

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]

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

[snar]

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

[adrimt]

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.

[larryblunk]

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]

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

[snar]

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 @.***>

[maznu]

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

[amshikov]

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.