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.
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
In fact, this even this would make cache_peer statements obsolete.
Yes indeed.
Amos
