TCP Dup ACK,段丢失,在smtp对话期间重新传输

客户试图发送带有(更小和更大)附件的电子邮件到我们的交换服务器之一,但在超时满足后重置连接。 对我来说,发送服务器似乎没有收到ACK,因此重新发送,从而导致我的DUP ACK。 我们正在使用思科ASA,但是我们并没有使用任何smtp / esmtp策略(又名fixup smtp)作为任何涉及的接口(它用于完全不同的vlan,没有交换驻留)。

1.1.1.1接收smtp服务器
2.2.2.2发送smtp服务器

直到包括“S:354开始邮件input;以。结尾”,它就像一个魅力。 发送数据时真的出现问题。

Wireshark转储

没有时间源目标协议长度信息
 20 504.923698 1.1.1.1 2.2.2.2 SMTP 78 S:250 2.1.5收件人确定

没有时间源目标协议长度信息
 21 505.304394 2.2.2.2 1.1.1.1 SMTP 60 C:DATA

没有时间源目标协议长度信息
 22 505.304713 1.1.1.1 2.2.2.2 SMTP 100 S:354开始邮件input; 结束。

没有时间源目标协议长度信息
 23 505.599857 2.2.2.2 1.1.1.1 SMTP 1434 C:DATA片段,1380字节

没有时间源目标协议长度信息
 24 505.620808 2.2.2.2 1.1.1.1 SMTP 1434 C:DATA片段,1380字节

没有时间源目标协议长度信息
 25 505.620823 1.1.1.1 2.2.2.2 TCP 54 smtp> 55346 [ACK] Seq = 450 Ack = 2904 Win = 64860 Len = 0

没有时间源目标协议长度信息
 26 505.919899 2.2.2.2 1.1.1.1 SMTP 1434 [TCP上一个段丢失] C:DATA Fragment,1380字节

没有时间源目标协议长度信息
 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

没有时间源目标协议长度信息
 28 505.940785 2.2.2.2 1.1.1.1 SMTP 1434 [TCP上一段丢失] C:数据段,1380字节

编号时间源目标协议长度信息
 29 505.940797 1.1.1.1 2.2.2.2 TCP 54 [TCP双重ACK 25#2] smtp> 55346 [ACK] Seq = 450 Ack = 2904 Win = 64860 Len = 0

编号时间源目标协议长度信息
 30 505.961793 2.2.2.2 1.1.1.1 SMTP 1434 [TCP重传] C:数据片段,1380字节

编号时间源目标协议长度信息
 31 505.982494 2.2.2.2 1.1.1.1 SMTP 1434 [TCP重传] C:数据片段,1380字节

编号时间源目标协议长度信息
 32 505.982508 1.1.1.1 2.2.2.2 TCP 54 smtp> 55346 [ACK] Seq = 450 Ack = 4284 Win = 64860 Len = 0

编号时间源目标协议长度信息
 33 506.302829 2.2.2.2 1.1.1.1 SMTP 1434 [TCP上一个段丢失] C:DATA段,1380字节

编号时间源目标协议长度信息
 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

编号时间源目标协议长度信息
 35 506.323446 2.2.2.2 1.1.1.1 SMTP 1434 [TCP重传] C:数据片段,1380字节 

等等,直到超时满足。

我们运行其他交换服务器,发件人可以发送相同的电子邮件到。 我们所有的交换服务器都位于相同的防火墙,路由器和交换机之后。 可能只有不同的补丁布线。
哦,并发送15MB附件从gmail到服务器的作品

 正常连续ping:

 2.2.2.2的Ping统计:
    包:发送= 249,收到= 249,丢失= 0(0%损失),
大约以毫秒为单位的往返时间:
    最小= 82ms,最大= 546ms,平均= 138ms
 ^ C

 #992字节的不分片数据包可以工作
  C:\ Users \ someadmin> ping -f -l 992 2.2.2.2

 Pinging 2.2.2.2用992字节的数据:
来自2.2.2.2的答复:字节= 992时间= 100ms TTL = 48
来自2.2.2.2的答复:字节= 992时间= 101ms TTL = 48
来自2.2.2.2的答复:字节= 992时间= 101ms TTL = 48
来自2.2.2.2的答复:字节= 992时间= 100ms TTL = 48

 2.2.2.2的Ping统计:
    数据包:发送= 4,收到= 4,丢失= 0(0%丢失),
大约以毫秒为单位的往返时间:
    最小= 100ms,最大= 101ms,平均= 100ms


 #993字节的未封装数据包失败
 C:\ Users \ someadmin> ping -f -l 993 2.2.2.2

 Pinging 2.2.2.2用993字节的数据:
请求超时。
请求超时。
请求超时。
请求超时。

 2.2.2.2的Ping统计:
    数据包:发送= 4,收到= 0,丢失= 4(100%丢失),

然而,我可以ping大Google数据包的DNS:

 ping -f -l 1472 8.8.8.8

用1472字节的数据Ping 8.8.8.8:
来自8.8.8.8的答复:字节= 64(发送1472)时间= 31ms TTL = 51

 ping -f -l 1472 8.8.4.4

用1472字节的数据屏蔽8.8.4.4:
来自8.8.4.4的答复:字节= 64(发送1472)时间= 30ms TTL = 51

思科ASA策略

 class-map inspection_default
 匹配默认检查stream量
 !
 !             
策略映射types检查dns preset_dns_map
 参数
  消息长度最大客户端自动
  消息长度最大3096
  没有防守
  没有协议执行
  没有nat-rewrite
 policy-map global_policy
  class inspection_default
  检查dns preset_dns_map 
  检查ftp 
  检查h323 h225 
  检查h323 ras 
  检查rsh 
  检查rtsp 
  检查sqlnet 
  检查瘦  
  检查sunrpc 
  检查xdmcp 
  检查一下  
  检查netbios 
  检查tftp 
  检查ip-options 
  检查icmp 
政策地图shape_policy
  class class-default
  警方input10000000 5000
  警方输出1000万5000
 !             

我应该从哪里开始寻找? 我是否应该首先要求发件人执行相同的wireshark / tcpdump跟踪?

很难确定,但在我看来,这里有一个MTUpath问题。 执行pathMTU发现并相应地减less网关(或服务器NIC)的MTU。 如果它解决了你的问题,那么你可以certificatepath中的某个节点没有正确处理MTU(丢弃ICMP代码4个数据包或者不发送它)。