During a merger both estates turn out to use the same private range, so why can the networks not simply be linked, and what actually fixes it?

seniorshould knowfreq 52%

answer

one prefix cannot have two targets
the ambiguity is in the plan
re-address, translate, or join the clean parts
translation breaks embedded addresses
check how many flows really need it

basics

~20 s

Forwarding picks a target by destination prefix, so an identical prefix on both sides makes the choice undecidable and platforms refuse the link. Real fixes are re-addressing one side, translating at the boundary, or joining only the ranges that do not collide.

solid answer

~50 s

A route table maps a destination prefix to a target, and a packet is matched against it. If the same prefix exists on both sides of a link, there is no answer to the question 'which side is this destination on', so platforms reject a link between overlapping ranges rather than build an ambiguous table. The clean fix is to re-address one estate, which is correct and permanent and also the most disruptive thing on the list. The pragmatic fix is an address-translating boundary: each side reaches the other through a non-overlapping stand-in range, which works immediately but breaks anything that embeds a literal address, complicates name resolution and makes tracing painful. The cheap partial fix is to link only the sub-ranges that happen not to collide, if the overlap is partial. Doing nothing and exposing a few services through a controlled boundary is also a legitimate answer.

A route table maps a destination prefix to a target, and a packet is matched against it. If the same prefix exists on both sides of a link, there is no answer to the question 'which side is this destination on', so platforms reject a link between overlapping ranges rather than build an ambiguous table. The clean fix is to **re-address** one estate, which is correct and permanent and also the most disruptive thing on the list. The pragmatic fix is an **address-translating boundary**: each side reaches the other through a non-overlapping stand-in range, which works immediately but breaks anything that embeds a literal address, complicates name resolution and makes tracing painful. The cheap partial fix is to link only the sub-ranges that happen not to collide, if the overlap is partial. Doing nothing and exposing a few services through a controlled boundary is also a legitimate answer.

code

yaml · 17 lines

yaml

# Two estates being merged, private ranges as allocated
estateOne:
  networks:
    - name: core
      range: 10.0.0.0/16
    - name: data
      range: 10.1.0.0/16
estateTwo:
  networks:
    - name: core
      range: 10.0.0.0/16      # identical to estateOne core
    - name: analytics
      range: 10.2.0.0/16

collision:
  overlapping: [10.0.0.0/16]
  joinableToday: [10.1.0.0/16, 10.2.0.0/16]

go deeper

for a junior

Hold on to the core fact: two networks with the same private range cannot be joined directly, because a destination inside that range no longer identifies a side.

for a middle

Explain why destination-based forwarding makes the overlap undecidable, and name the three responses: re-address, translate at a boundary, or link only the ranges that do not collide.

for a senior

Show you would scope it before choosing: which prefixes actually collide, which flows are required, and what a translating boundary costs in tracing, name resolution and embedded addresses.

for a principal

Frame it as debt with an owner: translation buys a deadline and is paid monthly forever, re-addressing is paid once. Say which condition would make you spend the programme money.

Why an overlap is fatal rather than merely awkward

Forwarding inside a private network is destination-based. A route table is a list of rows mapping a destination prefix to a target, and a packet is matched against it to pick exactly one target. That model has a hard requirement: within a single routing context, one destination prefix maps to one target.

An overlap violates exactly that. If both estates allocated 10.0.0.0/16 and a workload sends to an address inside it, the table cannot say whether the target is local or the link to the other estate, because both claims are equally true. There is no clever entry that resolves this — the ambiguity is in the address plan, not in the configuration. Platforms therefore refuse to create a link between networks with overlapping ranges, and that refusal is a feature: the alternative is a table whose behaviour depends on undocumented tie-breaking.

What you are choosing between

Option	What it costs	What it breaks	When it is right
Re-address one estate	Weeks to quarters of coordinated change windows	Every hard-coded address, allowlist and certificate pinned to a host	The estates will be one estate permanently
Translating boundary	Standing operational complexity and a device in the path	Embedded addresses, naive name resolution, straightforward tracing	The deadline is real and the join is partial
Link only clean ranges	Almost nothing technically	Nothing, but it covers only part of the need	The overlap is partial and the talkers happen to sit in clean ranges
Do not join at all	Building a controlled boundary for a few services	Any plan that assumed flat reachability	Only a handful of services genuinely need to talk

