Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(minor) multiple root nodes of the allocation tree #11

Open
aaronkaplan opened this issue Jun 24, 2020 · 4 comments
Open

(minor) multiple root nodes of the allocation tree #11

aaronkaplan opened this issue Jun 24, 2020 · 4 comments

Comments

@aaronkaplan
Copy link

Due to the import of multiple RIR files (afrinic, apnic, ripe, arin) we end up with multiple "root" nodes of the allocation, i.e.: multiple entries of 0.0.0.0/0:

 193.0.0.0/8 | RIPE-CIDR-BLOCK | AU                                | Not allocated by APNIC                               | MAINT-APNIC-AP |         | 2008-09-04 06:51:29 | apnic
 0.0.0.0/0   | IANA-BLK        | EU # Country is really world wide | The whole IPv4 address space                         | AFRINIC-HM-MNT |         |                     | afrinic
 0.0.0.0/0   | IANA-BLOCK      | AU                                | General placeholder reference for all IPv4 addresses | MAINT-APNIC-AP |         | 2008-09-04 06:51:49 | apnic

Proposal: the supplied SELECT statements should either dedup these or... we leave it as is (and every user needs to dedup) or we create a UNIQUE index on block.inetnum..

What's the best way to approach this? As a user of the DB , I would implicitly assume there is only one entry per inetnum and it's assigned to one of the RIRs.

@firefart
Copy link
Owner

I think I will simply merge the entries and prepend the single fields with the source

@aaronkaplan
Copy link
Author

Yes, I think that makes sense. If we still have the tree structure of the assignments / sub-allocations iterable via the DB then that reflects the IP address space. Thanks :)

@firefart
Copy link
Owner

it looks like there are overlapping netranges too which sucks :/

@aaronkaplan
Copy link
Author

aaronkaplan commented Jun 25, 2020 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants