A 300-store retailer's SD-WAN backhauls all SaaS traffic to its data centre; what does local internet breakout gain, and what has to move with it?
answer
- the trombone through the data centre
- per-application exit decision
- inspection follows the exit
- resolver location and source address
- payment traffic may stay home
basics
~20 sLocal breakout sends chosen applications straight from each store to the internet, cutting the detour, data-centre bandwidth and a shared choke point; inspection, logging, address translation and policy that lived at the data centre must now exist per store.
solid answer
~50 sBackhaul sends a store's SaaS traffic through a tunnel to the data centre, through its firewall and proxy, out to the internet and back the same way. That **trombone** adds the store-to-data-centre round trip to every exchange, makes the data centre's internet links carry all 300 stores, and makes one site a choke point for every SaaS session. **Local breakout** lets the edge send selected applications out of the store's own internet transport, translating to the store's public address. What moves with it: **inspection and logging**, either in the edge's own firewall or through a tunnel to a cloud-delivered security service; the store's new **internet exposure**, so unsolicited inbound traffic must be refused; **DNS**, so names resolve near the store; and **source-address assumptions**, since SaaS allow-lists keyed on the data centre's address break. Regulated flows such as card payments often stay backhauled.
go deeper
Recall the difference: backhaul sends internet traffic through the data centre first, local breakout sends chosen applications straight out of the store's own internet line.
Explain where backhaul's latency comes from, adding both legs, and why the exit decision is made per application rather than for all traffic.
List what must move with the exit: inspection, logging, address translation, inbound exposure, resolvers and source-address allow-lists, plus the fallback when broadband fails.
Weigh one central exit against 300 exits: latency and bandwidth gained against compliance scope, operational sprawl and the cost of a cloud security service.
## Backhaul and its costs In a classic hub-and-spoke WAN, every store reaches the internet through the data centre. A store's request to a software-as-a-service application goes through the overlay tunnel to the data centre, through the central firewall, web proxy and intrusion prevention, out of the data centre's internet links to the SaaS provider, and the reply returns along the same path. This **backhaul**, often called the trombone, had good reasons: one place to inspect, log and enforce policy, and one set of public addresses. It also has costs that grow with SaaS use: - **Latency.** Every round trip pays the store-to-data-centre leg as well as the data-centre-to-SaaS leg. - **Bandwidth.** The data centre's internet links and the hub's WAN links carry the SaaS traffic of every store. - **A shared choke point.** A data-centre internet or firewall problem takes SaaS away from every store at once. ### The arithmetic of the detour | Path | Round trip | |---|---| | Store to data centre | 30 ms | | Data centre to SaaS | 20 ms | | Backhauled total | 30 + 20 = 50 ms | | Store direct to SaaS | 12 ms | | Saved per round trip | 50 - 12 = 38 ms | A SaaS page load that needs twenty sequential round trips saves 20 x 38 = 760 ms. ## What local breakout is **Local internet breakout** lets each store's edge send chosen applications directly out of its own broadband or dedicated internet transport. The edge translates the store's private source addresses to its public address (address translation is a separate subject), and the traffic does not travel through the overlay to the data centre. The decision is per application: 1. **Trusted SaaS** (office suite, video meetings) breaks out locally. 2. **General web browsing** breaks out through a security service, either on the edge or in the cloud. 3. **Regulated or internal traffic**, such as card payments and inventory systems, stays in the overlay to the data centre. 4. **Everything unclassified** follows a default the operator chooses, commonly backhaul until classified. The edge often recognises an application only after its first packets (naming an application from flow evidence is a separate subject), so the default exit matters. A flow cannot simply switch exits mid-session: its public source address would change and the server would see a different client. Implementations therefore usually keep an already-started flow on its first exit and apply the breakout decision to the next flow. ## What has to move with it Everything the data centre did for internet-bound traffic now needs an answer per store. | Function | At the data centre | After breakout | |---|---|---| | Inspection | Central firewall, proxy, intrusion prevention | Edge firewall, or a tunnel to a cloud-delivered security service | | Logging and audit | Central logs | Exported from 300 edges or from the security service | | Address translation | A few data-centre public addresses | One public address per store transport | | Inbound exposure | Only the data centre faces the internet | Every store's edge now faces the internet | | Name resolution | Central resolvers | Resolvers that answer for the store's location | Two of these catch teams out: - **DNS location.** Many SaaS providers answer a name with servers near the querying resolver. If stores break out locally but still query resolvers in the data centre, the answers point at servers near the data centre, and part of the latency gain is lost. - **Source-address allow-lists.** A SaaS tenant that only accepts logins from the data centre's public addresses rejects 300 new store addresses, many of them dynamic. Identity-based controls or the security service's fixed egress addresses replace the address list. ## Failure behaviour and compliance - **When a store's internet transport fails**, breakout traffic must fall back to backhaul through the overlay over MPLS or LTE, which means the data-centre path still has to exist and be sized for that fallback. - **Payment card traffic** often stays backhauled so the inspected, logged path stays narrow and the compliance scope does not grow to include every store's internet exit. - **Guest Wi-Fi** is the easy first candidate: it should never enter the corporate overlay, so local breakout with its own segment is both cheaper and safer. ## The trade in one sentence Breakout trades the simplicity of one central exit for lower latency and less backhaul, and it is only safe once inspection, logging and policy have been moved to where the traffic now leaves.
- Why might a retailer keep card-payment traffic backhauled after enabling local breakout?Card data has strict inspection, logging and scope rules. Keeping it in the overlay to the data centre keeps one audited exit, while letting it break out would pull every store's internet edge into the compliance scope.
- A SaaS tenant accepts logins only from the data centre's public addresses. What breaks after breakout, and what replaces it?Store traffic now leaves from each store's own address, often dynamic, so logins are refused. Either the security service's fixed egress addresses go on the allow-list, or address checks give way to identity and device-based access controls.
- What happens to breakout traffic when a store's only broadband link fails?Local exit is gone, so the edge must send that traffic into the overlay over MPLS or LTE and out through the data centre. The fallback works only if the backhaul path still exists, is sized for it and has the matching inspection.
saying these in an interview costs you the question
- Local breakout is just a routing change; security stays where it was
- Breakout means every application leaves the store directly
- Resolver location does not matter once traffic breaks out locally
- Backhauling SaaS only costs the store-to-data-centre round trip
- SaaS allow-lists keep working because the store's address is hidden