Re: [squid-users] do I have peering configured correctly?

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Fri, 10 Dec 2010 02:23:08 +1300

On 09/12/10 15:07, Rich Rauenzahn wrote:
> I'm not convinced I have peering configured correctly. Here is my environment:
>
> These are internal specialized squid servers for serving internal web
> sites/deliverables. The main squid server at corporate is intended to
> accelerate a few sites. At corporate, we have 4 squid servers fronted
> by haproxy to load balance them.
>
> We have ACL's setup so that by default everything goes to the download
> web servers, but a few specific url's get proxied to some other
> servers. What I'm unsure about is whether the ACL's are preventing
> the cache_peer squid1-4 directives from being actually used...

Another check is to grep your access.log for those paths and see which
peer(s) are being used as source.

>
> http_port 80 defaultsite=squid
> http_port 8081 defaultsite=squid
> icp_port 3130
>
> cache_peer download1 parent 80 0 no-query originserver name=download1
> round-robin connect-fail-limit=1
> cache_peer download2 parent 80 0 no-query originserver name=download2
> round-robin connect-fail-limit=1
> cache_peer download3 parent 80 0 no-query originserver name=download3
> round-robin connect-fail-limit=1
>
> cache_peer maven-repo parent 8081 0 no-query originserver name=mavenrepo
>
> cache_peer foo parent 80 0 no-query originserver name=foo
>
> cache_peer squid1 sibling 80 3130 proxy-only name=squid1
> cache_peer squid2 sibling 80 3130 proxy-only name=squid2
> cache_peer squid3 sibling 80 3130 proxy-only name=squid3
> cache_peer squid4 sibling 80 3130 proxy-only name=squid4
>
> http_access allow all
>
> acl mavenpath urlpath_regex ^/artifactory
> acl mavenpath urlpath_regex ^/nexus
> acl mavenport myport 8081
> acl foopath urlpath_regex ^/foo-packages
>
> cache_peer_access download1 deny mavenport
> cache_peer_access download2 deny mavenport
> cache_peer_access download3 deny mavenport

The ones above are _possibly_ not working. myport and myip are not
reliable outside of forward-proxy mode.
  If you find errors with this match use a name= option on the http_port
line and myportname ACL.

>
> cache_peer_access download1 deny mavenpath
> cache_peer_access download2 deny mavenpath
> cache_peer_access download3 deny mavenpath
>
> cache_peer_access download1 deny foopath
> cache_peer_access download2 deny foopath
> cache_peer_access download3 deny foopath
>
>
> # Only allow mavenpath and maven port to go to maven

? the access lines below actually allow mavenpath OR mavenport...
to require AND conditions place them on the same line.

> cache_peer_access mavenrepo allow mavenpath
> cache_peer_access mavenrepo allow mavenport
> cache_peer_access mavenrepo deny all
>
> # Only allow foopath to go to foo
> cache_peer_access foo allow foopath
> cache_peer_access foo deny all
>
> We have another setup for remote sites that have their own squid
> server. Currently these point to the download servers at corporate,
> but I'd also like them to peer with the four squid servers configured
> as above. This is what I currently have:
>
> http_port 3128 defaultsite=squid
> http_port 80 defaultsite=squid
> http_port 8081 defaultsite=squid
> # download is actually a round robin dns for download1,2,3
> cache_peer download parent 80 0 no-query originserver name=download
> cache_peer maven-repo parent 8081 0 no-query originserver name=mavenrepo
> visible_hostname squid
>
> cache_peer squid1 sibling 80 3130 name=squid1
> cache_peer squid2 sibling 80 3130 name=squid2
> cache_peer squid3 sibling 80 3130 name=squid3
> cache_peer squid4 sibling 80 3130 name=squid4
>
> acl all src 0.0.0.0/0.0.0.0
> http_access allow all
>
> acl maven urlpath_regex ^/artifactory ^/nexus
> acl mavenport myport 8081
> cache_peer_access download deny maven
> cache_peer_access download deny mavenport
> cache_peer_access mavenrepo allow maven
> cache_peer_access mavenrepo allow mavenport
> cache_peer_access mavenrepo deny all
>
> What I'm concerned about is that when I tested a remote server I
> couldn't find evidence of it peering with the corporate squid server
> to pull a file -- and I'm wondering if my ACL's are somehow preventing
> the sibling peer relationship from being used for 'download'

There are no specific access lines for the siblings in either config. So
they will be used if they have the needed content.

The siblings will be ignored if...
  the content is already in the remote cache.
  Or if they reply to an ICP query indicating they don't already have
the object needed.
  Or if they don't reply to ICP at all.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.9
   Beta testers wanted for 3.2.0.3
Received on Thu Dec 09 2010 - 13:23:18 MST

This archive was generated by hypermail 2.2.0 : Thu Dec 09 2010 - 12:00:02 MST