Prisma SD-WAN Interview Q&A — ION, App-Fabric & Real Troubleshooting

An ION (Instant-On Network) is the data-plane appliance Prisma SD-WAN places at every branch and data center. It terminates the WAN circuits, builds the secure fabric overlay (IPSec) to other IONs, measures per-path quality, and enforces the policies the Controller pushes down. IONs come as physical models (for example the 1200-S, 3200, 9000 series for DC) and as a vION virtual form factor for AWS, Azure, GCP and VMware. The key point: the ION forwards every packet. The cloud Controller never touches user traffic — it only programs the ION.

This is a deliberate name trap to check you've worked with the product across its renames, not just read one old blog. CloudGenix was the original company Palo Alto acquired in 2020; the product is now Prisma SD-WAN — same technology, new name. The Controller is the legacy term for the cloud management plane; that role now lives inside Strata Cloud Manager (SCM), Palo Alto's unified cloud management console, so 'Controller' and 'SCM' point at the same control plane. ION (Instant-On Network) is unchanged — still the edge appliance. So when Rohan reads a 2019 CloudGenix doc that says 'log into the Controller and claim the ION', the modern equivalent is 'log into Strata Cloud Manager and claim the ION'. Knowing the old and new names map to the same thing is exactly what the interviewer is fishing for.

The Controller is the multi-tenant cloud control and management plane. You log into it for the whole lifecycle: claiming IONs, defining sites, building Path/QoS/Security/NAT policy stacks, and viewing analytics. It computes control-plane decisions — which paths exist, what policies apply — and pushes that state to each ION. Crucially it is out of band: it is not a packet forwarder and not a tunnel concentrator. If a branch loses reach to the Controller, the ION keeps forwarding on its last-known policy, so the branch does not go down just because the cloud is unreachable.

The data plane lives entirely on the ION: tunnel build, packet forwarding, per-flow steering, and quality measurement all happen locally. The control plane (policy intent, topology, analytics) lives in the cloud Controller and is pushed to the ION. Because forwarding decisions are pre-programmed into the ION, traffic does not need a round-trip to the cloud per packet. So if the WAN path to the Controller dies — or the Controller has a maintenance window — Aditya's branch in a Hyderabad SOC keeps running on cached policy and the fabric stays up. This is the same principle as a router still forwarding when its management VLAN is down. It also means the cloud is not a single point of failure for user traffic.

The secure fabric is the overlay of IPSec tunnels (VPNLinks) that Prisma SD-WAN auto-builds between IONs over every usable WAN circuit. Each ION advertises its WAN interfaces to the Controller; the Controller decides which IONs should peer and the IONs establish encrypted tunnels directly between themselves — the Controller is not a hub in the data path. Over each underlay circuit (MPLS, broadband, LTE) you get a separate measured path, so the same branch-to-DC pair may have three or four parallel fabric paths. Application traffic then rides whichever fabric path currently meets the app's SLA. This auto-meshing is why you do not hand-configure crypto maps per site.

Functionally both run the same software, but their role and scale differ. A branch ION (for example a 1200-S at a Chennai ITES floor) terminates a handful of circuits, serves local users, and offers Direct Internet Access (DIA). A DC ION (3200/9000 class) is the aggregation point: it terminates fabric tunnels from many branches, sits in front of DC services, and usually peers with the core via BGP. In the Controller you group DC IONs into a Data Center group so branches can be pointed at "the DC" rather than at individual boxes — giving you N+1 redundancy at the hub. So the difference is throughput, tunnel scale and topology position, not feature set.

This is the Zero-Touch Provisioning (ZTP) flow. The ION ships with firmware that, on first boot with internet, reaches the Prisma SD-WAN cloud and registers. In the Controller, Priya claims the device by its serial number, which binds it to her tenant. She then assigns it to a site and applies a configuration profile — interface roles (WAN/LAN), circuit labels, policy bindings. The Controller pushes that down, the ION builds its fabric tunnels, and it goes online. The branch staff only had to rack it and plug in the circuits — no CLI. If claiming fails, the usual culprits are the device having no internet reach to the cloud, a wrong/duplicate serial, or it already being claimed in another tenant.

I separate steady state from failure. In steady state the Controller pushes policy and topology to the ION; nothing about forwarding depends on a live cloud session. On Controller unreachability, the ION keeps forwarding on its last-known-good policy and keeps its fabric tunnels up, because tunnels and steering are local. What you lose is the ability to make new config changes and to stream fresh analytics — not connectivity. To harden this I would: give the ION more than one path to reach the cloud (DIA over a second ISP), make the local breakout policy explicit so critical SaaS still has a route, and confirm DNS/NTP locally so the box does not get stuck on a control dependency. So the honest answer is: the branch does not go dark — it goes 'frozen-but-forwarding' — and good design makes even the control-channel loss unlikely.

Link-state SD-WAN fails over when an interface goes down or a probe says the tunnel is dead — a binary up/down view. App-defined SD-WAN measures the actual quality each application is getting — loss, latency and jitter per path — and compares it to that app's SLA. So even if both ISPs at Rahul's Mumbai bank branch are up, if the path carrying Microsoft Teams crosses the jitter threshold, Prisma SD-WAN moves the Teams flows to the better path while leaving bulk file-copy where it is. The decision is per-application, not per-link. That is the headline difference: it steers on the experience the app sees, so it catches brownouts that a link-up check is blind to.

It uses an application catalog of thousands of pre-defined apps plus the ability to define custom applications. An app definition can be matched by Layer 3/4 tuple (IP ranges, ports, protocol), by domain/URL for SaaS, and by deep inspection of the first packets of a flow. SaaS apps like Salesforce or Office 365 come with their published prefix/domain sets so the ION knows which destinations belong to them. For an in-house app at an Infosys campus you build a custom app definition with its server IPs and ports. Once a flow is classified, every policy stack — path, QoS, security — can reference that application by name instead of by raw IP.

Policy is organised as separate stacks, each a set of rules you bind to a site: Path (which path/transport a flow takes), QoS (priority and bandwidth treatment), Security (zone-based allow/deny at the branch), and NAT (source/destination translation for breakout). A flow is first classified to an application, then evaluated against the Path policy to pick the egress path, the QoS policy to set its queue/priority, the NAT policy if it breaks out locally, and the Security policy for zone enforcement. Keeping them as distinct stacks means Divya can change steering for an app without touching its QoS or security — clean separation of concerns. You bind a stack to many sites, so one edit rolls out fleet-wide.

A Path policy decides which transport an application's traffic should ride and how it should behave when quality degrades. For each app (or app group) you set the preferred path (e.g. send ERP over MPLS, send YouTube via DIA), allowed/forbidden circuits, and the action on SLA breach — move to the next-best path or even replicate. You also tie it to the app's network-context SLA so the ION knows what 'good' means. For example Karthik sends voice with a tight jitter SLA preferring broadband-1, falling back to broadband-2, and never onto LTE unless both fail. The Path policy is the heart of app-defined steering — it is where 'business intent' becomes a forwarding rule.

Circuit labels (categories) are the names you give each WAN transport — for example INET-Primary, MPLS-Core, LTE-Backup — and they come in public and private categories (you get up to 32 of each). They are not cosmetic: the fabric uses labels to decide which circuits build tunnels to which, and Path policies reference traffic by label rather than by a specific site's interface, so one global policy applies fleet-wide. That global reach is also the trap. If Suresh tags the Wipro Pune branch's broadband as INET-Primary but a colleague tags the Chennai branch's as INET-Prim, the policy that says 'prefer INET-Primary' simply does not match the misspelt site — and it fails silently, no error. So a disciplined, documented label taxonomy is a real operational requirement, not a nicety.

The classic miss is binding. In Prisma SD-WAN you build a policy stack (Path or QoS), but a stack does nothing until it is bound to the site(s) that should use it. Engineers build a beautiful Path policy, save it, and assume it is live — but if it was never bound to the Infosys Bangalore branch, that branch keeps running its old/default policy and the new rules never apply, with no error shown. So my first check when 'the policy isn't working' is: is the right stack bound to this site, and is the rule I expect actually the one being hit? Other near-misses are rule order (a broader earlier rule shadows mine) and the app not being classified the way I assumed. But unbound stack is the number-one silent failure, and it is the first thing I verify in the site's configuration before touching anything else.

