RIR column - Registro.BR - No matching to some blocks

[fischerdouglas]

Some friends reported some issues on the RIR source.

I used an ASN of a university just to exemplify the issue.
https://irrexplorer.nlnog.net/asn/AS53046

• Marked with green are prefixes that IR Explorer says are from Registro.BR
• Marked with red are prefixes that IRR Explorer says are from LACNIC.

[decomartins1991]

My IPv4 prefixes are also like this, only the IPv6 ones are correct

[teunvink]

I think it's clear we need to look into this. Posting "Me too" messages without any details doesn't add any value, no need to do that. And from what I see, I don't think we need more examples to check what's wrong here.

[fischerdouglas]

I think it's clear we need to look into this. Posting "Me too" messages without any details doesn't add any value, no need to do that. And from what I see, I don't think we need more examples to check what's wrong here.

Sorry dude! My bad!
I asked some friends to check if their prefixes were affected also, and report.

[rubenvalsouza]

It's also happening with our AS

[rubenvalsouza]

It's also happening with our AS

[mxsasha]

I do not see an obvious cause in the code. I added this in #231, which reads https://ftp.registro.br/pub/numeracao/origin/nicbr-asn-blk-latest.txt. 143.208.160.0/22 is in there, for example.

[clyra]

@mxsasha _rir_for_prefix function in api/collectors.py looks for the prefix and returns the first ocurrence of it, right?
rirstat for rirstat in self.rirstats if rirstat.prefix.overlaps(prefix)
and
return next(relevant_rirstats).rir

Since the same prefix appears in lacnic (https://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-latest as lacnic|BR|ipv4|143.208.160.0|1024|20151113|assigned) but also in registro.br, it seems that the lacnic RIR appears first.

Perhaps a simple fix should be to change the RIR class and put registro.br before lacnic in state.py

[mxsasha]

Since the same prefix appears in lacnic (https://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-latest as lacnic|BR|ipv4|143.208.160.0|1024|20151113|assigned) but also in registro.br, it seems that the lacnic RIR appears first.

Yes, that would explain it. I did not expect an exact match prefix to occur in multiple "RIRs". Not entirely sure of the right fix, the return order from the query is arbitrary, maybe the code should look at all rows and decide the "most specific RIR".

[fischerdouglas]

I was thinking a little about this question this morning, and a hypothesis came to mind. In fact, a very boring hypothesis.

Shouldn't the RIR attribute be able to be multivalued? An array or something?

I thought about this considering how the numeric resource assignment hierarchy is in the real world. RIRs, NIRs, LIRs.

A prefix that is assigned by Registro.BR actually is ALSO a "child" of LACNIC.

I know it's not the focus of IRR-Explorer to address these intricacies.
And I also know that a change like this (attribute typing) would be quite laborious.
So I don't expect this to be the path followed.
I just thought it pertinent to bring this here considering the target audience for this discussion.

[clyra]

@fischerdouglas I was also thinking about it, but as I understand it, there's 3 distinct "levels" and it doenst really matter whos is child of who, because a prefix should never belong to more than one register at the same level. So we just need a list or a attribute that identifies that. My first approach would be to just create a NIR array. If a prefix appears on more than one register, look for the one in the NIR array.