I85PREP
⌘ K
ACE Professional study materials
ACE Professional study resources

Hub-and-Spoke Migration with Asymmetric Return Paths

ACE Professional · Put your knowledge to work in context.

All case studies

Hub-and-Spoke Migration with Asymmetric Return Paths

A retail company runs 40 branch sites, each with a 100 Mbps MPLS circuit to a regional hub and an unused 500 Mbps internet link. The design team wants to move to a Cisco SD-WAN overlay with direct internet access at branches, keeping a hub-and-spoke policy for PCI-scoped traffic. During a pilot at four sites, latency to the payment processor dropped from 45 ms to 18 ms, but the PCI compliance scanner now flags branch-to-branch cardholder traffic transiting the internet link. Meanwhile, voice quality at two pilot sites degrades every afternoon when the local backup job runs, even though WAN utilization stays under 30 percent. The security team insists PCI traffic must never traverse the public internet, and finance has approved only one more quarter of dual-running costs.

1. How should the architect reconcile the PCI segmentation requirement with the SD-WAN direct-internet goal, and what policy construct enforces it?

Read the worked answer

The architect should treat PCI segmentation as a topology constraint, not a QoS preference. Two facts drive the decision: (1) the scanner proved branch-to-branch cardholder flows are taking the internet underlay, and (2) dual-running budget expires in one quarter, so the fix must be durable, not a pilot workaround.

Reasoning steps:

  1. Classify traffic by regulatory scope first. Build an application-aware routing policy that matches PCI-scoped flows (payment processor subnets, cardholder data VLANs) and pins them to the MPLS transport with a hub-and-spoke service VPN. All other traffic - guest Wi-Fi, SaaS, general internet - uses local internet exit.
  2. Enforce with VPN topology plus centralized data policy. Put PCI segments in a separate service VPN whose topology is hub-and-spoke (no branch-to-branch spokes). Add a centralized data policy that drops any PCI flow attempting to use a non-MPLS TLOC. This is defense in depth: topology prevents the path, policy blocks the exception.
  3. Validate with the scanner, not with intent. Re-run the compliance scan after policy deployment and confirm zero PCI flows egress the internet link. Keep the evidence for audit.
  4. Retire dual-running deliberately. Once PCI traffic is pinned and scanned clean, decommission MPLS at non-PCI-heavy sites first, keeping MPLS only where cardholder volume justifies it.

The trap is answering "add a QoS policy" or "encrypt the internet link." Encryption does not satisfy a segmentation mandate that forbids public transit; only topology and data policy do.

2. The voice degradation correlates with the backup job, yet WAN utilization is under 30 percent. What is the likely cause and how should the architect verify and remediate it?

Read the worked answer

Low average utilization with periodic voice loss points to microbursts and queueing, not bandwidth exhaustion. A backup job sends bursts that momentarily fill the interface or a downstream queue, and voice packets arrive behind those bursts.

Verification plan:

  1. Look at sub-minute telemetry. Pull interface and queue statistics at 1-second or finer granularity from the SD-WAN analytics and NetFlow/IPFIX exports. Average utilization hides the bursts; percentile and peak-rate views expose them.
  2. Check queue drops and latency per class. Confirm voice is in the priority/low-latency queue and that drops are occurring in the backup class or default class, not voice. If voice itself is dropping, the priority queue may be misconfigured or oversubscribed.
  3. Confirm the backup path. Determine whether backup traffic is taking the internet link (where 500 Mbps may be shared with other flows) or the MPLS link, and whether it is shaped at the branch edge.

Remediation:

  • Apply a rate limiter or shaping policy to the backup application so it cannot burst above its committed rate.
  • Ensure voice gets a strict priority queue with an admission limit, and that the priority queue is not starved by an oversized burst class.
  • Schedule or window the backup to off-peak hours as a secondary control.
  • Re-measure with the same fine-grained telemetry to prove the fix.

The judgement being tested: distinguishing a capacity problem from a burst/queueing problem, and choosing telemetry granularity that can actually see the symptom.