Juniper Session Smart SD-WAN Deep Dive Part 8: Failure Modes, Scale Limits, and a Five-Way Vendor Comparison
Seven parts in, it’s time to do what the original control-plane showdown post did for Fortinet, Arista/VeloCloud, and Cisco, and what Part 8 of the Palo Alto series did to extend that to four — put Session Smart Routing’s answers next to all of them, honestly, including where it loses.
What happens when the control plane goes dark
Because Part 2 established that tenant/service classification happens locally, at the ingress SSR, on the first packet of a session, an SSR that’s lost contact with its control plane — Conductor or Mist, per Part 3 — keeps forwarding every session it’s already classified, and keeps applying whatever tenant/service policy it last received. That’s structurally the same “existing state keeps running, new state stops arriving” pattern this site has now documented for every architecture it’s covered:
- New sessions matching an already-known tenant/service pairing: continue to classify and forward normally, because the SSR already holds that policy locally.
- Policy changes: can’t be pushed down until the control plane is reachable again — a new tenant, a new service definition, or a change to an SLA threshold has to wait.
- Telemetry and AI-driven remediation: stop flowing to Mist specifically, so Marvis’s correlation and Self-Driving Actions (per Part 4) go quiet for the affected site until reconnection.
- New device onboarding: blocked, since ZTP genuinely needs the control plane reachable to authenticate and provision a fresh SSR.
That’s a materially softer failure mode than Cisco/Viptela’s vSmart dependency, where new route learning stops network-wide — SVR’s local policy caching means an isolated SSR degrades gracefully on exactly the traffic patterns it’s already seen, which for most branch sites is the overwhelming majority of steady-state traffic. It’s closer in shape to Arista/VeloCloud’s “existing tunnels keep forwarding” story or Palo Alto’s “nothing to the data plane” story than to Cisco’s centralized-route-reflector dependency — but for a reason distinct from either of those: SVR was never depending on a live round-trip to make a forwarding decision for a session it had already classified, because the classification itself, not a separately-signalled route, is what the data plane is acting on.
Scale
Juniper positions the Session Smart Router line across a broad range, from smaller branch-class virtual and physical instances through larger appliances sized for DC-class hub roles, mirroring the same small-to-large hardware tiering every vendor in this comparison uses. The more interesting scale question, consistent with the pattern this site’s other vendor finales have found, isn’t raw device count — it’s policy design discipline. Because tenant and service definitions carry the actual security and routing intent (per Part 5), an estate that’s accumulated years of inconsistent, sprawling tenant/service definitions is a harder long-term operational problem than the raw number of SSRs deployed — the same configuration-drift risk every large fleet on this site eventually surfaces, expressed here through policy objects rather than per-device templates or route-maps.
Five philosophies, side by side
| Fortinet | Arista/VeloCloud | Cisco/Viptela | Palo Alto/Prisma | Juniper/Session Smart | |
|---|---|---|---|---|---|
| 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, real-time decision on every ION | Policy authored centrally (Conductor or Mist), classification and forwarding local to every SSR |
| Reachability mechanism | BGP (iBGP over the overlay) | Proprietary overlay exchange | OMP (BGP-flavoured) | No routing protocol — full-mesh Secure Fabric Links | No tunnels at all — Secure Vector Routing, session metadata carried on the packet itself |
| Path-selection basis | Route preference / SD-WAN rules | Route reflection + DMPO link measurement | OMP route + TLOC preference | Per-flow, App-ID-keyed, against measured SLA thresholds | Per-session, tenant/service-keyed, classified once on the first packet |
| 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 | Choice of two: Session Smart Conductor (on-prem/private/public cloud) or Mist (cloud, AI-native) |
| 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; deep inspection via Prisma Access | Tenant/service segmentation is zero-trust by construction; deep inspection delegated to SRX |
| If the 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 | Existing sessions keep forwarding on cached policy; new policy and AI telemetry pause |
| Native cloud onramp | Engineer/Terraform-driven (TGW, vWAN) | Partner Gateway (BGP-to-MPLS bridge) | vManage-native TGW/vWAN integration | CloudBlade-automated | Virtual SSR runs natively in-VPC/VNet as an ordinary fabric site — no tunnel handoff |
| 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, largest install base | Cleanest SASE integration, policy in business terms | Zero encapsulation overhead; zero-trust segmentation as a routing-engine property, not a bolt-on |
| Distinctive cost | No centralized routing-table view | Gateway capacity per tenant is a real sizing exercise | vManage database strain at scale; premium engineering skill required | No on-prem management option; shallower native security depth | Tenant/service is a genuinely different mental model from tunnels/routes; deep inspection needs SRX alongside it |
Choosing between them still isn’t about which is “best”
The pattern this comparison closes with is the same one the original showdown post and the Palo Alto finale both landed on, holding just as well with a fifth architecture added. Fortinet’s collapsed model comes from a firewall company that already had a capable box at every branch. Cisco/Viptela’s decoupled model comes from founders who built route-reflector-scale thinking in from day one for the largest, most policy-heavy WANs. Arista/VeloCloud’s Gateway model comes from a clean-slate cloud-hosted overlay built for the MPLS-to-internet transition specifically. Palo Alto’s app-defined model comes from CloudGenix’s bet that routing itself was the wrong abstraction, aimed at a SASE destination. Session Smart Routing’s answer comes from a session border controller team’s bet that the session, not the packet or the tunnel, was always the right unit — a genuinely different starting axiom from any of the other four, arrived at by a team that had already proven the approach worked at carrier scale for real-time voice traffic before ever pointing it at enterprise WAN.
The practical version of “which one should I run,” extended one more time: if the WAN edge needs to be a fully self-sufficient security boundary regardless of cloud reachability, Fortinet’s inline-everywhere model still leads. If the softest possible control-plane failure mode matters most and a proprietary overlay is acceptable, Arista/VeloCloud earns that. If the estate is the largest, most policy-heavy WAN on the planet with the engineering depth to match, Cisco/Viptela’s OMP model was built for exactly that scale. If the organization’s next two years are genuinely headed toward SASE with policy expressed in application terms, Palo Alto/Prisma is the architecture built around that destination. And if minimizing encapsulation overhead and getting zero-trust segmentation as an inherent property of the routing engine — rather than a policy layer bolted on top of it — matters more than working in the tunnel/route/interface language every other platform on this site speaks, Session Smart Routing is the one architecture here that was never built around tunnels to begin with.
Series wrap, and the Juniper arc as a whole
Eight parts: 128 Technology’s tunnel-free premise, Secure Vector Routing’s tenant/service model, Conductor and Mist as control planes, WAN Assurance and Marvis, the zero-trust security model, cloud onramp, the cutover playbook, and this comparison capstone — together with the three-part Contrail arc and the opening history post that came before them. Five SD-WAN philosophies now sit side by side on this site, and Juniper is the only vendor among them with a first act worth learning from as a cautionary tale in its own right: a technically sound architecture, built for the wrong primary audience, ultimately succeeded by an acquisition built from a completely different set of first principles. Where the network engineer’s decision should live, and what happens when it can’t be reached, remains the same question every one of these five vendors is answering — Juniper is simply the vendor on this site that answered it twice, and shipped both answers.