Palo Alto Prisma SDWAN Deep Dive Part 1: From CloudGenix to App-Defined SASE
The fourth philosophy
The SD-WAN control-plane showdown post lined up three SD-WAN control-plane philosophies side by side: Fortinet collapses control onto every data-plane device via ADVPN and BGP, Arista/VeloCloud co-locates it on a multi-tenant Gateway, and Cisco/Viptela decouples it fully into vSmart and OMP. That post closed by saying the Cisco series would pick up the third answer “right before” — and it did, for ten parts. What it didn’t do is come back for the fourth, because the fourth vendor wasn’t ready yet. It’s ready now.
The history post already told the corporate version of this story: three startups, founded within a year of each other, chasing the same MPLS-is-expensive-and-the-internet-got-good-enough problem. Viptela became Cisco Catalyst SD-WAN. VeloCloud became Arista SD-WAN by way of VMware and Broadcom. CloudGenix became Prisma SD-WAN — and unlike the other two, the acquirer didn’t just relabel the UI and keep selling the same architecture. Palo Alto Networks pulled CloudGenix into a genuinely different strategic story, and the technology’s shape changed because of it. This series is about what that story actually built, and how it differs — structurally, not just in marketing copy — from the three architectures already covered here.
CloudGenix, briefly
CloudGenix was founded in 2013 by Kumar Ramachandran and Mani Ramasamy, a year after Viptela and VeloCloud, with a premise that was genuinely contrarian at the time: instead of giving a network engineer more routing knobs — preferred TLOCs, colour-based path policy, BGP communities over an overlay — get the network out of the business of routing decisions entirely and let it reason about applications instead. Classify the traffic, understand what “good” looks like for that application (loss, latency, jitter thresholds an engineer sets once, in business terms), and let the fabric pick a path that meets it, continuously, without anyone writing a route-map. That’s the “app-defined” premise the earlier history post flagged as “the architecture this site hasn’t covered yet.” It’s covered starting now.
Palo Alto Networks announced its intent to acquire CloudGenix in February 2020 and completed the deal in April 2020, for $420 million. That’s the smallest of the three headline acquisitions in this site’s SD-WAN history coverage — Cisco paid $610M for Viptela, VMware paid $449M for VeloCloud — but the strategic logic behind it was arguably the most specific of the three. Palo Alto wasn’t buying a WAN routing product to bolt onto an existing router line, the way Cisco was, and it wasn’t buying a virtualization-adjacent overlay to complete a software-defined-data-centre story, the way VMware was. It was buying a branch on-ramp for a security architecture it was already building: what would eventually be called Prisma SASE.
What survived the acquisition, and what didn’t
Compare this to how the other two acquisitions played out. Viptela’s vManage/vSmart/vBond naming survived for years post-acquisition and is still what you’ll hear on a call with a Cisco engineer today, official Catalyst SD-WAN rebrand notwithstanding. VeloCloud’s VCE/VCG/VCO initials survived three changes of ownership without the architecture being touched at all. CloudGenix’s branding didn’t survive in any form — no “Prisma (CloudGenix)” parenthetical, no legacy portal name lingering in the UI. The rebrand to Prisma SD-WAN landed within about a year, and the CloudGenix name is now something you find in old data sheets and this kind of history post, not in anything current.
What did survive, and matters far more for this series than the branding: the underlying architecture. The app-defined premise — no dedicated routing protocol, a full-mesh secure fabric between edge devices, per-flow path selection driven by real-time telemetry against business-intent policy — is structurally unchanged from the CloudGenix product Palo Alto bought in 2020. What changed around it is everything Palo Alto has since built on top: the pull into Prisma Access for cloud-delivered security, CloudBlades for chaining in third-party services without touching the branch device, ADEM for synthetic experience monitoring, and — most recently — the consolidation of what used to be a standalone “Prisma SD-WAN portal” into Strata Cloud Manager, Palo Alto’s unified management plane that also drives NGFW and Prisma Access policy from the same console. Part 2 gets into what that consolidation actually looks like architecturally; for now, the headline is that Prisma SD-WAN today is less a standalone SD-WAN product with its own identity and more a component of a single secure-access story — which is exactly the trajectory the history post predicted when it called CloudGenix “the one where the acquirer’s strategic priorities most visibly won out over preserving the original brand.”
Why “app-defined” is a genuinely different answer
Here’s the thing worth sitting with before Part 2 gets into components: every architecture this site has covered so far — Fortinet’s BGP-over-ADVPN, Arista/VeloCloud’s Gateway-reflected overlay exchange, Cisco/Viptela’s OMP — answers the same underlying question the same way. All three still have something that functions like a routing protocol: a mechanism for advertising reachability (a prefix, a TLOC, a next-hop) and a policy layer bolted on top that says which of several advertised paths to prefer. The vocabulary differs — TLOC preference, AS-path-flavoured OMP attributes, VeloCloud’s own overlay exchange — but underneath, it’s still “here’s what I can reach, here’s how to weigh the options.”
Prisma SD-WAN’s starting premise is that this is the wrong level of abstraction. Rather than propagate routes and then layer a policy on top to pick among them, every ION device builds a secure tunnel mesh to essentially everywhere it needs to reach by default — full details in Part 3 — and the interesting decision happens per-flow, in real time, keyed to the application, not the destination prefix. There’s no route advertisement to withdraw when a link degrades, because there was never a route in the traditional sense to begin with — there’s a continuously-measured set of paths and a policy that says “Zoom needs sub-150ms and sub-1% loss, pick whichever path currently satisfies that.” It’s a genuinely different mental model from “configure preferred paths” — closer to “tell the system what good looks like for this application and let it work out the plumbing.”
That’s not a value judgement yet — every architecture on this site has real trade-offs, and Part 8’s vendor-comparison capstone is where those get argued honestly. It’s a statement about where this series is going to spend its time: less on route-reflector mechanics (there isn’t one), more on how an app-defined policy engine decides what “good” means and enforces it without ever exchanging what a BGP engineer would recognise as a route.
What’s next
Part 2 gets concrete: the ION device line (1000 through 9000, physical and virtual), what actually runs in the cloud now that the standalone CloudGenix Portal has been folded into Strata Cloud Manager, and why Prisma SD-WAN’s management plane is the one architecture on this site with no on-premises controller option at all — not a scaling recommendation, not a best practice, an actual absence of the choice. If you’ve read the Cisco series and are expecting a vManage-shaped hole to fill, Part 2 is where that expectation gets corrected.