search

snar / bgpq3

bgpq3
BSD 2-Clause "Simplified" License
363 stars 53 forks source link

Limitations of bgpq3 -S #58

Open asbjornst opened 4 years ago

asbjornst commented 4 years ago

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.

snar commented 4 years ago

On Thu, Mar 05, 2020 at 10:30:36AM -0800, asbjornst wrote:

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" },

Not possible without major rewrite: for now at stage 'get networks belonging to ASN' bgpq3 using irrd-specific query '!gasNNNN' that returns only prefixes but not their other attributes like 'souce':

./bgpq3 -ddddj AS12654 DEBUG: bgpq_expander.c:818 bgpq_expand Acquired sendbuf of 1051008 bytes DEBUG: bgpq_expander.c:357 bgpq_pipeline expander: sending !gas12654 DEBUG: bgpq_expander.c:474 bgpq_read waiting for answer to !gas12654 , init 0 '' DEBUG: bgpq_expander.c:575 bgpq_read Got 84.205.74.0/24 84.205.90.0/24 [....] (835 bytes of 835) in response to !gas12654 final code: C

The only way to overcome 'missing source' problem is the switch from irrd protocol to raw whois protocol, and this is mentioned major rewrite.

And, btw, as prefix can be regitered in multiple registries, even in this simple output shall be not "source": "ARIN", but rather "sources": ["ARIN"]

  1. 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.

Can be implemented easily.

  1. 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.

Requires major rewrite too.

a) unless you use '-L ' (limit recursion) or 'EXCEPT' options, bgpq3 uses simplest query '!i${as-set},1', that automagically recursively expands as-set into number of autonomous systems. In your example it means that bgpq3 knows that as12654 is a recursive member of AS-FIBERBY but it has no ideas on 'how deep it included' or 'what parents it have' (what objects it contained in). b) even when you use limiting options, as-set expansion is done using irrd non-recursive query '!i${as-set}', that returns only direct members of corresponding as-set but the 'missing source' problem is the same as in 1 and can only be fixed in the same way. c) what about cycles ? let's say as-set AS-A includes AS-B and ASc, AS-B includes AS-A and ASc, you are going to expand AS-A: what shall be mentioned as 'parent' of routes in ASc: AS-A, AS-B, both ?

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

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

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.*