SD-Wan and Windows File Sharing/SMB not compatible?

[anfare]

We installed SD-Wan a few months ago in a very simple single vlan spoke and hub setup--just the 2 locations, spoke and hub involved. Both locations has 1000/1000Mbps connections (verified both are getting expected speeds). When we try to copy a file from a Windows 2022 server on the hub to a windows 10 client (all fully patched) on the spoke, the file copy speeds (as well as iperf) peak at about 3Mbps. This makes it very hard for the users to get work done as the files their software uses are usually fairly large so everything takes a long time to open/save and files are getting corrupted regularly.

All AMP/IDP services are disabled on the spoke; tunnel all is on as we need all traffic to exit the HUB. We did all of the standard and even standard troubleshooting (disablebandwidththrottling registry edit, SMB tuning on the server, checking MTU, etc.) all to no avail.

I went to the spoke location and scheduled a call with support (we get the service through ATT) who got a Meraki tech on the line. We spent 2 hours looking at things and testing with iPerf, testing file copy speeds between 2 machines on the spoke (worked fine) and at the end of it all, the final "answer" from the Meraki tech was that this is expected behavior with SD-Wan and SMB. If this is the case, how do people solve SD-Wan locations using fileshares? It seems like this should be a pretty standard and common setup, but is there really no solution to using SMB over SD-Wan (I confirmed we are using SMB3.1.1; packet captures show SMB2, SMB1 is definitely disabled).

I was looking at maybe getting a better connection at the spoke (it is VZN Fios, so Fiber but shared) like DIA, but it's much more expensive and if SD-Wan is incompatible with SMB it wouldn't fix the issue anyway.

[dipenrathod1997]

We do have file shares across our Network and we use it all the time plus we have HUB and SPOKE environment between 5 offices. MXs are far more capable of handling packets at least for us (since we have MX 105). Have you ran a test while transferring files what does the device utilization looks like since last time we had same problem and called tech support they insisted us disabling "AMP" and "IDP" under threat protection on HUB. In our case CPU usage was getting high and fans kept running all the time. That was my 2 cents hope this helps!

[anfare]

Thanks, good to know.

We are running MX at both location (95 at hub and 68 at spoke), with MS-120 switches going out to the clients. I'm getting the service through AT&T so I don't have full admin access unfortunately and I don't see anywhere where I can see utilization of CPU/RAM etc. the only charts I can see I have posted elsewhere in this thread. It doesn't look like it's using much on the traffic analytics pages, very little jitter and loss.

[JamesGill5290]

I know this is an old post, but the CPU numbers are under the Organization -> Summary report (set the date / time to today if you want current view). Or using the API call is an easy method to get

Sample Python script, just set your org and api key.

import meraki
import os
import pprint

API_KEY = os.environ.get('MERAKI_API')
organization_id = os.environ.get('MERAKI_ORG')

dashboard = meraki.DashboardAPI(API_KEY, caller='TopApplianceUtil.py/v1.0')

response = dashboard.organizations.getOrganizationSummaryTopAppliancesByUtilization(organization_id, quantity= 500, timespan = 2000)

print ('Number of MX Appliances = ' , len(response))
for mx in response:

print(mx['utilization'], mx['model'], mx['name'])

[Bobcheese2]

Bringing this back to life a little as I'm interested but was also researching something similar (not with MPLS though). I was wondering if the issue was actually to do with something similar I've seen when tunneling wireless traffic over MPLS, which turned out to be an MTU issue & fragmentation. Essentially the MTU size on the Wi-Fi controller needed to be reduced to allow for the MPLS headers that get added at transmission. Without this it caused fragmentation and essentially made the network unusable. Dropping the MTU for the tunnel made all the difference. I'm not saying this is the issue just that it is worth consideration as I know SMB v2 has some options for large MTU

[anfare]

Just FYI: our setup is entirely hard-wired. No WiFi at all (we have wifi and allow users to use it but it is on an isolated network inaccessible to the work LAN where Meraki etc. lives).

Appreciate the input, though. Still have not found a solution unfortunately. We are still limping along with the SD-Wan users using Remote Desktop Session Host for this particular work.

This whole experience really has been like a terrible nightmare all around. What was supposed to save me time and frustration (paying a 3rd party like ATT to provide this service) has turned out to be the exact opposite. Triple the time wasted, quadruple the frustration, and we're left off worse off than we were before we signed up.

[Bobcheese2]

You may be missing my point. I wasn't saying it was Wi-Fi, my point is that the Wi-Fi traffic was tunneled across the MPLS. The procedure of tunneling it added additional headers to the packet that were compounded by the additional headers added during transmission over the MPLS. All this meant the packets needed to be fragmented to be transmitted and that is what caused the degradation in service. Reducing the MTU from the Wi-Fi (hence pre-MPLS transmission) kept the packet size smaller which = no fragmentation.

The reason for the comparison is that SD-WAN is essentially a VPN which is in turn a tunnel. Therefore (in my head at least) the reason it doesnt happen when just using MPLS vs using SD-WAN over MPLS could be because fragmentation is happening in the same way it did for my Wi-Fi tunneling issue.

[Bobcheese2]

Here's a good doc on it and point 5 is what im referring to really https://documentation.meraki.com/General_Administration/Tools_and_Troubleshooting/Troubleshooting_MTU_Issues

[anfare]

Ah, got it, sorry about that, this topic makes my brain melt.

Unfortunately I haven't had much time to mess around with the whole setup but I did plenty of messing around with the MTU on the SD-Wan problem. As soon as I can start playing around with the MPLS line to do some research, I will check MTU out first. That said, I thought MPLS operated on a different layer that shouldn't be impacted by a given MTU?

Also In case it wasn't clear, the reason we went ahead and got the the MPLS line was as a replacement for the SD-Wan connection--not planning on using SD-Wan at all if we can get the MPLS line to work efficiently.

[Bobcheese2]

The way I read it was that you were using the MPLS but passing SD-WAN over the MPLS line, which was what lead me to my comments on MTU.

To be clear, the similar issue I was referring to, the MTU was adjusted on the network devices (in your case it would be the MX i guess) I did not alter any MTU settings on the MPLS router as this is all pre-MPLS encapsulation.

[anfare]

Sorry for the confusion...yeah, no SD-Wan needed if I can get the MPLS line working. Honestly don't care which, I just need the stuff to function. Being capped at ~5MB/s really causes users to get frustrated. The RDSH solution I setup as a stop-gap is better, but still not as stable as it should be.