Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
We are experiencing an intermittent TCP handshake problem between two of our servers. 10.2.2.21 is running apache on CENTOS 5 and is a proxy for 10.2.2.30 which is running IIS on Windows 2003. Below is a tcpdump showing a normal TCP handshake, and below that the one where it fails. We notice long outages during a request when this happens, and it is always exactly a 45 second wait.
All port 80 traffic from the internet is forwarded by DNAT rule on our border router (CENTOS 5 running shorewall/iptables firewall) to 10.2.2.21 and then the apache proxy hands it over to the IIS on 10.2.2.30
The TCP dump is identical on both machines so the SYN/ACK is actually received by the network interface on the Linux server, but for some reason the TCP stack doesn't respond with an ACK for quite some time, and keeps sending SYN's as if the SYN/ACK never arrived.
Both servers are Dell Poweredge 2950, quad core servers with 3GB of Memory. They aren't overloaded at all by the processes they are running. The Linux server has 2 interfaces bonded in a failover configuration, and the Windows machine has 2 interfaces in a failover teaming configuration. The teaming and bonding is set up so that only one interface is live, there is no load balancing. As the TCP dump is identical on both machines, I doubt the interfaces are the culprit.
The netowrk bandwith on the Linux machine is nowhere overloaded either.
Something that might be related is that doing a 'netstat -antp' on the linux machine shows that there are always aroud 2500 open sockets with status TIME_WAIT. This is because we have a lot of database connections going from this machine to a Postgresql server.
As far as I know /proc/sys/fs/file-max value is 295328, so isn't that the maximum amount of sockets the system can open? So surely 2500 open sockets shouldn't congest the TCP stack?
Surely a configuration option for apache wouldn't influence a low level TCP handshake as this is at layer 4?
Same issue occured on Solaris 10.
We thought first that the tcp_conn_req_max_q and tcp_conn_req_max_q0 were too low (now set @ 16384 and tcpListenDrop staying at 0) but the Load Balancers are still showing 1% of packets not SYN-ACKed.
Same probe on the same rythm ....
If someone has a clue, please share your knowledge