When requesting /api/v2/blocks with filter=range:contains(x.x.x.x) (where x.x.x.x is an ip in the network you wish to find the enclosing block for) you will receive a list of ALL blocks that contain this IP. If the IP is a candidate to create a network, you want the closest enclosing block so you know the to-be-network’s parent. You SHOULD be able to ask the API to sort the list with “orderBy(range)” - however, if the list of blocks being sorted includes a range block (e.g. a block with a start and end address, not a CIDR range) then the sorting returned is incorrect. See KI-025991. Supposedly this was fixed in 25.1 - however I’ve opened a new case on this because the sorting is still not as one would expect. Any reasonable networking professional when sorting a list of blocks would expect them to be sorted most specific to least specific (or vice versa) - but the sorting in 25.1 which was supposedly fixed is still not properly placing the range block.
The workaround until the API produces sane/accurate/expected sorting, is to sort the returned list in your own code, using your favorite networking/ip addressing module in your favorite language (I’m partial to netaddr in python).
And for any Product Management folks reading this, if you want to weigh in with engineering or myself on what a reasonable sorting of blocks is, please feel free to reach out to me with any comments.
-Tim
I should also note that I haven’t tested at all with IP6 objects...
I recently ran into this problem of finding the “closest enclosing block” when the list has a range in it. So instead of looking for the largest prefix, I now:
Pull out the id in the _links.up URL and create a list or set.
Scan through the id’s again looking for the one that is not in the above list. That should be the end of the chain, the “closest enclosing block”.
Note that this only works if the query is filtered by Configuration, otherwise you might find a chain for each Configuration.
If you want the whole list, then connect then by the ‘up’ id to the get right order.
Does that make sense? I have not had it in use for very long, so it is not well tested.
Interesting, I like your ingenuity. I never considered doing it that way. Still, should be unnecessary if the API sorted the blocks correctly when asked to.
I did not know about the sort option. Sorting in the right direction, and only asking for one result, should be faster and simpler, if the sorting worked, for finding the closest enclosing. I will have to keep this in mind for the future. Let us know if you get a new KI for version 25.1 not sorting properly, so we can follow it.
Thanks for the guidance Tim and Bob. It’s nice to know it isn’t just me that thought the results were odd.
As you suggest, I’ll use the zeroth address in the subnet I am searching for and play around with the sorting and links to determine the closest enclosing block.
KI-026622 published for the 25.1 sorting issue.
