On Tue, Apr 30, 2013 at 11:46 AM, Amos Jeffries <squ...@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?
