[squid-users] Strange Interaction between Squid and Facebook

[Patrick Blair - Peapod]

Hi Eliezer,

Thanks for your response.

I have set up a VM to test out configurations in the same data center and
address space as the problematic one.
What I haven't done is test it by rebuilding the squid configuration from
the defaults up and trying to use the same IP, that will probably be what
I'll try tomorrow.

Also, thanks for the tip on the CARP example. I was trying to find a
configuration that took advantage of SMP, but I see how that complicates
things further.

Thanks so much for the suggestions! I'll update this thread further if
things start working a bit better.
And thank you again for packaging newer squid versions for CentOS!

Pat Blair
Sr. Unix Administrator
Peapod, LLC
pblair at peapod.com
On Oct 29, 2015 21:09, "Eliezer Croitoru" <eliezer at ngtech.co.il> wrote:

> Hey Patrick,
>
> Thanks for clearing the picture out.
> Since it's HTTPS traffic it will might be a bit difficult to debug.
>
> I wanted to notify you that squid 3.5.10 is suffering from some bugs but
> it is very hard for me to actually find this specific issue meet any of the
> know bugs else then one bug(something with ssl-bump).
>
> One thing I can think of in this scenario in order to maybe somehow change
> how things are would be to use a second proxy just for the test.
> If you can run another proxy on a tiny VM with another IP on the same DC
> as the existing one it would narrow down couple things.
> If it works OK with squid default conf file then try to assign the IP of
> the problematic proxy to the new one.
> If it works with the same IP it's an issue with something in the proxy
> setup or the conf.
>
>
> Another approach would be to use the secondary DC proxy as a cache_peer of
> the primary DC proxy to verify if it affects the traffic in a similar way.
>
> --
> In the first post you have mentioned this link:
> http://wiki.squid-cache.org/ConfigExamples/SmpCarpCluster
>
> This specific example was intended for caching optimization or something
> similar.
> Since your case involves CONNECT requests which cannot be cached anyway
> and also this CARP has certain limitations I would first try to simplify
> the setup into a no-disk RAM only cache with couple workers rather then
> multi workers peering.
> The CARP example actually limits the whole service to the frontend
> capabilities and there for it's recommended to not use it if possible.
> Try a default squid.conf if possible.
>
> Since the issue can be reproduced very easily testing the different
> options will take couple minutes and can be done after work hours.
>
> The above options is what I would have tried with my own servers.
>
> Eliezer
>
> On 30/10/2015 01:17, Patrick Blair - Peapod wrote:
>
>> It is very unclear, our network team is trying to determine if a
>> network issue may be in play, but we believe that is unlikely...
>>
>> I couldn't understand how you ran the tests.
>>
>>> >I do understand that you have two proxies and one is peering to the
>>> >other, right?
>>>
>> Apologies if that wasn't clear, I'll try to give a better explanation:
>>
>>     - There is always one proxy in this situation.
>>     - The difference is that we run the proxy out of our secondary
>>     datacenter and route all user internet traffic through that location
>> so it
>>     doesn't cause any issues with the traffic to our website flowing in
>> and out
>>     of our primary datacenter.
>>     - A test instance I used to recreate the squid instance that is having
>>     the issues with, works as expected in our primary datacenter,
>> however, the
>>     older version of squid we were using is located in the secondary
>> datacenter
>>     and also works as expected, only the newer version doesn't work.
>>
>>
>> Thanks for your help!
>>
>> Pat Blair
>> Sr. Unix Administrator
>> Peapod, LLC
>> pblair at peapod.com
>>
>
>

-- 
This email and any attachments may contain information that is proprietary,
confidential and/or privileged and for the sole use of the intended 
recipients(s)
only.
If you are not the intended recipient, please notify the sender by return
email and delete all copies of this email and any attachments. Ahold and/or 
its
subsidiaries shall neither be liable for the inaccurate or incomplete 
transmission
of the information contained in this email or any attachments, nor for any 
delay
in its receipt. To the extent this email is intended to create any legal 
obligation,
the obligation shall bind only the contracting entity and not any other 
entity within
the Ahold Group.

-- 
This email and any attachments may contain information that is proprietary,
confidential and/or privileged and for the sole use of the intended 
recipients(s)
only.
If you are not the intended recipient, please notify the sender by return
email and delete all copies of this email and any attachments. Ahold and/or 
its
subsidiaries shall neither be liable for the inaccurate or incomplete 
transmission
of the information contained in this email or any attachments, nor for any 
delay
in its receipt. To the extent this email is intended to create any legal 
obligation,
the obligation shall bind only the contracting entity and not any other 
entity within
the Ahold Group.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20151029/0441dfe1/attachment.html>