Palo Alto Prisma SDWAN Deep Dive Part 3: AppFabric and Path Selection Without a Routing Protocol

Part 1 made the claim that Prisma SD-WAN doesn’t run anything resembling a routing protocol. This is the post where that claim gets tested against the actual mechanics — how the tunnel mesh forms, what identifies a path, and how a per-flow decision gets made without ever exchanging a route.

Circuits, not TLOCs

Every other architecture on this site has some concept of a tagged, identified transport path — Cisco’s TLOC (a colour plus an encapsulation), Arista/VeloCloud’s underlay-link identity feeding DMPO, Fortinet’s interface-plus-SD-WAN-zone membership. Prisma SD-WAN’s equivalent is the circuit: a physical WAN-facing interface, bound to a circuit label (a free-text identifier you define — the documented best practice is something like CHI-INET-VZN or CHI-MPLS-ATT, encoding site, transport type, and provider in one string) and a circuit category — Public (Internet circuits) or Private (MPLS/private WAN circuits), with up to 32 of each definable per tenant if the defaults don’t fit.

Marking an interface’s scope as Global is what makes it WAN-facing in the architecture’s terms — an ION only attempts to build overlay VPN tunnels on interfaces configured with Global scope. This is a smaller, flatter concept than a TLOC: there’s no colour-based preference metric attached to the circuit itself, no encapsulation negotiation. A circuit is just “this physical path exists, here’s what kind of transport it is, here’s what I call it” — the interesting behaviour happens one layer up, in the policy that decides what to do with the paths that circuit can build.

AppFabric: full mesh by default

AppFabric is Palo Alto’s name for the aggregate secure application fabric — a VPN mesh established over every WAN circuit, between every ION that needs to reach every other ION. The individual tunnels that make it up are called Secure Fabric Links, and the default behaviour is aggressive by the standards of every other architecture covered on this site: secure fabric tunnels are built by default between all devices in a branch cluster, and from every branch to every configured data-centre/hub site — a de facto full mesh, not a hub-and-spoke topology you have to deliberately build out with an ADVPN shortcut negotiation or a partial-mesh Gateway relay.

That’s a genuine philosophical difference from all three architectures covered so far. Fortinet’s ADVPN starts hub-and-spoke and negotiates direct spoke-to-spoke shortcuts on demand, only once traffic actually needs one. Arista/VeloCloud’s Edges build tunnels to their assigned Gateways and optionally direct to other Edges depending on mode. Cisco’s WAN Edges build IPsec tunnels based on what OMP tells them is reachable — again, generally provisioned rather than blanket. Prisma SD-WAN’s starting position is closer to “build the mesh first, decide what to do with it after” — every ION has a path to essentially everywhere from the moment it’s onboarded, and the interesting policy work is entirely about which of those already-existing paths a given flow should use, not whether a path exists at all.

Deployment modes: Analytics, Control, Disabled

Not every ION runs the full policy-enforcement story from day one, and the three deployment modes map directly onto how much authority you’ve handed the fabric:

Mode	Behaviour
Analytics	The ION sits in-path, builds the fabric, and observes every flow — but does not act on path-selection or security policy. Pure visibility: this is the “prove it works before you trust it” mode.
Control	Builds on Analytics — the ION now actively enforces path selection, prioritisation, and security policy per the configured App-Defined Policies. This is the mode that does the interesting work described below.
Disabled	The circuit or device isn’t participating in the fabric at all.

The Analytics-then-Control progression is a deliberate onboarding pattern: stand up a new site in Analytics mode, let it build a baseline of what its circuits actually look like under real traffic for a period, then flip it to Control once you trust the telemetry enough to let the fabric start making decisions autonomously. We’ll lean on this pattern again in Part 7’s cutover playbook — it’s a cleaner “prove it, then trust it” story than most vendors offer, precisely because Analytics mode costs nothing architecturally; the fabric and the tunnels already exist either way.

Path selection: per-flow, real-time, against business intent

Here’s the mechanic that makes “app-defined” more than a marketing word. In Control mode, every flow gets classified by App-ID (the same application-fingerprinting engine that underlies Palo Alto’s firewall products generally — more on this in Part 4) the moment it hits an ION. That classification determines which App-Defined Policy applies, and an App-Defined Policy is expressed in terms a business stakeholder would recognise, not a network engineer’s routing preference: acceptable loss, latency, and jitter thresholds for this application, and — critically — which circuit categories or specific circuit labels are even eligible to carry it.

With eligible paths and SLA thresholds established, the ION’s local path-selection logic does the rest, continuously: every Secure Fabric Link is being measured in real time — loss, latency, jitter, per path, all the time, not just at tunnel-establishment — and a flow gets placed on whichever eligible path currently satisfies its policy’s thresholds. When a path stops satisfying them — a broadband circuit’s latency spikes past the ceiling a voice policy demands — new flows for that application move to a path that still qualifies, and depending on policy, in-progress flows can be steered too. There’s no withdrawal message to process, no route-reconvergence timer, because nothing was ever “advertised” as reachable in a way that needed withdrawing — the mesh was always there; only the eligibility and fitness of a given link for a given application changes, moment to moment.

A representative App-Defined Policy rule, expressed through the Terraform provider introduced in Part 2, makes the shape concrete:

resource "prismasdwan_appdef_policyrule" "voice_realtime" {
  name        = "voice-realtime-sla"
  policy_set  = prismasdwan_path_policyset.branch_default.id
  app_ids     = [data.prismasdwan_appdef.ms_teams_voice.id]

  sla {
    max_loss_pct   = 1.0
    max_latency_ms = 150
    max_jitter_ms  = 30
  }

  active_paths = ["mpls", "public-broadband"]
  backup_paths = ["cellular"]
}

Notice what’s absent compared to a Cisco centralized-policy block or a Fortinet SD-WAN rule keyed on source/destination prefix: no IP addressing at all. The rule is keyed entirely to an application definition and a business-intent SLA. Traditional destination-based routing hasn’t disappeared from the picture entirely — branch and DC LAN-side routing still uses static routes and BGP to learn what subnets exist behind a site, the same way every other vendor’s edge needs to know what’s on its own LAN — but which fabric path a flow rides is governed entirely by the app-intent policy above, never by a prefix-based route preference.

What this buys you, and what it costs

The upside is real: policy that reads like a business requirement rather than a routing configuration, genuinely fast reaction to path degradation because every path is being measured continuously rather than only at BFD-failure-detection intervals, and an onboarding story (Analytics → Control) that de-risks turning autonomous decision-making on. The cost, which Part 8’s vendor comparison will weigh honestly against the other three architectures: there’s no single “show me the routing table” command or view, because there was never a routing table in the traditional sense — visibility here means the Monitor → Flows and Monitor → Paths views in Strata Cloud Manager, watching per-application path placement and SLA compliance rather than reading a RIB. Engineers coming from a BGP- or OMP-literate background sometimes find this genuinely disorienting for the first few weeks, precisely because the debugging instinct of “trace the route” doesn’t map onto an architecture where the interesting state is per-flow telemetry, not a prefix table.

What’s next

Part 4 goes one layer deeper into the data plane itself: what App-ID actually does at the packet level, how Adaptive QoS interacts with the SLA-based path selection just described, and the practical differences between an ION running Control mode and one still in Analytics — including what that means for a device that’s mid-migration between the two.