Forum Linux.noyau Problème TCP

Posté par  .
Étiquettes : aucune
-1
3
sept.
2010
Bonjour,

J'ai un soucis avec un serveur (centos 5.4 x64 2.6.18-128.4.1.el5).

De temps en temps (aléatoire et non reproductible) ce server ne peut plus faire de connection TCP sur une autre machine et uniquement sur celle là et uniquement sur l'IP virtuelle de celle ci. Si on essaye une connection TCP sur l'ip physique ca fonctionne.

Au niveau TCPdump ca donne:

Emetteur -> Recepteur: SYN
Recepteur -> Emetter: ACK
Emetteur -> Recepteur: RST (avec un seq num très élevé)

Pas de firewall entre les deux, pas d'iptables.

J'ai des erreurs sur la carte du server émetteur avec un max de packet drop:
rx_no_buffer_count: 95367
rx_missed_errors: 32679
tx_restart_queue: 1994492

Celà indique en général un pb de ring size. Ok. Mais ..... Tous celà semble être de niveau 3 (connection sur IP virtuelle pas possible , mais sur IP eth0 OK)

Question:Est ce que le kernel peut dropper en fonction de l'ip de destination ? Si oui dans quel cas ?

PS: ICMP passe toujours.
PPS: pas de QOS ou quoi que ce soit niveau 3 sur les switches.
PPPS: Dans une configuration antérieure, les deux machine n'étaient pas sur le même VLAN, le traffic passait par un firewall (cisco PIX) et était translaté ..Ce problème n'est jamais apparu.

Merci pour les idées.

Arnaud

  • # MTU ?

    Posté par  . Évalué à 2.

    Au pif, toujours regarder le MTU quand on a des erreurs inexplicables.

  • # duplex et tunning....

    Posté par  (site web personnel) . Évalué à 2.

    A la louche j'ajouterai :

    - La carte est bien en full duplex ?
    $> dmesg | grep duplex

    - le buffer tcp est suffisant sur l'interface ?
    $>sysctl net.core.rmem_max
    $>sysctl net.core.wmem_max

    Vérifier aussi que les param suivant sont à 1 :
    $>sysctl net.ipv4.tcp_window_scaling
    $>sysctl net.ipv4.tcp_timestamps
    $>sysctl net.ipv4.tcp_sack

    Fuse : j'en Use et Abuse !

    • [^] # Re: duplex et tunning....

      Posté par  (site web personnel) . Évalué à 5.

      Et jeter un oeuil aussi au nombre de filedescriptor autorisé...
      Surtout sur les "manges descripteurs" genre "O racle, O desespoir..."
      $>ulimit -a

      Fuse : j'en Use et Abuse !

  • # port reuse

    Posté par  (site web personnel) . Évalué à 3.

    > Emetteur -> Recepteur: SYN
    > Recepteur -> Emetter: ACK
    > Emetteur -> Recepteur: RST (avec un seq num très élevé)

    Si le récepteur ne renvoit pas un SYN, c'est sans doute qu'il considère que la connexion concernant ces ports n'est pas complétement fermée. Il ACK le dernier paquet qu'il a reçu pour cette connexion. Du coup, l'émetteur comprend pas de quoi il parle et il RST la connexion.

    Typiquement, le récepteur pense que la connexion est dans l'état TIME_WAIT tandis que l'émetteur pense qu'elle est fermée. Dans ce cas de figure, si les deux systèmes concernés sont sous Linux, s'assurer que les TCP timestamps sont activées aide généralement assez bien (ça l'est par défaut mais il peut y avoir un proxy TCP dont tu n'es pas au courant entre les deux qui casse tout). Après tu peux envisager de jouer avec tcp_tw_re{use,cycle} mais si tu en arrives là, il y a sans doute un autre problème quelque part.

    Une capture du réseau prise des deux côtés en même temps peut aussi aider à comprendre ce qui se passe.

    Je vois pas en quoi les erreurs sur la carte réseau pourraient être liées au phénomène décrit.

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: port reuse

      Posté par  . Évalué à 1.

      Mea culpa, je n'ai pas trouver comment éditer mon poste:

      Le récepteur envoie bien SYN,ACK, puis l'émetteur retourne RST.

  • # solutionné

    Posté par  . Évalué à 1.

    Le problème venait d'un bug de l'IOS de l'ASA 5500 (sur l'option proxy-arp)


    Arnaud

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.