Question

Nous utilisons une Debian avec un noyau 2.6.16, avec iptables activé. Le système exécute un proxy HTTP personnalisé, qui est soumis à une charge légère (il fonctionne correctement avec la même charge sur d'autres sites). Le système est composé de 4 serveurs précédés d'un équilibreur de charge avec IP virtuelle, précédés d'un tableau de 4 machines ISA 2004. La topologie de base est donc la suivante:

Client - > ISA [1-4] - > Equilibreur de charge - > Notre proxy [1-4] - > Internet

Parfois, l’ISA nous envoie un paquet SYN, auquel aucun SYN-ACK n’est envoyé. Il réessayera après 3 secondes et une troisième fois après 6 secondes, après quoi il signalera le proxy en panne et passera en connexion directe. Pendant ce temps, c'est-à-dire avant, entre et après ces 3 SYN, d'autres SYN du même ISA arrivent et on y répond avec succès.

Un problème très similaire est rapporté par d'autres (sans solution cependant):

Tous proviennent d’une version de Linux appelée CentOS. Sa particularité est d’avoir activé iptables par défaut.

http://www.linuxhelpforum.com/showthread.php?t = 931912 & amp; mode = linéaire http://www.centos.org/modules/newbb/viewtopic. php? topic_id = 16147

Presque pareil: mais un peu différent: http: //www.linuxquestions.org/questions/linux-networking-3/tcp-handshake-fails-synack-ignored-by-system.-637171/

semble également être pertinent: http://groups.google.com/group/ comp.os.linux.networking / browse_thread / thread / b1c000e2d65e0034

Je soupçonne iptables d’être un coupable, mais tout commentaire supplémentaire sera le bienvenu.

Était-ce utile?

La solution

Regardez le deuxième paramètre de l'appel d'écoute, comme indiqué dans le premier lien que vous avez posté. C'est le nombre maximum de connexions en attente (pas encore acceptées). Selon la page de manuel listen (2), si le protocole prend en charge la retransmission (TCP, par exemple), la demande de connexion est abandonnée lorsque la file est pleine (dans l’attente d’une retransmission ultérieure qui créera la connexion s’il ya suffisamment d’espace disponible dans la file. ).

Autres conseils

En effet, les iptables se sont avérés être la clé de voûte, avec la règle qui supprimait les paquets INVALID. Nous ne savons toujours pas avec certitude ce qui a amené iptables à penser que ces SYN étaient invalides (pas de TIME_WAIT à coup sûr, car nous n’avions aucun trafic avec les mêmes ports source pendant au moins 30 minutes avant le largage).

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top