Re-addressing: the only clean answer

Moving one side onto a non-colliding range removes the ambiguity permanently and leaves you with one coherent estate. It is also the option people quietly rule out in the first meeting, because it touches everything: workloads restart with new addresses, every allowlist written as a literal address goes stale, anything that recorded an address in configuration or in a database is wrong, and the change has to be sequenced network by network with a rollback for each.

It is still the right answer when the two estates are going to be operated as one for years. The cost is paid once; every other option is paid monthly, forever, by whoever is on call.

Translation: the fix that buys time

An address-translating boundary gives each side a stand-in view of the other. Traffic leaving one estate for the other is rewritten so that the far estate appears to live in a range that does not collide with anything locally, and the reverse happens on the way back. It is genuinely useful and it is genuinely a debt:

Literal addresses stop being true. Anything that embeds an address in a payload, a configuration file, a registration or a log is now describing an address that means something different on the other side.
Name resolution has to cooperate. The name a client resolves must return the translated address from that client's side, which means split answers and a place where those answers are maintained.
Tracing becomes a translation exercise. An address in one estate's logs is not the same address in the other's, so every incident starts with a mapping step.
It is directional and stateful. Something in the path holds the mapping, and that something is now a capacity limit and a failure domain.
It rarely gets removed. The pressure that produced it disappears the moment it works.

The partial and the minimal answers

Overlaps are often partial. If each estate allocated several ranges and only one collides, the ranges that do not collide can frequently be joined, which is enough when the workloads that actually need to talk live in them. This buys real progress for very little, and it is worth checking before anyone schedules a re-addressing programme.

The minimal answer deserves more respect than it gets: ask how many services genuinely need to talk. Merger plans assume flat mutual reachability because that is what an unmerged network looks like from the inside, but the real requirement is often a short list — an identity service, a reporting feed, two internal APIs. Publishing that short list through one controlled boundary avoids the whole problem and leaves the address plan free to be fixed properly later.

The order to work in

Enumerate the ranges on both sides and mark exactly which prefixes collide; the answer is frequently smaller than the room assumes.
List the flows that must work by the deadline and note which ranges they actually sit in.
If the flows fit in clean ranges, link those and stop.
If they do not, decide explicitly between translation with a written removal condition and a re-addressing programme with a budget — and record which one you chose and why, because the person who inherits the translating boundary will need to know it was a decision rather than an accident.

