: > 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
