skip to content

How would you hand out private address ranges across many teams so networks can still be joined later?

level: principalimportance: should knowfreq 38%

answer

  1. one supernet, one authority
  2. standard block sizes, generously drawn
  3. registry as data, not a wiki
  4. an automated overlap check
  5. avoid the blocks everyone defaults to

basics

~20 s

One authority allocates non-overlapping blocks out of one reserved supernet, in standard sizes per environment and region, recorded in a registry that lives with the infrastructure and is checked automatically. Self-service picking guarantees collisions that only renumbering can undo.

solid answer

~40 s

Reserve one large block for the whole organisation, then allocate standard-sized, non-overlapping sub-blocks from it - per team, per environment, per region - from a single registry that lives in version control next to the infrastructure and is enforced by an automated check rather than by a wiki page. Deliberately over-allocate: unassigned space costs nothing while renumbering a live estate costs a rolling replacement plus the hunt for every address recorded outside the network. Steer away from the blocks other estates commonly pick by default, so an acquisition or a partner connection does not collide on day one. The trade-off worth naming is that a registry slows teams down and wastes space; it buys the ability to join anything to anything later.

code

yaml · 24 lines
yaml
supernet: 10.0.0.0/8          # reserved for the whole organisation
standardBlock: /16            # one per team, per environment, per region
selfServiceInsideBlock: true  # teams cut subnets within their own block

allocations:
  - team: payments
    environment: production
    region: region-1
    range: 10.16.0.0/16
    status: allocated
  - team: payments
    environment: staging
    region: region-1
    range: 10.17.0.0/16
    status: allocated
  - range: 10.18.0.0/15
    status: reserved
    note: growth space next to payments, do not issue
  - range: 10.24.0.0/13
    status: free

avoid:
  - range: 192.168.0.0/16
    reason: commonly chosen by default elsewhere, likely in a merger

go deeper

for a junior

Know that two networks with overlapping ranges cannot be joined, and that ranges are therefore handed out centrally rather than chosen per project.

for a middle

Explain the mechanics of a registry: one supernet, standard block sizes, recorded status, and an automated check that refuses an overlap.

for a senior

Show how it is enforced in practice and how a block is safely reserved, issued and reclaimed without creating a collision inside your own estate.

for a principal

Name the trade-off you are buying: teams wait and address space is deliberately wasted, so that a future integration is a change request instead of a renumbering project.

## Why this is a decision someone has to own Two private networks with overlapping ranges cannot be joined - not by any mechanism the platform offers - without renumbering one of them. Renumbering a live estate is a rolling replacement of every workload plus an archaeological search for every address recorded outside the network. So an allocation policy is not a tidiness exercise: it is the difference between a future integration being a change request and being a project. And the collision is not hypothetical. Left to themselves, independent teams pick the same few obvious blocks, because everyone's default is the same default. ## The shape of a policy that works 1. **Reserve one supernet for the whole organisation** and treat everything inside it as issued or free, nothing else. 2. **Allocate in standard sizes.** One block size per environment per region, chosen generously, so a team that doubles needs no decision and no negotiation. 3. **Carve along the axes you will actually need to keep apart** - environment first, then region, then team - so that a rule expressed in terms of any of those maps onto a contiguous block. 4. **Keep the registry as data**, in version control beside the infrastructure definitions, with an automated check that refuses an overlap. A registry a human must remember to consult is a registry that will be wrong within a quarter. 5. **Leave gaps between blocks**, so a block can grow into adjacent space instead of being scattered. 6. **Avoid the blocks everyone else defaults to**, so that an acquired estate or a partner network is less likely to arrive already overlapping yours. ## The trade-off a lead actually owns | | Central registry | Teams pick their own | |---|---|---| | Speed for a new team | Slower: an allocation request | Immediate | | Address space used | More: blocks are over-sized | Less, apparently | | Chance of a collision | Near zero, if enforced | High, and discovered late | | Cost when it goes wrong | A wasted block nobody uses | Renumbering a live estate | | Who carries it | A named owner and a check | Nobody, until it matters | The honest case against a registry is real: it is a queue, it wastes address space, and it is one more thing to run. The case for it is that the two costs are not comparable. **Unassigned address space is free; renumbering is a project.** Where the queue is the objection, the answer is usually to pre-allocate per team and let them self-serve inside their own block, rather than to abandon central allocation. ## What the registry should record - The **block**, its **owner**, its **environment and region**, and whether it is allocated, reserved or free. - The **date** and the **reason** - a block with no owner and no story is a block nobody dares reclaim. - **Explicitly reserved-but-unassigned space**, so nobody re-issues it believing it to be spare. - **Blocks deliberately avoided**, with the reason, so the next person does not helpfully reclaim them. ## Failure modes to speak to - **The wiki registry.** Accurate on the day it was written. Enforce in the pipeline instead. - **Allocating exactly what is asked for.** A team asks for what it needs today; the block should cover what it needs after doubling twice. - **Environments sharing a block.** The moment a rule needs to name `everything in staging`, a non-contiguous allocation makes it unexpressible. - **Forgetting acquisitions and partners.** Your policy governs your estate; the range you meet in a merger was chosen by someone with a different policy, which is why leaving the obvious blocks alone is worth the small waste. - **Reclaiming too eagerly.** A block freed while a forgotten workload still uses it produces a collision inside your own estate, which is the one case the registry was supposed to make impossible. ## What good looks like in the answer Say who owns allocation, where the record lives, what enforces it, and what size a default block is. Then name the trade-off explicitly: the policy costs teams time and costs the organisation address space it will never use, and it is bought because the alternative cost is paid during an integration, under time pressure, by people who did not make the original choice.

  • A team argues that central allocation slows them down. What would you offer instead of abandoning it?
    Pre-allocate a generous block to the team and let them cut subnets inside it freely. Central allocation then happens once, at team creation, and daily work is self-service. The organisation keeps its non-overlap guarantee and the team keeps its speed.
  • Why steer away from the address blocks most estates pick by default?
    Because the estates you will one day need to join - an acquisition, a partner, a supplier's network - were drawn by someone with the same defaults. Choosing elsewhere costs nothing and removes the most likely source of a collision you will not control.
  • How do you reclaim a block that looks unused without creating the collision you were preventing?
    Require an owner and a reason on every allocation, mark a candidate as reserved rather than free for a full cycle, confirm no interfaces remain in it, and only then return it to the free pool. A block with no recorded owner is the one you must not reclaim quickly.

A street numbering authority: handing out address ranges in advance looks bureaucratic until two neighbourhoods merge and half the houses turn out to share numbers.

saying these in an interview costs you the question

  • Lets each team choose its own range from the obvious defaults
  • Keeps the allocation record on a page nobody enforces
  • Allocates exactly the space a team asks for today
  • Treats unused address space as waste worth optimising
  • Assumes overlapping networks can be joined with more configuration