Re: FORWARDING ERROR

On Tue, 8 Dec 1998, Henrik Nordstrom wrote:

> P.RAJARAM wrote:
>
> > the cache will not beforward your request because it is trying to
> > enforce a sibling relationship.perhaps the client at 192.168.1.xx
> > is a cache which has been misconfigured
>
> This means that you have configured a sibling as a parent, and that this
> sibling (which your Squid thinks is a parent) does not allow miss_access
> to you.

Henrik - I don't think this is 100% correct; I have a number of siblings
configured, and one of them returned this *exact* error at one point. I
stress, they were definitely *siblings* in the config not parents.

To this day I've been wondering why it happened (and hasn't happened since)
and I think I've just hit the reason (and I'd appreciate your, or anyone
else's for that matter, comment/correction).

If for some reason Squid can't access the originating site directly (perhaps
the link to the Internet is down, reporting "no route to host" or similar), it
decides that its siblings are really *parents*. Until Squid convinces itself
that it can access sites directly again, it sticks in this state (and will of
course strike the above error).

If multiple organisations are sharing a single link to the Internet (which is
definitely true of Australian universities wherein each state/territory has a
single link shared by the universities in that state/territory) and that link
goes down, you can still access siblings at other organisations but not sites
directly (and thus, will fall afoul of the forwarding error).

Well, that's the theory anyway .. I can't think of any other reason why the
error appeared. :-(

Basic run-down from squid.access.log (don't have the cache.log for that day,
sorry):

- user tries URL (PDF doc), squid logs:

  user_ip TCP_MISS/200 URL SIBLING_HIT application/pdf (partial download)
  user_ip TCP_MISS/403 URL SIBLING_HIT text/html (user gets forwarding err)
  user_ip TCP_NEGATIVE_HIT/403 URL NONE text/html
  user_ip TCP_NEGATIVE_HIT/403 URL NONE text/html

- user calls support desk, they try:

  supp_ip TCP_MISS/200 URL SIBLING_HIT application/pdf (partial download)
  supp_ip TCP_MISS/403 URL SIBLING_HIT text/html (forwarding error from peer)
  supp_ip TCP_NEGATIVE_HIT/403 URL NONE text/html

- support calls me, of course Murphy's Law is in effect and the problem's
  disappeared so I can't recreate/check.

Other comments re setup - hierarchy (there be method in the madness):

  proxy-1 -----+- peer-1
   | |
   +- proxy-2 -+- peer-2

- proxy-1 peers (sibling) with peer-1 and peer-2
- proxy-2 peers (sibling) with peer-1 and peer-2
- proxy-1 is parent to proxy-2, proxy-2 is child to proxy-1
- all four proxies can go direct to the Internet
- proxy-1 and proxy-2 are within organisation-1 (Squid/2.1PATCH1)
- peer-1 and peer-2 are within organisation-2 (Squid/2.0PATCH2)
- proxy-2 is using cache-digests and ICP for proxy-1
- proxy-1 and proxy-2 are only using ICP for peer-1 and peer-2
- the access.log comments above are from proxy-2 (the one the clients were
  all hitting for their requests)
- the forwarding error came from peer-2

Make any sense? As I say I don't have the cache.log for that day so I can't
double-check the theory...

dave
Received on Fri Dec 11 1998 - 06:08:46 MST