Jump to chapter (9)
Planning a Prisma SD-WAN network: what you will learn and the big picture
What you will learn in this module. This is the Planning and Design domain of the Palo Alto Networks SD-WAN Engineer exam, the part that carries 24 percent of the marks. You will learn how to choose ION devices for branches, data centers and virtual sites, how licensing works and which option fits which customer, how to plan bandwidth with real numbers, how to assess the existing network before you touch anything, how to design data center and branch sites, how to connect them (overlay, internet breakout, multiple data centers), how high availability works, and how to state security requirements with zones and segmentation. You finish with a design checklist and the classic exam traps.
Note. Honest note about the simulator. The NK-OS simulator does not model the Prisma SD-WAN portal or ION devices, so this module has no labs. Every portal walk-through is labelled Portal walk-through (not run in the simulator) and every configuration listing is labelled Reference configuration (not run in the simulator). I describe only portal paths and fields that appear in the Palo Alto Networks documentation, and where I am not sure of a detail I describe it in words instead of inventing it. Model and licence names change between releases, so always confirm them against the current datasheet and licensing guide before you quote them to a customer.
Prerequisites. Read the free module psd-start first. You should already know the words site, ION device, controller, element, circuit and fabric. If you know PAN-OS firewalls (see the pan-start and pan-policy modules) that helps, but it is not required: Prisma SD-WAN is a different product from a firewall.
Analogy: designing a courier network before buying vans
Imagine you run a courier company with one head office, two big warehouses and forty shops. Before you buy a single van you ask: how many parcels does each shop send per day, which roads exist, which roads are cheap, what happens if the main road floods, and who is allowed to enter the warehouse? A good SD-WAN design answers exactly those questions in network language. The shops are branch sites, the warehouses are data center sites, the roads are circuits (internet, MPLS, LTE), the vans are ION devices, the van licence is the subscription and the gate rules are the security policy.
The five design steps, and the story company we use through the module.
The big picture in four sentences
- Every site has one or more ION devices sitting in the path between the LAN and the WAN circuits.
- A cloud-based management plane (Strata Cloud Manager, with the controller behind it) holds the configuration and the policy; the ION devices follow it.
- Sites form an application fabric: secure VPN tunnels run over every circuit between ION devices, and each tunnel is measured continuously.
- Your design decides what hardware and licence each site gets, how the sites are wired to each other, and what the failure behaviour is.
Three deployment modes you must know
The documentation describes three modes for a site or device: Analytics mode (the ION is in the path and watches, but does not control traffic), Control mode (the ION enforces policy and chooses paths) and Disabled mode (the ION is a passive pass-through). Good designs start sites in Analytics mode to prove the fabric is healthy, then move to Control mode. The documentation also says you activate a data center only when you deploy in Control mode.
Worked example: the design brief. Harbor Foods has 40 branches and 2 data centers. The brief says: payment terminals must never lose connectivity, voice must stay clear, guest Wi-Fi must be isolated, and the company wants to cancel its expensive MPLS at small shops. From this you already derive design decisions: dual circuits at every site, HA pairs at the 12 stores that take payments, an internet-only design with LTE backup for the 25 small shops, security zones for guest and corporate, and a performance policy for voice. The rest of the module teaches you how to turn each sentence into a design.
Common mistake. Starting with the product catalogue. Beginners pick a model first and ask questions later. Experts start with the assessment (circuits, applications, users) and let the numbers choose the model.
Exam trap. The exam asks scenario questions, for example "which device and licence for a site with 400 Mbps of internet and a requirement for firewall zones". You need the logic of the design, not just a list of names. Whenever a name looks unfamiliar, read the question for the requirement (throughput, ports, bypass, HA, virtual) and match it.
The design that skipped the assessment
A retailer bought forty identical small ION devices because the price was good. During rollout they found that eight stores had 600 Mbps fibre but a device that was sized for a few hundred Mbps, and six stores had no free rack space for a second device that the HA requirement needed. They paid twice: replacement hardware and a delayed project. A one-week assessment of circuits, users and rack space would have shown both problems.
Lesson: assess first, size second, buy last.
"You are asked to design an SD-WAN for 40 branches and 2 data centers. Where do you start?"
A strong candidate starts with requirements and an assessment: sites and users, circuits and their bandwidth, applications and their criticality, existing routing and VLANs, security zones, availability targets. Only then they select ION models, licences, topology and HA, and finally the policies. They also mention a phased rollout: Analytics mode first, Control mode after validation.
Key takeaways
- Planning and Design is 24 percent of the exam: devices, bandwidth, licensing, assessment, data center and branch design, security, HA and policy design.
- Design order: assess, size, license, topology and HA, security, policy.
- Sites run in Analytics, Control or Disabled mode; start in Analytics to validate.
- This module has no labs; portal walk-throughs and configurations are labelled as not run in the simulator.
- Always confirm model and licence names against the current Palo Alto Networks documents.
ION device families and how to size them
An ION (Instant-On Network) device is the Prisma SD-WAN box that sits at a site. It terminates the WAN circuits, builds the VPN tunnels of the fabric, enforces the policies and reports to the cloud. Choosing the right ION is the first design skill the exam tests under device selection.
Analogy: vans, trucks and cargo planes
A small shop does not need a cargo plane, and a regional warehouse cannot run on a scooter. ION models are the same: small desktop boxes for small branches, bigger rack units for large branches and data centers, and software versions for virtual environments. You choose by how much traffic must be encrypted and forwarded, how many ports you need, and what special features the site needs (hardware bypass, LTE, PoE, redundant power).
The three families
- Branch hardware. Small fanless desktop or wall-mount units, and 1U rack units for large branches.
- Data center hardware. Higher-throughput rack units with SFP+ 10 gigabit ports. The Palo Alto Networks documentation lists ION 5200, ION 7000, ION 9000 and ION 9200 as suitable for a data center ION.
- Virtual (software) ION. The same software on a hypervisor or cloud: ESXi, Hyper-V, KVM, and public clouds (AWS, Azure, GCP are named in the compatibility documentation).
Current hardware at a glance
The table below comes from the Prisma SD-WAN ION device specifications datasheet that I reviewed while preparing this module. Throughput figures are vendor datasheet numbers for the whole device with encryption; always re-check the current datasheet and the compatibility matrix, because models, supported software releases and end-of-life dates move.
| Model | Throughput (datasheet) | Notable ports and features | Typical use |
|---|---|---|---|
| ION 1200 | 700 Mbps | 4 x 1GE RJ45; 4G LTE and 5G variants exist | Small branch, micro-site |
| ION 1200-S | 700 Mbps | Embedded switch: 1GE ports, combo ports, 4 PoE++ ports; 1 bypass pair; cellular variants | Small branch that wants LAN ports on the box |
| ION 3200 | 1 Gbps branch, 1.4 Gbps data center | 1GE ports, 2 combo, PoE++; 1 bypass pair | Typical branch (small data center) |
| ION 3200H | 1 Gbps branch, 1.4 Gbps data center | Extended-temperature unit; 5G variant | Harsh environments |
| ION 5200 | 2 Gbps branch, 4 Gbps data center | Multigig and PoE++ ports, 10GE SFP+; 2 bypass pairs; dual hot-swap power | Large branch, data center |
| ION 9200 | 5 Gbps branch, 14 Gbps data center | 10GE SFP+ ports; 4 bypass pairs | Large data center or hub |
Older generations still appear in networks and on the exam: ION 1000, 2000, 3000, 7000 and 9000. The compatibility matrix I reviewed notes that some of them are at or near end of life for new software releases, so in a new design you propose the current generation and in a migration design you plan their replacement.
Virtual ION
| Model | Throughput (datasheet) | vCPU / RAM / disk | Use |
|---|---|---|---|
| ION 3102V | up to 100 Mbps | 2 / 8 GB / 40 GB | Remote office |
| ION 3104V | up to 200 Mbps | 4 / 8 GB / 40 GB | Remote office |
| ION 3108V | up to 350 Mbps | 8 / 8 GB / 40 GB | Remote office |
| ION 7108V | up to 3 Gbps | 8 / 32 GB / 100 GB | Data center |
The compatibility matrix also lists larger virtual models (7116V and 7132V) for newer releases. A virtual data center ION is common when the hub sits in a public cloud or in a virtualised colocation.
Worked example: sizing three Harbor Foods sites.
- Small shop SHOP-014: 100 Mbps internet plus LTE backup, 20 users, no HA. Peak encrypted traffic about 60 Mbps. An ION 1200 with the LTE or 5G variant is far more than enough. Use the cellular variant so the backup circuit needs no extra router.
- Store STORE-007: 500 Mbps internet and 100 Mbps MPLS, payment terminals, HA required. Peak about 400 Mbps. Two ION 3200 (1 Gbps each) give headroom and the bypass pair support that HA topologies use.
- DC-EAST hub: all 40 branches connect, aggregate peak about 6 Gbps at the hub, and growth of 30 percent is planned. 6 x 1.3 = 7.8 Gbps, so one 9200 (14 Gbps datacenter figure) fits, and a second one gives redundancy.
Rules of thumb for selection
- Size to the sum of the encrypted traffic you really expect, not to the circuit size. A 1 Gbps fibre line with 150 Mbps of real peak traffic does not need a 1 Gbps ION.
- Add 30 to 50 percent headroom for growth and for services that cost CPU, such as the zone-based firewall and packet-level features.
- Count ports: each circuit, each LAN, the HA link and the controller port consume interfaces.
- Check special needs: hardware bypass for fail-to-wire, PoE for phones and access points, LTE or 5G, redundant power, extended temperature, virtual form factor.
- Hub devices carry the sum of many branches, so size them on aggregate throughput and on how many tunnels they terminate.
Common mistake. Sizing the branch ION to the interface speed. Gigabit ports do not mean gigabit of encrypted SD-WAN throughput. Another mistake is forgetting that the data center figure and the branch figure of the same model differ, because the data center role is tuned differently.
Exam trap. "Which ION supports hardware bypass?" The bypass pair is a feature of specific physical models (for example 3200, 5200 and 9200), not of the small ION 1200 and not of virtual IONs. A requirement of "fail-to-wire when power is lost" excludes software IONs. The bypass pair feature is documented as available exclusively for branch ION devices.
The virtual ION that was too small
A customer put a data center ION in a public cloud on a small virtual model because the cloud team wanted a cheap instance. Branches reported slow cloud applications at the lunchtime peak. The hub was dropping traffic at about 350 Mbps. The team moved to a data center class virtual model and the problem vanished. The assessment had sized the hub for average traffic, not peak.
Lesson: size hubs for peak and growth, and use the model made for the role.
"How do you choose between an ION 3200 and an ION 5200 for a branch?"
I look at the real encrypted peak throughput, the number and type of ports (10G, multigig, PoE), whether HA with bypass pairs is needed, redundant power requirements and growth. If the site is under about a gigabit with 1GE circuits, a 3200 is enough; if I need 10GE SFP+ uplinks, more bypass pairs, or hub-like aggregation, I choose the 5200. I always confirm the figures in the current datasheet.
Key takeaways
- ION families: branch hardware, data center hardware, virtual software IONs.
- Branch models (1200, 1200-S, 3200, 3200H, 5200); data center models (5200, 9200 and legacy 7000/9000, virtual 7108V and larger).
- Size on real encrypted peak plus 30 to 50 percent headroom, then check ports and special features.
- Bypass pairs are physical-branch features; virtual IONs have none.
- Throughput numbers come from vendor datasheets and change; verify before you quote them.
Licensing: data center, per-device, per-site and aggregate bandwidth
An ION device is not useful until it has a subscription. Licensing is a design topic because the model you choose changes the cost, the flexibility and what features are included. The exam lists licensing options and tiers under Planning and Design, so you must know the structure well.
Analogy: a mobile phone plan
You can buy a plan per phone with a data limit (per-device), a family plan for all phones in one house (per-site), or a company pool of data that anyone in the company can draw from (aggregate). Prisma SD-WAN licensing works the same way, and the unit you are metering is bandwidth in Mbps.
The structure, as documented
The Palo Alto Networks activation guide (Your Prisma SD-WAN License) describes two groups of subscriptions. All of them have a minimum term of one year and a maximum term of five years, and they apply equally to physical and virtual ION devices.
| Licence | Where it applies | How the bandwidth is counted | Included |
|---|---|---|---|
| Data center subscription | Each ION (physical or virtual) assigned to a data center site | One licence per DC device | The DC role |
| Branch per-device | Each branch ION | Tier per device: Small (S) up to 25 Mbps, Medium (M) up to 250 Mbps, Large (L) up to 2,500 Mbps; finer tiers also exist (25, 50, 150, 250, 500 Mbps, 1 Gbps, 2.5 Gbps) | Zone-based firewall (ZBFW) always included in the list price; WAN Clarity Reporting (WCR) and Clarity Network DVR are optional add-ons |
| Branch per-site | A branch site, whatever number of IONs it has | Tier shared by all IONs at the site (S, M, L) | ZBFW, DVR and WCR included |
| Branch aggregate bandwidth | All branch sites together | One pool in Mbps, shared across all branch sites, including HA scenarios | ZBFW, WCR and DVR included |
Note. Names and tiers change as Palo Alto Networks updates its licensing (for example enterprise agreements and Prisma Access bundles). Treat this table as the structure to understand, and confirm the current names in the Palo Alto Networks licensing documentation before you write a bill of materials.
What the licence meters
The tier is a licensed bandwidth ceiling for the site or device, not the speed of the circuit. The hardware model has its own physical limit (chapter 2), the licence has a commercial limit, and the effective limit is the lower of the two. A site with a 3200 (1 Gbps hardware) and an S licence (25 Mbps) is licensed far below what the box can do.
The three branch models: tier per box, tier per site, or one shared pool. The per-device picture for HA shows the typical design question: how many boxes must you licence?
Worked example: three ways to license Harbor Foods
The assessment gives these branch peak needs: 25 small shops at 40 Mbps each, 12 stores at 200 Mbps each (6 of them have two devices in HA), and 3 regional offices at 400 Mbps each.
- Peak sum: 25 x 40 = 1,000 Mbps; 12 x 200 = 2,400 Mbps; 3 x 400 = 1,200 Mbps. Total 4,600 Mbps of peaks.
- Aggregate approach: peaks do not happen at the same moment, so a pool of, for example, 3,000 Mbps might cover real simultaneous use. The company must still understand whether the pool is enforced per site by hardware limits.
- Per-site approach: shops fit tier S (25 Mbps) only if 25 Mbps is enough; 40 Mbps is not, so they need the M tier (up to 250 Mbps). Stores at 200 Mbps fit M; regional offices at 400 Mbps need L (up to 2,500 Mbps). The HA stores pay one site tier no matter how many IONs they hold.
- Per-device approach: the 6 HA stores need a licence for each device, so 18 devices at stores, not 12. Finer tiers (for example 50 or 500 Mbps) avoid paying for an oversized M or L.
The numbers show the design logic: per-site is cheap for HA sites, per-device gives fine granularity for single-box sites, and aggregate is best when many sites share peaks or when you add and remove bandwidth often.
Portal walk-through (not run in the simulator)
Licences are claimed and assigned through the Palo Alto Networks activation and the management portal; the documentation for your tenant describes the exact steps. In the design phase you do not click anything: you produce a table that maps every site to a licence type and tier, and compare it with the entitlement the customer owns. Include the data center subscriptions as a separate column so no data center ION is forgotten.
Common mistake. Licensing only the primary ION of an HA pair under a per-device model. The documentation says a DC subscription is required for each ION assigned to a data center site, and per-device licences follow devices. Ask explicitly how the standby is covered.
Exam trap. Remember what is included. ZBFW is part of the per-device list price, and per-site and aggregate licences include ZBFW, DVR and WCR. WCR and Clarity Network DVR are optional add-ons only for the per-device model. Also remember min 1 year and max 5 years, and that physical and virtual IONs both need subscriptions.
The data center that nobody licensed
A project team licensed all 60 branch devices carefully and ordered two ION 9200 for the data center, but nobody ordered the data center subscriptions. On the cut-over weekend the data center devices could not be assigned to the DC role and the branches had no hub. The licence order took two days to expedite.
Lesson: the bill of materials needs three lines: branch licences, data center subscriptions and optional reporting add-ons.
"A customer has 200 branches, many with HA pairs. Which licensing model do you recommend?"
I compare the options against the HA count and traffic pattern. Per-site is attractive for HA sites because the pair shares one tier; aggregate bandwidth is flexible when peaks differ across sites and it explicitly covers HA scenarios and includes ZBFW, WCR and DVR; per-device suits single-box sites that need fine tiers. I model the three on the assessment numbers and choose the cheapest that still covers every site's peak.
Key takeaways
- DC subscription: one per ION (physical or virtual) at a data center site.
- Branch models: per-device, per-site, aggregate bandwidth; terms 1 to 5 years.
- Tiers S, M, L (25, 250, 2,500 Mbps) and finer steps; ZBFW is included in all.
- WCR and DVR are add-ons for per-device and included for per-site and aggregate.
- The effective limit is the lower of hardware throughput and licensed bandwidth.
Assessing the existing network and planning bandwidth
Before you design anything you must know what exists. The exam lists existing network assessment and bandwidth planning as separate skills, and they feed each other: the assessment gives the inputs, the bandwidth plan turns them into hardware and licence decisions.
Analogy: measuring a house before ordering furniture
You measure doors, ceiling height and the staircase before you order a sofa. A sofa that does not fit through the door is worth nothing. In the same way, an SD-WAN design that ignores the real circuits, VLANs and applications will fail at deployment, not on paper.
What to collect, site by site
| Area | Questions to answer | Why it matters for the design |
|---|---|---|
| Sites | How many, where, users per site, rack space, power, criticality | Model, HA, licence tier |
| Circuits | Type (fibre, DSL, cable, MPLS, LTE), contracted down and up speed, provider, public or private address, CGNAT, SLA, monthly cost | Circuit categories, path policy, backup choice |
| Applications | Voice, video, ERP, SaaS, backups, guest browsing: volume, peak hour, sensitivity to loss and delay | Performance and QoS policy, bandwidth |
| LAN | VLANs, subnets, which are corporate, guest, IoT, payment | Interfaces, zones, segmentation |
| Routing | Static or dynamic (BGP, OSPF), default routes, MPLS provider routing, overlapping subnets | Where the ION injects and learns routes |
| Security and NAT | Existing firewalls, NAT, published servers, compliance rules | ZBFW zones, NAT policy, where inspection stays |
| Management | DNS, NTP, syslog, SNMP servers, access to the cloud management plane | Controller connectivity at every site |
How to collect it
- Interview the site owner and fill a standard site sheet, one per site.
- Pull flow or utilisation data from existing routers for at least a full business cycle (for example four weeks) so month-end peaks appear.
- Check circuit contracts for committed rate and for burst.
- Walk the site, or ask for photos, to confirm rack space, power and cabling.
- Use Analytics mode after deployment of a pilot to measure real application traffic; the documentation describes Analytics mode as monitoring without controlling traffic.
Turning numbers into a bandwidth plan
- Peak per site. Take the busiest-hour traffic, not the daily average. Separate download and upload, because most circuits are asymmetric.
- Overlay overhead. Tunnels add encapsulation and encryption headers to every packet. As a planning rule of thumb (my own engineering margin, not a vendor figure) add 10 to 20 percent for small-packet traffic such as voice.
- Growth. Apply a growth factor, for example 30 percent for three years.
- Hub aggregation. Add the branch peaks that go to a hub, then multiply by a concurrency factor that reflects that not every branch peaks at once (for example 0.6 to 0.8). This is oversubscription: the hub is smaller than the sum of its branches by design.
- Internet breakout decision. Traffic that goes straight from the branch to the internet never reaches the hub, so it lowers the hub requirement. Traffic backhauled to the data center (for example for central inspection) adds to it.
- Failure case. Check the design when one circuit or one hub is down: the remaining circuits must carry the critical traffic.
Worked example: DC-EAST hub bandwidth.
| Group | Count | Peak each (to data center) | Subtotal |
|---|---|---|---|
| Small shops | 25 | 20 Mbps | 500 Mbps |
| Stores | 12 | 120 Mbps | 1,440 Mbps |
| Regional offices | 3 | 300 Mbps | 900 Mbps |
| Sum of peaks | 2,840 Mbps | ||
Concurrency factor 0.7: 2,840 x 0.7 = 1,988 Mbps. Overhead 15 percent: 1,988 x 1.15 = 2,286 Mbps. Growth 30 percent: 2,286 x 1.3 = 2,972, round to about 3 Gbps. DC-EAST needs about 3 Gbps of encrypted capacity from branches. If DC-WEST must take over completely when DC-EAST fails, DC-WEST needs the same 3 Gbps for the failure case, even though in normal operation it carries only its own half.
Oversubscription check: the stores have contracted 500 Mbps each, 12 x 500 = 6,000 Mbps of circuits, while the hub plan is 3,000 Mbps. That is 2 to 1 oversubscription of circuit capacity to hub capacity, acceptable because real peaks are far below circuit speed.
Circuit categories in the plan
Prisma SD-WAN labels each circuit with a category, public (internet) or private (for example MPLS), plus a label such as a provider and city. The data center documentation describes configuring internet circuits and private WAN circuits with pre-defined categories, and says labels can be edited under circuit categories in the stacked policies area. During assessment, write down the label you will give each circuit, because policies refer to categories and labels, not to interface names.
Portal walk-through (not run in the simulator)
The documented path to describe a data center and its circuits is Configuration, Prisma SD-WAN, Data Centers, Add Site. The wizard asks for site information (name, city, country, address), then a WAN circuits and devices tab where you add circuits (internet and private WAN), and finally device assignment: assign available devices or create device shells (up to two shells are mentioned for pre-provisioning). The assessment sheet should contain every value this wizard asks for, so that the configuration step is a copy job.
Common mistakes. Using monthly averages instead of busy-hour peaks. Forgetting upload speed on asymmetric links, where the upstream limit is the real bottleneck. Ignoring overlapping subnets between branches. Forgetting that CGNAT or an upstream NAT can prevent a public address and change how tunnels form.
Exam trap. A scenario with "branches send traffic to a SaaS service through the data center" implies backhaul, which raises hub bandwidth. A scenario with "direct internet breakout" lowers hub bandwidth but moves inspection to the branch (ZBFW) or to a cloud security service. Read which direction the traffic flows before you size.
Month-end surprise
A distributor sized its hub on weekly averages. At month end all branches uploaded invoices and backups at the same hour, saturating the hub and making voice choppy. After the assessment was redone with the busiest four hours of the month, they doubled the hub capacity and moved backups to run at night through a bulk-transfer policy.
Lesson: plan for the true peak, and shift what can wait.
"How do you plan hub bandwidth for 100 branches?"
Collect busy-hour peak per branch toward the hub, sum them, apply a concurrency factor for non-simultaneous peaks, add overlay overhead and growth, and check the failure case where one hub carries everything. State that internet breakout reduces hub load and backhaul increases it, and confirm the result with the licence tier and the hardware throughput.
Key takeaways
- Assess sites, circuits, applications, LAN, routing, security, NAT and management before sizing.
- Plan with busy-hour peaks, upload and download separately, overlay overhead and growth.
- Hubs are oversubscribed on purpose using a concurrency factor, but must also cover the failure case.
- Breakout versus backhaul changes both hub bandwidth and where inspection happens.
- Circuits get categories (public or private) and labels that policy will use.
Data center design: hubs, interconnection and multi-DC
In Prisma SD-WAN the data center site is where the branches meet your servers, your private network and often your internet and cloud security exits. The exam names data center configuration and interconnection as a design skill. This chapter covers what a DC ION does, how it is wired, and how data centers connect to each other and to Prisma Access.
Analogy: the airport hub
Think of an airline. Small towns (branches) fly to a hub airport (data center), and from the hub passengers go to the big cities (servers, other branches, the internet). The hub needs more runways (throughput), a good connection to the road network (the core router), and a second hub in case the first is closed.
What is different about a DC site
- A DC ION terminates tunnels from many branches. It needs hub-class throughput (chapter 2).
- It has a data center subscription (chapter 3).
- It has an internet-facing interface and a network-peering interface. The documentation for the DC ION says: connect at least one port to the internet to enable public VPNs (with a circuit label), and at least one port to peer with a network, so the ION can inject routes toward the core router.
- It also needs routing, SNMP, syslog export and NTP client settings, which the DC configuration documentation lists as part of the setup.
- VPN tunnels build automatically between activated branches and data centers, and the documentation tells you to activate the data center only when you deploy in Control mode.
Branches build tunnels to both data centers. Each DC ION has an internet-facing port and a port that peers with the core. A DC-to-DC fabric link can join the data centers.
Connecting to the DC network
The DC ION sits in the routed path between the SD-WAN and the core. The design questions are: which routing method (static routes, BGP or OSPF, covered in psd-routing), which prefixes the ION advertises toward the core (the branch networks) and which prefixes it learns from the core (the data center and any other networks the branches must reach), and how traffic returns. Return routing is the classic failure: if the core does not know that 10.101.0.0/16 (a branch range) lives behind the ION, replies go to the wrong place.
Branch-to-branch through the DC
The fabric builds VPN connectivity between IONs; a branch-to-branch flow can go directly or through a hub, depending on the design and policy. The DC documentation mentions an option, Force VPN to VPN Traffic to Local Next Hop, which sends inter-branch traffic via a local data center hop instead of an external path. It is particularly relevant where DC IONs connect over private WAN circuits. Use it when the data center must see or inspect inter-branch traffic, for example to enforce a central security device.
Multiple data centers
Two data centers give resilience: branches build tunnels to both, and when one is lost traffic uses the other. Design points:
- Decide whether DCs are active/active (each serves some branches or applications) or active/standby (one primary). Path policy can express "prefer DC-EAST, then DC-WEST".
- Make sure both DCs can reach the application servers, either by sharing the application network or by replicating it.
- Check route symmetry: if branches reach an application via DC-WEST but the server returns via DC-EAST, a stateful device in the middle will drop the reply.
- Size each DC for the failure case (chapter 4).
DC-to-DC secure fabric links
The documentation describes secure SD-WAN fabric tunnels between data centers, which replaces third-party solutions or complex MPLS configurations and supports connecting AWS, Azure, Equinix, GCP and physical locations. It requires both ION devices on software 6.5.1 or later and is managed through Strata Cloud Manager. Overlay prefix filters control which prefixes (global prefixes, static routes, WAN paths, site prefixes, BGP and OSPF learned routes) are distributed between data centers.
Portal walk-through (not run in the simulator)
Documented path: Configuration, Prisma SD-WAN, Data Centers, Overlay Connections, then Add Secure Fabric Link. Optionally give a name, description and tags. Choose the source cluster and circuit, switch on Admin Up, then choose the destination data center, hub cluster and hub circuit (several destinations are supported) and save. Afterwards the Site Summary page shows the advertised prefixes and circuit health. In your design document, list for each fabric link: source DC, source circuit, destination DC, destination circuit and the prefix filter intent.
Interconnection with Prisma Access
Many designs send internet-bound traffic from branches to a cloud security service. The documentation describes SASE easy onboarding, a native integration that creates IPsec tunnels from Prisma SD-WAN circuits to Prisma Access. Requirements in the page I reviewed: Prisma SD-WAN managed by Strata Cloud Manager, ION devices on 5.6 or later (physical or virtual), a pre-configured branch site with an assigned ION and an attached WAN circuit, Prisma Access with the aggregate bandwidth licensing model (cloud managed) or the Panorama-managed variant, and both products in the same tenant service group. The full SASE design is the subject of psd-sase; at planning time you only record which sites use it and what bandwidth the Prisma Access side must carry.
Worked example: Harbor Foods DC design. DC-EAST (10.20.0.0/16) and DC-WEST (10.30.0.0/16) each have two ION 9200 (a hub pair is a design choice, covered with HA in chapter 7). Each has two internet circuits from different providers (198.51.100.0/29 and 203.0.113.0/29 are documentation examples) and one port peering with the core. Branches connect to both. Policy: stores prefer DC-EAST for the ERP application, DC-WEST for the data warehouse, and each fails over to the other. Prefix filters stop the DC-to-DC link from advertising branch guest networks. DC capacity: 3 Gbps each as calculated in chapter 4.
Common mistakes. Putting the DC ION behind a NAT or a firewall that blocks the VPN tunnels. Forgetting the return route from the core to the branch prefixes. Activating the data center before Control mode is planned. Using one internet provider for both DC circuits so a single provider outage removes the hub.
Exam trap. The DC ION needs both an internet-facing port (tunnels from branches) and a network-peering port (to the core router). A question about "branches cannot reach servers though tunnels are up" points at the peering and routing side. A question about "inter-branch traffic must pass the data center" points at the force-VPN-to-local-next-hop option.
Two hubs, one provider
A bank built two data centers with two ION 9200 each, but all four DC internet circuits came from the same carrier and used the same metro fibre. A fibre cut took all four circuits down and every branch fell back to LTE. The second DC existed but had no tunnels to carry the traffic. After the review, DC-WEST got a circuit from a different carrier on a different path.
Lesson: diversity must be real: different providers, different paths, different power.
"How do you connect two data centers in a Prisma SD-WAN design?"
I use secure SD-WAN fabric links between the DC IONs (software 6.5.1 or later, managed from the cloud), choose source and destination circuits, and control what is exchanged with overlay prefix filters. Branches also connect to both data centers, so the DCs back up each other. I check route symmetry and the failure sizing.
Key takeaways
- A DC ION needs hub-class hardware, a DC subscription, an internet-facing port and a network-peering port.
- Routes must flow both ways between the core and the fabric; return routing is the classic gap.
- Multiple DCs give resilience; check symmetry, diversity and failure capacity.
- DC-to-DC secure fabric links (6.5.1 or later) are configured under Data Centers, Overlay Connections.
- Prisma Access is reached by native IPsec tunnels from ION circuits; design details are in the SASE module.
Branch design and interconnectivity: circuits, LTE, overlay and internet breakout
A branch site is where users, phones, cash registers and printers live. The exam asks for branch and gateway configuration and interconnectivity: how many devices, how many circuits, how the branch reaches other branches, the data center and the internet. This chapter gives you a small set of branch patterns and shows how to choose.
Analogy: how many doors does the shop need?
A shop with one door has a problem when the door jams. A shop with a front door and a back door is safer. A shop with two doors and two guards (two devices) keeps trading even when one guard goes home sick. Circuits are the doors, ION devices are the guards, and the cost grows with each one you add.
Five branch patterns
| Pattern | Devices and circuits | Survives | Typical site |
|---|---|---|---|
| A. Single ION, one internet | 1 ION, 1 circuit | Nothing | Lab, very small, low-risk |
| B. Single ION, two circuits | 1 ION, internet + internet (or internet + MPLS) | One circuit failure or brownout | Most branches |
| C. Single ION with LTE or 5G | 1 ION with a cellular variant or external modem, plus one wired circuit | Wired circuit failure | Small shops, kiosks, temporary sites |
| D. Dual ION (HA) | 2 IONs in an HA group, circuits shared between them | Device failure and circuit failure | Stores, payment sites, regional offices |
| E. Dual ION, multiple circuits and bypass | 2 IONs with bypass pairs, 3 or more circuits | Power loss, device, circuit | Large branches, critical sites |
Three of the five patterns. The dotted line between the two IONs in pattern D is the HA relationship (chapter 7).
Choosing a pattern
- Write the availability requirement in business terms (for example "the shop can lose 5 minutes of card payments per month").
- If a single device failure is not acceptable, you need pattern D or E.
- If only circuit failure is the risk, pattern B or C is enough and much cheaper.
- Pick circuits from different providers and different technologies so that one event cannot take both down; an LTE or 5G circuit is the classic diverse backup.
- Check licence and model: cellular variants for pattern C (the ION 1200 family has LTE and 5G variants in the datasheet I reviewed), bypass-capable models for pattern E.
Interconnectivity: how the branch reaches everything else
The branch ION builds VPN tunnels over each circuit toward the data centers and the other sites. The path policy (psd-policy module) can steer traffic over three kinds of overlay, which the documentation lists when you define active, backup and Layer 3 failure paths: Direct (no tunnel, straight out of the circuit, used for internet breakout), Prisma SD-WAN VPN (the fabric tunnels between IONs) and Standard VPN (a standard IPsec tunnel to a third-party or cloud endpoint). Plan which of the three each traffic class will use:
| Destination | Overlay | Design note |
|---|---|---|
| Branch to data center | Prisma SD-WAN VPN | Over all circuits; the best path is chosen by policy |
| Branch to branch | Prisma SD-WAN VPN | Direct between branches or through the DC; decide by latency and by whether the DC must inspect |
| Branch to SaaS or internet | Direct, or a tunnel to a security service | Breakout at the branch, or backhaul, or cloud security |
| Branch to a partner or cloud network | Standard VPN | Third-party IPsec profile; see the Standard VPN documentation |
Internet breakout options
- Local breakout. Internet traffic leaves the branch directly. Best performance for SaaS; the branch must protect itself with zone-based firewall rules and source NAT (chapter 8 and the policy module).
- Backhaul to the data center. Internet traffic travels through the fabric and leaves at the DC, where central security is. Adds latency and hub load (chapter 4).
- Cloud security service. Internet traffic goes in an IPsec tunnel to Prisma Access, as covered in the data center chapter and the SASE module.
A mixed design is normal: trusted SaaS direct, everything else to the cloud security service, and sensitive internal flows through the fabric.
Worked example: three Harbor Foods branches.
- SHOP-014 (small shop): pattern C. Fibre 100 Mbps (198.51.100.10 as an example address) plus 5G backup. Voice and card payments prefer fibre, fall back to 5G; bulk traffic is blocked on 5G to avoid data charges.
- STORE-007 (store): pattern D. Two IONs, internet 500 Mbps from provider A, internet 300 Mbps from provider B, MPLS 100 Mbps. Payment traffic uses MPLS first, then internet; SaaS goes direct on internet A.
- REGION-02 (regional office): pattern E. Two IONs with bypass pairs, three circuits, LAN with guest, corporate and voice VLANs.
Common mistakes. Counting two circuits from the same provider on the same building entry as diverse. Using LTE as a primary data path with no data-cap planning. Forgetting that an HA pair needs a LAN switch (the HA control interface must be on an external LAN switch, chapter 7). Designing breakout without NAT and zone rules.
Exam trap. The three overlay names: Direct, Prisma SD-WAN VPN and Standard VPN. "Direct" is not a tunnel. A question that says "traffic must reach an Azure virtual network gateway" points to a standard IPsec VPN, not to a fabric tunnel, because the far end is not an ION.
The shop with a single door
A chain of 120 small shops ran pattern A on one broadband line each. When a fibre cut hit a district, 14 shops could not take card payments for six hours and the chain lost the day's sales there. The redesign moved to pattern C with a 5G variant and a path policy that sent only payments and voice over 5G during outages. The monthly cost per shop rose by the price of a data plan; the next outage cost nothing.
Lesson: a cheap, diverse backup circuit is the best insurance for small sites.
"How would you design a branch that must never lose card payments?"
Two ION devices in HA so a device failure is survivable, at least two diverse circuits plus cellular, bypass pairs if power loss matters, payment traffic in its own zone with a path policy preferring the most stable circuit, and a performance policy that moves payment flows if the path degrades. I also confirm the licence covers the second device.
Key takeaways
- Five branch patterns, from single ION and one circuit to dual ION with bypass and several circuits; choose by the availability requirement.
- Diverse providers and technologies make backup real; cellular is a classic diverse backup.
- Overlays: Direct, Prisma SD-WAN VPN, Standard VPN.
- Breakout choices: local, backhaul, or cloud security service; each changes bandwidth and inspection.
- An HA pair needs a LAN switch for the HA control interface.
High availability: ION HA groups, interface bypass and link failover
Availability in Prisma SD-WAN has three layers: link failover (a circuit fails or degrades), device HA (an ION fails) and interface bypass (an ION loses power or crashes and traffic must still pass). The exam lists interconnectivity and high availability under Planning and Design, so you must be able to say which layer solves which failure.
Analogy: three safety nets under a trapeze artist
The first net catches a slip (a bad circuit: the policy moves traffic to another circuit). The second net is a second artist who takes over if the first one cannot continue (the standby ION). The third is a trapdoor that keeps the stage open even if the lights go out (bypass pair). Each net covers a different fall.
| Failure | Protection | Where it is designed |
|---|---|---|
| One circuit down or brown-out | Several circuits plus path policy (active, backup, Layer 3 failure paths) | Branch design, policy |
| One ION fails | HA group with a second ION | HA design |
| ION loses power or crashes | Bypass pair (fail-to-wire), or the HA partner | Hardware choice and port design |
| Whole data center lost | Second data center | DC design (chapter 5) |
ION HA, as documented
- An HA group holds a maximum of two ION devices in the release I reviewed.
- The model is active/backup: one device forwards, the other waits. The marketing claim of the product is that this deployment model survives a device failure and still preserves 100 percent of WAN capacity, because both devices keep their WAN circuits connected (the standby is on the circuits, not idle in a box).
- Each device gets a priority between 1 and 254. If preempt is enabled, the higher priority device becomes active; without preempt, the device added first stays active.
- Recommended gap: at least 40 between active and backup priorities, because tracking failures reduce the active priority by a configurable amount.
- Track availability: the ION can track the state of physical interfaces and Layer 3 reachability of WAN circuits. When a tracked item fails, the priority of the active device is lowered and the roles switch. A maximum of four interfaces can be tracked.
- Cautions in the documentation: do not enable Layer 3 availability tracking on a private WAN interface that has BGP peering configured, nor on devices sharing a single circuit.
- The documentation also says the HA control interface must live on an external LAN switch in a common VLAN; the two devices cannot be joined only by a direct Ethernet cable.
Both IONs are connected to the circuits; only the active one answers on the LAN. If tracking fails on ION-1, its priority drops below ION-2 (a gap of at least 40 makes this predictable).
Bypass pairs
A bypass pair is a pair of ports where one port connects to the LAN and the other to the WAN. The documentation distinguishes a hardware bypass pair (Ethernet interfaces with relay hardware, with strict rules about which ports pair) and a virtual bypass pair (interfaces without that hardware; virtual interfaces cannot be created on them). Bypass pairs are used for Internet or private WAN connectivity, for private Layer 2 operation where the ION is a Layer 2 element toward a router, and for LAN-only configuration used in branch clustering and HA. They are available only on branch ION devices and cannot be set on controller interfaces. The practical meaning: with a hardware bypass pair the physical path LAN to WAN can remain connected if the box is off, which is why physical-model choice matters for fail-to-wire designs.
HA topologies by platform
The branch HA documentation groups topologies by platform: Gen-1 (2000, 3000, 7000, 9000), Gen-2 (3200, 5200, 9200), Gen-2 embedded switch (1200-S, 3200 L2), software cellular bypass (1200-S with 5G), platforms without bypass pairs (for example ION 1000 and 1200) and a hybrid mode mixing 3000 and 3200. In every topology you do the same planning: decide which circuits each device terminates, make sure each circuit is reachable by both devices, create the HA control interface and the LAN interface on a VLAN, then add the devices to the HA group.
Example from the documentation for devices without bypass pairs: the HA control interface is a subinterface on a port with a dedicated VLAN (the example uses VLAN 130), the LAN subinterface uses another VLAN (the example uses 100) and is identical on both devices, and only the active device answers ARP. Each device has its own unique IP address on every circuit.
Reference configuration (not run in the simulator)
! Reference configuration (not run in the simulator) ! Design record for STORE-007 HA group. These are design parameters, ! not device commands. Field wording follows the HA documentation. HA group: STORE-007-HA Members: ION-1 (priority 200), ION-2 (priority 100) Preempt: enabled Priority gap: 100 (documentation recommends at least 40) Track availability: WAN circuit reachability on Internet-A (reduce priority by 120) Physical interface status on LAN trunk (reduce priority by 120) HA control VLAN: 130 on the LAN switch (example value) LAN VLAN: 100, same address on both IONs (example value) Do not track: private WAN with BGP peering, shared single circuit
For checking an HA group on a real device, the documentation mentions the ION CLI commands dump spoke ha config and dump spoke ha status. I do not show sample output, because I could not verify its exact format.
Worked example: priority arithmetic. ION-1 priority 200, ION-2 priority 100. Tracking Internet-A reachability reduces ION-1 by 120, so it falls to 80, lower than ION-2 at 100, and with preempt enabled ION-2 becomes active. If the reduction were only 50, ION-1 would drop to 150 and stay active even with the circuit down. That is why the reduction must be larger than the gap. Also, if both devices lose the same shared circuit and you tracked it on both, both priorities drop together and you get no useful switch.
Common mistakes. Gap smaller than the tracking reduction, so failover never fires. Tracking a circuit that both devices share. Connecting the two IONs with a direct cable for HA instead of through the LAN switch. Using a model without bypass pairs and expecting fail-to-wire. Forgetting a licence for the second device.
Exam trap. HA is active/backup with at most two devices per group; priority range 1 to 254; track up to four interfaces; recommended gap at least 40. Do not confuse Prisma SD-WAN HA with PAN-OS firewall HA (which has its own HA ports and pair rules), and do not claim active/active.
The failover that never happened
At a store the active ION lost its internet circuit, but the standby never took over, so card payments went over the slow MPLS only. The review found priorities 120 and 100 and a tracking reduction of 10. The active device kept the higher priority even with the circuit down. They changed priorities to 200 and 100 and the reduction to 120, then tested by unplugging the circuit. Failover happened in the expected window.
Lesson: design the arithmetic, then test failure by unplugging, not by trusting the screen.
"How does HA work for a Prisma SD-WAN branch, and what are its limits?"
Two IONs in an active/backup HA group, priority 1 to 254, optional preempt, with the HA control interface on a LAN switch VLAN. Tracking physical interface state and WAN reachability lowers the active priority to force a switch. Limits: two devices per group, up to four tracked interfaces, and care with BGP private WANs and shared circuits. Bypass pairs on physical models add fail-to-wire.
Key takeaways
- Three layers: link failover (policy), device HA (HA group), interface bypass (fail-to-wire).
- HA group: max two IONs, active/backup, priority 1 to 254, gap of at least 40, up to four tracked interfaces.
- Tracking reductions must exceed the priority gap or failover will not fire.
- HA control interface lives on a LAN switch VLAN; the LAN address is identical on both IONs.
- Bypass pairs are for physical branch IONs; pick the model for the failure you must survive.
Security requirements, segmentation and the design-review workflow
A design is not finished until you have written the security requirements: who may talk to whom, where inspection happens, and how guest, payment and corporate networks stay apart. In Prisma SD-WAN the built-in tool is the zone-based firewall (ZBFW). This chapter also gives you the design-review workflow, the checklist you run before you sign off any design, which doubles as the troubleshooting order when a design fails in the field.
Analogy: office building with badge zones
A building has a public lobby, staff floors, a payment-processing room and a server room. Badges decide which zone you may enter, and a guard at each corridor checks them. A zone-based firewall is the badge system: you group networks into zones, then write rules that say which zone may reach which, for which application.
Zones and policy as documented
- A security zone maps to networks attached to physical interfaces, logical interfaces or sub-interfaces of the ION. You can allow or deny every interface in a zone access to other zones.
- Typical organisations create three to four zones: a guest zone, one or more corporate LAN zones, an outside zone for internet, and a corporate WAN zone for private networks and VPN traffic. The documentation advises that more than 5 or 6 zones usually means overlapping requirements; use prefix filters inside existing zones instead.
- A zone that is created but bound to no interface is a trap: the documentation says all traffic on unbound interfaces is blocked by default.
- Security policy sets contain rules that allow or deny application access between source and destination zones with prefix filters. Every set carries three default rules (self-zone, default and intra-zone) that cannot be edited. The platform does not create a default security policy set for you.
- Stacks and binding. A simple stack has one set (the documentation suggests it for fewer than 50 rules). An advanced stack evaluates up to four sets from left to right, top to bottom, and stops at the first match; the best practice is most specific first. A stack is bound to sites, and only one security stack can be active per site, though several sites can use the same stack.
- Prefix filters can be global (the same everywhere) or local (different per branch). Local prefixes must be attached to sites to work, and very large prefix lists are not recommended because they can exhaust ION memory.
Zone plan for a Harbor Foods store: three LAN zones, the WAN zone for the fabric and the outside zone for the internet.
Writing security requirements
Write them as a matrix before any configuration. Rows are source zones, columns are destination zones, cells say what is allowed.
| From \ To | Corporate | Payment | Guest | Corporate WAN | Outside |
|---|---|---|---|---|---|
| Corporate | allow | deny | deny | allow business apps | allow web, SaaS |
| Payment | deny | allow | deny | allow payment servers only | deny |
| Guest | deny | deny | allow | deny | allow web |
Then check each requirement: where is it enforced (branch ION ZBFW, data center, a firewall in the DC, Prisma Access), and is any inspection beyond zone and application rules needed? A ZBFW filters by zone, prefix and application; if a compliance rule demands deeper threat inspection, the design must place a firewall or a cloud security service in the path.
Segmentation across the WAN
Zones separate traffic inside a site. To keep segments separate across the whole fabric you also use network contexts in policy (the policy documentation says a network context segments traffic so that identical applications can have different rules for different user communities) and VRF-based segmentation (module psd-routing). In design, decide the segments once (corporate, payment, guest, IoT) and use the same names in zones, contexts and VRFs.
The design-review workflow
Run this order for every design and for every field problem that looks like "the design is wrong".
- Requirements. Is every business requirement written with a number (users, Mbps, minutes of downtime)?
- Hardware. Does each model meet throughput, ports and special features (bypass, PoE, LTE)? Is the DC model a DC model?
- Licences. Does every ION (physical or virtual) have a subscription, including DC ones and the standby?
- Circuits. Are circuits diverse in provider and path? Is each labelled with a category?
- Bandwidth. Does the plan include peaks, overhead, growth and the failure case?
- Topology and HA. Does the pattern survive the stated failure? HA gap and tracking arithmetic checked?
- Routing. Are prefixes advertised and learned both ways, with no overlaps?
- Security. Zones bound to interfaces, matrix written, NAT for breakout, one stack per site?
- Policy. Path, performance, QoS policy defined per application class (next module)?
- Operations. DNS, NTP, syslog, SNMP and controller reachability at every site? Phased rollout through Analytics mode?
Worked review: STORE-007. Requirement: payments never lost. (1) Written: under 5 minutes per month. (2) Two ION 3200, 1 Gbps each, peak 400 Mbps: fits. (3) Per-site licence M covers both devices. (4) Internet-A and Internet-B from different carriers, MPLS from a third. (5) Plan 400 Mbps peak, 15 percent overhead, growth to 600 Mbps: within the 1 Gbps device. (6) HA priorities 200 and 100, reduction 120, tested. (7) The core router has a route for 10.110.0.0/16 via DC-EAST. (8) Payment zone to payment servers only, guest to outside only. (9) Payment flows given highest priority. (10) Pilot in Analytics mode for two weeks, then Control mode. The review passes.
Common mistakes. Creating zones but not binding them to interfaces, which blocks that traffic. Creating dozens of zones instead of using prefix filters. Assuming ZBFW replaces a full next-generation firewall. Forgetting that a site has only one active security stack.
Exam trap. Each security policy set has three default rules (self-zone, default, intra-zone) that cannot be edited; the platform does not create default sets for you; one security stack is active per site; an advanced stack holds up to four sets evaluated left to right. A zone with no interface bound blocks the traffic on unbound interfaces.
Guest Wi-Fi that reached the cash registers
During a customer audit, a tester on guest Wi-Fi at one store could ping the payment terminals. The review found that the store had a zone for guest in the plan, but the guest VLAN sub-interface was never bound to that zone and a permissive rule applied to the unbound network. After binding the VLAN to the guest zone, applying the zone matrix with deny between guest and payment, and re-running the audit, the finding closed.
Lesson: a zone does nothing until it is bound to an interface, and the matrix must be tested, not assumed.
"What security can the ION provide at a branch, and what can it not?"
It provides zone-based firewalling: zones bound to interfaces, rules by source and destination zone, prefix filters and application, plus NAT policy for breakout. It is not a full next-generation firewall with deep threat inspection, so when the requirements demand that, I send traffic to a security service such as Prisma Access or a firewall at the data center, and I design the path policy accordingly.
Key takeaways
- ZBFW groups networks into zones bound to interfaces; keep zones few and use prefix filters for detail.
- Security policy sets have three non-editable default rules; one security stack is active per site.
- Write a source/destination zone matrix first, then test it.
- Segmentation spans zones, network contexts and VRFs; use the same segment names everywhere.
- Run the ten-step design review before sign-off; it is also the order for design troubleshooting.
Summary and exam checklist: planning and design
This chapter pulls the module together. Use it the night before the exam and as a template for real design documents. Remember the honest note from chapter 1: there are no simulator labs for this module, so the practice is on paper. Take the Harbor Foods story and redo the design for a different company with different numbers; if you can do that without looking, you know the module.
Can-do checklist
- I can name the three ION families (branch hardware, data center hardware, virtual) and choose a model from throughput, ports and special features.
- I can explain the data center subscription and the three branch licence models (per-device, per-site, aggregate), the S, M, L tiers, what is included and the 1 to 5 year term.
- I can run an assessment of sites, circuits, applications, LAN, routing, security, NAT and management.
- I can compute hub bandwidth with peaks, concurrency factor, overhead, growth and failure case.
- I can design a data center site: internet-facing port, network-peering port, routing, return routes, DC-to-DC fabric links, Prisma Access connection.
- I can pick one of five branch patterns and justify circuits, LTE or 5G and breakout.
- I can describe HA groups, priorities, tracking and bypass pairs and compute failover arithmetic.
- I can write a zone matrix, bind zones to interfaces and say what ZBFW can and cannot do.
- I can run the ten-step design review.
The module on one page.
Mini glossary
- ION
- Instant-On Network device, the Prisma SD-WAN edge device (physical or virtual).
- Data center site
- A hub site that terminates branch tunnels and connects to the core network.
- Circuit
- A WAN connection with a category (public or private) and a label.
- ZBFW
- Zone-based firewall built into the ION.
- HA group
- Two IONs in active/backup, with priorities and tracking.
- Bypass pair
- A LAN port and WAN port pair (hardware or virtual) used for pass-through and HA topologies.
- Aggregate bandwidth
- A licence pool in Mbps shared across all branch sites.
- Secure fabric link
- A secure tunnel between ION devices, including DC-to-DC links.
- Analytics, Control, Disabled
- The three deployment modes of a device or site.
- Standard VPN
- An IPsec tunnel to a non-ION endpoint.
Most-tested facts
| Topic | Fact |
|---|---|
| Data center ION models | 5200, 7000, 9000, 9200 in the documentation; virtual 7108V and larger |
| DC ION interfaces | An internet-facing port for public VPNs and a network-peering port toward the core |
| DC licence | One DC subscription per ION at a data center site, physical or virtual |
| Branch licence | Per-device (ZBFW included; WCR and DVR optional), per-site (ZBFW, DVR, WCR included), aggregate (ZBFW, WCR, DVR included) |
| Tiers | S up to 25, M up to 250, L up to 2,500 Mbps; term 1 to 5 years |
| DC-to-DC links | Secure fabric links, 6.5.1 or later, under Data Centers, Overlay Connections |
| HA | Max 2 devices, active/backup, priority 1 to 254, gap at least 40, track up to 4 interfaces |
| HA caution | Do not track L3 on private WAN with BGP or on a shared circuit |
| Bypass pair | Hardware or virtual; branch IONs only; not on controller interfaces |
| Overlays | Direct, Prisma SD-WAN VPN, Standard VPN |
| Security | Three non-editable default rules per set; one stack per site; up to four sets in an advanced stack |
| Modes | Analytics (observe), Control (enforce), Disabled (pass-through) |
Reference commands and portal paths (not run in the simulator)
! Reference configuration (not run in the simulator) ! ION CLI commands named in the HA documentation (no sample output shown) dump spoke ha config dump spoke ha status
Portal paths named in the documentation: Configuration, Prisma SD-WAN, Data Centers, Add Site; and Configuration, Prisma SD-WAN, Data Centers, Overlay Connections, Add Secure Fabric Link. Both are portal walk-throughs (not run in the simulator).
Top exam traps. (1) Sizing by interface speed instead of encrypted throughput. (2) Forgetting the DC subscription or the second device in HA. (3) Calling Prisma SD-WAN HA active/active. (4) A tracking reduction that is smaller than the priority gap. (5) A zone not bound to an interface. (6) Counting two circuits from one provider as diverse. (7) Forgetting return routes from the core to branch prefixes. (8) Mixing PAN-OS firewall HA with ION HA.
Common mistake. Memorising model numbers. Names and figures change; the exam rewards the logic of matching requirements to features. Keep the datasheet open while you practise and learn which column answers which requirement.
A design that passed review
A logistics company with 3 data centers and 80 branches used the ten-step review as a gate. Step 3 found no licence for the standby IONs at 14 HA sites, step 6 found an HA gap of 15 with a tracking reduction of 20 (inconsistent), and step 7 found no return route at one DC. All three were fixed on paper, so the cutover weekend had no surprises.
Lesson: the checklist is cheap; the cut-over weekend is expensive.
"Walk me through your approach to a Prisma SD-WAN design in two minutes."
Assess requirements and the existing network; size ION devices and bandwidth with peak, overhead, growth and failure case; choose licensing; design data centers (internet and peering ports, DC-to-DC links, Prisma Access), branches (patterns, diverse circuits, HA and bypass) and overlays; write security zones and segmentation; hand over to policy design; and run a review checklist before a phased rollout through Analytics mode.
Key takeaways
- Design order: assess, size, license, topology and HA, security, policy, review.
- Know the licence structure, HA numbers and DC interface roles precisely; these are exam favourites.
- Check every claim against current documentation; models and tiers change.
- No simulator labs: practise by redoing the Harbor Foods design with new numbers.
- Next: the policy design module (psd-policy), then deployment and routing.