Skip to main content
Flexible Top Header
Answer

Finding IP Blocks that (might) contain a CIDR block

  • October 14, 2025
  • 11 replies
  • 108 views
A
Forum|alt.badge.img+3

We are working on a script to read route tables and with some automatic enrichment and human validation, add missing IP Networks (as IP4Network/IP6Network objects) to Integrity. Since creating a network requires providing the parent IP Block ID, I am wondering what the ‘right’ way is to find the parent for a CIDR range that may or may not exist as an IP?Network already in the IPAM database.

I have tried the following:
filter=range:contains(“204.0.113.0/24”) - which errors (because ‘contains’ doesn’t work with CIDR)

filter=range:contains(“204.0.113.0”) - where I just take the lowest IP in the CIDR range. This works but seems sub-optimal to me for some reason. Maybe because I can’t be sure if the block fits the entire CIDR, though that seems unlikely to be a real problem in practice.

I have also tried various forms of range:le and range:ge but (as documented) they only match on the prefix length and protocol (determined based on whether the address is v4 or v6), and so is not useful in this case.

Anyway, I am reasonably certain I am missing some better way and likely obvious way that I just can’t see for some reason.

Any ideas?

Best answer by tmaestas

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

 

11 replies

T
Forum|alt.badge.img+2
  • tmaestas
  • Verified Resolver
  • Answer
  • October 14, 2025

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

 

R
T
Forum|alt.badge.img+2
  • tmaestas
  • Verified Resolver
  • October 14, 2025

I should also note that I haven’t tested at all with IP6 objects...

rharolde
Forum|alt.badge.img+4
  • rharolde
  • DNS/DHCP/IPAM at U of Michigan
  • October 15, 2025

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.

T
Forum|alt.badge.img+2
  • tmaestas
  • Verified Resolver
  • October 15, 2025

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.

rharolde
Forum|alt.badge.img+4
  • rharolde
  • DNS/DHCP/IPAM at U of Michigan
  • October 15, 2025

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.

 

A
Forum|alt.badge.img+3
  • augustineas
  • Author
  • Active Endpoint
  • October 16, 2025

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.

T
Forum|alt.badge.img+2
  • tmaestas
  • Verified Resolver
  • October 17, 2025

KI-026622 published for the 25.1 sorting issue.

rharolde
T
Forum|alt.badge.img+2
  • tmaestas
  • Verified Resolver
  • November 20, 2025

The fix to properly sort blocks by range went into 25.1.1 which was released today.  I have verified that orderBy=asc(range) now sorts blocks, including range blocks, as one would expect.

rharolde
A
rharolde
Forum|alt.badge.img+4
  • rharolde
  • DNS/DHCP/IPAM at U of Michigan
  • November 21, 2025

Curiously, KI-026622 says it is fixed in 26.1.

 

T
Forum|alt.badge.img+2
  • tmaestas
  • Verified Resolver
  • November 21, 2025

Yeah I’ve reported that to Enterprise Support (the fix version is 25.1.1 and 26.1 is not a “current release” as that KI as well as a few others currently state).  26622 is listed in the 25.1.1 release notes and I’ve verified the fixed behavior.

A
Forum|alt.badge.img+3
  • augustineas
  • Author
  • Active Endpoint
  • November 21, 2025

Curiously, KI-026622 says it is fixed in 26.1.

 

Well, technically speaking the KI isn’t wrong (assuming no regressions when it is finally released)… 😁

Terms & ConditionsCookie settingsAccessibility statement