Traffic shaping not working

[smccloud]

I have configured traffic shaping to prioritize our Backblaze B2 cloud backup lower than everything and our client VPN higher than everything else.  However, even when I limit the bandwidth down to 500 Kbps for the Backblaze traffic it doesn't matter.  I have rebooted the clients sending data to Backblaze as well as the MX64 and it doesn't do anything to limit the traffic.  Does anyone have any ideas on what I have done wrong?

[jdsilva]

Looks right to me. Perhaps the Meraki application definition is out of date? I'd say a call to support is in order.

[smccloud]

It was support that had me set it up that way.  I also tried the IPs listed at https://help.backblaze.com/hc/en-us/articles/217664588-Backblaze-IP-Address-List (can't do *.backblaze.com and *.backblazeb2.com :()

[smccloud]

Did some more definition work, included the subnets for Backblaze and it still doesn't work.uploading at well above 500 Kbps 😞

[NolanHerring]

Traffic shaping policies perform the rules in the order to which they appear, top down. Like firewall rules.

Move Rule #2 up so it becomes Rule #1 and try again.

[smccloud]

Rule order changed, same thing is still happening.  I am also making sure to stop all uploads before I made the rule changes to they are new flows when everything starts.

[OCT_OMG]

Have you tried disabling the default traffic shaping rules and entering a custom expression for the hostnames backblaze.com and backblazeb2.com (without the *.wildcard)?

[MacuserJim]

Do you happen to have any group polices applied to that that client in particular that might override the network wide settings? Also when viewing the client list in the Meraki dashboard and hovering over that client what does the dashboard report for historical traffic usage?

[smccloud]

We do not have any group policies defined at all. If I can accomplish what I want to that way, I can look there too.  Unfortunately, the machines I have uploading to Backblaze do not show up in the clients list.  Not sure if its due to how our network is setup (VLAN1 runs to a HP ProCurve which then does the rest of the VLANs, and VLAN 20 is a DMZ vlan which runs to a dumb switch).

[MacuserJim]

If the clients are not showing up in the MX client list then I would be a little concerned. That makes me think it is not actually passing traffic through the MX. Would it be possible to plug one of the clients directly into the MX for a little bit and observe to see if it follows the traffic shaping rule then?

[smccloud]

Not easily, I inherited the network design here (and I hate it).  The subnet between the MX64 and ProCurve is different than the subnet between the ProCurve and the rest of the network.  However, I am 100% sure all traffic goes through the MX64, since we have a single connection and it is our only security device.  All client traffic shows as coming from our ProCurve.  I suppose I need to figure out how to get the MX64 to see individual client traffic coming through it.

[jdsilva]

@MacuserJim Nah, I don't think there's a big concern from the description.

---

@smccloud wrote:

We do not have any group policies defined at all. If I can accomplish what I want to that way, I can look there too.  Unfortunately, the machines I have uploading to Backblaze do not show up in the clients list.  Not sure if its due to how our network is setup (VLAN1 runs to a HP ProCurve which then does the rest of the VLANs, and VLAN 20 is a DMZ vlan which runs to a dumb switch).

---

I take that to mean that the ProCurve is the gateway for those VLANs, meaning the MX doesn't see the MACs of the clients, only the IP's @smccloud likely just needs to change the Client Tracking setting on the MX. 

Unless I'm interpreting that incorrectly?

[smccloud]

Correct, the ProCurve is the gateway for the VLANs.  I just changed client tracking to IP, but I had to split my network first. 

[jdsilva]

@smccloud Ugh! I didn't realize that was a limitation. Thinking about it though, I understand it, but I certainly don't like it.

So if this is important to you, then you're going to have to split out the MX into it's own network. You can do this from the Organization overview page. check the checkbox for the combined network, and the hit the "Split Networks" button at the top. 

BIG FAT DISCLAIMER: I've never actually done this myself, but I know others who have. It might be best for you to test it on a dummy network first, or in a change window . 

Edit: Haha you removed the picture. But I did see it 🙂

[smccloud]

---

@jdsilva wrote:

@smccloud Ugh! I didn't realize that was a limitation. Thinking about it though, I understand it, but I certainly don't like it.

So if this is important to you, then you're going to have to split out the MX into it's own network. You can do this from the Organization overview page. check the checkbox for the combined network, and the hit the "Split Networks" button at the top. 

BIG FAT DISCLAIMER: I've never actually done this myself, but I know others who have. It might be best for you to test it on a dummy network first, or in a change window . 

---

Only major loss was no clients for a while.  Now to see if it shows up properly and is limited.  It appears to let it run at whatever speed it can for a while, then stops it, then lets it work again.  Is this right?

[smccloud]

Part of the issue could have been some one fat fingered the IP for our client VPN too......