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

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?
Received on Tue Apr 30 2013 - 18:34:14 MDT