Re: [squid-users] Managing clusters of siblings (squid2.7)

: > 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
Received on Thu Oct 01 2009 - 18:59:46 MDT