SD WAN Load Balancing

Here to help

SD WAN Load Balancing


SD-WAN & traffic shaping > Uplink Selection > Load Balancing

You have the option of enabled of disabled - do these options only control internet bound traffic not VPN traffic? Reason I ask is that for me, either enabled or disabled it seems to have no effect on traffic travelling over WAN 1 and 2 - but pretty much all of my traffic is VPN. I have suspicions that some of the traffic on my SD WAN is traversing a lower quality backup link instead of the primary leased line as i'm getting complaints of slow speeds. How should I set up the uplinks so that SD WAN VPNs only use the primary, and the secondary only comes into force if the primary was to fail?


And yes I have tried this option:
Do not create VPN tunnels over the secondary uplink unless the primary uplink fails.


Which broke connectivity as the MX started complaining that it could not reach the VPN registry



7 Replies 7
Kind of a big deal
Kind of a big deal

Should  work


You would  be able to see what what  traffic  exits wan1 or wan2 at the vpn  section.  Or making a packet capture.



If you can not reach the VPN registry using only primary wan  maybe thats the problem. I would  fix that first

Here to help

So i configured a policy (any to any) to only use WAN 1 unless it needs to failover and that seems to have made no difference


In VPN status its still sending traffic down both WAN links. Under "Reason" for sending down WAN 2 it has "Performance based" which makes no sense as WAN 1 is the better performing link. This is happening even though its matching against the policy "Prefer WAN 1".


While i was looking at the VPN status page the VPN registry went from green to yellow, saying it can connect to at least one VPN registry...hmmm


Drilling down on the performance stats it is monitoring for each uplink, it seems to think that Loss is at 100% for Uplink 1 which makes no sense as the link is operational. And yet, if you go to Appliance Status > Uplink and look at the Live stats.....whatya know, there is no loss on the WAN1 at all


Makes no sense to me

Kind of a big deal
Kind of a big deal

>In VPN status its still sending traffic down both WAN links. Under "Reason" for sending down WAN 2 it has "Performance based" 


The decision on which link to use is based on the end to end performance, not just the performance of your local WAN circuit.

You might think WAN2 is a lower quality backup link, but perhaps its end to end performance to the remote party is better.


If you go:

Security & SDWAN/VPN Status

and then click on the usage and latency statistics for a VPN it will only up a far more detailed page about the end to end performance over each WAN link.

There is no way a telephone line to leased line has better connectivity than leased line to leased line. The stats on the MX confirm that. I rebooted the MX which cleared the erroneous 100% loss rate the MX was reporting on WAN1 however it still overrides the manual policy that is meant to send everything down WAN1 and sends stuff down both. Loss/latency/jitter stats are much better on WAN1.


Just knocked off the active-active auto-VPN which broke connectivity to from this MX to one of our other sites. So it seems that autoVPN will not form over this particular interface therefore will only send it over WAN2. I'm at a loss, will be logging with Meraki



Building a reputation

If you want to force VPN traffic to certain WAN link, you can try to create SD-WAN Policy.


2020-04-24 17_14_32-Window.png


Under VPN traffic, set filter as custom filter, and set protocol/source/destination as Any.

This means all VPN traffic.

Set preferred uplink as WAN 1, and failover is uplink down

With this settings, all VPN traffic will use WAN 1 until it goes down.


Plus, "Do not create VPN tunnels over the secondary uplink unless the primary uplink fails." is for Active-Active VPN tunnel setting, and it doesn't do anything with load balancing.



Kind of a big deal

If possible to confirm your theory disable the WAN 2 and see if the complaints happen. If not possible, when someone is having the speed issue run a trace route from their workstation to see which WAN it goes out.

Kind of a big deal
Kind of a big deal

We sorted this out by creating more specific custom performance classes.  i.e. one for low latency, one for low packet loss etc.  Then we add VPN traffic preferences to match the traffic that matters, i.e. Citrix ICA, video, VDI streams etc. to the appropriate performance class.


You can instantly tell if it has worked by looking at the VPN status page.  If your policies don't appear to be making the changes you want, just play with them, applying and removing policies doesn't seem to interrupt the traffic from an end user point of view.

Get notified when there are additional replies to this discussion.