A branch has two healthy circuits, yet an application keeps using the link you did not expect. Before changing circuit priorities, separate three questions: did the intended rule match, was the preferred path eligible, and what did the configured selection mode actually optimize? This troubleshooting matrix is designed to answer those questions without turning a narrow application issue into a branch-wide routing change.
Scope: Prisma SD-WAN ION path policies, not PAN-OS Policy-Based Forwarding or the separate PAN-OS SD-WAN plugin. The tables below are original operational worksheets, not recorded customer incidents. Device tests are proposed, not executed. The current Administrator’s Guide is the reference for policy controls; the older Dynamic Path Selection paper supplies background on affinity and session behavior, not a universal description of every newer selection mode.[2][1]
Why a healthy link is not necessarily the selected link
Prisma SD-WAN path rules match more than destination routes: the documented criteria include network context, prefixes, ports, protocol, application, user/group and device identity.[2] The configured choices also distinguish the overlay type—Direct, Prisma SD-WAN VPN or Standard VPN—from the circuit category.[2] A physical ISP circuit and a usable, policy-allowed application path are therefore not interchangeable troubleshooting objects.
A second distinction is selection mode. In SLA Compliant Path mode, the guide describes load sharing across SLA-compliant active paths and using backup paths when no active paths are compliant.[2] In Best Path Selection, the guide describes choosing the lowest selected metric; its link-quality mode disregards available bandwidth, and only one metric is used per rule, with no load sharing for that traffic class.[2] “Use the lowest-latency circuit” and “use eligible circuits that meet this SLA” are different requirements.
Start with the Data Center networking hub for the wider branch-to-application context. For a metered-cellular backup problem rather than an unexpected healthy-path choice, use the separate Prisma SD-WAN LTE brownout troubleshooting matrix.
Path policy troubleshooting matrix
Use this as an investigation order. The evidence and proposed actions are an original workflow; the numbered citations identify the documented product behavior behind each check.
| Symptom | Evidence to collect | Interpretation to test | Narrow next action |
|---|---|---|---|
| Editing the rule has no apparent effect | Site mode, bound path stack, enabled state and deployed rule | Analytics mode observes traffic but does not apply path-selection policy; the intended stack may not be bound.[2] | Confirm Control mode and the actual site binding before changing preferences. |
| A specific app follows a broad/default rule | Identified application, source/destination criteria, network context, rule order and selected policy set | Explicit rule order can override implicit specificity; tied order values use more-specific attributes for precedence.[2] | Correct only the test application's match scope or order; retain evidence of the previously selected rule. |
| The expected ISP is up but never selected | Allowed overlay/category pair, VPN status and destination reachability | A reachable physical link does not prove that the corresponding application path survives policy and reachability filtering.[1][2] | Trace that candidate through each eligibility check; do not remove the security path requirement. |
| Traffic is shared instead of always choosing the lowest-latency path | Actual selection mode and all eligible active paths | SLA-compliant mode can load share across compliant active paths.[2] | Decide whether compliance or a single best metric is the approved requirement. |
| The lower-bandwidth circuit wins | Best-path metric, metric samples at the event time, actual circuit capacity | Link-quality Best Path Selection chooses the lowest configured metric while disregarding available bandwidth.[2] | Review the selection objective, not just the carrier bandwidth label. |
| New connections from one client remain on the same path | Application affinity, related flows, observed egress/NAT identity | Session affinity can constrain related connections to preserve path or NAT-domain consistency.[1] | Use an isolated test client and inspect affinity before blaming a stale policy. |
| Internet traffic continues through the data center | Service/DC groups, Required setting and chosen overlay | Required transit constrains traffic to the configured groups.[2] | Confirm the inspection requirement with the security owner; do not enable direct breakout as a shortcut. |
| The measured return path differs from the outbound path | Simultaneous branch/DC flow evidence and core return-route lookup | The background design permits flow movement to an asymmetric return path only if policy allows it.[1] | Investigate return routing and policy eligibility together; do not broadly disable stateful checks. |
Diagnosis workflow: one flow, one timeline
1. Capture the effective policy, not just the rule you edited
Record a single test client's flow tuple, time zone, application operation and destination as resolved during the test. Store real identifiers only in your private incident record. For a public ticket summary, replace them with generic roles such as “test client,” “application endpoint” and “branch ION.”
Check the site's operating mode before evaluating path policy. In Analytics mode the ION monitors but does not apply policy or make application path-selection decisions; in Control mode it forwards traffic, selects paths and applies security and QoS policies.[2] Also verify the stack bound to the site: creating or editing a rule is not the same as activating it for the intended branch.[2]
Within an advanced stack, record the relevant policy set as well as the rule. The documented explicit order takes precedence over implicit specificity, and equal order values invoke implicit ordering.[2] Do not infer the winner merely because a rule looks more specific in a screenshot. Save the effective match evidence and the application identity observed for the test flow.
2. Write down why each candidate is eligible or excluded
For each potential path, record overlay type, circuit category, destination reachability, configured role, service/DC constraints and current health. Ask a binary question first: is this path allowed for this application? Only then ask which eligible path should win.
The Dynamic Path Selection paper describes policy, reachability, quality and application checks before final capacity-based selection in its documented workflow.[1] Do not apply that final capacity rule blindly to newer Best Path Selection: the current guide explicitly documents its different metric-based behavior.[2] This is an important documentation boundary, not a contradiction to solve by guessing which circuit is “better.”
A carrier portal showing “up” is supporting context, not a substitute for checking the overlay and destination on the ION. Preserve the exclusion reason. “Not selected” and “not eligible” need different fixes.
3. Separate a new transport connection from an independent application session
The background paper describes affinity as a constraint on related client/application connections, including preservation of a NAT boundary.[1] Opening another browser tab is therefore a weak isolation test: your test plan should establish whether it created an independent application session rather than assuming it did.
Use a dedicated test endpoint, record the application's affinity configuration and observe a fresh connection. If changing or expiring test state is necessary, use a release-appropriate, narrowly scoped operation approved for that endpoint. Do not clear all branch flows to make a troubleshooting result look clean.
4. Observe forward and return behavior together
Collect the outbound path, reply path and full application transaction on the same timeline. The background paper describes symmetry correction as conditional on the return path being allowed by application policy.[1] A routing change at the data-center core should therefore be examined alongside path policy, not treated as a separate, unrelated event.
Prefer a bounded capture for the selected endpoint and time window. Packet payloads may contain confidential information; retain only what the incident needs and follow your organization's access and retention rules. No capture commands here have been executed against a production device.
Worked policy decision: SLA compliance versus lowest latency
Hypothetical design, not a benchmark: a branch has two direct-internet paths approved for a collaboration application. Circuit A has the lowest measured latency; Circuit B has more spare capacity. Both currently satisfy the agreed application SLA. The complaint is that traffic sometimes uses B.
If the effective policy uses SLA Compliant Path with both paths active, use of B is not by itself evidence of a wrong-path fault: the guide permits load sharing among compliant active paths.[2] If the business requirement is instead to choose the minimum latency metric, evaluate Best Path Selection, while recognizing that its documented link-quality mode disregards available bandwidth and does not load share that traffic class.[2]
That is a policy-design decision, not permission to change every application. A bulk-transfer application may have a different objective. Propose an isolated application rule, obtain approval, and validate both application completion and circuit impact before widening the scope.
Implementation worksheet for a safe correction
Fill this in before saving a change. Keep old and proposed values side by side so rollback does not depend on memory.
| Field | What to record | Approval or stop condition |
|---|---|---|
| Intended outcome | SLA compliance, a named best-path metric, or mandatory inspected transit | Stop if stakeholders disagree about what “preferred” means. |
| Scope and binding | Test site, mode, bound stack, policy set and rule | Do not edit a shared stack without identifying every affected site. |
| Match criteria | Application, network context and narrowly bounded endpoint criteria | Stop if the test also captures unrelated business traffic. |
| Candidate paths | Overlay/category pairs, active/backup roles and observed eligibility | Do not treat a different VPN or NAT exit as equivalent without approval. |
| Selection controls | Current mode, selected metrics, probe scope and thresholds | Record installed ION release and confirm supported controls. |
| Session controls | Application affinity and permitted test-state handling | Preserve login, payment and other state-sensitive sessions. |
| Inspection constraints | Service/DC groups and Required status | Security approval is mandatory for any changed inspection path. |
| Rollback | Saved configuration, owner, trigger and re-test steps | Stop if rollback access depends solely on the path being changed. |
Do not copy a numeric threshold from an unrelated application merely to force the intended circuit to win. Define acceptable behavior with the application owner, then verify that the measurements and policy implement that objective.
Acceptance test matrix
Agree the observation window and acceptable interruption before the test. Leave the result column blank until measured; this article does not claim to have run these tests.
| Test | Pass evidence | Result to record |
|---|---|---|
| Fresh test flow | Intended application and effective rule are identified; chosen path is explained by eligibility and mode | Rule, mode, path and timestamp |
| Related application connections | Login and dependent transactions complete; affinity behavior matches the configured requirement | Session evidence and observed egress identity |
| Unrelated application | Its pre-change forwarding and success criteria remain intact | Before/after application outcome |
| Approved active-path degradation | Selection follows the configured SLA or metric behavior, without assuming carrier-down is required | Metric timeline and selected path |
| Restoration | New and existing sessions are observed separately; recovery meets the agreed requirement | Recovery behavior and application interruption |
| Mandatory service transit | The application still traverses required inspection/service groups | Path evidence and security verification |
| Rollback | Previous rule, stack binding and intended application behavior are restored | Configuration reference and fresh test outcome |
For a failure-test program, connect this worksheet to the broader branch migration and rollback checklist. The Start Here hub is the stable entry point for related operational guides.
Practical takeaways
Diagnose the effective rule before changing a path. Explain eligibility before comparing metrics. Keep SLA compliance, best-path optimization, mandatory transit and session affinity separate in the incident record. The durable deliverable is a completed matrix that shows why the observed path was selected, not simply a screenshot of two green links.
The source PDFs below provide the vendor behavior; the investigation order, change worksheet and acceptance matrix are original recommendations. Confirm installed-release support before translating the workflow into a production change.
Post a Comment