We recently completed a migration from Palo Alto Networks Prisma Access to Fortinet's SASE (FortiSASE) solution across our primary and six satellite offices. The primary motivation was cost consolidation, but the performance data we captured during the parallel run phase revealed a more significant, quantifiable benefit than we had anticipated.
Our baseline was established over a 30-day observation period prior to any changes. We instrumented our internal latency monitoring to track round-trip time (RTT) for a set of critical internal services (AD authentication, file server access, CI/CD pipeline heartbeats) from each branch location. The monitoring agent executed a script every 5 minutes, logging the results to our central observability platform.
**Pre-Migration Baseline (Prisma Access, last 30-day avg):**
* **Service:** `east-us-file01.corp.internal`
* **Branch: Denver** - Avg RTT: 47ms, P95: 62ms
* **Branch: Atlanta** - Avg RTT: 38ms, P95: 51ms
* **Overall Weighted Average RTT:** 41ms
The cutover was performed branch-by-branch over two weekends. We maintained the Prisma Access tunnels for a 7-day parallel run, routing non-critical traffic over the new FortiSASE paths while critical traffic used the legacy path. This allowed for direct A/B testing.
**Post-Migration Results (FortiSASE, first 7-day avg):**
* **Service:** `east-us-file01.corp.internal`
* **Branch: Denver** - Avg RTT: 38ms (**-9ms**), P95: 49ms
* **Branch: Atlanta** - Avg RTT: 30ms (**-8ms**), P95: 42ms
* **Overall Weighted Average RTT:** 33ms (**-8ms, ~20% reduction**)
The configuration for both solutions was functionally equivalent: full tunnel, no local breakout, with equivalent security policy sets. The latency improvement was consistent across all monitored services, not just a single endpoint. Our hypothesis is that this stems from a more favorable PoP (Point of Presence) geographical distribution and ingress routing within the Fortinet network for our specific branch locations, particularly in the Midwest and Southeast US.
I am interested in deconstructing this result further. Has anyone else performed similar instrumentation during a SASE migration? I am particularly curious about:
* Methodologies for benchmarking real-user latency beyond simple ICMP pings to the cloud gateway.
* Comparative data on PoP locations and backbone peering relationships between major SASE providers.
* Whether this latency delta is sustainable, or if it's an artifact of being on a new, less congested platform.
Our monitoring agent script (Python) for those interested in replicating the methodology:
```python
import subprocess
import time
import json
from datetime import datetime
targets = ["east-us-file01.corp.internal", "auth.corp.internal"]
results = []
for target in targets:
for _ in range(5): # 5 packets per target
try:
# Using timestamped ping for better accuracy
output = subprocess.check_output(
["ping", "-c", "1", "-W", "1", target],
stderr=subprocess.STDOUT,
text=True
)
time_str = output.split("time=")[-1].split(" ms")[0]
latency = float(time_str)
results.append({
"timestamp": datetime.utcnow().isoformat(),
"target": target,
"latency_ms": latency
})
except subprocess.CalledProcessError:
# Handle timeouts or failures
results.append({
"timestamp": datetime.utcnow().isoformat(),
"target": target,
"latency_ms": None
})
time.sleep(0.5) # Small delay between pings
# Log results to file for ingestion
with open("/var/log/latency_monitor.json", "a") as f:
for r in results:
f.write(json.dumps(r) + "n")
```
-- elliot
Data first, decisions later.