Slow browsing when enabling content filtering

[kjellover]

When enabling content filtering on a MX100 (MX 18.107.10) the users complain about very slow browsing. It is almost useless.

I found some other complaining about this, but no real solution (as far as I can see). Without the filtering the utilization is between 10-65% and normally not more than 120 Mb/s download.

Is there any solution to this?

[RWelch]

What all categories are you selecting/using?  That might be part of the issue.

[kjellover]

I have tried both enabling several and only one (Pornography). There is no difference.

The same applies when eanbling one or more threat categories.

[RWelch]

Without knowing more details about your network/setup/configuration it would be mere speculation on our part.

Maybe the troubleshooting link below can be of help to you.

Content Filtering Troubleshooting 

[RWelch]

MX Sizing Guide & Principles  

[RWelch]

How many devices (clients/users) does your MX support?  
Have you set your WAN uplink bandwidth limits to what your ISP provides?  
What is the global bandwidth per user set at?  

Those would be the things I would tend to look at first because it's causing such a slow browsing experience.  

[kjellover]

The MX100 has a recommended limit of 500 users. During the time period we tested the filtering there was approx 350 unique clients, but the usage peaked at 70 Mbit/s. That is far from the stated 650 Mbit/s with  Advanced security Throughput. Anyway, the number of users should not be a problem. What matters is the number og concurrent sessions and the throughput at the given tim.

The WAN uplink is set to the speed offered by our ISP provider. Each client does not have any limit.

We only experience the lag when the content filtering is enabled. I don't find any place to view the usage in real time, but in the summary report it is not over 60% during these tests. We have 6-7 VPN site-to site connections.

With these numbers the MX should not be over-utilized, but could it be anyway?

[RWelch]

If every user/device has NO limit and you have 350ish clients, that very well could be the problem itself since they are unrestricted/unregulated.

Have you tried to set a global bandwidth per user to see if it has any improvement?

When you say 350 unique clients...is that counting the 6-7 VPN site to site connections or is that in addition to the 350 unique clients?

[kjellover]

The 350 clients is during the whole day, not concurrent. The normal bandwith utilization is normally approx. 25 Mbit/s with som peaks racing 100-120. That is far from tha capacity of the MX and I can't see why it should be needed to use limitations/quota for the clients.

I guess that the MX sees one VPN-connection as one client, but I am not sure about that. There is not much traffic going there anyways

[BlakeRichardson]

How many client devices is the MX supporting, it sounds like it's being over utilised. 

Do you have any site to site or client VPN connections? 

[Caleb-Engle]

Hi @kjellover,

It might not be related, however, there are situations in which having the incorrect tracking method configured AND enabling content filtering can result in issues with HTTP/HTTPS traffic, which may manifest as slow web browsing.

Do you have static routes configured on your MX appliance, and if so is your network's client tracking method set to MAC address? If it is, then try changing the tracking method to IP address (or Unique Client Identifier if it's a combined MX & MS network).

[kjellover]

There are local static routes for the vlans defined on the MX. The Client tracking mode is set to MAC address. We have some layer 3 Cisco switches that handles some routing for clients. I see from the description that the IP address mothod should be used for client tracking. However, that will require us to have a split network. I can not see why the browsing should be slower with this tracking method. That must be a bug or bad design.

Will the change of tracking method interrupt traffic in any way? Will it cause downtime and a need og reconfiguration?

[Caleb-Engle]

Hi @kjellover,

I my experience, splitting the network and changing the tracking method does not incur downtime. However, keep in mind that any client tracking data will be lost (including group policy mappings). 

https://documentation.meraki.com/MX/Monitoring_and_Reporting/Client-Tracking_Options#Configuring_Cli...

That being said, I am pretty confident that the tracking method is causing the issue based on your network's configuration. If this is a combined network with non-Meraki L3 switches, you would need to split the network and change to track by IP address. If you still have issues after that, let me know!

[kjellover]

Thank you. We will try this and see if it works.