I85PREP
⌘ K
CNEpv study materials
CNEpv study resources

Overlapping Address Space After a Merger

CNEpv · Put your knowledge to work in context.

All case studies

Overlapping Address Space After a Merger

Two regional distributors merged last quarter. Company A uses 10.10.0.0/16 across three buildings and a small data center; Company B uses 10.10.8.0/16 at its warehouse campus and 10.10.0.0/24 for a legacy ERP cluster. The new CIO wants a single routed domain within 90 days, no permanent NAT between internal sites, and a 30 percent growth reserve at every site. A has 900 hosts today; B has 420. Both use 10.10.0.1 as their default gateway, and DNS forwarders are hard-coded on 60 devices. The WAN is a 200 Mbps MPLS service with a managed router at each site; the provider will not carry overlapping prefixes. The ERP vendor supports renumbering only in a six-hour maintenance window and requires the old address to remain reachable for 30 days. The network team has two engineers and no change freeze.

1. Which address block should be retained, and how should the other company be renumbered? Show the subnet sizes for 900 and 420 hosts with 30 percent growth, and state the order of work.

Read the worked answer

Retain Company A's 10.10.0.0/16. It is the larger aggregate and already contains both of B's overlapping blocks, so keeping it avoids moving 900 hosts and the associated 60 hard-coded DNS entries. Move B into a clean 10.20.0.0/16 and summarize that at the WAN.

Sizing:

  • B warehouse: 420 x 1.30 = 546 usable addresses required. A /23 gives 510 usable, which fails; a /22 gives 1,022, so use 10.20.0.0/22. That is more than 30 percent growth but the next smaller mask cannot satisfy the requirement.
  • B ERP: use 10.20.4.0/24 for the current cluster and vendor growth; a /25 would be too tight once management and staging hosts are included.
  • A: 900 hosts across three buildings is roughly 300 per building. 300 x 1.30 = 390, so each building needs a /23 (510 usable), for example 10.10.0.0/23, 10.10.2.0/23, and 10.10.4.0/23.

Order of work:

  1. Build the new B gateway and DNS/DHCP services in 10.20.0.0/16.
  2. Renumber non-ERP warehouse hosts in floor-by-floor waves, keeping the old and new addresses on dual-homed servers where possible.
  3. Lower DNS TTLs to 60 seconds at least 24 hours before the ERP window.
  4. Renumber the ERP cluster in the six-hour window, with a tested rollback.
  5. For the 30-day old-address requirement, use a scoped one-to-one NAT on the B border for vendor VPN access only; do not build general site-to-site NAT. Remove it after day 30.

2. How would you resolve the duplicate 10.10.0.1 default gateway and the 60 hard-coded DNS entries without causing an outage?

Read the worked answer

Treat the duplicate gateway as a routing and Layer 2 separation problem, not a DNS problem. B's 10.10.0.1 must not be advertised into the merged domain while A's 10.10.0.1 exists. Build 10.20.0.1 as a VRRP or HSRP gateway for B, put the legacy 10.10.0.0/24 into a migration VRF on the B router, and advertise only 10.20.0.0/16. Before cutover, scan for duplicate ARP and IP conflicts; after cutover, enable DHCP snooping and IP source guard on access ports.

For DNS:

  • Inventory the 60 static devices with an address scan plus a configuration review; identify owner and criticality.
  • Lower the TTL on existing records to 300 seconds or less.
  • Add the new B forwarder (for example 10.20.0.53) and keep the A forwarder reachable during migration.
  • Use DHCP option 6 for dynamic clients and a configuration-management push for static devices.
  • Configure conditional forwarding on the new DNS servers so legacy names still resolve during the 30-day coexistence period.

Do not change the default gateway and DNS on the same maintenance window. Change gateway first, validate application sessions and return paths, then change DNS in a second wave. Keep a per-device rollback note, because 60 devices is small enough that an automated push without verification can still cause a lengthy outage.

3. The MPLS provider will not carry overlapping prefixes. What migration architecture and acceptance criteria would you use for the 90-day plan?

Read the worked answer

Use a phased architecture that never advertises B's old prefixes into the provider cloud. The provider carries only A's 10.10.0.0/16 and B's new 10.20.0.0/16. B's old 10.10.8.0/16 and 10.10.0.0/24 stay local to B inside a migration VRF, with a default route toward the new B core. The old ERP /24 is reachable only through the scoped vendor NAT described earlier.

90-day plan:

  • Days 1-14: discovery, source-of-truth inventory, duplicate-IP scan, DNS dependency map, and rollback design.
  • Days 15-45: renumber non-ERP warehouse hosts and move them to 10.20.0.0/22; validate DHCP, DNS, and application access after each wave.
  • Days 46-60: ERP renumbering window, vendor connectivity test, and old-address NAT validation.
  • Days 61-90: stability monitoring, removal of temporary routes, and decommissioning of old B prefixes.

Acceptance criteria: every B host answers on a new address; no old B prefix appears in the provider routing table; traceroute from the data center to the warehouse adds no more than one hop compared with baseline; ERP transaction latency stays within 50 ms of baseline; no duplicate-IP alarms for 14 consecutive days; and rollback can restore a wave within two hours. Also verify the 30 percent growth reserve remains after the first year of projected additions.