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
Received on Tue Apr 30 2013 - 08:46:26 MDT
This archive was generated by hypermail 2.2.0 : Wed May 01 2013 - 12:00:48 MDT