Dynamic Path Selection & Application-Aware Routing

Objective

Validate that the zWAN device steers traffic over the best available path (e.g., WAN00 vs WAN01 or tunnel IPSEC00/IPSEC01/IPSEC03) and that selected applications/SaaS can be routed via preferred paths with automatic failover when a path is disabled or becomes unavailable.

Prerequisites

• Admin access to zWAN Director.
  • Device has two usable egress paths (e.g., two WAN links and/or multiple tunnels as shown on Network → Net Balancer).
  • At least one Windows client on the LAN (Wi-Fi on LAN05 or wired on LAN00).
  • Basic internet access working (you can browse from the test client).

Test 1: App-Aware Policy (SaaS Preference + Failover)

Route a chosen SaaS app over a preferred path, then prove automatic failover by disabling that path.

Steps

1. Baseline & Identify Paths
   • Director: Edge Controllers → [Your device] → Network → Net Balancer.
   • On the Branches tab, note the available Gateways (e.g., IPSEC00/IPSEC01/IPSEC03) and their Link Status, Weight, Status toggle.
   • Open a second tab: Analytics → Statistics for your device, then the Interfaces tab. Keep this open to observe traffic on the chosen gateway(s).
2. Create SaaS Preference
   • Director: Network → Net Balancer → SaaS Apps.
   • Locate a clearly-listed SaaS entry in your build (for example, Microsoft 365/Teams or any item visible in your UI).
   • For that SaaS entry, set the Preferred gateway/path (e.g., IPSEC01) and allow alternate/backup path(s) (e.g., IPSEC03).
   • Save.
3. Generate Traffic & Verify Preferred Path
   • From the Windows client, browse to the selected SaaS (e.g., Teams/Outlook web, whichever you chose).
   • In Director, watch Analytics → Statistics → Interfaces and/or Global Applications: you should see traffic counters/rates on the preferred gateway increase while using the SaaS.
   • (Optional) On Analytics → Statistics → Link Status / Signal Quality, confirm both paths are up/healthy.
4. Simulate Path Failure → Validate Failover
   • Director: Network → Interfaces (or Network → Net Balancer → Branches, depending on where you toggle in your build).
   • Temporarily disable the preferred egress (e.g., toggle WAN00 off or disable IPSEC01 gateway).
   • Keep your browser session active; refresh the SaaS page or continue usage.
   • Observe in Analytics → Statistics → Interfaces that the traffic moves to the backup path (e.g., IPSEC03).
5. Restore
   • Re-enable the preferred path.
   • Confirm service is still reachable; observe counters rising again on the preferred path if your policy allows immediate return, or remaining on backup if sticky.

Validation
• While the preferred path is up, SaaS traffic uses it.
• When the preferred path is disabled, SaaS traffic continues via the alternate (failover).
• Traffic distribution is visible in Analytics → Statistics → Interfaces (and optionally Global Applications).

Test 2: Dynamic Path Selection under Link Events (Non-SaaS Web Traffic)

Prove generic web/HTTPS traffic switches paths when the active path is disabled.

Steps

1. Preferred Path for General Web
   • Director: Network → Net Balancer → Balancing Rules.
   • Create a rule targeting Web/HTTPS (choose the appropriate selector available in your build—e.g., “Web/HTTPS” or a “Global Application” entry exposed here).
   • Set Preferred = your primary gateway (e.g., IPSEC01), with a backup gateway allowed.
   • Save.
2. Generate Traffic & Observe
   • On the Windows client, browse several popular sites (docs, news, etc.).
   • Watch Analytics → Statistics → Interfaces; you should see web traffic on the primary gateway.
3. Disable Primary Path → Validate
   • Temporarily disable the primary egress (same method you used in Test 1).
   • Keep browsing; confirm pages continue to load.
   • Verify traffic counters now increase on the backup gateway.
4. Restore
   • Re-enable the primary path and confirm overall stability.

Validation
• Web/HTTPS traffic follows the active policy and fails over automatically on path disable.

Test 3: Path Preference by Weight (Steady-State Distribution)

Show that when multiple paths are up, traffic distribution follows configured weights.

Steps

1. Review/Adjust Weights
   • Director: Network → Net Balancer → Branches.
   • For the gateways you use, review the Weight column (e.g., Primary = 50, Secondary = 1).
   • Adjust if needed (e.g., 50/1 for strong preference vs 10/10 to balance).
2. Generate Steady Traffic
   • From the Windows client, run a sustained web activity (e.g., downloading a large file in a browser).
   • Watch Analytics → Statistics → Interfaces; with equal weights you should see both paths carry traffic, while a heavily weighted primary should carry most.

Validation
• Observed traffic splits according to Weights when both paths are healthy.

Monitoring & Evidence Collection

• Analytics → Statistics
  – Interfaces: confirm per-path throughput, packets, and errors.
  – Global Applications: confirm app/SaaS distribution if present in your build.
  – Link Status / Signal Quality / TWAMP: observe link health/changes while testing.
  • System → Logs → Syslog
  – Use recent time filter; look for path up/down and balancing-related messages (e.g., gateway/interface state changes).

Notes & Tips

• Your earlier screenshot shows Network → Net Balancer with Branches / SaaS Apps / Balancing Rules / Advanced; use those tabs exactly.
  • For failover simulation, the cleanest demo is simply toggling the interface/gateway OFF in UI (you already showed toggles under Network → Interfaces and “Status” toggles under Net Balancer → Branches).
  • If a specific SaaS name isn’t present in your SaaS Apps tab, pick another item that is listed in your build (the test is the same).
  • Leave policies in place for the POC; document preferred path settings so you can revert quickly after demos.