On 1/05/2013 6:34 a.m., Alex Domoradov wrote:
On Tue, Apr 30, 2013 at 11:46 AM, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote:
On 30/04/2013 8:16 p.m., babajaga wrote:
Hi,
just my few cents:
Up to my understanding. what is going in here, the original simple
tcp_outgoing_address yyy.yyy.yyy.239
"forces" squid to use this outgoing interface for all connections,
yes.
overriding or taking precedence over the cache_peer condition.
Not quite.
On the peer connections it would create packets with src-IP yyy.yyy.yyy.239
and dst-IP 192.168.220.2.
Something (broken?) in Alex's configuration does not know how to handle
those packets properly.
As far as I know, usually, in external tables there are no route to
internal subnets
It will just depend upon the sequence of checks in squids code.
In case, presence of tcp_outgoing is checked first in squids internal
execution path, cache_peer will not be evaluated any more.
cache_peer is always checked first.
(It should be possible to verify my suspicion by debugging squid using
very
generous debug_options. May be, debug_options ALL,5 33,2 28,9 could be
worth
a first try)
However, it is possible to use ACLs with tcp_outgoing
So I would try to do something like this
tcp_outgoing_address yyy.yyy.yyy.239 !AMAZON !RACKSPACE
May be, also this one
#yyy.yyy.yyy.240 (bonded) interface to parent_squid
tcp_outgoing_address yyy.yyy.yyy.240 AMAZON
tcp_outgoing_address yyy.yyy.yyy.240 RACKSPACE
ok, I will try and let you know
In fact, this even this would make cache_peer statements obsolete.
Yes indeed.
Amos
I will try acl peername, but first I need to update squid to at least
3.1. And that is a problem. As I know, there were a lot of changes
P.S.
Is there possibility to upgrade squid-2.6 to 3.1 and keep all objects in cache?
Yes.
Leave your cache in place during the upgrade and use the same cache_dir
settings, if the new Squid is able to read and use the old content it
will do so, otherwise it will inform you about a "dirty" scan and begin
rebuilding the swap.state journal and memory index from scratch using
the on-disk content. The process can be quite slow on large caches
though, so if you are unsure whether you can cope with the lag involved
do it on a duplicate of the cache..
Amos
