IPv4 Prefix Set Collapse
Collapse the exact union of explicit IPv4 prefixes to minimal aligned CIDRs by merging overlaps/adjacency first; no route preference or policy interpretation.
Description
Collapse the exact union of explicit IPv4 prefixes to minimal aligned CIDRs by merging overlaps/adjacency first; no route preference or policy interpretation.
Overlapping or adjacent IPv4 prefixes can be represented by a compact union of CIDR blocks. Normalization and range merging preserve exactly their combined coverage.
When to use this tool
Collapse the exact union of explicit IPv4 prefixes to minimal aligned CIDRs by merging overlaps/adjacency first; no route preference or policy interpretation.
- Prepare the supplied prefixesJson fields for this operation.
- Compare the complete example with the representation used by your own input before carrying the result into another step.
How to use the tool and how it works
- Enter prefixesJson. Use the exact text syntax, units and index conventions explained below.
- Run the tool. If input validation fails, correct the supplied fields before interpreting any result.
- Read result.cidrs. Interpret false, null and empty lists using the distinctions below; they can be valid outputs.
Parse prefixesJson address/prefix objects, normalize and sort their ranges, merge overlaps and adjacency, then greedily cover each merged range with the largest aligned blocks that fit.1
| Input field | Meaning and representation | Accepted input |
|---|---|---|
| prefixesJson | JSON text, entered as one text field. The decoded structure is illustrated below; it is not a separate file. | Text |
For the JSON text fields, the following decoded structures show the example records before they are serialized into input strings. Keep field names, list nesting and value types as shown.
[
{
"field": "prefixesJson",
"decoded": [
{
"address": "10.0.0.0",
"prefix": 25
},
{
"address": "10.0.0.128",
"prefix": 25
}
]
}
]| Output field | Interpretation |
|---|---|
| result | Object containing the named outputs below. |
| result.cidrs | The cidrs list in the ordering and representation described above. |
{
"input": {
"prefixesJson": "[{\"address\":\"10.0.0.0\",\"prefix\":25},{\"address\":\"10.0.0.128\",\"prefix\":25}]"
},
"output": {
"result": {
"cidrs": [
{
"address": "10.0.0.0",
"prefix": 24
}
]
}
}
}Limitations and assumptions
- This collapses address sets without considering route attributes, policies or allocation ownership. An empty input produces an empty list.
- IPv4 input uses strict dotted-decimal octets without leading zeros or surrounding whitespace. IPv6 accepts its supported compressed or full spellings and trims surrounding whitespace, but rejects zone identifiers; embedded dotted IPv4 uses the strict IPv4 spelling. IPv6 address outputs are fully expanded unless stated otherwise.
- All declared input fields are required and unexpected top-level fields are rejected. Numbers must be finite; lists are limited to 128 entries and ordinary text fields to 8,192 UTF-16 code units, with tighter limits where stated.
- JSON text inputs must parse within bounded nesting and size limits. Numeric outputs outside the safe finite range are rejected; large exact integer results use decimal strings. Indexes and half-open spans are zero-based unless a rank is explicitly described as one-based.
Alternative or Complementary methods
Use address-set arithmetic for prefix planning and a routing or interface inspection for deployed configuration. Membership and overlap do not establish reachability, ownership or route preference.
References
Similar or alternative tools
- IPv4 Prefix Set Uncovered Ranges
Find arbitrary inclusive IPv4 domain ranges not covered by an explicit prefix set, preserving uncovered endpoints exactly.
- IPv4 Address Pair Common Prefix
Find the exact common leading-bit prefix of two IPv4 addresses; identical addresses yield a /32 ancestor.