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

On 1/05/2013 6:34 a.m., Alex Domoradov wrote:
> On Tue, Apr 30, 2013 at 11:46 AM, Amos Jeffries <squid3_at_treenet.co.nz> 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
Received on Wed May 01 2013 - 02:16:23 MDT