----- "Henrik Nordström" <hen...@henriknordstrom.net> wrote:
> tor 2010-09-30 klockan 13:24 +1000 skrev Paul Freeman: > > > However on further investigation, I don't think this is the case in > this > > instance. For some reason, the squid GET request to www.mhhe.com > (IP > > 12.26.55.139) takes a long time to be completed - approx. 2 minutes. > Some > > data is returned quickly but then there is a period where on my > squid server > > I see a TCP Previous Segment lost then squid server sending Dup ACKs > to > > www.mhhe.com and www.mhhe.com sending TCP Retransmissions for the > same > > segment. The Retransmission RTTs to ACK the one segment are at > 0.2,4,8,16,32 > > and 60 seconds. After that segment has finally been received, the > rest of > > the data is received OK. > > This smells like TCP window scaling issues in a firewall somewhere. > > Try as a test: > > echo 0 >/proc/sys/net/ipv4/tcp_window_scaling > > note that this is somewhat intrusive and reduces performance of TCP > in > general, but is an easy way of testing for the problem. > > Regards > Henrik Henrik, Firstly, I am struck with the coincidence of the timing of your response! After not looking at this issue for 4 weeks, I tackled it again today, and within minutes of adopting a workaround, your message was sent! This is the second odd coincidence in the past few hours - the first was finding two machines with the same MAC (from the factory, it seems) on our network... :-( I have not had time to try another version of squid, and Paul's test of 3.x indicated it may not help, so I set about trying a workaround. I am using cisco ip policy route-maps to redirect http traffic to the transparent squid box. I excluded the 12.26.55.139, and instead nat'd that traffic. This works fine, and page loads are within 30 seconds. It is messy, however, since our network is currently a mix of machines using wpad auto proxy, manual proxy, and two different redirect methods to a transparent squid. (a Cisco 6500 MSFC, and an Aruba 6000 wireless controller both handle redirects for http traffic for their VLANs). So adding an exception like this requires changes in quite a few places. As an aside, we had to abandon WCCP2 with our Cisco 6500 MSFC1, as it appeared to be unstable under heavy loads, and would slow down during peak periods, and actually crashed once. I will look into the tcp window scaling idea and report back. Thanks! Shawn Wright I.T. Manager Shawnigan Lake School
