Re: [squid-users] Question on sibling relationships

Hi,

On Thu, 19 Sep 2002, Gino LV. Ledesma wrote:

> Hi,
>
> I'd like to clarify how squid accesses the Internet when its
> part of a hierarchy. I've read the Squid config guides and FAQ and it
> doesn't directly address the questions. If a proxy is part of a
> hierarchy, say it has some siblings and a parent, how does that
> particular proxy handle a network error when, say, its link to its
> parent dies, but the link toward its siblings (and assuming its
> siblings connection to the internet is ok) is ok? Does the proxy then
> proxy requests through its siblings? I know that the proxy queries its
> siblings before its parent, and it only queries the parent if its
> siblings do not return the object requested.
>
> This is the scenario I'm facing. The proxy cluster is configured
> as follows:
>
> ISP1 ISP2 ISP3
> | | |
> | | |
> +-+-+ +-+-+ +-+-+
> | A |--sibling--| B |--sibling--| C |
> +-+-+ +---+ +-+-+
> | |
> +------------sibling------------+
>
> The problem I'd like to (or have to) address is that, if one of
> the proxies's direct connection is for some reason unavailable, the
> proxy must be able to be "functional" by querying its siblings. I
> guess in a longer term, is it possible for squid to be configured to
> dynamically adapt to its network connections?

Methinks you have some conflicting requirements. If you make the
relationships "parent" instead of "sibling" you should be able to do the
following as described in squid.conf:

# By combining nonhierarchical_direct off and prefer_direct on you
# can set up Squid to use a parent as a backup path if going direct
# fails.

However by changing the relationships to parent and using "prefer_direct
on" you lose the caching of the siblings. You might be able to get around
this by using "neighbour_type_domain":

# TAG: neighbor_type_domain
# usage: neighbor_type_domain parent|sibling domain domain ...
#
# Modifying the neighbor type for specific domains is now
# possible. You can treat some domains differently than the the
# default neighbor type specified on the 'cache_peer' line.
# Normally it should only be necessary to list domains which
# should be treated differently because the default neighbor type
# applies for hostnames which do not match domains listed here.
#
#EXAMPLE:
# cache_peer parent cache.foo.org 3128 3130
# neighbor_type_domain cache.foo.org sibling .com .net
# neighbor_type_domain cache.foo.org sibling .au .de

I guess it's a case of suck it and see with this.

Colin
Received on Thu Sep 19 2002 - 17:31:45 MDT