Palo Alto Prisma SDWAN Deep Dive Part 8: Failure Modes, Scale Limits, and a Vendor Comparison Checklist
Seven parts in, it’s time to do what the control-plane showdown post did for Fortinet, Arista/VeloCloud, and Cisco: pull the philosophy apart into specific, testable claims about what breaks, what keeps running, and where the numbers stop scaling — then put Prisma SD-WAN’s answers next to the other three’s, honestly, including the places it loses.
What actually happens when Strata Cloud Manager goes dark
Part 2 already made the structural claim: policy authoring and telemetry aggregation live in Strata Cloud Manager, but the real-time path-selection decision loop runs locally on every ION, against locally-cached policy and locally-measured telemetry. Losing connectivity to Strata Cloud Manager, then, has a specific and narrower blast radius than the name “cloud-only controller” might suggest:
- What keeps working: App-ID classification, Adaptive QoS shaping, and — critically — App-Defined Policy path selection all continue exactly as configured, because none of that decision loop requires a live round-trip to the cloud. Existing Secure Fabric Links stay up and continue carrying traffic. A branch that loses its connection to Strata Cloud Manager at 3am doesn’t blackhole a single flow.
- What stops working: Policy changes can’t be pushed down — if you needed to add a new App-Defined Policy rule or adjust an SLA threshold during the outage, that has to wait. Telemetry stops flowing upstream, so Strata Cloud Manager’s dashboards go stale for that site even though the site itself is fine. New device onboarding (ZTP claiming a fresh ION) is also blocked, since that bootstrap handshake genuinely does need the cloud controller reachable.
That’s structurally closer to Arista/VeloCloud’s “new routes stop, existing tunnels keep forwarding” failure mode than to Cisco’s vSmart-dependency story — but for a different underlying reason. Arista’s Gateway is a route-reflector whose absence stops new route learning specifically. Prisma SD-WAN’s cloud controller was never in the real-time forwarding-decision path to begin with, by design, so its absence doesn’t degrade an active decision loop at all — it just pauses the ability to change what that loop is deciding against.
Scale
Palo Alto’s own positioning for Prisma SD-WAN spans 5 to 5,000-plus sites per deployment, with the ION hardware line — 1000/2000 at the small-branch end through 7000/9000 at the large-DC-hub end — sized to match: smaller branch models handle a modest fabric-VPN peer count appropriate to a single site’s circuits, while the largest DC-class appliances are built to aggregate several thousand fabric peers as a hub. Exact per-model VPN-scale numbers are worth checking against the current datasheet rather than trusting a figure quoted here — Palo Alto revises them with each ION software release, and the official specification sheets are explicit that throughput and scale numbers are tied to a specific release version and are “subject to change.”
The more interesting scaling question, given Part 2’s architecture, isn’t “how many sites can one controller manage” the way it is for vManage’s NMS database — Strata Cloud Manager is a multi-tenant SaaS platform, not a customer-operated cluster with a documented ceiling the way an on-prem vManage deployment has. The scaling pressure point that actually matters operationally is closer to policy design discipline: because App-Defined Policy is authored per application rather than per site, an estate with thousands of sites and a sprawling, inconsistent set of custom application definitions accumulated over years is a harder operational problem than raw site count — the same “configuration drift across time” risk any large fleet accumulates, just expressed through policy objects rather than per-device templates.
Side by side: four philosophies
| Fortinet | Arista/VeloCloud | Cisco/Viptela | Palo Alto/Prisma | |
|---|---|---|---|---|
| Control plane location | Collapsed onto every data-plane device | Collocated with data-plane relay on the Gateway | Fully separate (vSmart) | Split: policy in the cloud (Strata Cloud Manager), real-time decision on every ION |
| Reachability mechanism | BGP (iBGP over the overlay) | Proprietary overlay exchange | OMP (BGP-flavoured) | No routing protocol — full-mesh Secure Fabric Links by default; reachability is a LAN-side BGP/static concern, separate from path choice |
| Path-selection basis | Route preference / SD-WAN rules | Route reflection + DMPO link measurement | OMP route + TLOC preference | Per-flow, App-ID-keyed, against continuously measured SLA thresholds |
| Management plane | FortiManager — on-prem or cloud, push-only | Orchestrator — push/pull, out of loop | vManage — on-prem cluster or cloud, push/pull | Strata Cloud Manager — cloud-only, no on-prem option |
| Local security depth | Full NGFW on every device by design | Basic; security typically inserted separately | Basic on-box; UTD container for deeper inspection | Zone-based firewall + App-ID locally; deep inspection (IPS/DLP/URL/sandbox) delegated to Prisma Access |
| If the cloud/control function disappears | Nothing — every box already had its own view | New routes stop; existing tunnels keep forwarding | New routes stop; existing tunnels keep forwarding | Nothing to the data plane; policy pushes and telemetry pause |
| Native cloud onramp automation | Engineer/Terraform-driven (TGW, vWAN) | Partner Gateway (BGP-to-MPLS bridge) | vManage-native TGW/vWAN integration | CloudBlade-automated (Azure vWAN, AWS TGW); cloud region = ordinary DC site |
| Distinctive strength | Inline NGFW depth at every branch, decades of BGP tooling | Softest control-plane failure mode; mature multi-owner track record | Deepest policy/segmentation granularity, SRv6 traffic engineering, largest install base | Cleanest SASE integration story; policy expressed in business/application terms, not routing terms |
| Distinctive cost | No centralized routing-table view | Gateway capacity per tenant is a real sizing exercise | vManage database strain past ~2–3k edges; premium engineering skill required | No on-prem management option; local security depth is genuinely shallower without Prisma Access; less mature routing-protocol tooling for engineers who need it |
Choosing between them isn’t about which is “best”
The pattern that closed the original showdown post holds just as well with a fourth architecture added: none of these is more correct, each is the right answer for what its builders were solving for. Fortinet’s collapsed model comes from a company whose every device was already a capable firewall and router before SD-WAN existed. Cisco/Viptela’s decoupled model comes from founders who explicitly built route-reflector-scale thinking in from day one, aimed at the largest policy-heavy WANs. Arista/VeloCloud’s Gateway model comes from a clean-slate, cloud-hosted overlay built for the MPLS-to-internet transition specifically. Prisma SD-WAN’s app-defined model comes from CloudGenix’s founding bet that the routing abstraction itself was the wrong layer to hand a network engineer — and Palo Alto’s subsequent decade of investment has pointed that bet squarely at a SASE outcome, for better and for worse depending on how committed an organisation already is to that outcome.
The honest, practical version of “which one should I run” from Part 5 generalises to the whole series: if your WAN edge needs to be a fully self-sufficient security boundary regardless of cloud reachability, Fortinet’s inline-everywhere model is hard to beat. If you want the softest possible control-plane failure mode and don’t mind a proprietary overlay exchange, Arista/VeloCloud earns that. If you’re running the largest, most policy-heavy enterprise WAN on the planet and have the engineering depth to match, Cisco/Viptela’s decoupled OMP model is what that scale was built for. And if your organisation’s next two years are genuinely headed toward SASE rather than just SD-WAN, and you’re comfortable with policy expressed in application terms instead of routing terms, Prisma SD-WAN is the one architecture on this site actually built around that specific destination rather than arriving at it as an add-on.
Series wrap
Eight parts: the CloudGenix lineage and the app-defined premise, ION and Strata Cloud Manager, AppFabric and path selection without a routing protocol, the data plane, security and CloudBlades, cloud onramp, the cutover playbook, and this comparison capstone. Four SD-WAN philosophies now sit side by side on this site — collapse it, co-locate it, decouple it fully, or abstract it away entirely — and every one of them is a defensible, shipping answer to the same underlying question a WAN engineer has been asking since MPLS got too expensive to justify: where should the decision live, and what happens when it can’t be reached.