SD-WAN Performance SLA Packet Loss False Positive on High-Speed 1Gbps Links
FortiGate SD-WAN Performance SLA health checks report false 40%–80% packet loss and trigger erratic route flapping on high-speed 1Gbps circuits when line-rate outbound traffic starves the local network driver's best-effort probe transmit queue.
Technical Root Cause Analysis
To monitor WAN health, the FortiOS link_monitor daemon generates continuous active probe packets (ICMP ping, HTTP GET, DNS queries, or TWAMP) across all member interfaces in the SD-WAN zone. The calculated packet loss, latency, and jitter directly determine which interface satisfies configured SLA targets for policy-based routing.
In affected FortiOS 7.2 releases, user-space probe packets generated by link_monitor are injected into the kernel network stack without an elevated socket priority or DSCP classification tag. When outbound WAN link utilization approaches 1Gbps line rate, the hardware driver's egress transmit ring buffer (txring) becomes completely full. Because probe packets lack priority, the network driver discards them locally at the tail of the FIFO queue (tracked internally as tx_dropped). The remote server never receives the probes, and the health check erroneously flags the 1Gbps link as degraded, failing over traffic to secondary connections and causing unnecessary voice and video session drops.
Affected Firmware & Blast Radius Matrix
| FortiOS Branch | Vulnerable Builds | Confirmed Clean Build | Status & Workaround |
|---|---|---|---|
| FortiOS 7.2 | 7.2.1 – 7.2.5 | 7.2.6+ | Apply diffservcode 101110 (CS6) to SLA probes |
| FortiOS 7.4 | 7.4.0 – 7.4.1 | 7.4.2+ | Probe SO_PRIORITY auto-marking introduced in 7.4.2 |
| FortiOS 7.0 | Not Affected | 7.0.x Branch Clean | Simpler egress ring buffer management avoided queue drop |
Platform Impact: Affects FortiGate 80F, 100F, and 200F appliances equipped with Gigabit Ethernet WAN interfaces handling high egress traffic bursts (over 700 Mbps).
Step 01: Free Verification CLI (Safe Read-Only)
Execute these diagnostic commands to verify whether your SD-WAN SLA packet loss is caused by local driver ring buffer drops rather than physical circuit loss:
Diagnostic Commands
# 1. Check SD-WAN health-check SLA metrics, packet loss, and link state
diagnose sys sdwan health-check status
# 2. Inspect kernel netlink interface statistics for tx_dropped packets
diagnose netlink interface list | grep -A 8 -B 2 "wan1"
# 3. Query historical SLA log churn for the active health-check
diagnose sys sdwan sla-log <health-check-name> 5
# 4. Verify physical interface duplex, link speed, and carrier errors
diagnose hardware deviceinfo nic wan1Remediation & Workaround Steps (Teaser Preview)
Follow the complete step-by-step remediation guide in the interactive Ferrite platform:
Frequently Asked Questions
When high-speed 1Gbps WAN links operate near line capacity, the network interface driver transmit queue (txring) fills up. In vulnerable FortiOS releases, link_monitor probe packets were treated as best-effort traffic without socket priority. The Linux driver discarded the probes locally before they ever reached the physical cable, causing the health check to calculate false 30% to 80% loss.
False packet loss causes SD-WAN rules to disqualify the primary fiber circuit and route traffic over slower backup lines (such as cellular or broadband), introducing unnecessary jitter and degrading VoIP/video quality.
FortiOS 7.2.6, 7.4.2, and later releases assign SO_PRIORITY flags to all link_monitor probe sockets, ensuring SLA probes bypass data plane queue congestion.