> 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_at_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
Received on Fri Jul 25 2008 - 03:10:46 MDT
This archive was generated by hypermail 2.2.0 : Fri Jul 25 2008 - 12:00:02 MDT