Peter Pilsl wrote:
> But routing is not the problem here. I did a more 'sensible' test: I
> didnt shut down the whole NIC, I just blocked the way to proxy1 and
> left the rest unchanged. Now I dont get an error, but the page is
> build up extremely slow (minutes !!!) AND squid is not fetching the
> page from proxy2 but DIRECT.
Correct. It will keep on using proxy1 until it figures out that there is
no point in trying to reach proxy1. Up to 10 accempts will be made
before proxy1 is declared dead.
Since it is allowed to go direct, Squid assumes going direct is OK if it
cannot forward the request along the path it selected in peer selection.
> Squid is simply ignoring my second cache_peer-line (remember, I
> disabled the prefer-direct). When I do a few refreshs on the browser,
> squid finally switches to proxy2 and displays the page in a acceptable
> speed.
It is not ignoring proxy2, but it finds proxy1 before proxy2, and proxy1
looks like it might be OK.
> When I bring in proxy1 again, squid will use proxy2 as first_up_parent
> for the next 3-4 refreshs and then use proxy1 again forever. (I doesnt
> even try proxy2 then, there is not a single packet running from
> squid-host there ...)
It will only use both if you tell Squid to do so, for example by using
the round-robin option or CARP peering. Or if using ICP and the response
time for the two varies.
-- Henrik Nordstrom Squid Hacker -- To unsubscribe, see http://www.squid-cache.org/mailing-lists.htmlReceived on Wed Jan 24 2001 - 15:32:35 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:57:34 MST