That's path flapping, and the usual cause is an SLA threshold set too tight relative to the circuits' normal variance. If you tell Prisma SD-WAN that an app must never exceed, say, 20 ms jitter, but both broadband circuits routinely brush 18–22 ms, the ION keeps deciding the active path 'breached', steers to the alternate, that one then breaches too, and it oscillates — hurting the very app you were protecting and churning sessions. The fix is to set the SLA against measured reality: look at each path's baseline loss/latency/jitter in the metrics or AIOps view, then set the threshold with sensible headroom above normal variance so only a genuine brownout trips it. You can also dampen the reaction so a single brief spike doesn't cause an immediate move. The senior lesson for the panel: an SLA that is too aggressive is as harmful as one that is too loose — tune it to the link's real behaviour, not to an aspirational number.

DIA means the branch breaks out to the internet locally through its own ISP — best for trusted SaaS like Office 365 or Zoom, because it cuts the hairpin and gives the lowest latency. Backhaul sends internet traffic across the fabric to a DC or regional hub, then out through centralized security. You backhaul when you need centralized inspection, a fixed egress IP for an allow-listed partner, or when local breakout is not trusted. The modern answer combines both: DIA for sanctioned SaaS, and for the rest you either backhaul to the DC or — better — service-chain the branch to Prisma Access so you get cloud-delivered security without the DC hairpin. So the trade-off is latency/cost (DIA wins) versus centralized control (backhaul wins), and SASE largely resolves it.

Beyond basic path steering, Prisma SD-WAN lets you express performance/compliance intent. A Performance policy ties an application to its required loss/latency/jitter SLA and the remediation when the active path violates it — so you are not just picking a path once, you are continuously holding it to a number. Compliance-style rules let you mandate, for example, that PCI traffic at a Mumbai bank must only traverse MPLS and never break out locally, regardless of which path is 'best'. Transit considerations cover how branch-to-branch traffic flows through a hub when there is no direct path. The senior point: business rules ('regulated traffic stays on private transport') override pure performance optimisation, and the policy stacks let you encode that hierarchy explicitly rather than hoping the algorithm agrees.

First, ensure Teams is correctly classified as its own application (Microsoft's published endpoints, real-time-media sub-app). Then in the Path policy set Teams' preferred path to whichever circuit currently meets its SLA, with the action-on-breach set to immediately move to the next-best path — so a jitter spike on broadband-2 evicts Teams in sub-second, not after a tunnel goes down. Attach a Performance/SLA profile with a tight jitter and loss threshold (voice/video is jitter-sensitive). In QoS, mark Teams real-time traffic to the highest priority queue so it is protected during congestion. Finally I'd verify in the flow browser that Teams flows are actually sitting on the good path and watch the path's measured jitter. The combination — accurate classification, tight SLA, fast breach action, and QoS priority — means the ION steers around the choppy link before the user notices.

The underlay is the raw transport — your MPLS, broadband and LTE circuits and whatever routing gets the ION's WAN interface reachable (often a default route or BGP/static to the ISP). The overlay is the secure fabric of IPSec tunnels Prisma SD-WAN builds on top of those circuits, plus the app-aware steering that rides it. User and site prefixes are carried inside the overlay; the underlay just has to deliver tunnel packets between ION WAN IPs. Keeping the two separate is the whole point: the underlay can be any messy mix of ISPs, while the overlay presents one consistent, encrypted, policy-driven fabric to applications.

BGP is the main dynamic-routing tool, used most at the DC IONs and at branches with their own routed LAN. A DC ION typically runs eBGP/iBGP with the core or a firewall to learn DC service prefixes and to advertise the branch prefixes it learns over the fabric. At a branch, the ION can BGP-peer with an internal L3 switch to learn LAN networks dynamically instead of static routes. Prisma SD-WAN then redistributes between the fabric and BGP so that a route learned at one site is reachable from another. The senior nuance: you control which prefixes you advertise into the fabric and into BGP so you do not leak DC routes everywhere or create asymmetric paths.

A Data Center group bundles two or more DC IONs (often across two physical data centers) into one logical hub. Branches build fabric tunnels to the group, so traffic can land on whichever DC ION is healthy. If the primary DC ION or its circuit fails, branch traffic shifts to the secondary member without you re-pointing every site — that is your hub-level N+1/active-active redundancy. It also lets you do controlled DC failover and maintenance: drain one member, let branches ride the other. Pointing a branch at a single ION would make that one box a single point of failure for the whole site's DC-bound and backhauled traffic, which no panel wants to hear you design.

Hub-and-spoke sends all branch traffic through a DC/regional hub — simplest to secure and route, but branch-to-branch traffic hairpins through the hub, adding latency. Full mesh builds direct fabric tunnels between every branch — best for branch-to-branch apps (VoIP between a Pune and a Chennai office) but tunnel and policy count explodes as sites grow. Partial mesh is the pragmatic middle: hub-and-spoke as the base, plus direct branch-to-branch tunnels only where the traffic justifies it. In Prisma SD-WAN you express this through how you bind branches to DC groups and whether you enable direct branch peering. For most enterprises I'd default to partial mesh — centralized control with on-demand direct paths for latency-sensitive site-to-site flows.

Each ION advertises the networks behind it (its LAN prefixes, statically or via BGP) to the Controller's view of the fabric, and those prefixes are distributed to the IONs that need them. So a DC ION advertises DC service subnets; a branch ION advertises its local 10.x LAN. Branches reach the DC over the fabric using the DC's advertised prefixes, and reach each other (in a mesh) the same way. You can summarise and filter what gets advertised so you do not flood every branch with every route — for instance only advertise the DC service block to branches, not inter-branch management subnets. The principle is the same as any routing domain: advertise reachability, control scope, avoid loops and asymmetry.

The auto-built secure fabric only exists between IONs. When you must reach something that is not an ION — a partner extranet, a legacy firewall, a cloud security stack, or a third-party SD-WAN — you configure a Standard VPN: a manually defined IPSec tunnel from the ION to that peer, with its own crypto parameters and the remote networks you route over it. You then steer the relevant application traffic onto that standard VPN via the Path policy, while normal site-to-site traffic stays on the fabric. The design care points are: keep the standard VPN's reachable prefixes scoped so you do not blackhole fabric routes, and treat it as a path the policy can prefer or avoid. So fabric = ION-to-ION automation; standard VPN = the escape hatch to the non-ION world.

Prisma SD-WAN provides the WAN edge and app-aware steering; Prisma Access provides cloud-delivered security (firewall, threat prevention, URL filtering, CASB, ZTNA). Integrated, the branch ION service-chains internet- and app-bound traffic to the nearest Prisma Access location instead of backhauling to a DC for inspection. Together they form SASE: networking from SD-WAN, security from Prisma Access, both cloud-managed. So when Neha's Hyderabad branch user opens a risky URL, the ION steers that flow to Prisma Access where full inspection happens, while sanctioned SaaS can still take DIA. The win is consistent security policy everywhere without putting a next-gen firewall in every closet, and without the latency of hairpinning all internet traffic through HQ.

Unified SASE is its own design domain, not just 'turn on a feature' — networking and security become one managed fabric. The split: Prisma SD-WAN (the IONs) owns transport, app-aware steering and on-box segmentation; Prisma Access owns cloud-delivered security (FW, IPS, URL filtering, CASB, ZTNA). I onboard each branch ION to its nearest Prisma Access location — typically Mumbai or Bengaluru for India — over redundant IPSec tunnels, advertising branch prefixes with private BGP and ECMP across two tunnels for resilience. Then I service-chain by intent in the Path/security policy: sanctioned SaaS (Office 365, Salesforce) takes DIA locally; all general web and risky traffic is steered through Prisma Access for inspection before egress; internal app traffic rides the AppFabric to the DC. The two planes share one management surface (Strata Cloud Manager), so security policy is consistent at all 200 sites without a next-gen firewall in any closet. The headline answer: SD-WAN decides which path, Prisma Access decides what's safe, and service chaining is how a flow is handed from one to the other per business intent.

CloudBlades are Prisma SD-WAN's framework for integrating third-party (and Palo Alto) cloud services into the fabric without local hardware or manual tunnel config. You enable a CloudBlade in the Controller and it programmatically wires the branches to that service. The classic example is the Zscaler CloudBlade: enable it, and Prisma SD-WAN automatically builds the IPSec/GRE tunnels and steering from your branches to the nearest Zscaler ZIA node, so internet traffic gets Zscaler inspection with no per-site tunnel building. Other CloudBlades cover services like cloud security and monitoring integrations. The point for a panel: CloudBlades turn 'integrate 200 branches with a cloud security vendor' from a manual tunnel project into a toggle plus policy.

ZTP lets you deploy an ION without sending an engineer or touching a CLI. The box is pre-claimed to the tenant in the Controller; when local staff rack it and connect a circuit with internet, it calls home, authenticates, and pulls its full configuration and policy. At scale this is the difference between rolling out 300 branches in weeks versus months — Aman in the NOC stages every device's config centrally, and the branch electrician just plugs in cables. It also reduces human error: every site gets the same vetted profile. The caveats a senior should mention: the first hop must have internet/DHCP to reach the cloud, and you need a process for the rare device that fails to claim (serial mismatch, already-claimed, or no cloud reachability).

AIOps for Prisma SD-WAN applies analytics and ML across your fabric's telemetry to surface problems and capacity issues before they page you. It does things like baseline each path's normal loss/latency/jitter and flag anomalies, predict circuit capacity exhaustion, correlate an app-degradation event to a specific path or site, and recommend remediation. In practice I'd use it for proactive ops: instead of waiting for a Chennai ITES user to complain about Teams, AIOps shows the path that is trending toward its jitter SLA and which branches are affected, so the team acts on a trend rather than an outage. The honest framing for a panel: it is decision-support and early warning built on the per-app telemetry the IONs already collect — it shortens mean-time-to-detect, it does not replace an engineer's judgement on the fix.

The ION is an SD-WAN edge, not a full next-gen firewall, so I split the job. On the ION you get the fabric's IPSec encryption, zone-based security policy (allow/deny between LAN/WAN/fabric zones), and segmentation so guest, IoT and corporate stay separated at the branch. To the cloud you push the heavy security — threat prevention, IPS, URL filtering, DLP, CASB, ZTNA — by service-chaining to Prisma Access or a CloudBlade like Zscaler. So the design is: enforce basic segmentation and encryption locally for low latency, and steer anything needing deep inspection to cloud security. For a regulated Mumbai bank I'd be explicit that PCI segments are isolated on the ION and that all internet egress is inspected in the cloud, never broken out raw.

Service chaining means the ION forwards selected traffic through an external security service before it reaches the internet or the destination — typically Prisma Access or a Zscaler CloudBlade. You define in the Path/security policy which apps must traverse the chain (e.g. all general web), and the ION tunnels those flows to the service node, which inspects and forwards. The failure mode to watch: if the chained service node or its tunnel goes down, you must decide fail-open vs fail-closed. Fail-closed (drop traffic if security is unreachable) is safest for a regulated branch but risks an outage; fail-open keeps users working but sends traffic uninspected. A senior answer says: pick per traffic class — fail-closed for sensitive/regulated flows, and provide a redundant security node or second nearest Prisma Access location so the question rarely arises. Always test the failover, do not assume it.

Prisma SD-WAN is fully API-driven — the Controller / Strata Cloud Manager exposes a REST API, and Palo Alto ships a Python SDK (commonly the prisma-sase / CloudGenix SDK) plus reference scripts so the GUI is just one client over that same API. For a fleet role I'd use it to script repetitive config — bulk-claim and bind IONs to sites, push standard Path/QoS policy stacks across hundreds of branches, and template circuit labels so a new site is provisioned by code, not clicks. I'd also pull telemetry programmatically — path metrics, flow data, site health — into a dashboard or alerting pipeline, and wire it into CI/CD so policy changes are reviewed and version-controlled like code (NetDevOps). A concrete example: a Python job that reads a CSV of new Wipro branches and creates each site, assigns its ION, applies the regional policy stack, and verifies the device came online — turning a day of manual work into a reviewed, repeatable run. The panel point: know that everything in the UI is reachable by API, and that scripted, idempotent config is how you operate at scale without drift.

A blackout is total path failure — the tunnel is down, packets are dropped completely. A link-state SD-WAN catches this fine, and so does Prisma SD-WAN: it stops using that path immediately. A brownout is the dangerous one — the path is still up but quality has degraded: loss climbs, latency or jitter spikes, so the app suffers while the LED stays green. Legacy SD-WAN is blind to brownouts; Prisma SD-WAN's continuous per-app measurement detects when a path crosses the application's SLA and steers the affected flows off the browned-out path to a better one, even though no link went down. So in interview language: blackout = link down, easy; brownout = link up but bad, and app-defined steering is precisely what handles it.

I stop looking at the LED and look at quality and steering. First, open the flow browser and find the affected app's flows — see which path they are actually on and what loss/latency/jitter that path is currently delivering. If the path is browning out, I check why steering did not move them: is the app classified correctly, is there a Path policy for it, is its SLA threshold set, and are other paths actually healthy to move to? Then I check whether the issue is on the WAN path or beyond — is it every site hitting that SaaS (provider/Prisma Access side) or just this branch (local circuit)? I confirm against the per-path metrics and AIOps anomaly view. The structured answer is: classify the flow, read its path metrics, verify the policy and SLA, and localise branch-vs-DC-vs-provider — not 'reboot the ION'.

The flow browser is the Controller's live/near-live view of individual application flows traversing the fabric. For each flow it shows the source/destination, the classified application, which path/circuit it is using, and the path's measured performance. Day to day I use it to answer 'where is this traffic actually going and is it healthy?' — confirming that Teams is on the good circuit, that a backhauled app is taking the DC path I expect, or that a flow I thought should be DIA is wrongly riding the fabric. When a user complains, the flow browser turns a vague 'it's slow' into a concrete 'this flow is on broadband-2 which has 4% loss'. It is the single most useful screen for app-level troubleshooting, which is exactly why panels ask if you know it exists.

I work outward from the box. 1) Internet reachability: the ION's WAN interface needs a working uplink — DHCP/IP, gateway, and DNS to resolve the cloud, plus the relevant outbound ports allowed by any upstream firewall. 2) Serial / claim state: confirm the serial number I'm claiming matches the device and that it is not already claimed in another tenant — a common cause for refurbished or re-deployed units. 3) Time / NTP: a badly wrong clock breaks the TLS handshake to the cloud. 4) Firmware: very old firmware may not know the current cloud endpoints. 5) Physical/interface role: make sure the cable is in a WAN-role port that actually has the path out. I verify each from the local console/status before escalating — most 'won't claim' cases are upstream internet, DNS, time, or a duplicate/already-claimed serial.

