TTechclick ⚡ XP 0% All lessons
Versa · Secure SD-WAN · ConfigurationInteractive · L1 / L2 / L3

Versa SD-WAN Config — Templates, Service Chains & Policy Order

Versa is configured once in Director and pushed to thousands of branches. This lesson maps the whole model — device and service templates bound to device groups, bind-data that fills per-site values, the VOS service chain that sets the order of functions, and the SD-WAN policy hierarchy where rules are matched top-down and the first match wins — then how you commit, deploy and roll back safely.

📅 2026-06-18 · ⏱ 16 min · 5 infographics · live policy demo · 🏷 10-Q assessment + AI Tutor inline

⚡ Quick Answer

A clear, interactive guide to the Versa SD-WAN configuration model (2026): how Director-driven device and service templates bind to device groups, how bind-data fills per-site values to scale to thousands of branches, how VOS service chaining sets the order of network functions, and how SD-WAN policy rules are matched top-down with first-match wins — plus commit, deploy and rollback.

🎯 By the end you will be able to

Read as:

Pick where you want to start

1

The model

Director-driven templates, one config to many branches.

 2

Templates & bind-data

Device vs service templates, variables per site.

 3

Service chaining

Order of functions inside VOS.

 4

Policy order & deploy

First-match rules, commit, diff, rollback.

🧠 Warm-up — 3 questions, no score

Just notice which ones make you pause. We answer all three inside the lesson.

1. Where is Versa branch config authored and pushed from?

Answered in The model.

2. What fills per-site values like WAN IP into a shared template?

Answered in Templates & bind-data.

3. When two SD-WAN rules could match traffic, which one applies?

Answered in Policy order & deploy.

Most engineers think…

Most people picture SD-WAN config as 'log into each branch and set it up'. With Versa at any real scale, that mental model falls apart — and it fails you in an interview.

Versa is template-driven from Director: you build a device template and a service template once, attach them to a device group, and let bind-data fill the per-site values (WAN IP, site name) so the same template produces correct config for thousands of branches. Inside the box, VOS runs a service chain whose order you decide, and SD-WAN policy rules are matched top-down with first-match wins. Understanding that split — central authoring, per-site variables, chain order, rule order — is what lets you scale, troubleshoot and roll back safely.

① What the Versa config model actually is — author once in Director

The single most important idea: Versa is configured once in Director and pushed to many branches, not box-by-box. You build the configuration centrally as templates, attach them to a device group, and every member device inherits that config automatically.

This is what makes Versa scale. A single template, combined with per-site values, produces correct configuration for thousands of branches without anyone touching a branch CLI. The same Director then handles commit and deploy, tracks what changed, and lets you roll back. One controller, reusable templates, per-site fill-in.

Figure 1 — Author once, deploy everywhere
Versa builds config centrally in Director and pushes it to every branch, filling per-site values along the way.Author once, deploy everywhereBuildtemplates in DirectorAttachto a device groupBindper-site variablesDeploypush to branchesTrackdiff + rollback
Versa builds config centrally in Director and pushes it to every branch, filling per-site values along the way.
Figure 2 — Layers of the Versa config model
Each layer narrows central intent down to correct per-site config on every branch.Layers of the Versa config modelDirector templatesDevice + service config authored onceDevice groupTemplates attach; members inheritBind-dataVariables filled per site (wan-ip, site)Branch (VOS)Final config running on the device
Each layer narrows central intent down to correct per-site config on every branch.
Quick check · Q1 of 10 · Understand

The Versa configuration model is best described as…

Correct: b. Versa is template-driven from Director: you build config centrally, attach templates to a device group, and member devices inherit it — so one model scales to thousands of branches without touching each box.
👉 So far: Versa = author config once in Director as templates, attach to a device group, and every member branch inherits it — one model scales to thousands of sites.

② Templates and bind-data — the key to scale

Versa splits config into two template types. A device template holds device-level config — interfaces, system settings and base routing. A service template holds services — SD-WAN steering, forwarding and SLA profiles, security policies and NAT. Both attach to a device group and members inherit them.

How one template fits every site

The trick is bind-data. A template contains placeholders — template variables such as {{wan-ip}} or {{site-name}} — and bind-data fills them in per device. So one shared template produces the right config for every branch. Most of the service config is applied by post-staging templates once a device is staged and online.

Figure 3 — Device template vs service template
Two template types split the config: device-level basics versus the services that ride on top.Device template vs service templateDevice templateInterfaces and WAN/LANSystem settingsBase routingDevice-level identityService templateSD-WAN steering + forwardingSLA profilesSecurity policy (FW/IPS/URL)NAT and services
Two template types split the config: device-level basics versus the services that ride on top.
🖥️
Versa Director
tap to flip

The central controller — you author templates, bind-data, commit and deploy here, and it tracks config diffs and rollback for every device.

🧩
Device template
tap to flip

Holds device-level config: interfaces, system settings and base routing. Attaches to a device group so members inherit it.

