Certain prefixes that show up in the RIPE GUI don't get outputted by BGPq3 when the ASSet is queried #74
Comments
|
On Mon, Jul 24, 2023 at 03:51:56AM -0700, Navar0ne wrote:
Hey there!
When I was querying AS200070, it returned some prefixes, however it did not
return all of the ones it should
Can you be more exact and provide example of prefix that is missed in output ?
…
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.*Message ID:
***@***.***>
|
Edited* |
|
@Navar0ne If you remove |
|
On Mon, Jul 24, 2023 at 04:17:33AM -0700, Navar0ne wrote:
On Mon, Jul 24, 2023 at 03:51:56AM -0700, Navar0ne wrote: Hey there! When I
was querying AS200070, it returned some prefixes, however it did not return
all of the ones it should
Can you be more exact and provide example of prefix that is missed in
output ?
…
— Reply to this email directly, view it on GitHub, or unsubscribe. You are
receiving this because you are subscribed to this thread.Message ID: @.**>
Edited*
Thanks. As you can see in
whois -h whois.ripe.net 199.253.250.0/24
route: 199.253.250.0/24
descr: .ca dns anycast
origin: AS25192
mnt-by: CZ-NIC-MNT
created: 2018-01-10T13:43:09Z
last-modified: 2018-09-04T19:04:44Z
source: RIPE-NONAUTH
this route has source of RIPE-NONAUTH, so when you are specifying
-S RIPE this object is filtered out (you requested only for RIPE objects,
you got what you asked for). To get this object you can
- specify multiple sources, bgpq3 -S RIPE,RIPE-NONAUTH
- do not specify sources at all (do not use -S flag), altough that's
generally bad idea.
…
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.*Message ID: <snar/bgpq3/issues/74
***@***.***>
|
Ahhh this makes a lot of sense, thanks! Out of interest, why do you think RIPE would show it on it's GUI if its not part of their database? Also, whats the difference between not specifying a database at all and specifying RIPE and RIPEnoAuth? |
|
On Mon, Jul 24, 2023 at 04:47:11AM -0700, Navar0ne wrote:
Ahhh this makes a lot of sense, thanks!
Out of interest, why do you think RIPE would show it on it's GUI if its not
part of their database?
Because this object still exists in their database. It's not
as trusted as normal RIPE objects (address space belongs to ARIN,
so RIPE can't be sure that this network is indeed allocated for
AS200070), but it has no conflicts with RPKI objects, so there
are no reason for deleting this object.
As for 'what difference between not specifying source and specifying
RIPE and RIPE-NONAUTH' (sorry, github for some reason did not included
this part of question in email): when you specify sources, you get
answers from these sources only (so you are still able to specify
what sources you trust and what you are not). When you not specifying
sources - you get answers from ANY sources those are mirrored by RADB,
there are lots of those (see
https://www.radb.net/support/informational/irrs.html#availabledatabases
for the full list) and not all of them shall be considered 'trusted':
for example, in ALTDB anyone can create route-object for ANY network
with ANY origin ASN..
|
|
Hey there, I don't mean to re open an old issue with the same problem, but when I query 185.140.236.0/23 with BGPQ3 I don't get anything, just like before, however when I so the WHOIS lookup, it shows that the source is RIPE not some other database. Would you have any insight on this? inetnum: 185.140.236.0 - 185.140.239.255 oc-server01 files]$ bgpq3 -S RIPE,RIPE-NONAUTH 185.140.236.0/23 |
|
On Mon, Aug 07, 2023 at 12:56:06AM -0700, Navar0ne wrote:
Hey there,
I don't mean to re open an old issue with the same problem, but when I query
185.140.236.0/23 with BGPQ3 I don't get anything, just like before, however
when I so the WHOIS lookup, it shows that the source is RIPE not some other
database. Would you have any insight on this?
inetnum: 185.140.236.0 - 185.140.239.255
netname: CZ-KRAJVYSOCINA-20160229
country: CZ
org: ORG-KV14-RIPE
admin-c: JP10120-RIPE
admin-c: KVNA1-RIPE
tech-c: JP10120-RIPE
tech-c: KVNA1-RIPE
status: ALLOCATED PA
mnt-by: RIPE-NCC-HM-MNT
mnt-by: cz-krajvysocina-1-mnt
mnt-lower: cz-krajvysocina-1-mnt
mnt-lower: plz-mnt
mnt-routes: cz-krajvysocina-1-mnt
mnt-routes: plz-mnt
created: 2016-02-29T15:04:34Z
last-modified: 2018-10-20T12:32:08Z
source: RIPE
oc-server01 files]$ bgpq3 -S RIPE,RIPE-NONAUTH 185.140.236.0/23
no ip prefix-list NN
ip prefix-list NN permit 185.140.236.0/23
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You've got exactly what you asked for: prefix-list in IOS format for
185.140.236.0/23. Nothing more (because it's a prefix and prefix is not
and ASn and thus can't have associated route-object) and nothing less..
PS: if you want to build prefix-filter for your customer's asn,
you shall ask for this ASN, not for prefix:
bgpq3 -S RIPE,RIPE-NONAUTH AS48091
no ip prefix-list NN
ip prefix-list NN permit 185.140.236.0/23
ip prefix-list NN permit 195.93.216.0/23
please note that 185.140.236.0/22 is absent in this output. That's because
your customer registered only inetnum object in RIPE, but route-object
covering all addresses is missing.
… oc-server01 files]$
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.*Message ID: <snar/bgpq3/issues/74
***@***.***>
|
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?
The text was updated successfully, but these errors were encountered: