M&A Integration with Overlapping Subnets and a 30-Day ERP Deadline
Your company acquires a competitor that also runs ExtremeCloud SD-WAN. The acquirer uses 10.10.0.0/16; the acquired company uses 10.10.0.0/16 at multiple sites, including duplicate 10.10.20.0/24 server subnets. The immediate requirement is ERP access between 20 acquired sites and the acquirer's data center within 30 days. A full re-IP of the acquired estate is estimated at nine months. The acquired sites have no consistent DNS naming and several applications embed server IP addresses in configuration. You must provide connectivity without creating routing loops or exposing overlapping subnets to the core. Leadership wants a 'temporary' fix but is worried about long-term complexity.
1. Recommend an integration architecture for the overlapping subnets that provides immediate ERP connectivity without a 30-day re-IP.
Read the worked answer
Use a segmented integration zone rather than injecting the acquired 10.10.0.0/16 into the acquirer's core. Place the acquired SD-WAN domain in a separate routing segment or VRF, and connect it to the acquirer through a controlled gateway that performs NAT for the specific ERP flows. Only the ERP server addresses and required client subnets should be translated; do not NAT the entire /16. Each duplicate 10.10.20.0/24 must remain isolated within its acquired site or segment, and inter-site traffic must pass through the gateway so the overlap is never visible to the core. Publish the ERP service on a unique NAT address and use destination NAT for inbound sessions, source NAT for return traffic, and stateful inspection. This provides immediate connectivity, keeps the core routing table clean, and limits the blast radius. It is a bridge, not a target architecture: document the translated flows and require a re-IP plan for the acquired server subnets.
2. Explain the risks of using NAT at the boundary and how you would sequence the migration to a routed design.
Read the worked answer
NAT solves the overlap but breaks end-to-end addressability. Applications that embed IP addresses will fail unless the embedded address is translated or the application is reconfigured. Logs, SIEM, and troubleshooting lose source identity; IPsec and some protocols do not survive NAT without helpers; and double NAT can create asymmetric or untraceable paths. The migration sequence should start with an inventory of duplicate subnets and embedded-IP applications, then re-IP the least critical acquired sites first while keeping NAT for ERP. Build consistent DNS naming before moving servers, because DNS reduces dependence on embedded IPs. Pilot one acquired site with a routed segment and no NAT for test traffic. Then migrate server subnets in priority order, update firewall rules and monitoring, and only remove the NAT gateway after all ERP flows are routed natively. Keep a rollback path and do not decommission the integration zone until two clean audit cycles pass.
3. What policy and monitoring controls would you put in place during the coexistence period?
Read the worked answer
Enforce a deny-by-default policy between the acquired segment and the core, with explicit permits only for ERP and approved management flows. Do not allow acquired sites to advertise overlapping prefixes into the core; filter at the integration gateway and log any attempted route leak. Apply application-aware policy so only ERP protocols and required ports cross the NAT boundary, and rate-limit or block lateral traffic between duplicate subnets. Monitor NAT translations, session counts, and failures; alert on translation exhaustion and on any new flow to an unapproved destination. Retain NetFlow or equivalent records with both pre- and post-NAT addresses so investigations remain possible. Add synthetic ERP checks from several acquired sites, and review firewall and routing changes weekly. Finally, track the re-IP burn-down and set an expiration date for each NAT exception so the temporary design does not become permanent by default.