Traffic Shaping Advice

[dwash]

Hi there,

Here's a little background for context: 

I work in K-12 where I have a high school with around 3000 students and about 175 staff. We are a 1 to 1 district where students get Macbook Airs and staff gets Pros (and several shared laptops, desktops, ipads, etc). MacOS & VPP updates (Office/native apps/any volume license app) are getting larger and larger. We can control when MacOS system updates are pushed, but not VPP. Two days ago an update came out that was almost 4gb. So naturally, 3000+ devices tried to download once next connected to the internet, which is Monday morning on campus. We have been having major (timeouts, etc) slowness issues since then. Do we send notifications for students/staff to leave devices on and online at home?--yes. Do they do that? ---no. 

I see in the dashboard that majority of traffic has been coming from our caching servers (we have them on prem so egress isn't tapped out). The past 24 hrs, 2TB+. So, it's our internal network that's being tapped out (I believe on the AP level). I think creating a Traffic Shaping rule that lowers the priority of traffic from these caching servers would be the way to go. What do you think?

Network Setup: MR42 (avg 30-45 devices connected per AP/classroom)--> MS250--> MS425 --> Egress router

[ZeeBoussaid]

@dwash in the Meraki dashboard, go to Wireless-> Configure-> Firewall & Traffic Shaping. I think you can set rules and limit the bandwidth per SSID. under Default Rules you should see an option for Software update.

[cmr]

@dwash are your devices spread across both bands as it isn't recommended to have more that 30 devices per radio if you want decent performance?

[dwash]

No, we have band steering on so for the most part it's 95% 5ghz.

[cmr · Accepted solution]

@dwash might be worth disabling band steering, you'll get more throughout when heavily loaded as more client should go to 2.4GHz.  That is unless the 2.4 interference is terrible in your area?

[dwash]

@cmr Yes, 2.4 interference is a concern, but not to the point where I'm not willing to try turning it off and seeing what happens. Can't get any worse than what it has been this week lol. 

@DarrenOC I'm not sure about limiting caching server connected devices, BUT, I will definitely research this and send that over to our MDM person. 

[DarrenOC]

Hi @dwash ,

https://support.apple.com/en-gb/guide/mac-help/mchl9b56e1cf/mac

Could possibly restrict connections via IP ranges?

[DarrenOC]

Bit of a tricky one this as you literally want your users on the wifi/network to download the patch as quickly as possible and then get off again. So if you restrict or rate limit that traffic then the devices are going to be hogging airtime for longer whilst waiting for the patch to download.

[DarrenOC]

Are you able to limit the number of devices connecting to your caching server at any given point to conserve bandwidth?

[GIdenJoe]

I would start with trying to match that traffic as best as you can do.  If you can match on L3/4 info then great!

Then I'd start with putting that traffic in the background queue by using pcp tag 1 and DSCP marking CS1.

Also on your switches make sure CS1 is sent to CoS queue 0 for least bw treatment.  And if you really need you could restrict the bw of that flow on the AP per client but usually I let queuing take care of it instead of limiting bw.

[PhilipDAth]

Looking at this article:

https://discussions.apple.com/thread/7441955 

it looks like you can configure a specific port to be used for Apple caching.  If you did this, you could shape this port.

I think you would also need to enable "Wireless Client Isolation" on the WiFi network, otherwise, one WiFi attached device might try and get the update from another WiFi attached device (rather than your caching servers).

https://documentation.meraki.com/MR/Firewall_and_Traffic_Shaping/Wireless_Client_Isolation 

[dwash]

Thank you all for your suggestions! All of this has given me a very solid starting point!