Search squid archive

Re: Managing clusters of siblings (squid2.7)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



: > Couldn't the same thing be done with ACLs?  (deny icp/htcp from
: localhost)

: The problem is multi-stage loops:   proxyA->proxyB->proxyA which only shows
: up in the two headers.
: 
: The first-degree example I list above can be solved by ACL in icp_access,
: but when you go another level out into a mesh things get much more
: complicated unless pulling the data from those headers. So for example

Gotcha ... I didn't even realize that multi-stage queries was something 
squid would do with siblings.

But now you've got me scared: what prevents this from happening even 
with distinct configurations for each peer?

If the A, B, and C, have cache_peer sibling configs that look like this...

  A -> B, C
  B -> C, A
  C -> A, B

...what prevents an A->B->C->A ICP loop from happening right now?

: Multicast-ICP with all the siblings NOT relaying tests at all might be the
: best option for your current setup. Where peers simply get added to the
: multicast group and first responder to a broadcast query gets used.  You

Hmmm... i breifly considered multicast, and while it seemed like it might 
be a worthwhile network optimization (to reduce the number of packets on 
the wire) i hadn't done any checking to see if my network was supporting 
it because it didn't seem like it would actually simply the administration 
of clusters, particularly because of this line from the FAQ...

http://wiki.squid-cache.org/SquidFaq/MultiCast#Should_I_be_using_Multicast_ICP.3F
	Multicast does not simplify your Squid configuration file. 
	Every trusted neighbor cache must still be specified.

...but based on your comments, and reading a little closer, it seems like 
taht's mainly just a security issue (further down: "...it would be a bad 
idea to implicitly trust any ICP reply from an unknown address")  If squid 
is running in a private network, and only reachable by internal hosts, 
then there's probably little downside in accepting multicast-replies 
blindly.

which raises the question: how would you configure squid to do that?  Is 
putting a "multicast-responder" option on a "multicast" group cache-peer 
line supported?

Your comment about "first responder to a broadcast query gets used" is 
also a little concerning.  By "first responder" do you literally 
mean just the first server to respond to the multicast ICP request, even 
if it's a "MISS" ? ... or will squid not reply to a multicast query 
if it doesn't have a cached copy? 

(The situation i'm worried about is when squidB & squidC both recieve the 
same multicast ICP query from squidA and B replies first with a MISS 
before C can reply with a HIT ... would squidA ever pay attention to 
squidC's reply?)

: Or cache digest sharing, where all current peers indexes are already known
: and no query at all is made.

This would still require each peer to be cofigured to point to every other 
peer (except itself) correct? ... so this would just be a network i/o 
optimization, not an administration simplification.


-Hoss

[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux