TCP Dup ACK, segments perdus, retransmission pendant la conversation smtp

Un client essaie d'envoyer des courriels avec des pièces jointes (de plus en plus petites) à l'un de nos servers d'échange, mais obtenez la réinitialisation de la connection une fois que le timeout d'attente est atteint. Pour moi, il semble que le server d'envoi ne reçoive pas les ACK et, par conséquent, renvoie, en conséquence, DUP ACK de notre côté. Nous utilisons Cisco ASA, mais nous n'utilisons aucune politique smtp / esmtp (aka fixup smtp) pour aucune des interfaces impliquées (elle est utilisée pour un vlan complètement différent, où aucun échange ne réside).

1.1.1.1 réception du server smtp
2.2.2.2 envoi du server smtp

Jusqu'à y compris la "S: 354 Entrée de début de messagerie, finissez avec". Cela fonctionne comme un charme. Le problème vient vraiment lorsque datatables sont envoyées.

Wireshark dump

 Pas de source de time Source Protocole Longueur Info
 20 504.923698 1.1.1.1 2.2.2.2 SMTP 78 S: 250 2.1.5 Destinataire OK

 Pas de source de time Source Protocole Longueur Info
 21 505.304394 2.2.2.2 1.1.1.1 SMTP 60 C: DONNÉES

 Pas de source de time Source Protocole Longueur Info
 22 505.304713 1.1.1.1 2.2.2.2 SMTP 100 S: 354 Entrée de début de messagerie;  terminer par .

 Pas de source de time Source Protocole Longueur Info
 23 505.599857 2.2.2.2 1.1.1.1 SMTP 1434 C: fragment de données, 1380 octets

 Pas de source de time Source Protocole Longueur Info
 24 505.620808 2.2.2.2 1.1.1.1 SMTP 1434 C: fragment de données, 1380 octets

 Pas de source de time Source Protocole Longueur Info
 25 505.620823 1.1.1.1 2.2.2.2 TCP 54 smtp> 55346 [ACK] Seq = 450 Ack = 2904 Win = 64860 Len = 0

 Pas de source de time Source Protocole Longueur Info
 26 505.919899 2.2.2.2 1.1.1.1 SMTP 1434 [segment segment précédent de TCP perdu] C: Fragment de données, 1380 octets

 Pas de source de time Source Protocole Longueur Info
 27 505.919912 1.1.1.1 2.2.2.2 TCP 54 [TCP Dup ACK 25 # 1] smtp> 55346 [ACK] Seq = 450 Ack = 2904 Win = 64860 Len = 0

 Pas de source de time Source Protocole Longueur Info
 28 505.940785 2.2.2.2 1.1.1.1 SMTP 1434 [TCP segment précédent perdu] C: fragment de données, 1380 octets

 No. Source de time Protocole de destination Infos sur la longueur
 29 505.940797 1.1.1.1 2.2.2.2 TCP 54 [TCP Dup ACK 25 # 2] smtp> 55346 [ACK] Seq = 450 Ack = 2904 Win = 64860 Len = 0

 No. Source de time Protocole de destination Infos sur la longueur
 30 505.961793 2.2.2.2 1.1.1.1 SMTP 1434 [Retransmission TCP] C: fragment de données, 1380 octets

 No. Source de time Protocole de destination Infos sur la longueur
 31 505.982494 2.2.2.2 1.1.1.1 SMTP 1434 [Retransmission TCP] C: fragment de données, 1380 octets

 No. Source de time Protocole de destination Infos sur la longueur
 32 505.982508 1.1.1.1 2.2.2.2 TCP 54 smtp> 55346 [ACK] Seq = 450 Ack = 4284 Win = 64860 Len = 0

 No. Source de time Protocole de destination Infos sur la longueur
 33 506.302829 2.2.2.2 1.1.1.1 SMTP 1434 [TCP segment précédent perdu] C: fragment de données, 1380 octets

 No. Source de time Protocole de destination Infos sur la longueur
 34 506.302846 1.1.1.1 2.2.2.2 TCP 54 [TCP Dup ACK 32 # 1] smtp> 55346 [ACK] Seq = 450 Ack = 4284 Win = 64860 Len = 0

 No. Source de time Protocole de destination Infos sur la longueur
 35 506.323446 2.2.2.2 1.1.1.1 SMTP 1434 [Retransmission TCP] C: fragment de données, 1380 octets 

etc etc jusqu'à la fin du time mort.

Nous exécutons d'autres servers d'échange, auxquels l'expéditeur peut envoyer le même email. Tous nos servers d'échange sont assis derrière les mêmes pare-feu, routeurs et commutateurs. Probablement seulement le câblage de patch qui diffuse.
oh, et envoyer des pièces jointes sur 15 Mo de gmail au server fonctionne

  Ping continuel continu:

 Statistiques Ping pour 2.2.2.2:
     Paquets: Envoyé = 249, Reçu = 249, Perdu = 0 (perte 0%),
 Temps d'aller-return approximatifs en milli-secondes:
     Minimum = 82ms, Maximum = 546ms, Moyenne = 138ms
 ^ C

 # package non déployé de 992 octets fonctionne
  C: \ Users \ someadmin> ping -f -l 992 2.2.2.2

 Pinging 2.2.2.2 avec 992 octets de données:
 Réponse de 2.2.2.2: octets = 992 fois = 100 ms TTL = 48
 Réponse de 2.2.2.2: octets = 992 fois = 101ms TTL = 48
 Réponse de 2.2.2.2: octets = 992 fois = 101ms TTL = 48
 Réponse de 2.2.2.2: octets = 992 fois = 100 ms TTL = 48

 Statistiques Ping pour 2.2.2.2:
     Paquets: Envoyé = 4, Reçu = 4, Perdu = 0 (perte 0%),
 Temps d'aller-return approximatifs en milli-secondes:
     Minimum = 100ms, Maximum = 101ms, Moyenne = 100ms


 # package non déchargé de 993 octets échoue
 C: \ Users \ someadmin> ping -f -l 993 2.2.2.2

 Pinging 2.2.2.2 avec 993 octets de données:
 La request a expiré.
 La request a expiré.
 La request a expiré.
 La request a expiré.

 Statistiques Ping pour 2.2.2.2:
     Paquets: Envoyé = 4, Reçu = 0, Perdu = 4 (100% de perte),

Je peux cependant appeler ping googles dns avec de gros packages:

 ping -f -l 1472 8.8.8.8

 Pinging 8.8.8.8 avec 1472 octets de données:
 Réponse de 8.8.8.8: bytes = 64 (envoyé 1472) time = 31ms TTL = 51

 ping -f -l 1472 8.8.4.4

 Pinging 8.8.4.4 avec 1472 octets de données:
 Réponse de 8.8.4.4: octets = 64 (envoyé 1472) time = 30 ms TTL = 51

Politiques Cisco ASA

 class-map inspection_default
  match par défaut-inspection-trafic
 !
 !             
 type de carte de stratégie inspecter dns preset_dns_map
  parameters
   nombre maximal du message maximum client
   nombre de messages maximum 3096
   pas de garde
   pas d'application de protocole
   sans re-écriture naturelle
 policy-map global_policy
  class inspection_default
   inspecter dns preset_dns_map 
   inspecter ftp 
   inspecter h323 h225 
   inspecter h323 ras 
   inspecter rsh 
   inspecter rtsp 
   inspecter sqlnet 
   inspecter maigre  
   inspecter sunrpc 
   inspecter xdmcp 
   inspecter la gorgée  
   inspecter netbios 
   inspecter tftp 
   inspecter les options ip 
   inspecter l'icmp 
 policy-map shape_policy
  class class par défaut
   input de la police 10000000 5000
   sortie de la police 10000000 5000
 !             

Où devrais-je commencer à regarder? Dois-je commencer par requestr à l'expéditeur de faire la même trace wireshark / tcpdump?

One Solution collect form web for “TCP Dup ACK, segments perdus, retransmission pendant la conversation smtp”

Il est difficile de le savoir avec certitude, mais, à mon avis, vous avez ici un problème MTU. Faites un path MTU découverte et réduisez MTU de votre passerelle (ou server NIC) en conséquence. Si vous résolvez votre problème, vous avez la preuve que certains nœuds dans le path ne manient pas correctement à MTU (soit en supprimant les packages ICMP code 4, soit simplement en ne le renvoyant pas).

  • IIS SMTP Configurer le contenu de la notification du statut de la livraison
  • Quelle stratégie dois-je utiliser pour installer le server smtp sur linux? pour le service multithread
  • Étapes à suivre pour améliorer la livraison de courrier électronique [en double]
  • Le courrier sortant Postfix soudainement différé
  • Basculer les smarthosts en échange lors de l'utilisation de WAN double
  • Ajouter le courrier électronique sortant sur ExIM de manière appropriée
  • Annoncez NO-SOLICITING (RFC3865)
  • Désactiver la livraison locale pour un domaine virtuel dans postfix
  • Envoi de courrier électronique à partir d'un server hébergé par un tiers
  • Enregistrements SPF pour le service SMTP
  • Le filter de destinataire SMTP Postfix ne filter pas
  • Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de rĂ©seau.