I85PREP
⌘ K
Aruba SD-WAN (ACSDP) study materials
Aruba SD-WAN (ACSDP) study resources

Duplicate Subnets Across Two Data Centers

Aruba SD-WAN (ACSDP) · Put your knowledge to work in context.

All case studies

Duplicate Subnets Across Two Data Centers

A manufacturer is migrating two acquired sites into one SD-WAN fabric. Site A (data center 1) uses 10.10.0.0/16 for servers and 10.10.20.0/24 for a legacy ERP. Site B (data center 2) uses the same 10.10.0.0/16 and 10.10.20.0/24 ranges because both were built from the same template. Branches at each site must reach their local DC's ERP and also a shared SaaS application. The company wants a single overlay with a hub in each region. During a pilot, branch users at Site A intermittently reach the Site B ERP and see session resets; traceroutes show asymmetric paths. The underlay is healthy and BGP sessions between hubs and branches are up.

1. Explain why the pilot shows intermittent cross-site ERP reachability and asymmetric paths, and what design property is being violated.

Read the worked answer

The two data centers advertise overlapping prefixes (10.10.0.0/16 and 10.10.20.0/24) into one overlay. When the same prefix is reachable via more than one hub, the fabric has no unambiguous way to decide which copy a given branch should use. Depending on the order of route installation, per-flow hashing, or BGP best-path selection, some flows go to the local DC and others to the remote DC. That produces:

  • Intermittent reachability: a flow may land on the wrong DC's ERP, which has no state for the session.
  • Session resets: TCP state exists on one DC's server, but return traffic is steered to the other.
  • Asymmetric paths: forward and reverse flows take different hubs because each hub prefers its local copy of the same prefix.

The violated property is unique, unambiguous prefix ownership per VPN/segment. Overlapping address space must be isolated (separate VRFs/segments, NAT, or route-target separation) before it can share a fabric.

2. Propose a segmentation and routing design that lets each branch reach its local ERP and the shared SaaS while eliminating the ambiguity. Be specific about VRFs/segments and route exchange.

Read the worked answer

Isolate the duplicate space into distinct segments and control route exchange:

  1. Create per-DC segments (VRFs) - e.g., DC1-ERP and DC2-ERP - each containing only that DC's 10.10.20.0/24. The shared 10.10.0.0/16 server space, if it must be reachable, should also be split or NATed so it is not advertised twice.
  2. Attach branches to the correct segment by site: Site A branches import DC1-ERP, Site B branches import DC2-ERP. Use route targets/import-export policy so a branch never sees the other DC's copy of the same prefix.
  3. Shared SaaS lives in a common segment reachable by all branches, with its own non-overlapping prefix.
  4. Route exchange: only advertise each DC prefix into its own segment. Do not leak both copies into a shared segment.
  5. If a branch legitimately needs the remote ERP, use NAT or a distinct translated prefix rather than advertising the raw overlapping range.

This removes the ambiguity at the source: each prefix has exactly one owner per segment, so path selection is deterministic.

3. How would you verify the fix and detect any residual leakage between the two ERP segments?

Read the worked answer

Verification plan:

  • Route table inspection per segment: confirm DC1-ERP contains only DC1's 10.10.20.0/24 and DC2-ERP only DC2's. Any segment showing both copies is a leak.
  • Path trace from a Site A branch: traffic to 10.10.20.0/24 must resolve to the local hub and never traverse the remote hub.
  • Asymmetry check: forward and reverse traces should be symmetric for ERP flows.
  • Session stability: run a sustained ERP session test from both sites; zero resets over a soak period.
  • Policy/route-target audit: confirm import/export lists do not accidentally match both segments.
  • Alarm on overlap: add a monitoring rule that flags any segment advertising the same prefix from two hubs.