## Why an overlap is fatal rather than merely awkward Forwarding inside a private network is **destination-based**. A route table is a list of rows mapping a destination prefix to a target, and a packet is matched against it to pick exactly one target. That model has a hard requirement: within a single routing context, one destination prefix maps to one target. An overlap violates exactly that. If both estates allocated `10.0.0.0/16` and a workload sends to an address inside it, the table cannot say whether the target is `local` or the link to the other estate, because both claims are equally true. There is no clever entry that resolves this — the ambiguity is in the address plan, not in the configuration. Platforms therefore refuse to create a link between networks with overlapping ranges, and that refusal is a feature: the alternative is a table whose behaviour depends on undocumented tie-breaking. ## What you are choosing between | Option | What it costs | What it breaks | When it is right | |---|---|---|---| | Re-address one estate | Weeks to quarters of coordinated change windows | Every hard-coded address, allowlist and certificate pinned to a host | The estates will be one estate permanently | | Translating boundary | Standing operational complexity and a device in the path | Embedded addresses, naive name resolution, straightforward tracing | The deadline is real and the join is partial | | Link only clean ranges | Almost nothing technically | Nothing, but it covers only part of the need | The overlap is partial and the talkers happen to sit in clean ranges | | Do not join at all | Building a controlled boundary for a few services | Any plan that assumed flat reachability | Only a handful of services genuinely need to talk | ## Re-addressing: the only clean answer Moving one side onto a non-colliding range removes the ambiguity permanently and leaves you with one coherent estate. It is also the option people quietly rule out in the first meeting, because it touches everything: workloads restart with new addresses, every allowlist written as a literal address goes stale, anything that recorded an address in configuration or in a database is wrong, and the change has to be sequenced network by network with a rollback for each. It is still the right answer when the two estates are going to be operated as one for years. The cost is paid once; every other option is paid monthly, forever, by whoever is on call. ## Translation: the fix that buys time An **address-translating boundary** gives each side a stand-in view of the other. Traffic leaving one estate for the other is rewritten so that the far estate appears to live in a range that does not collide with anything locally, and the reverse happens on the way back. It is genuinely useful and it is genuinely a debt: - **Literal addresses stop being true.** Anything that embeds an address in a payload, a configuration file, a registration or a log is now describing an address that means something different on the other side. - **Name resolution has to cooperate.** The name a client resolves must return the translated address from that client's side, which means split answers and a place where those answers are maintained. - **Tracing becomes a translation exercise.** An address in one estate's logs is not the same address in the other's, so every incident starts with a mapping step. - **It is directional and stateful.** Something in the path holds the mapping, and that something is now a capacity limit and a failure domain. - **It rarely gets removed.** The pressure that produced it disappears the moment it works. ## The partial and the minimal answers Overlaps are often partial. If each estate allocated several ranges and only one collides, the ranges that do not collide can frequently be joined, which is enough when the workloads that actually need to talk live in them. This buys real progress for very little, and it is worth checking before anyone schedules a re-addressing programme. The minimal answer deserves more respect than it gets: ask how many services genuinely need to talk. Merger plans assume flat mutual reachability because that is what an unmerged network looks like from the inside, but the real requirement is often a short list — an identity service, a reporting feed, two internal APIs. Publishing that short list through one controlled boundary avoids the whole problem and leaves the address plan free to be fixed properly later. ## The order to work in 1. Enumerate the ranges on both sides and mark exactly which prefixes collide; the answer is frequently smaller than the room assumes. 2. List the flows that must work by the deadline and note which ranges they actually sit in. 3. If the flows fit in clean ranges, link those and stop. 4. If they do not, decide explicitly between translation with a written removal condition and a re-addressing programme with a budget — and record which one you chose and why, because the person who inherits the translating boundary will need to know it was a decision rather than an accident.

Why does a platform refuse the link outright instead of letting you write the routes yourself?
Because there is no correct table to write. One destination prefix must resolve to one target, and an overlap makes two targets equally valid. Allowing it would produce behaviour that depends on undocumented tie-breaking and that changes silently between platform versions, so refusing at creation time is the safer contract.
A translating boundary is in place and working. What do you write down so it can eventually be removed?
The mapping between real and stand-in ranges, the list of flows that depend on it, every place a stand-in address has been embedded or resolved, and the condition under which the re-addressing programme becomes cheaper than keeping it. Without that record the boundary becomes permanent by default, because nobody can prove what would break.
The overlap is discovered a week before the deadline. What do you do first?
Compare the colliding prefixes against the flows that must actually work. Frequently the required talkers sit in ranges that do not collide, and linking only those meets the deadline with no translation and no re-addressing. Establishing that takes an hour and can remove the entire emergency.

saying these in an interview costs you the question

Thinks a longer, more specific route entry can resolve an identical prefix on both sides
Believes translation is free once configured and needs no removal plan
Assumes re-addressing is just changing a configuration value per workload
Says the platform is being unhelpful by refusing the link
Plans for flat mutual reachability without asking which flows are required

During a merger both estates turn out to use the same private range, so why can the networks not simply be linked, and what actually fixes it?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

Why an overlap is fatal rather than merely awkward

What you are choosing between

Re-addressing: the only clean answer

Translation: the fix that buys time

The partial and the minimal answers

The order to work in

▾common follow-ups3 questions

▾red flags5 flags

Why an overlap is fatal rather than merely awkward

What you are choosing between

Re-addressing: the only clean answer

Translation: the fix that buys time

The partial and the minimal answers

The order to work in

answer

go deeper