Re: [squid-users] Re: How to use tcp_outgoing_address with cache_peer

From: Amos Jeffries <>
Date: Wed, 01 May 2013 14:16:13 +1200

On 1/05/2013 6:34 a.m., Alex Domoradov wrote:
> On Tue, Apr 30, 2013 at 11:46 AM, Amos Jeffries <> 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
>> 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?

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..

Received on Wed May 01 2013 - 02:16:23 MDT

This archive was generated by hypermail 2.2.0 : Wed May 01 2013 - 12:00:48 MDT