I check the chain that enables steering, link by link. First, is the degraded path actually crossing the app's SLA threshold, or is it just 'a bit worse'? If the threshold is loose, Prisma SD-WAN correctly stays put — so I read the real loss/latency/jitter versus the configured SLA. Second, is there a Path policy matching this app at all, with an action-on-breach that says move? A flow with no specific policy may ride a default that does not steer aggressively. Third, are the alternative paths healthy — failover needs a better path to move to; if both circuits are degraded, there is nowhere good to go. Fourth, is the app classified as I assume (custom app misconfigured = wrong policy applied). Fifth, check whether a compliance/forbidden-path rule is pinning the traffic deliberately. So the root-cause is almost always: SLA not actually breached, no/loose policy, no healthy alternate, or misclassification — and the flow browser plus the policy config tell me which.

Prisma SD-WAN continuously probes each fabric path and reports packet loss, latency (round-trip delay) and jitter (variation in delay). The interpretation is app-specific. Voice and video (Teams, Zoom, SIP) are most hurt by jitter and loss — even 1–2% loss or rising jitter makes calls choppy, while moderate latency is tolerable. Interactive/transactional apps (SSH, RDP, a trading front-end at a Pune BFSI) are latency-sensitive. Bulk transfer (backups, file sync) mostly cares about throughput and tolerates higher latency. So I set each app's SLA against the metric that actually hurts it — tight jitter/loss for real-time media, tight latency for interactive, looser for bulk — and let the path policy steer on the right number. Reading the metric without mapping it to the app's sensitivity is the rookie mistake.

I run a consistent loop. 1) Scope it: one app, one site, or many? Many sites to one SaaS points at the provider or the cloud security path, not the branch. 2) Read the paths: in the Controller check each circuit's state and its loss/latency/jitter — is this a blackout (down) or brownout (up-but-bad)? 3) Flow browser: find the affected flows, confirm which path they ride and whether steering moved them. 4) Policy check: is the right Path/QoS policy applied, SLA sane, alternate path healthy? 5) Underlay: if a circuit itself is bad, validate the ISP handoff — is it the ION or the carrier? 6) Onboarding/health: confirm the ION is claimed, online, on current firmware, and reaching the Controller. 7) AIOps: check for a flagged anomaly or capacity trend that explains it. I document the path metrics that prove the conclusion. This ordering — scope, paths, flows, policy, underlay, device, AIOps — keeps me from rebooting boxes randomly and gives the panel a repeatable method.