Re: [squid-users] High load problem with a broken client (Nokia app)

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Thu, 20 Sep 2012 15:55:29 +1200

On 19/09/2012 7:04 p.m., Fran Márquez wrote:
> Hi friends,
>
> I have a weird problem of saturation due to a broken client and I don't
> know how fix it (I can force user to disable the app who cause the
> problem, but I think that should be a solution for avoid that a bad
> client can overload the server and affect to proxy service by itself).

Welcome to the real world. Software all has capacity limits. Someone is
performing a *DoS* on your proxy using an internal link with higher
capacity than your service software. What do you do about that?
  * close the hole (fix the app, disable it)
  * lower the clients service capacity (QoS limit them)
  * raise your software capacity (polish your squid.conf for
performance, and add a blacklist on that apps requests to reject then
with a 403 instead of 407)

... then re-evaluate whether they are a problem.

Hint: the faster your Squid responds the faster they will retry. Unless
you manage to get Squid response capacity to be greater than the load
facing it. Thus the QoS kind of appears to work even if it does not
solve anything.

> I have found a person who have same problem (here:
> http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-memory-issue-td3044458.html)
> but not solution is provide in that thread.
>
> The problem is that some Nokia application try to access to an URL, it
> receive 407 error and try again ad infinitum. This cause high load after
> few minutes and I need restart the squid/dansguardian services for
> restore the correct load of my server.
>
> This problem affect to snmp daemon (who works through squid to do some
> checks) and also cause NTLM auth problem.

Er. yes. Maybe NTLM is a large part of the real problem and this is a
side-effect?

Hint: if the NTLM auth helper is being contacted the client *is* sending
NTLM labeled credentials which need to be checked by it. The start 407
message of the NTLM handshake is just the proxy saying it supports NTLM.
A client which responded by re-trying without any credentials would
simply get the same response back with no load on the helper.

> Info about my proxy server:
> ---------------------------
>
> Centos 6.0
> Squid 3.1.10 (from base repository)
>
>
> Log fragment:
> ---------------------------------------------------------------------
> 1347861663.915 9 192.168.1.48 TCP_DENIED/407 4209 GET
> http://feeds.store.ovi.com/service/bannerrequest.ashx? - NONE/- text/html
> 1347861663.929 0 192.168.1.48 TCP_DENIED/407 3985 GET
> http://feeds.store.ovi.com/service/bannerrequest.ashx? - NONE/- text/html
> 1347861663.953 1 192.168.1.48 TCP_DENIED/407 4170 GET
> http://feeds.store.ovi.com/service/bannerrequest.ashx? - NONE/- text/html
> 1347861663.973 4 192.168.1.48 TCP_DENIED/407 4213 GET
> http://feeds.store.ovi.com/service/bannerrequest.ashx? - NONE/- text/html
> 1347861663.986 0 192.168.1.48 TCP_DENIED/407 3985 GET
> http://feeds.store.ovi.com/service/bannerrequest.ashx? - NONE/- text/html
> 1347861664.008 1 192.168.1.48 TCP_DENIED/407 4170 GET
> http://feeds.store.ovi.com/service/bannerrequest.ashx? - NONE/- text/html
> 1347861664.026 3 192.168.1.48 TCP_DENIED/407 4209 GET
> http://feeds.store.ovi.com/service/bannerrequest.ashx? - NONE/- text/html
> 1347861664.040 0 192.168.1.48 TCP_DENIED/407 3985 GET
> http://feeds.store.ovi.com/service/bannerrequest.ashx? - NONE/- text/html
> 1347861664.065 1 192.168.1.48 TCP_DENIED/407 4170 GET
> http://feeds.store.ovi.com/service/bannerrequest.ashx? - NONE/- text/html
> 1347861664.084 4 192.168.1.48 TCP_DENIED/407 4209 GET
> http://feeds.store.ovi.com/service/bannerrequest.ashx? - NONE/- text/html
> 1347861664.097 0 192.168.1.48 TCP_DENIED/407 3985 GET
> http://feeds.store.ovi.com/service/bannerrequest.ashx? - NONE/- text/html
> 1347861664.119 1 192.168.1.48 TCP_DENIED/407 4170 GET
> http://feeds.store.ovi.com/service/bannerrequest.ashx? - NONE/- text/html
> ---------------------------------------------------------------------
>
> Thank you very much,
> Regards
>
Received on Thu Sep 20 2012 - 03:55:41 MDT

This archive was generated by hypermail 2.2.0 : Tue Sep 25 2012 - 12:00:06 MDT