<font size=2 face="sans-serif">Thank you Amos, I was pretty brain drained
by the time I posted so please excuse my pasting slip up.</font>
<br>
<br><font size=2 face="sans-serif">I tried adding no-netdb-exchange
and no-digest to the cache_peer lines, the first one eliminated the forward
loop warnings but I am still experiencing the first request coming from
the cache and then subsequent requests going direct. Also I did disable
the tproxy port.</font>
<br>
<br><font size=2 face="sans-serif">I now suspect some sort of logic bug
in the code as is shows in the cache logs carp.cc is not called a second
time before peer_select.cc on the second attempt. Unfortunately my programming
skills are poor and have limited time to look at this issue.</font>
<br>
<br><font size=2 face="sans-serif">For now to work-around this behaviour
I will use the never_direct directive, but if you would like to investigate
further I have provided level 2 and 3 debug cache logs that you could look
at.</font>
<br><a href="https://droplet-wlg.solnetsolutions.co.nz/public.php?service=files&t=8a3b73eff46a9cf1a91829c0b9d0016a"><font size=2 color=blue face="sans-serif">https://droplet-wlg.solnetsolutions.co.nz/public.php?service=files&t=8a3b73eff46a9cf1a91829c0b9d0016a</font></a>
<br>
<br><font size=2 face="sans-serif">Cheers</font>
<br>
<br><font size=2 color=#0000a1 face="Verdana"><b>Mike Hodgkinson</b></font>
<br><font size=2 color=#4f4f4f face="Verdana"><b>Internal Support Engineer</b></font>
<br>
<br><font size=2 color=#4f4f4f face="Verdana">Mobile +64 21 754 339</font>
<br><font size=2 color=#4f4f4f face="Verdana">Phone +64 4 462 5064</font>
<br><font size=2 color=#4f4f4f face="Verdana">Email mike.hodgkinson@solnet.co.nz</font>
<br>
<br><font size=2 color=#4f4f4f face="Verdana"><b>Solnet Solutions Limited</b><br>
Level 12, Solnet House</font>
<br><font size=2 color=#4f4f4f face="Verdana">70 The Terrace, Wellington
6011<br>
PO Box 397, Wellington 6140</font>
<br>
<br><a href=http://www.solnet.co.nz/ target=blank><font size=2 color=#0000a1 face="Verdana"><b>www.solnet.co.nz</b></font></a><font size=2 color=#a2a2a2 face="Verdana"> </font>
<br>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Amos Jeffries <squid3@treenet.co.nz></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">30/10/2015 11:03 p.m.</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [squid-users]
Squid with SMP, CARP and a forwarding loop</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">"squid-users"
<squid-users-bounces@lists.squid-cache.org></font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>On 30/10/2015 1:45 p.m., Mike.Hodgkinson wrote:<br>
> I have been attempting to setup a squid forward proxy with one frontend
<br>
> and two backends as per configuration example <br>
> </font></tt><a href="http://wiki.squid-cache.org/ConfigExamples/SmpCarpCluster"><tt><font size=2>http://wiki.squid-cache.org/ConfigExamples/SmpCarpCluster</font></tt></a><tt><font size=2><br>
> <br>
> My issue is that only the first attempt comes from the cache and then
<br>
> additional requests are downloaded direct by the frontend instead
of from <br>
> the backend caches. I suspect it is due to a detected forwarding loop
<br>
> which shows up in the logs:<br>
> <br>
> 2015/10/30 13:07:49.239 kid1| 44,3| peer_select.cc(137) peerSelect:
<br>
> e:=XIWV/0x7f7bfee2e730*2 </font></tt><a href=http://127.0.0.1:40/><tt><font size=2>http://127.0.0.1:40</font></tt></a><tt><font size=2><br>
> 02/squid-internal-dynamic/netdb<br>
> 2015/10/30 13:07:49.239 kid1| 20,3| store.cc(466) lock: peerSelect
locked <br>
> key 64AAA11C8DEF57153B10BA2C9D2F3D60 e:=XIWV/0x7f7bfee2e730*3<br>
> 2015/10/30 13:07:49.240 kid1| 44,3| peer_select.cc(441) peerSelectFoo:
GET <br>
> 127.0.0.1<br>
> 2015/10/30 13:07:49.240 kid1| 44,3| peer_select.cc(468) peerSelectFoo:
<br>
> peerSelectFoo: direct = DIRECT_YES (forwarding loop detected)<br>
> 2015/10/30 13:07:49.240 kid1| 44,3| peer_select.cc(477) peerSelectFoo:
<br>
> peerSelectFoo: direct = DIRECT_YES<br>
> 2015/10/30 13:07:49.240 kid1| 44,2| peer_select.cc(258) <br>
> peerSelectDnsPaths: Find IP destination for: <br>
> </font></tt><a href="http://127.0.0.1:4002/squid-internal-dynamic/netdb'"><tt><font size=2>http://127.0.0.1:4002/squid-internal-dynamic/netdb'</font></tt></a><tt><font size=2>
via 127.0.0.1<br>
> <br>
> I can force the backend caches to be used successfully with this option
<br>
> "never_direct allow all" however I would like to resolve
the underlying <br>
> issue.<br>
<br>
The above is an internal Squid request from the fontend to its backends.<br>
This one specifically is going direct due to a hack in the code.<br>
<br>
You can avoid it by adding "no-netdb-exchange" to the cache_peer
lines.<br>
I'm not sure if that will affect the CARP selection since these requests<br>
are one of the types feeding into the peer up/down/overloaded<br>
monitoring. With "no-query" also in use you will be left with
the client<br>
HTTP traffic being the only source of that data which carp depends on.<br>
<br>
Or using that "never_direct allow all" will override that code
hack.<br>
<br>
> <br>
> I have no iptables configured on this server and have made sure the
<br>
> environment variable http_proxy is not set. Also I have tested this
on <br>
> Squid 3.4.8 and 3.5.10 on Debian.<br>
<br>
Since you have no iptables rules configured the traffic arriving in port<br>
3129 will be completely borked.<br>
<br>
Either, remove that port 3129 line from the frontend config and use port<br>
3128 for testing until you are ready to setup TPROXY properly;<br>
<br>
Or, setup the TPROXY iptables and routing rules and test the proxy<br>
exactly as the clients would be using it.<br>
<br>
<br>
> <br>
> My config is below:<br>
> #/etc/squid/squid.conf#<br>
> debug_options = ALL,3<br>
> cachemgr_passwd ******<br>
<br>
NOTE: if that was your actual password you now need to change it.<br>
<br>
> acl localnet src 10.1.0.0/16<br>
> acl localnet src 10.2.0.0/16<br>
> acl localnet src 192.168.0.0/23<br>
> acl localnet src fe80::/10<br>
> acl squid_servers src 10.1.209.0/24<br>
<br>
See below...<br>
<br>
<snip><br>
> #/etc/squid/squid-frontend.conf#<br>
> http_port 3128<br>
> http_port 3129 tproxy<br>
> http_access allow localhost manager<br>
> http_access deny manager<br>
> http_access allow localhost<br>
> http_access allow localnet<br>
> http_access allow squid_servers<br>
<br>
With squid_servers IP range being entirely within "localnet"
this<br>
"http_access allow squid_servers" line is not doing anything.<br>
You can simplify by removing it.<br>
<br>
<br>
> htcp_access allow squid_servers<br>
> htcp_access deny all<br>
> cache_peer 127.0.0.1 parent 4002 0 carp login=PASS name=backend-kid2
<br>
> no-query<br>
> cache_peer 127.0.0.1 parent 4003 0 carp login=PASS name=backend-kid3
<br>
> no-query<br>
> prefer_direct off<br>
> nonhierarchical_direct off<br>
> memory_replacement_policy heap LRU<br>
> cache_mem 2048 MB<br>
> access_log /var/log/squid3/frontend.access.log<br>
> cache_log /var/log/squid3/frontend.cache.log<br>
> visible_hostname frontend.cloud.solnet.nz<br>
> <br>
> #/etc/squid/squid-backend.conf#<br>
> http_port 127.0.01:400${process_number}<br>
> http_access allow localhost<br>
> cache_mem 5 MB<br>
> cache_replacement_policy heap LFUDA<br>
> maximum_object_size 1 GB<br>
> cache_dir rock /cache/rock 20480 max-size=32768<br>
> cache_dir aufs /cache/${process_number} 20480 128 128 min-size=32769<br>
> visible_hostname backend${process_number}.cloud.solnet.nz<br>
> access_log /var/log/squid3/backend${process_number}.access.log<br>
> cache_log /var/log/squid3/backend${process_number}.cache.log<br>
> <br>
> I did have visible_hostname set to backend.cloud.solnet.nz but that
did <br>
> not help either.<br>
<br>
Nod. All that did previously was prevent forwarding loops between the<br>
backends in case something unusually nasty happened in the<br>
routing/iptabels layers. What you have now is okay and slightly better<br>
for diagnosing the issues.<br>
<br>
<br>
Amos<br>
_______________________________________________<br>
squid-users mailing list<br>
squid-users@lists.squid-cache.org<br>
</font></tt><a href="http://lists.squid-cache.org/listinfo/squid-users"><tt><font size=2>http://lists.squid-cache.org/listinfo/squid-users</font></tt></a><tt><font size=2><br>
</font></tt>
<br>Attention:
This email may contain information intended for the sole use of
the original recipient. Please respect this when sharing or
disclosing this email's contents with any third party. If you
believe you have received this email in error, please delete it
and notify the sender or postmaster@solnetsolutions.co.nz as
soon as possible. The content of this email does not necessarily
reflect the views of Solnet Solutions Ltd.