🛠️
Service template
tap to flip

Holds the services: SD-WAN steering, forwarding and SLA profiles, security policy and NAT. Rides on top of the device template.

🔑
Bind-data
tap to flip

Per-device values that fill template variables like {{wan-ip}} and {{site-name}}, so one template produces correct config for every branch.

Separate device-level from service-level

In an interview, split the device template (interfaces, system, base routing) from the service template (SD-WAN steering/SLA, security, NAT), and add that bind-data fills per-site variables. That trio — two templates plus variables on a device group — is the whole Versa scaling story.

Quick check · Q2 of 10 · Remember

Which template type holds interfaces, system settings and base routing?

Correct: c. The device template holds device-level config — interfaces, system and base routing. The service template holds the services (SD-WAN steering/SLA, security, NAT) that ride on top.
👉 So far: Device template = interfaces/system/base routing; service template = SD-WAN steering/SLA, security, NAT; bind-data fills per-site variables like wan-ip and site-name.

③ Service chaining — the order of functions inside VOS

Inside the branch, VOS applies a service chain to traffic — a sequence of network functions you decide the order of. A typical chain runs routing → NAT → SD-WAN steering → security (firewall, IPS, URL filtering). In a single VOS image this is a single-pass flow; in larger designs the chain can span multiple service nodes or VNFs.

The interview line: you choose the order of services in the chain, and that order changes the outcome. Steering before NAT versus after NAT, or security before steering, will treat the same packet differently — so the chain is a design decision, not an accident.

Figure 4 — Functions in the VOS service chain
VOS applies a chain of functions to traffic; you decide the order they run in.Functions in the VOS service chainVOS chainsingle-pass orderRoutingNATSD-WAN steeringFirewallIPS / URL filterSLA measure
VOS applies a chain of functions to traffic; you decide the order they run in.
Treating the service chain order as 'automatic'

VOS runs functions in the order you define — routing, NAT, steering, security. Assuming Versa 'just figures it out' bites you: NAT before steering versus after, or security before steering, changes the result. Always name the chain order as a deliberate design choice.

▶ Watch an Office 365 flow get steered onto broadband

How one app flow is classified and steered end-to-end. Press Play for the healthy path, then Break it to see the classic failure.

① ClassifyAn Office 365 packet enters VOS at the branch and DPI identifies the application.
▼
② Match ruleSD-WAN policy is checked top-down; the specific O365 rule matches first and selects its forwarding profile.
▼
③ Check SLAThe SLA profile checks broadband for loss, latency and jitter and confirms it meets the app's target.
▼
④ Steer + chainThe flow is steered onto broadband and the rest of the service chain (NAT, security) is applied on the way out.
Press Play to step through the healthy steering path. Then press Break it.
Quick check · Q3 of 10 · Apply

You need the same packet to be NATed before security inspects it. Where is that decided?

Correct: a. VOS applies a service chain and you choose the order of functions (routing, NAT, steering, security). Changing where NAT sits relative to security changes how the same packet is treated — it is a design decision.
👉 So far: VOS applies a service chain — routing → NAT → SD-WAN steering → security — and you choose the order, which changes how the same packet is treated.

④ SD-WAN policy order and safe deploy — first match wins

SD-WAN policy is a top-down list of rules. Traffic is matched against rules by app/DPI, source, zone and more, and the first matching rule decides the path through its forwarding and SLA profile. Because evaluation stops at the first hit, rule order matters: put more-specific rules above broad ones, with an implicit default at the bottom for the rest.

Change it safely

Edit the template in Director, then commit and deploy to the devices. Director shows a config diff of exactly what changed and supports rollback to a known-good version. The classic failure is dropping a broad catch-all rule above a specific one — the specific rule never matches.

Figure 5 — How an SD-WAN rule is chosen
Rules are checked top-down; the first match decides the path, so order is everything.How an SD-WAN rule is chosenPacket inclassify by app/DPIRule 1match? source/zoneRule 2first match winsForwardSLA + path chosenDefaultimplicit catch-all
Rules are checked top-down; the first match decides the path, so order is everything.

Vikram at a Pune retail chain faces this

A new SD-WAN rule meant to send Office 365 over the broadband link does nothing — all O365 still rides the MPLS path.

Likely cause

A broad 'all internet traffic → MPLS' rule was placed above the specific O365 rule, so first-match-wins never reaches the O365 rule.

Diagnosis

Open the SD-WAN policy in Director and read top-down: the catch-all internet rule matches O365 first, so the specific rule below it is dead.

Director ▸ Services ▸ SD-WAN ▸ Policies (rule order) + Config diff
Fix

Move the specific O365 steering rule above the broad internet rule, commit and deploy, and confirm via the config diff that only rule order changed.

Verify

Re-test: O365 now egresses on broadband per the specific rule; monitoring shows the MPLS catch-all only handling the remaining traffic.

Prove it from the config diff, not a hunch

