ERP Freezes but SD-WAN Does Not Fail Over
A logistics company runs SD-WAN across 25 branches. Each branch has two ISPs and a PA-460. The ERP application is matched by an SD-WAN policy that uses a path quality profile with latency 100 ms, jitter 30 ms, and loss 2%. The policy action is "lowest latency" and both ISP paths are allowed. At branch 12, ISP-B shows latency 20 ms, jitter 10 ms, and periodic loss spikes to 8% for 30 seconds every 10 minutes; ISP-A shows 35 ms latency, 8 ms jitter, and 0.1% loss. Users report ERP sessions freeze during the loss spikes, but the SD-WAN monitor shows no failover. The path quality probe interval is 5 seconds and the probe count is 3. The branch has no bandwidth saturation. The operations team wants to know why the policy did not move ERP to ISP-A and what to change.
1. Why does "lowest latency" keep ERP on ISP-B despite the loss spikes, and how do the path quality thresholds interact with path selection?
Read the worked answer
"Lowest latency" selects the lowest-latency path among paths that satisfy the attached path-quality profile. If ISP-B remains selected, one of three things is true: the profile is not attached to the ERP rule, the rule permits only ISP-B, or the loss spike is not being evaluated as a threshold violation. With a 5-second probe interval and a 3-probe count, a 30-second loss spike should generate samples, but if the profile averages over a longer window, the average loss may remain below 2%. Also confirm that the loss threshold is applied to the same tunnel monitor and direction that the policy uses.
A loss threshold of 2% is too loose for ERP. A 30-second burst at 8% can still disrupt sessions without tripping a 2% average. Check the policy hit counters, the profile attachment, and the path-quality history before changing anything.
2. What changes would you make to the path quality profile and policy, and what monitoring would you use to confirm?
Read the worked answer
Tighten the ERP profile: loss 0.5%, jitter 20 ms, latency 80 ms. Keep both paths allowed and use best available path with a failback hold time so ERP does not flap back immediately after a spike. Ensure the profile is attached to the ERP rule and that the rule is above broader business-application rules. If the platform supports it, shorten the probe interval or adjust the probe count so a 30-second loss burst is detected within the first few probes.
Confirm with path-quality history for both ISPs, SD-WAN policy match and route counters, and a controlled test: inject loss on ISP-B or shut it down and verify ERP moves to ISP-A. Also check that return traffic is symmetric and that the ERP session re-establishes cleanly after failover.
3. What would you check if the policy still does not fail over after the threshold change?
Read the worked answer
Check policy order and application identification first. A broader rule may still match ERP before the ERP rule, or the application may be identified as a different custom application. Then check whether the SD-WAN rule is actually using the intended path-quality profile and whether the profile is applied to both tunnels.
Next, verify routing and symmetry: the branch may select ISP-A for outbound ERP but the return path may still arrive over ISP-B, or a static route may override the SD-WAN decision. Check HA status and session ownership; an active/active or asymmetric HA state can prevent clean failover. Finally, confirm that the loss spikes are visible to the same tunnel monitor that the policy uses, not just to interface counters.