Squid_ The Definitive Guide - Duane Wessels [93]
By default, Squid logs all ICP queries (but not responses) to access.log. If you have a lot of busy neighbors, your log file may become too large to manage. Use the log_icp_queries directive to prevent logging of these queries. Although you'll lose the detailed logging for ICP, you can still get some aggregate stats via the cache manager (see Section 14.2.1.24).
If you have sibling neighbors, you'll probably want to use the miss_access directive to enforce the relationship. It specifies an access rule for cache misses. It is similar to http_access but is checked only for requests that must be forwarded. The default rule is to allow all cache misses. Unless you add some miss_access rules, any sibling cache can become a child cache and forward cache misses through your network connection, thus stealing your bandwidth.
Your miss_access rules can be relatively simple. Don't forget to include your local clients (i.e., web browsers) as well. Here's a simple example:
acl Browsers src 10.9.0.0/16
acl Child1 src 172.16.3.4
acl Child2 src 192.168.2.0/24
acl All src 0/0
miss_access allow Browsers
miss_access allow Child1
miss_access allow Child2
miss_access deny All
Note that I haven't listed any siblings here. The child caches are allowed to request misses through us, but the siblings are not. Their cache miss requests are denied by the deny All rule.
The icp_hit_stale directive
One of the problems with ICP is that it returns ICP_MISS for cached but stale responses. This is true even if the response is stale, but valid (such that a validation request returns "not modified"). Consider a simple hierarchy with a child and two parent caches. An object is cached by one parent but not the other. The cached response is stale, but unchanged, and needs validation. The child's ICP query results in two ICP_MISS replies. Not knowing that the stale response exists in the first parent, the child forwards its request to the second parent. Now the object is stored in both parents, wasting resources.
You might find the icp_hit_stale directive useful in this situation. It tells Squid to return an ICP_HIT for any cached object, even if it is stale. This is perfectly safe for parent relationships but can create problems for siblings.
Recall that in a sibling relationship, the client cache is only allowed to make requests that are cache hits. Enabling the icp_hit_stale directive increases the number of false hits because Squid must validate the stale responses. Squid normally handles false hits by adding the Cache-Control: only-if-cached directive to HTTP requests sent to siblings. If the sibling can't satisfy the HTTP request as a cache hit, it returns an HTTP 504 (Gateway Timeout) message instead. When Squid receives the 504 response, it forwards the request again, but only to a parent or the origin server.
It makes little sense to enable icp_hit_stale for sibling relationships if all the false hits must be reforwarded. This is where the ICP client's allow-miss option to cache_peer becomes useful. When the allow-miss option is set, Squid omits the only-if-cached directive in HTTP requests it sends to siblings.
If you enable icp_hit_stale, you also need to make sure that miss_access doesn't deny cache-miss requests from siblings. Unfortunately, there is no way to make Squid allow only cache-misses for cached, stale objects. Allowing cache misses for siblings also leaves your cache open to potential abuse. The administrator of the sibling cache may change it to a parent relationship without your knowledge or permission.
The ICP_MISS_NOFETCH feature
The