Four High-Latency Sites in the Middle of an MPLS-to-SASE Migration
Meridian Retail runs 22 sites in 11 countries and is 60% through replacing MPLS hub-and-spoke with a SASE fabric. Each site has two internet circuits and a tunnel to its nearest point of presence. Voice shares that path with a 150 ms one-way latency budget. Four sites - Lagos, Nairobi, Buenos Aires and Perth - have no nearby PoP; their tunnels land in Frankfurt or Singapore and add 170-210 ms round trip, and Lagos has logged 30 voice complaints in two weeks. Procurement cannot add circuits at those four sites for six months. Finance traffic must be inspected by the full security stack regardless of path. The infrastructure team proposes returning all traffic from the four sites to the old MPLS hub in London until circuits improve, which would put inspection in London rather than at a PoP.
1. Evaluate the MPLS-backhaul proposal against the alternatives for the four problem sites, using the stated latency budget.
Read the worked answer
The proposal is not one option, it is two changes bundled: a path change and an inspection-location change. Separate them.
The 170-210 ms figure is round trip, so once codec delay, jitter buffer and queuing are added it consumes most of the 150 ms one-way budget before the user speaks. Backhauling everything to London does not automatically beat Frankfurt for Lagos, and it definitely does not help Perth, where the London path is longer than Singapore. So the proposal should be rejected as a blanket rule.
Alternatives, in order of preference: (1) keep the four sites on their tunnels but split policy by application - real-time voice and video break out locally to the internet with no TLS break and priority queuing, while web and SaaS traffic stays on the inspected tunnel; (2) for finance users at those sites, keep the full inspection stack on the path and accept the latency, because the requirement is explicit and the population is small; (3) if voice still fails, add a local SD-WAN box with a direct internet path for the voice VLAN only, which needs no new circuit.
The decision rule: never trade a regulated control for latency, and never trade voice quality for inspection that can be applied to a narrower traffic class. Measure both options with synthetic voice probes for two weeks before committing, and publish the rollback condition.
2. Design the security policy for the four sites so inspection still exists without breaking real-time traffic.
Read the worked answer
The policy has to be written per application class, not per site, so it survives the next opening.
Rules: identity and device posture evaluated before any access decision at all four sites; real-time media identified by application signature and placed in a low-latency queue, excluded from TLS decryption, with DSCP honoured end to end; business web and SaaS traffic decrypted and inspected at the PoP with the standard profile; finance traffic pinned to the full stack with no breakout, regardless of the latency cost; guest traffic isolated to its own tunnel and bandwidth ceiling so it cannot starve voice.
Two details decide whether this works in practice. First, the exception must be written as 'real-time media application signatures are not decrypted', not as 'Lagos users are not inspected', because the second version cannot be audited and will spread. Second, the local-breakout path needs its own logging: if voice bypasses the PoP, DNS and flow logs from the site device must still reach the SIEM, or you have created an unmonitored exit.
Document the compensating control for each exception (logging, endpoint agent, device posture), because at the six-month review those are what justify keeping or removing the exception.
3. What evidence would you collect to prove circuit failover and policy behaviour actually work at these sites before declaring the migration complete?
Read the worked answer
Completion should be a set of measurements, not a cutover date.
Baseline first: per-site round-trip time, jitter and packet loss to the PoP, plus a voice MOS estimate from synthetic calls, captured before any change so improvement is provable.
Then fault injection, one site at a time: bring down the primary circuit during business hours and record tunnel re-establishment time, whether established sessions survive, whether voice re-routes or drops, and whether policy is still enforced on the secondary path. Do the same for the PoP path itself by forcing traffic to the secondary PoP, which is the failure the design has never exercised.
Policy proof: run a small set of known-bad test requests (malware sample download, unauthorised SaaS upload, finance user attempting breakout) from each of the four sites and record which control caught them and how fast.
Finally, keep a two-week observation window with the voice complaint rate and ticket volume as acceptance criteria, and write the rollback trigger in advance - for example, more than five voice complaints per week at a site returns that site to its previous path pending review.