Matus UHLAR - fantomas wrote:
This causes the Cisco router to redirect the response to the other
Squid server which just drops it.
mån 2009-08-17 klockan 10:42 +0200 skrev Matus UHLAR - fantomas:
I think that is a bad configuration on DNS or your network.
On 17.08.09 23:43, Henrik Nordstrom wrote:
No. It's a natural consequence of TPROXY+WCCPv2 balancing based on
requested IP, with separate DNS lookups done by the client & Squid. You
can limit some of it by DNS server hackery to implement IP pinning in
the DNS server but not eleminate it.
AHa, I missed the part with load balancing on destination IP. Yes, that is
the reason.
The workaround is simple, but not without drawbacks.. don't balance on
the destination IP, balance on the client IP instead.
and configure squids to behave as siblings with proxy-only option, so the
same content won't be duplicated on them.
The solution is to extend Squid to connect to the requested IP on
intercepted requests, but requires some extra validations to avoid cache
poisoning.
doable imho.
Yes doable. And already being worked on for CVE-2009-0801.
I will have an updated patch ready for public testing "any day now".
Amos
--
Please be using
Current Stable Squid 2.7.STABLE6 or 3.0.STABLE18
Current Beta Squid 3.1.0.13
