Merging Two Enterprises That Both Claim 10.20.0.0/16
Northwind Health (2,300 staff, 60 sites) has acquired Arbor Diagnostics (1,100 staff, 38 sites). Both companies use 10.0.0.0/8 internally: 214 subnets overlap, including 10.20.0.0/16, which is the primary server VLAN in both. The combined network must run on one routed core within 18 months, but no site may lose connectivity to either company's ERP for more than a 4-hour window, and finance has frozen new hardware purchases until fiscal Q3. Arbor's Frankfurt data center is subject to a data-residency rule: patient records for German citizens may not be routed to or stored in Northwind's US data centers. A pilot link between the two headquarters was turned up last month; since then OSPF adjacencies between the two cores flap every 30-90 minutes and 10.20.0.0/16 routes oscillate between sites. The CIO wants a design decision in two weeks and wants to know which option is cheapest over three years, not just in year one.
1. Which address-remediation approach do you recommend for the 214 overlapping subnets, and how do you decide per subnet between re-addressing, NAT, and VRF isolation?
Read the worked answer
Treat the flapping as a duplicate-subnet symptom, not an OSPF problem. Two cores advertising 10.20.0.0/16 alternately win the RIB, SPF churns, and the adjacency resets. First action is to stop leaking the overlapping space at the pilot boundary, before any remediation.
Decide per subnet against a written scorecard rather than by preference:
- Re-address when the subnet is under roughly 50 endpoints, is DHCP/DNS-driven, and has no hard-coded addresses in application configuration. Expect about 70% of the 214 subnets to fall here.
- NAT only as a time-boxed bridge: subnets owned by third parties you cannot renumber, or applications with embedded IPs (older HL7 interfaces, license servers, some SCADA). NAT is cheap in year one but adds state, breaks inbound connections, complicates IPsec and logging, and makes every future troubleshooting call slower. That carrying cost is why it usually loses the three-year comparison once engineer hours are counted.
- VRF isolation where separation is a permanent requirement: the German residency flows, and any business unit likely to be divested.
Scope the VRF narrowly. A VRF is a permanent operational tax on every tool, firewall rule, and troubleshooting session; applying it company-wide is the expensive answer, not the safe one. Publish an expiry date for every NAT rule, or it becomes the architecture.
2. How would you sequence the migration across 18 months, and what makes a wave go/no-go?
Read the worked answer
Sequence by dependency, not by site size or geography: (1) freeze the boundary and eliminate leaked prefixes; (2) build the target core, VRF-aware and dual-stack ready; (3) move shared services - DNS, AD, IPAM - because these gate everything downstream; (4) migrate a few non-overlapping sites to prove the operating model; (5) re-address overlapping subnets in dependency order, application first, then servers, then clients; (6) decommission the NAT bridges.
Go/no-go per wave must be measurable, not a feeling: DNS resolves every migrated record from both domains; no application owner reports a failure across a five-day soak; a route-table diff shows zero leaked prefixes; a rollback has been executed in a lab rather than assumed. The 4-hour window means client subnets can move inside a maintenance window, but server subnets should be dual-homed or behind a load balancer before cutover.
The 18-month clock is the binding constraint. With 214 subnets and roughly two engineers, the plan is about nine subnets per engineer-month including soak time. If wave one runs more than 20% over plan, the correct decision is contractor capacity, not a shorter soak - the soak is exactly what protects the 4-hour availability requirement.
3. How do you satisfy the German data-residency rule without cutting Frankfurt off from the rest of the company?
Read the worked answer
Residency is a routing and DNS problem before it is a firewall problem.
Routing: place the Frankfurt records in a dedicated VRF whose only exits are the Frankfurt data center and a Frankfurt Internet edge. Do not let that VRF's prefixes appear in US route tables at all. Filtering is stronger than policy-based routing, because a prefix that is never learned cannot be accidentally preferred after a routing change. If a German clinician needs the US ERP, publish a reverse-proxied API endpoint rather than routing the client into the US VRF.
DNS: split-horizon, with German names resolving only to Frankfurt addresses. Audit the replication topology as well - AD, monitoring, and log shipping all copy data across borders by default and are the usual audit findings.
Transport: keep IPsec or MACsec on the WAN links to the two German sites so no transit provider can claim the plaintext, and hand the auditor an as-built diagram showing exactly two permitted exit points.
On cost: re-addressing is a one-time expense; a VRF is a permanent one. Scope the residency VRF to the regulated flows only, not to the whole acquired company - perhaps 24 subnets in the VRF, 150 re-addressed, and 40 NAT bridges with a 24-month expiry.