[squid-users] "NF getsockopt(SO_ORIGINAL_DST)" filling cache.log due to AWS ELB healthchecks
squid3 at treenet.co.nz
Thu Oct 29 20:19:12 UTC 2015
On 30/10/2015 8:39 a.m., John Smith wrote:
> Hi Eliezer,
> It is entirely possible that haproxy is a better solution than squid for
> what we are doing.
> I have never used either solution, and inherited this 'working' squid
> configuration with the task of cleaning things up and stabilizing it.
> Regarding your question of 'How do the first layer of proxies send their
> request to the second layer of proxies?', all I can tell you is that all
> the work is done in the squid.conf, and I've posted the entire contents
> with a few replacements for security reasons.
The LB is the first layer.
Squid is the second layer.
The cache_peer Squid is relaying on to are a third.
The hierarchy is thus:
clients --(?1?)--> LB --(?2?)--> Squid --(HTTP)--> peer(s)
The "?1?" and "?2" parts are what we need to figure out.
How are the clients messages getting to the LB?
a) is it published in DNS as the host of some domain and clients making
requests directly from it that need to be serviced by the proxies you
are wrangling with?
b) are the clients outboung traffic being intercepted/diverted in their
travels to some other server and sent through the LB instead?
How is the load blancer then relying the TCP connections and HTTP
messages inside them to Squid?
A) Is it using NAT to change both dst-IP and dst-port on the TCP packets?
B) Is it terminating the TCP connection from clients, opening one to
Squid and relaying the HTTP inside based on URL hostnames etc. ?
C) Is it opening a L2 tunnel and relaying the TCP packets to the Squid
> As I've said, I've removed the word 'intercept' several times and the
> requests to secondary proxies no longer work.
> I just confirmed this behaviour again.
> If this is as 'quiet' as I can make the logs then it is what it is.
"getsockopt(SO_ORIGINAL_DST) failed ...: (92) Protocol not available"
Should never happen in a working proxy. Ever.
It can appear because a) the NAT tables in the Squid machine kernel are
overflowing, or b) the external network is configured in a broken way.
Both are really bad scenarios. Your are having the (b) problem.
More information about the squid-users