> Hey ,Guys > > We met a performance issue when Squid working with NAT ... > Thanks in advance for your attention. > > There are two squid servers, Squid1 and Squid 2. > And We use web polygraph to do the performance test. So there are > another two servers, PolyClient and PolyServer. > Firstly, the 4 servers were in the same vlan. We used PolyClient to > send traffic to both Squid1 and Squid2. And the PolyServer could > receive all http requests. All in a word, every server worked well. > Secondly, we chaged the deployment. PolyClient, squid1 and Squid2 were > put into the internal vlan. PolyServer was put into another external > vlan. In this situation, PolyClient, Squid1 and Squid2 can not reach > PolyServer directly. So we add a NAT functionality which provide the > NAT in a PC between the squid server and Polyserver . > . > We send traffics to only one squid server. All is OK. But if we sent > the traffics to the two squid servers in the same time. > Some error occurred. , which come from squid1. But on the squid2 side, > all is OK. > part of netstat -na in squid2 output like following: > tcp 0 1 198.18.24.3:46304 10.56.233.99:9999 > SYN_SENT > tcp 0 1 198.18.24.3:46311 10.56.233.99:9999 > SYN_SENT > tcp 0 1 198.18.24.3:46310 10.56.233.99:9999 > SYN_SENT > tcp 0 1 198.18.24.3:46309 10.56.233.99:9999 > SYN_SENT > tcp 0 1 198.18.24.3:46308 10.56.233.99:9999 > SYN_SENT > tcp 0 1 198.18.24.3:46331 10.56.233.99:9999 > SYN_SENT > tcp 0 1 198.18.24.3:46330 10.56.233.99:9999 > SYN_SENT > tcp 0 1 198.18.24.3:46329 10.56.233.99:9999 > SYN_SENT > tcp 0 1 198.18.24.3:46328 10.56.233.99:9999 > SYN_SENT > tcp 0 1 198.18.24.3:46335 10.56.233.99:9999 > SYN_SENT > tcp 0 1 198.18.24.3:46334 10.56.233.99:9999 > SYN_SENT > tcp 0 1 198.18.24.3:46333 10.56.233.99:9999 > SYN_SENT > tcp 0 1 198.18.24.3:46332 10.56.233.99:9999 > SYN_SENT > tcp 0 1 198.18.24.3:46323 10.56.233.99:9999 > SYN_SENT > tcp 0 1 198.18.24.3:46322 10.56.233.99:9999 > SYN_SENT > tcp 0 1 198.18.24.3:46321 10.56.233.99:9999 > SYN_SENT > tcp 0 1 198.18.24.3:46320 10.56.233.99:9999 > SYN_SENT > tcp 0 1 198.18.24.3:46327 10.56.233.99:9999 > SYN_SENT > tcp 0 1 198.18.24.3:46326 10.56.233.99:9999 > SYN_SENT > tcp 0 1 198.18.24.3:46325 10.56.233.99:9999 > SYN_SENT > tcp 0 1 198.18.24.3:46324 10.56.233.99:9999 > SYN_SENT > tcp 0 1 198.18.24.3:46283 10.56.233.99:9999 > SYN_SENT > tcp 0 1 198.18.24.3:46282 10.56.233.99:9999 > SYN_SENT > tcp 0 1 198.18.24.3:46281 10.56.233.99:9999 > SYN_SENT > tcp 0 1 198.18.24.3:46280 10.56.233.99:9999 > SYN_SENT > tcp 0 1 198.18.24.3:46329 10.56.233.99:9999 > SYN_SENT > tcp 0 1 198.18.24.3:46328 10.56.233.99:9999 > SYN_SENT > tcp 0 1 198.18.24.3:46335 10.56.233.99:9999 > SYN_SENT > tcp 0 1 198.18.24.3:46334 10.56.233.99:9999 > SYN_SENT > tcp 0 1 198.18.24.3:46333 10.56.233.99:9999 > SYN_SENT > tcp 0 1 198.18.24.3:46332 10.56.233.99:9999 > SYN_SENT > tcp 0 1 198.18.24.3:46323 10.56.233.99:9999 > SYN_SENT > tcp 0 1 198.18.24.3:46285 10.56.233.99:9999 > SYN_SENT > tcp 0 1 198.18.24.3:46284 10.56.233.99:9999 > SYN_SENT > .. > tcp 0 0 198.18.24.3:9001 198.18.255.1:33454 > ESTABLISHED > tcp 0 0 198.18.24.3:9001 198.18.255.1:34222 > ESTABLISHED > tcp 0 0 198.18.24.3:9001 198.18.255.1:34478 > ESTABLISHED > tcp 0 0 198.18.24.3:9001 198.18.255.1:35758 > ESTABLISHED > tcp 0 0 198.18.24.3:9001 198.18.255.1:34990 > ESTABLISHED > tcp 0 0 198.18.24.3:9001 198.18.255.1:35246 > ESTABLISHED > tcp 0 0 198.18.24.3:9001 198.18.255.1:36526 > ESTABLISHED > tcp 0 0 198.18.24.3:9001 198.18.255.1:37294 > ESTABLISHED > tcp 0 0 198.18.24.3:9001 198.18.255.1:38830 > ESTABLISHED > tcp 0 0 198.18.24.3:9001 198.18.255.1:38062 > ESTABLISHED > tcp 0 0 198.18.24.3:9001 198.18.255.1:39342 > ESTABLISHED > tcp 0 0 198.18.24.3:9001 198.18.255.1:39598 > ESTABLISHED > tcp 0 0 198.18.24.3:9001 198.18.255.1:40878 > ESTABLISHED > tcp 0 0 198.18.24.3:9001 198.18.255.1:40110 > ESTABLISHED > tcp 0 0 198.18.24.3:9001 198.18.255.1:41902 > ESTABLISHED > tcp 0 0 198.18.24.3:9001 198.18.255.1:41390 > ESTABLISHED > tcp 0 0 198.18.24.3:9001 198.18.255.1:42926 > ESTABLISHED > ..... > We check the connections on squid1, > [root@squid1 ~]# cat /proc/net/sockstat > sockets: used 40107 > TCP: inuse 40020 orphan 0 tw 3 alloc 40028 mem 20034 > UDP: inuse 18 > RAW: inuse 0 > FRAG: inuse 0 memory 0 > Then We did the functional test in the same enviorment : > We found out Squid 1( 198.18.24.3 ) has sent lots of SYN_SENT to > Polyserver (10.56.233.99) to try to estiblish TCP , but no response > from polyserver side , so the squid1 to webpolygraph client > (198.18.255.1) have to keep the TCP connection . all these connection > make the squid1 server keep lots of TCP connection. (Very abnormal > state) > Looking forward your suggestion . > Thanks, > -Arkin > So basically your traffic is going out through NAT but not getting back in? Make sure your NAT rules are symetrical and the SYN/ACK can get back to the connector machine. That usually means adding a NAT MASQUERADE or somesuch rule to the NAT gateway. Amos
