SD-WAN policies doesn't make any sense

[IgorPodgorny]

Hello everybody,

I have multiple MX appliances at multiple locations (MX100, MX250, MX84, Z3). When navigating to 

Security & SD-WAN > SD-WAN & Traffic Shaping > SD-WAN policies section I get a bit confused.

This section makes no sence whatsoever. I see VPN Traffic section and Add preference.

Here is how it doesn't make any sence. Traffic filter gives me all kinds of things, like email, video, VoIP, Blogging, gaming, online backup, etc.

Please tell me how any of these apply to VPN Traffic? For example "Productivity > Office 365", I would love to be able to select best uplink for it (based on custom performance class, or better performing link, like a true SD-WAN would do), but what good is this section if it applies to VPN traffic? I don't have a VPN tunnel to Office 365. Or any other services listed there for that matter.

How would you do SD-WAN on Meraki. Doesn't seem to be an option at all. Flow preference is manual process designed for something else all together.  Traffic shaping section doesn't account for link performance. The only section sutable for it aplies only to VPN traffic.... No SD-WAN with MX?

Thank you

[ww · Accepted solution]

For the underlay they call it sd-internet but you need sdwan plus lic for it.

I think the "Feature" part explains your question

https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/...

[IgorPodgorny]

Thank you for your reply:)

This confirms what I was thinking that they don't do SD-WAN. SD-WAN is a term for what they decided to call SD-Internet. Steering traffic based on uplink performance  and not based on service in question, isn't good idea either. I currently have ~8ms latency to 1.1.1.1 on WAN1 and ~12ms on WAN2, so SD-Internet would use WAN1 for Office365 traffic (roughly speaking), but my latency to Office 365 is ~2ms on WAN2 (true metric). Thus 2nd connecion would be a better choice...

Doesn't seem to be much diferent from manual flow prefernce, just look at latency statistic for the past month or so and it will match their SD-Internet 99% of the time 🙂

What a joke. Couldn't get SD-WAN right to begin with, renamed it to SD-Internet and can't get that right either:) License expires in 97days, got to start thinking about replacement solution.

Really apreciate your promp responce though:) Thank you once again.

[ww]

SD-WAN can be interpeted  in so many ways. Everyone has a different explanation  for it. so it would be better to avoid using it imho

[IgorPodgorny]

Cisco has a different definition of SD-WAN. Would be great if that held true across all Cisco products, given that they own Meraki.

[GIdenJoe]

If your services like o365 are directly reachable over the internet then for the moment you won't have much joy using the SD-WAN.  You're supposed to have SD-Internet then in combination with the most expensive SD-WAN license on the MX.
The SD-WAN policies in this case are only useful if you are using a central site or DC that has a direct connection to MS datacenters like an expressroute.  Then your branches can actually use the best path towards the DC which has the closest connection to MS Azure.

[IgorPodgorny]

That's what I got from a previous reply. No SD-WAN on MX:) Even SD-Internet, which is SD-WAN by definition:), will only use uplink performance to a handful of IPs and not actual WAN performance to a particular service target.

I happened to have 2ms latency to o365 on WAN2 while WAN1 generally performs better for other things (1.1.1.1 and 8.8.8.8, etc.).

Meraki sounded so promissing a few years ago, with "getting better over time as long as you maintain a license", which we bought the most expencive at that time (Advanced Security). What a disapointment.

[IgorPodgorny]

Even by their parrent company definition SD-WAN is what they are rebranding as SD-Internet.

https://www.cisco.com/c/en/us/solutions/enterprise-networks/sd-wan/what-is-sd-wan.html

My guess is that Cisco is cripling Meraki on purpouse to sell more robust and expencive products.