Palo Alto SD-WAN Engineer cheat sheet

A Prisma SD-WAN (formerly CloudGenix) deployment is built from three planes: the controller (management/API), the fabric (ION devices at branches), and the Prisma SD-WAN portal/Prisma SASE tenant that ties them together.

ION devices must reach the controller over the underlay before any overlay forms; they authenticate with a one-time claim code or device serial bound to the tenant, then receive their full configuration from the controller.

A Prisma SD-WAN 'site' is the logical container for one location; all ION devices at that site share the site's network policy, WAN interfaces, and service links, so site membership must be correct before policy is applied.

Each WAN interface is bound to an 'interface profile' (bandwidth, ISP, cost, and whether it is active/backup); the sum of provisioned bandwidth per interface feeds the path-selection and QoS engines, so understating bandwidth breaks QoS.

A 'service link' is the logical tunnel endpoint (VPN, internet, or private WAN) used for path selection; the same physical interface can carry multiple service links with different tags.

Deployment modes: ION in inline (routed) mode forwards traffic through the device; in 'router' mode it participates in routing; in 'bridge' mode it transparently forwards without changing IP addressing.

Zero-touch provisioning requires outbound reachability to the controller (HTTPS 443) plus a valid claim; if the ION is behind NAT, ensure the return path for controller-initiated management is allowed.

HA at a branch uses two ION devices in a redundant pair; the pair shares a virtual IP and synchronizes state so the overlay tunnels fail over without re-establishing from the far end.

Prisma SD-WAN policy is evaluated top-down in the policy stack, and the first rule that matches wins; the default rule at the bottom of the stack is the catch-all, so explicit deny/allow rules must be ordered above it.

Network policy (site-level) controls path selection and traffic steering; stack policy (global, ordered) controls security and application behavior; both use application/prefix match criteria.

Path selection uses 'path quality' profiles (latency, jitter, loss thresholds) with preferred/backup WAN paths; when the active path degrades beyond the profile, traffic is re-steered to the next qualifying path.

Application identification drives policy: Prisma SD-WAN uses a layer-7 application signature database, so a rule matching 'Office365' behaves differently from a rule matching 'any' or an IP prefix.

BGP on the LAN side is used to advertise branch prefixes into the fabric and to learn routes from the LAN; the ION acts as a BGP peer to the LAN core, and the fabric handles the overlay reachability.

Static routes and BGP can both be used; the ION prefers more specific prefixes, and administrative distance/route preference must be set so the intended underlay path is chosen.

QoS/bandwidth allocation is applied per application class within the site's interface profile; the sum of guaranteed bandwidths must not exceed the provisioned interface bandwidth, or the configuration is rejected.

Service-link 'tags' (e.g., VPN, internet, MPLS) let a policy select which service links a given application may use; a rule that references a tag not present on the site yields no viable path.

Prisma SASE combines Prisma SD-WAN (branch fabric) with Prisma Access (cloud-delivered security) and Prisma SD-WAN security services; the branch ION can steer traffic to Prisma Access for inspection.

Security policy in the Prisma SASE tenant is enforced in the cloud (Prisma Access) for internet-bound traffic and on the ION for local/on-prem inspection, so the same rule can be applied at either enforcement point.

A 'security zone' (trust, untrust, etc.) defines where traffic enters/exits; zone-based rules must reference the correct source and destination zones or the rule will not match.

SSL/TLS decryption is required for URL filtering and threat inspection of encrypted traffic; decryption policies are separate from security rules and must be enabled for the relevant traffic classes.

Prisma Access integration uses an IPsec tunnel from the branch (or a service connection) to the Prisma Access location; the branch's service link must be tagged so policy can steer traffic into that tunnel.

URL filtering, DNS security, WildFire (malware sandboxing), and threat prevention are the core Prisma SASE security subscriptions; each must be licensed and enabled in the security profile bound to the rule.

Decryption and inspection add latency; for latency-sensitive applications, use a policy exception or a local-inspection profile rather than full cloud inspection.

Security rules are ordered and first-match; a broad 'allow any' rule placed above a specific deny rule will bypass the deny, so ordering is a security control.

The Prisma SD-WAN portal's 'Monitor' view shows per-site and per-interface health: path quality (latency/jitter/loss), tunnel status, and application performance; a red path indicates the active path exceeded its quality profile.

Troubleshooting order for a branch outage: (1) is the ION claimed and online in the controller, (2) does the underlay reach the controller/internet, (3) do the overlay tunnels come up, (4) is policy steering traffic correctly.

ION device logs and the 'Events' view in the portal show configuration pushes, tunnel flaps, and policy changes with timestamps; correlate a user-reported outage with the event timeline before changing configuration.

The 'Flow' view (or flow browser) shows per-flow path selection, application identification, and bytes; use it to confirm whether an application is being steered to the intended path.

'Path quality' thresholds are configured per path profile; a path marked 'bad' is not automatically removed from service - the steering decision depends on whether a qualifying alternate path exists.

Configuration changes are staged and committed; a commit that fails validation (e.g., bandwidth over-subscription) does not apply, so check the commit/validation status after every change.