Never deploy a Versa change on 'should be fine'. Director shows a config diff of exactly what changed before you push, and supports rollback if it goes wrong. Read the diff and check rule order — that single look answers most SD-WAN policy tickets.

Quick check · Q4 of 10 · Analyze

Two SD-WAN rules could match the same traffic. Which one takes effect, and why does order matter?

Correct: d. SD-WAN policy is matched top-down and the first match wins; lower rules are never consulted. Put specific rules above broad catch-alls or the specific ones never fire, with an implicit default at the bottom.
👉 So far: SD-WAN policy is matched top-down, first-match-wins; specific rules go above broad ones. Edit in Director, commit/deploy, and use config diff + rollback.

🤖 Ask the AI Tutor

Tap any question — instant, scoped to this lesson. No login, no waiting.

Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.

📝 Wrap-up assessment — six more

You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.

Q5 · Remember

Where is Versa branch configuration authored and pushed from?

Correct: b. Versa is template-driven from Director: you build config centrally, attach templates to a device group, and deploy to all member branches — that is what lets it scale.
Q6 · Understand

What does bind-data do?

Correct: a. Bind-data is a per-device table that fills template variables (placeholders), so a single template produces correct config for each site — the key to scaling to thousands of branches.
Q7 · Apply

You want NAT to run before SD-WAN steering on a branch. How do you control that?

Correct: c. VOS applies a service chain in an order you define. To make NAT run before steering you order the functions accordingly — service chain order is a deliberate design choice that changes packet handling.
Q8 · Analyze

Why does the order of SD-WAN policy rules matter?

Correct: b. SD-WAN policy is evaluated top-down and stops at the first matching rule. A broad catch-all placed above a specific rule will match first, so the specific rule never fires — order is critical.
Q9 · Evaluate

An interviewer asks how Versa scales config to thousands of branches. Best answer?

Correct: d. The scaling story is central templates (device + service) on a device group plus bind-data for per-site variables, authored and deployed from Director. Per-box CLI or a bigger box is the wrong mental model.
Q10 · Evaluate

What is the safest way to make and verify a Versa policy change?

Correct: c. Director lets you review a config diff of exactly what changed, commit and deploy to selected devices, and roll back to a known-good version — reviewable and reversible, unlike blind CLI edits.
Lesson complete — saved to your profile.
Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again".

🧠 In your own words

Type one line: why is the Versa model called 'one config, many branches' rather than 'configure each box'? Then compare with the expert version.

Expert version: Because the configuration lives centrally in Director as reusable templates — a device template for device-level basics and a service template for services — attached to a device group that all branches inherit. Bind-data then fills per-site variables like wan-ip and site-name, so the same template produces correct config for every branch. Inside each box VOS runs a service chain in an order you choose, and SD-WAN policy is matched top-down with first-match-wins. You never hand-build thousands of configs; you author once, bind per site, deploy from Director, and use config diff and rollback to stay safe — which is exactly why it scales.

🗣 Teach a friend

Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.

📖 Glossary

Versa Director
The central controller where you author templates and bind-data, commit and deploy config, and track config diffs and rollback.
Device template
A template holding device-level config — interfaces, system settings and base routing — attached to a device group.
Service template
A template holding services — SD-WAN steering/forwarding/SLA profiles, security policy and NAT — that ride on top of the device template.
Device group
A logical grouping of branch devices; templates attach to the group and member devices inherit the config.
Bind-data / template variable
A per-device table that fills placeholders like {{wan-ip}} or {{site-name}}, so one template produces correct per-site config.
Post-staging template
A template that applies the bulk of service config after a device is staged and online.
Service chaining
The ordered sequence of network functions VOS applies to traffic — routing, NAT, SD-WAN steering, security — in an order you decide.
SD-WAN policy / first-match
Rules matched top-down by app/DPI, source and zone; the first matching rule's forwarding and SLA profile decides the path.
Commit / deploy
Saving a change in Director (commit) and pushing it to selected devices (deploy).
Rollback
Reverting a device or template to a previous known-good configuration version from Director.

📚 Sources

  1. Versa Networks — Versa SASE / Secure SD-WAN product and architecture overview. versa-networks.com
  2. Versa Networks Documentation — Versa Director: device and service templates, device groups. docs.versa-networks.com
  3. Versa Networks Documentation — Bind-data and template variables for per-site configuration. docs.versa-networks.com
  4. Versa Networks Documentation — VOS service chaining and network functions. docs.versa-networks.com
  5. Versa Networks Documentation — SD-WAN policies, forwarding and SLA profiles (rule order). docs.versa-networks.com
  6. Versa Networks Documentation — Commit, deploy, config diff and rollback in Director. docs.versa-networks.com

What's next?

Got the config model? Next, go deep on SD-WAN steering itself — SLA profiles, forwarding profiles, app-steering and how Versa measures loss, latency and jitter to pick and switch paths in real time.

Next · All interview lessons → Practice on exam.techclick.in →