A Brief History of SD-WAN Controllers: Viptela, VeloCloud, CloudGenix, and Why Cisco Runs Two SD-WAN Stacks
The 2012 cohort
Last post laid out the choice every SD-WAN vendor has to make: collapse the control plane onto the forwarding devices, or decouple it onto something dedicated. What it didn’t get into is where the decoupled answer actually came from, and that turns out to be a tighter story than you’d expect — three startups, founded within about a year of each other, all chasing the same idea at the same moment, for the same underlying reason: enterprise WAN circuits were expensive, MPLS lock-in was getting harder to justify, and the internet had gotten good enough to be a real transport rather than a consumer-grade afterthought.
Two of the three got bought by exactly the company you’d guess if you knew nothing else about them. The third didn’t survive as a brand at all. None of that was inevitable — it’s worth knowing how it actually happened, because the acquirer in each case shaped what the architecture became afterward more than the founders’ original vision did.
Viptela: the one that became “official” Cisco
Founded in 2012 by Amir Khan and Khalid Raza — both with backgrounds at Cisco, Juniper, and Alcatel-Lucent — Viptela built the architecture this site is about to spend ten posts on: a stateless orchestrator for first contact, a dedicated controller running a BGP-flavoured overlay routing protocol, and edge devices that do nothing except what the controller tells them. Sequoia backed it from the start; by the time Cisco came calling, Viptela had raised north of $108M and landed deployments at more than two dozen Fortune 500 companies across six continents — a real, independently viable SD-WAN vendor, not a feature bolted onto something else.
Cisco announced its intent to acquire Viptela in May 2017 and closed the deal that August, for $610 million in cash plus assumed equity. For the first few years the product ran largely unchanged — vManage, vSmart, vBond, and ViptelaOS edges, sold as “Cisco SD-WAN.” The bigger architectural shift came later, with the introduction of cEdge (Viptela’s SD-WAN feature set running on Cisco’s own IOS-XE, rather than ViptelaOS), and then a 2023 rebrand to Cisco Catalyst SD-WAN that, on paper, renamed every controller component too — vManage became Catalyst SD-WAN Manager, vBond became Catalyst SD-WAN Validator, vSmart became Catalyst SD-WAN Controller. In practice, the field never really adopted the new names, which is exactly why the upcoming series on this site is going to keep saying “vManage” and “vSmart” without apology — that’s still what you’ll hear on a call with an actual Cisco engineer, official branding notwithstanding.
VeloCloud: three owners, one technology
VeloCloud was founded the same year as Viptela — 2012 — and took a different shape on purpose: instead of a single full-mesh-to-controller architecture, it built a multi-tenant Cloud Gateway that does double duty as overlay route-reflector and data-plane relay, with a separate Orchestrator doing pure management. The architecture deep dive on this site covers the mechanics properly; what matters here is the corporate history, because the technology has now changed hands three times without the underlying product really changing at all.
VMware acquired VeloCloud in late 2017 for $449 million, folding it in as “VMware SD-WAN” — a sensible move for a company trying to sell a full virtualized branch-to-cloud story, and the deal that put VeloCloud’s gateway-centric architecture in front of every VMware enterprise account team on the planet. VeloCloud rode along through VMware’s acquisition by Dell, and then through Broadcom’s $61 billion purchase of VMware in 2023, becoming — on paper — a Broadcom product for a while. Broadcom’s well-documented strategy of stripping acquired companies down to their highest-margin core didn’t leave much room for a WAN networking product line that didn’t fit the data-centre-and-virtualization story, and in 2024 Broadcom divested the VeloCloud SD-WAN business to Arista Networks, who got the IP and the core engineering team. The product is now sold as Arista SD-WAN — still branded VeloCloud in the UI, still running VCMP, still the same Gateway/Orchestrator split it shipped with in 2012.
Three owners, one architecture, never meaningfully re-platformed. That’s almost the inverse of what happened to the third company in this cohort.
CloudGenix: the one that disappeared
CloudGenix, founded in 2013 by Kumar Ramachandran and Mani Ramasamy, took the most philosophically different approach of the three: instead of routing protocols and TLOC preferences configured by a network engineer, it built an app-defined model, where the controller classifies traffic by application and steers it according to business-level SLA intent rather than manual per-link policy. It’s the architecture this site hasn’t covered yet, and one of the reasons is that it’s genuinely a different mental model from the BGP-flavoured-overlay approach Viptela and VeloCloud both lean on — closer to “tell the system what good looks like for this application” than “configure preferred paths.”
Palo Alto Networks acquired CloudGenix in April 2020 for $420 million, immediately rebranding it Prisma SD-WAN. Unlike Viptela and VeloCloud, the CloudGenix name didn’t survive the acquisition in any form — no “Prisma (CloudGenix)” parenthetical, no legacy UI branding. The technology has since been pulled further still, folded into Palo Alto’s broader Prisma SASE portfolio as a component of a unified secure-access story rather than a standalone SD-WAN product with its own identity. Of the three 2012-13-era SD-WAN startups, CloudGenix is the one where the acquirer’s strategic priorities most visibly won out over preserving the original brand and architecture as a recognizable, separately-marketed thing.
Three acquisitions, one pattern
| Company | Founded | Architecture idea | Acquired by | Year | Price | Where it is now |
|---|---|---|---|---|---|---|
| Viptela | 2012 | Decoupled controller, BGP-flavoured OMP | Cisco | 2017 | $610M | Cisco Catalyst SD-WAN |
| VeloCloud | 2012 | Gateway-collocated control + relay | VMware → Broadcom → Arista | 2017 (→ 2024) | $449M | Arista SD-WAN |
| CloudGenix | 2013 | App-defined, business-intent steering | Palo Alto Networks | 2020 | $420M | Prisma SASE (brand retired) |
The pattern underneath the numbers: every major networking and security platform vendor that didn’t already have a credible SD-WAN story bought one, in roughly the same three-year window, for roughly the same reason — SD-WAN had become a checkbox enterprise buyers expected, and building a controller architecture from scratch was slower than buying one that already had production deployments. None of these three companies failed. All three got bought specifically because they’d succeeded.
Cisco’s other SD-WAN
Here’s the detail that makes this history more than trivia: Cisco’s relationship with SD-WAN didn’t start with Viptela in 2017. It started with Meraki, which Cisco acquired in November 2012 — the same year Viptela and VeloCloud were founded — for $1.2 billion in cash. Meraki wasn’t bought for SD-WAN at all; it was bought for cloud-managed WiFi and switching, with a dashboard simplicity story that Cisco’s existing enterprise lineup didn’t have. SD-WAN capability — AutoVPN, dual-uplink load balancing across the MX security appliance line — got added later as a dashboard feature, grown organically inside Meraki’s own cloud platform rather than acquired as a dedicated control-plane technology.
The result, five years before Viptela even entered the picture, was a Cisco product that already did something called SD-WAN, built on completely different principles: single cloud dashboard, zero-touch provisioning, intentionally limited routing sophistication, aimed squarely at IT generalists running branch offices who have no interest in OMP, TLOCs, or anything resembling a routing protocol. When Viptela arrived in 2017 with a vSmart-and-OMP architecture aimed at network engineers running complex multi-VRF enterprise WANs, Cisco didn’t merge the two. It couldn’t, really — they don’t share a data plane, a control protocol, or a target customer, and trying to force one architecture’s concepts onto the other would have broken the thing that makes each one good at its job.
Why two stacks still make sense
This is still true today, and it’s not Cisco being disorganized — Meraki SD-WAN (cloud-managed MX/vMX, AutoVPN) and Catalyst SD-WAN (Viptela-lineage, vManage/vSmart/vBond, OMP) are sold in parallel, to different buyers, with no roadmap to collapse one into the other. Meraki wins on time-to-deploy and operational simplicity for a flat branch network with modest routing needs. Catalyst wins on policy granularity, segmentation, and the kind of multi-VRF, multi-region enterprise design this site has been covering on the Fortinet and Arista side for months — the trade-off is genuinely the same one underneath every vendor’s product-tiering decision: how much control do you want to hand a network engineer, versus how fast do you want a generalist to get a branch online.
The series starting on the 6th is squarely about Catalyst SD-WAN — the Viptela lineage, vManage/vSmart/vBond, OMP. If you came here expecting Meraki AutoVPN, that’s a different (and considerably shorter) post for another time.
What’s next
Now that the lineage is straight — who built what, who bought it, and why the architectures still look the way their founders drew them on a whiteboard a decade ago — the next post lines the surviving philosophies up side by side: Fortinet’s collapsed, no-separate-controller model; Arista/VeloCloud’s gateway-collocated control; and Cisco/Viptela’s fully decoupled OMP. Three answers to the same question, compared directly, right before the Cisco series spends two full posts on the third one.