Traffic uses a backup link while the main link appears available.
Probable causes
- SLA threshold
- SD-WAN rule
- priority
Verifications.
- Limit the impact. — Identify whether an endpoint, service, or whole site is affected.
- Collect evidence. — Keep the exact error message, timestamp, and associated logs.
- Test the simplest hypothesis first. — Compare the affected system with a known-good path.
- Correct the confirmed cause and validate the result. — Apply one controlled change at a time and retest.
Solutions.
- Correct the confirmed cause rather than the symptom.
- Document the change and its result.
- Establish monitoring if the fault can recur.
When to escalate?
Escalate if the impact expands, data are at risk, or remediation requires an irreversible change.
SD-WAN path-selection focus
A healthy physical link can still lose SD-WAN preference if its SLA probe, route, policy or session state says otherwise. Separate link availability from the policy decision that selected the backup path.
What to verify
- Inspect latency, packet-loss and jitter measurements for the health check used by the affected rule.
- Compare member priority, cost, weight and SLA thresholds with the intended primary-versus-backup design.
- Check policy matching, source and destination objects, application rules and any more-specific route that may override the expected path.
- Remember that existing sessions can remain pinned to a member until they expire or are deliberately cleared.
Resolution path
Correct the failed SLA target, threshold or rule ordering rather than forcing the preferred interface up. If the probe destination is unreliable, use a target that represents the service path you actually want to protect.
Validation
Generate a new test session after the policy change and confirm both the selected SD-WAN member and the measured SLA state.