On 30/06/2015 8:55 p.m., Stakres wrote: > Amos, > We used this example from the wiki: > http://wiki.squid-cache.org/Features/CacheHierarchy > We can see a sibling/sibling archi is possible, right ? Possible vs Useful. For you at present its possible, but not particularly useful. I've just received an update about bug (<http://bugs.squid-cache.org/show_bug.cgi?id=4223>) that matching your symptoms. Chudy seems to have isolated it to the particular mix of HTTP/1.1 features sibling requests use. So a workaround would be to avoid the sibling relatinonship ... > > Here, we can not have a "cache_peer parent" archi as the tproxy (original > user ip) will be lost at the parent level, you wrote this in a previous post > I did. > So, we must have a sibling/sibling with the 2 squid servers, both in tproxy. The TPROXY is separate. The IP is lost the instant the peer TCP connection packets leave the Squid box regardess of the peer type. > > Now, if there is a better archi and correct settings to build a > tproxy/sibling-sibling archi, please share To use TPROXY on traffic between peers you need a cable/pathway between the proxies that does not go through the Mikrotik/Cisco routers feeding them with intercepted traffic. And routing rules on the Squid boxen to ensure that TPROXY traffic exits via the same interface that it arrived on. Alternatively you can use the no-tproxy rule on parent type cache_peer lines with the same effect as you expected to get out of the siblings (but not hitting the bug 4223). Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