For controller reachability issues, verify DNS resolution, outbound HTTPS 443, and any proxy/NAT in the path; the ION must be able to reach the controller's FQDN.

Operational best practice: keep a baseline of path quality and application performance before making policy changes so you can compare post-change behavior.

When deploying a new site, define the site object first, then add ION devices and assign them to the site, then configure WAN interfaces and interface profiles, then service links, and only then apply network/stack policy.

Interface profiles must reflect actual ISP bandwidth; if the provisioned bandwidth is lower than the real link, QoS will under-utilize the link, and if higher, QoS cannot enforce the guarantee.

For a dual-ISP branch, put each ISP on its own interface profile and service link; path selection then chooses between them based on the path quality profile and the policy's preferred path.

In HA pairs, the secondary ION must have its own management reachability and a matching configuration; verify the pair's synchronization status before trusting failover.

Zero-touch provisioning requires the claim code to be entered in the correct tenant; a code claimed in the wrong tenant will not appear in the intended site.

When migrating from a legacy router, keep the legacy device in the path temporarily and use a maintenance window to cut over; verify overlay tunnels and policy before removing the legacy device.

Policy stack order is the single most common source of 'traffic is not being steered' issues; review the stack top-down and confirm no earlier rule matches the traffic first.

Application signatures are updated by the controller; if a new SaaS application is not recognized, check the signature/database version before writing an IP-based workaround.

BGP route preference on the ION is controlled by local preference and MED where applicable; an unexpected path selection often traces to a route learned with a better preference than intended.

Path quality profiles are per-application-class; a voice profile with tight jitter/loss thresholds will fail over more aggressively than a bulk-data profile, which is intentional.

When a policy references a service-link tag that the site does not have, the rule matches but no path is available; verify tags on the site's service links.

QoS classes must be mapped to the application classes used in policy; an application in the default class gets best-effort treatment regardless of the interface's total bandwidth.

Prisma Access service connections (IPsec or GRE) are used when a branch should send traffic to a specific Prisma Access location; the branch's service link must map to that connection.

Decryption policy is evaluated before security policy for encrypted flows; if decryption is not applied, URL filtering sees only the SNI/hostname and threat inspection is limited.

Security zones must match the actual ingress/egress interfaces; a rule with the wrong zone will not match even if the IP/application criteria are correct.

WildFire verdicts are asynchronous; a file may be allowed initially and blocked later when the verdict arrives, so 'allowed then blocked' behavior is expected for unknown files.

DNS security requires the branch to use a DNS proxy that forwards to Prisma SASE; if the branch uses a local resolver directly, DNS security is bypassed.

For compliance, log retention and forwarding are configured in the Prisma SASE tenant; verify logs reach the SIEM before relying on them for audit.

A tunnel that is up but carrying no traffic usually indicates a policy/steering issue, not a connectivity issue; check the flow view and the policy stack before troubleshooting the tunnel.

Path quality 'bad' states are transient by design; use the historical path quality graph to distinguish a persistent ISP problem from a momentary blip.

Commit failures are surfaced in the portal with a validation message; read the message (e.g., bandwidth over-subscription, duplicate prefix) rather than retrying the commit.

For controller connectivity, confirm the ION's management interface has a default route and DNS; a missing default route is a common cause of 'device offline'.

When opening a support case, capture the site ID, device serial, timestamp, and the relevant event/flow export; this shortens resolution.

Change management: stage configuration, review the diff, and commit during a window; the portal keeps a configuration history you can roll back to.

Device onboarding checklist: claim code entered, device online, site assigned, interfaces configured, service links up, policy applied, and a test flow verified.

Interface profile bandwidth should be set to the committed rate (CIR) of the ISP circuit, not the burst rate, so QoS guarantees are enforceable.

For a branch with a single ISP, still configure a backup path (LTE or a second circuit) if the policy requires failover; a single-path site cannot fail over.

HA pair verification: confirm both devices are online, the pair is synchronized, and a controlled failover test succeeds before relying on it.

When replacing an ION, the new device must be claimed and assigned to the same site; the site's policy then applies automatically.

Document the site's WAN circuits and their interface profiles; mismatched documentation is a frequent cause of misconfigured QoS.

Before adding a policy rule, confirm the traffic's application identification in the flow view; writing a rule for the wrong application is a common error.

Order rules from most specific to least specific; the catch-all default rule should be last.

When a path fails over unexpectedly, compare the path quality metrics against the profile thresholds and check whether a better path became available.

BGP neighbor state should be verified after any LAN-side change; an idle neighbor means the branch is not advertising its prefixes.

QoS changes require a commit and take effect on new flows; existing flows may retain their prior class until re-established.

Keep a change log of policy stack edits with timestamps so you can correlate a user report with a specific change.

Verify the branch-to-Prisma Access tunnel status before troubleshooting a security block; a down tunnel means traffic is not being inspected.

If a site is unexpectedly blocked, check whether a new security rule was committed above the allow rule.

Decryption exceptions should be narrow (e.g., financial or health sites) and documented; broad exceptions weaken inspection.

DNS security requires the branch to forward DNS to Prisma SASE; confirm the DNS proxy configuration on the ION.

