PacketPanda

Address planning

VLSM Calculator

Build a complete IPv4 subnet plan around existing and reserved space. The fixed policy, exact counts, address map, and exports all come from one browser-local result.

Calculates locally

Describe the address plan

Use a canonical parent network, then add every new requirement and any space that is already unavailable.

Planning boundary

Parent network

Host bits are not changed silently. The parent must already begin on its CIDR boundary.

New space

Allocation requests

1 request. Row order is significant when block sizes match.

Protected space

Existing and reserved blocks

No unavailable blocks. Add only canonical CIDRs contained by the parent.

No existing or reserved space has been added.

Private by default. Calculations run locally in your browser. The site does not send or save calculator inputs.

Copy manually

Automatic clipboard access is unavailable. The complete text is selected below.

Fixed planning policy

Repeatable results, visible assumptions.

The Version 1 planner uses one deterministic policy. It never presents a partial allocation as a complete plan.

01

Largest blocks first

Requests are sized by their explicit type and allocated from largest to smallest. Original row order breaks equal-size ties.

02

Lowest aligned address

Each block uses the lowest available address that satisfies its CIDR boundary without touching unavailable space.

03

All or nothing

A result is exportable only when every request fits. Failure explains the fixed-policy constraint without exposing a partial plan.

Operational workflow

Greenfield and brownfield planning.

Start from an empty parent network or describe the CIDRs already occupied or intentionally reserved. Every completed result preserves the request order, allocation order, and stable row identity for review.

01

Declare intent

LAN requests reserve traditional network and broadcast addresses. Point-to-point requests explicitly use RFC 3021 /31 semantics, while host routes use /32.

02

Protect existing space

Existing and reserved blocks must be canonical, contained by the parent, and non-overlapping. They are subtracted before new placement begins.

03

Audit the complete plan

The address-sorted tables, exact-scale map, count conservation, warnings, and exports all consume the same normalized result model.

Brownfield example

10.20.0.0/21

Protect an existing core subnet and a reserved tail block, then place new office, camera, and point-to-point networks around them. Use the brownfield example above to inspect the exact result.

Existing core
10.20.0.0/24
Reserved tail
10.20.7.224/27
Office request
300 LAN hosts
Camera request
40 LAN hosts
WAN request
2 RFC 3021 endpoints
Output
Complete or explicit failure

Evidence

Addressing standards and boundaries

Calculations are deterministic and local. Standards notes describe address semantics; they do not assert that a particular device supports every option.

Common questions

VLSM planner behavior

Does row order affect the plan?

Only when two requests need equal-size blocks. In that case, the request appearing first receives the earlier valid address. Move controls make this policy explicit and keyboard-operable.

Why must the parent and unavailable blocks be canonical?

Planning boundaries should never move silently. If host bits are present, the planner reports the canonical suggestion and asks you to apply it deliberately.

Does a failure prove that no arrangement can fit?

No. It means no complete plan was found under the fixed Version 1 placement policy. The failure distinguishes raw-capacity shortage from alignment or fragmentation.

Why is /31 a separate request type?

Two hosts on a LAN and two endpoints on a point-to-point link have different semantics. Explicit intent prevents the planner from silently choosing RFC 3021 behavior.