WildFire verdicts can change a file's disposition after the fact; review the verdict timeline when investigating a malware alert.

Confirm log forwarding to the SIEM is healthy; missing logs are often a forwarding configuration issue, not a security event.

Establish a baseline of path quality and application performance per site before changes; compare post-change metrics to the baseline.

Use the event timeline to correlate a user report with a configuration commit or tunnel flap.

Check commit validation messages before retrying a failed commit; the message identifies the specific conflict.

For 'device offline', verify management default route, DNS, and outbound HTTPS 443 to the controller.

Capture site ID, serial, timestamp, and flow/event exports when opening a support case.

Stage, review the diff, and commit during a maintenance window; use configuration history for rollback.

Design the site topology first: number of ISPs, HA or single device, and whether the ION is inline, router, or bridge mode.

Assign each ISP to its own interface profile and service link so path selection has distinct choices.

Size QoS guarantees to the sum of committed rates across interfaces; over-subscription is rejected at commit.

Plan IP addressing for the LAN side and the BGP peering to the LAN core before onboarding.

For HA, plan management reachability for both devices and a controlled failover test.

Document the claim codes and tenant assignment to avoid mis-claiming devices.

Map applications to policy classes (voice, video, bulk, default) before writing rules; this drives both path selection and QoS.

Choose path quality profiles per class: tight thresholds for voice/video, looser for bulk.

Decide the policy stack order: security/deny rules first, then application steering, then catch-all.

Plan service-link tags so policy can reference them consistently across sites.

Decide BGP vs static for LAN routes based on the LAN core's capabilities.

Document the policy stack and review it before each commit.

Decide which traffic is inspected locally vs in Prisma Access; latency-sensitive traffic may warrant local inspection.

Plan decryption policy scope and exceptions before enabling inspection.

Map security zones to interfaces so rules match correctly.

Plan DNS forwarding to Prisma SASE if DNS security is required.

Plan log forwarding to the SIEM and retention for compliance.

Confirm licensing for URL filtering, DNS security, WildFire, and threat prevention before enabling.

Define what 'healthy' means per site: path quality thresholds, tunnel status, and application performance baselines.

Plan alerting for tunnel down, path quality bad, and device offline events.

Plan a change management process with staging, diff review, and maintenance windows.

Plan a rollback procedure using configuration history.

Plan a support-case template with site ID, serial, timestamp, and exports.

Review the event timeline after every change to confirm intended behavior.

Device offline: check management default route, DNS, and HTTPS 443 to the controller.

Tunnel down: check underlay reachability and whether the service link is up.

Policy not steering: check the policy stack order and the flow view's application identification.

QoS not enforcing: check interface profile bandwidth vs actual circuit rate.

HA failover not working: check pair synchronization and management reachability of the secondary.

Commit failure: read the validation message before retrying.

Unexpected failover: compare path quality metrics to the profile thresholds.

Traffic on wrong path: check the policy stack for an earlier matching rule.

BGP neighbor idle: check LAN-side peering configuration and reachability.

Service-link tag missing: verify the site's service links carry the tag referenced by policy.

QoS class mismatch: verify the application is mapped to the intended class.

Route preference issue: check local preference and MED on learned routes.

Security block: check for a new rule committed above the allow rule.

No inspection: verify the branch-to-Prisma Access tunnel is up.

URL filtering limited: check whether decryption is applied to the flow.

DNS security bypassed: verify the branch forwards DNS to Prisma SASE.

WildFire verdict changed: review the verdict timeline.

Missing logs: check SIEM forwarding configuration.

Correlate user reports with the event timeline and recent commits.

Use the flow view to confirm path selection and application identification.

Use historical path quality graphs to distinguish persistent vs transient issues.

Check commit validation messages for configuration conflicts.

Capture site ID, serial, timestamp, and exports for support cases.

Use configuration history for rollback after a bad change.

Site object first, then devices, interfaces, service links, policy.

Interface profile bandwidth must match the circuit's committed rate.

Dual-ISP branches need separate interface profiles and service links.

HA pairs need management reachability for both devices and a failover test.

Claim codes must be entered in the correct tenant.

Document circuits and profiles to avoid QoS misconfiguration.

Policy stack is first-match; order rules specific to general.

Application identification drives steering; verify in the flow view.

Path quality profiles per class determine failover aggressiveness.

Service-link tags must exist on the site for policy to steer.

BGP advertises branch prefixes to the LAN core.

QoS guarantees must not exceed provisioned bandwidth.

Prisma SASE = Prisma SD-WAN + Prisma Access + security services.

Security policy enforced in cloud or on ION depending on traffic path.

Zones must match interfaces for rules to match.

Decryption is required for full URL/threat inspection.

DNS security requires DNS forwarding to Prisma SASE.

WildFire verdicts are asynchronous.

Troubleshoot in order: online, underlay, overlay, policy.

Path quality 'bad' is not the same as path down.

Commit validation messages identify conflicts.

Baseline before changes; compare after.

Capture site ID, serial, timestamp, and exports for support.

Stage, review diff, commit in a window, roll back if needed.