某单位无法发送大附件邮件的故障分析案例、解决方案.docx

某单位无法发送大附件邮件的故障分析1.1. 故障描述1. 故障现象该单位近两个月内发现邮件发送异常，具体表现为：邮件发送很慢，但接收正常。空头信或文字较少的邮件能正常发送，但文字较多或携带超过15KB以上的附件则无法正常发送。使用web邮件收发正常，使用outlook 和foxmail 等客户端出现异常。网络拓扑:如下图，用户使用outlook 等客户端发送邮件的基本路径为：用户-接入交换机-核心交换机-邮件服务器-邮件网关-防火墙-路由器-SP。 邮件服务器位于FW的 DMZ区。而通过WEB 发送邮件则不通过邮件服务器和邮件网关。 （图1 某单位邮件传输路径原始简易拓扑图）1.2. 具体分析1. 抓包分析客户的邮件出现问题已经两个月没有解决，而以前使用了近5年都是正常的，邮件服务器和邮件网关没有做任何改变，一直运行良好了多年。这种问题很奇怪，客户自己做过很多排查工作，做过撇开邮件网关直接使用邮件服务器发送，问题依然；也尝试着使用其他方法将设备拿掉，但多次尝试依然无法找出根源在哪，因此问题一直存在。根据邮件链路情况分析，我们先在邮件服务器前端进行抓包，查看客户端的邮件发送情况，抓包采用核心交换机镜像邮件服务器接口方式。抓包同时使用客户PC的邮件客户端发送大附件邮件测试。我们发现服务器接受到邮件服务器的时候大字节的数据包 1518byte的数据包重传很多次。而且多次重传无法将数据包后，服务器还是没有收到大字节的数据包，而经过90秒之后，服务器认为此连接为异常连接，发送重置数据包，邮件传输中断。（图2 异常的SMTP会话） 如上图，我们看到1518byte 的字节几乎都无法顺利的传输。而之前的协商都很正常。经过多次重传后服务器还是没有收到1518数据包，服务被中止。 经过多个会话的分析发现，此种会话很多，而且大的数据包都很难被传输，多次重传。数据包个数为20368，而TCP重传发生的次数就达5456，重传概率达到26.7%。（图3 大量的SMTP数据包重传） 为什么传输小数据包没问题，而大的数据包都不成功呢？MTU？难道是路径中某个接口的MTU太小而又不做分片导致的？是防火墙呢，路由器，还是邮件网关等设备的原因呢？为了验证猜想，决定在防火墙后面进行抓包看下1518byte 的数据包有没有被正确传输。我们在防火墙后面抓包发现1518byte的数据包是可以穿越防火墙的。如图：（图4 防火墙后抓包）上图我们也看到，几乎大多数的1518byte的数据包的分片标识中分段标志都置位1，这就意味着1518byte的数据包是不准许分片的。这种做法是上层协议的需要，SMTP协议在打包的时候就告诉了IP层，封装数据的时候不要分片。大多数的TCP传输是很少有分片现象的存在，分片大多出现在UDP和IP协议的传输中。防火墙被排除后本地网络就剩下路由器了，我们在路由器后面抓包看下是不是有异常。路由器承担了NAT功能，因此在路由器后面抓包，抓到的将是其公网地址。抓包几分钟后，果然验证了猜想。如图：（图5 发送SMTP 走GRE通道）我们看到，网络中存在GRE通道，而且GRE通道是为发送SMTP专门建立的。我们看到GRE的数据包统计中没有任何1518byte的数据包存在。也就是说1518byte的数据包在传输到路由器后，被丢弃了。为什么会被丢弃呢？其实道理很简单，GRE需要4byte头部+20字节的IP头部，共增加了24字节的额外负荷。而原来1500byte的负荷（1518byte-14byte帧头-4byte校验=1500byte）变成了1524。而路由器的接口默认MTU都是1500，在负荷大于MTU的情况下，IP层会做出分片，但不幸的是本网络SMTP协议传输不准许分片，在这种情况下只能选择丢弃超过1518byte的数据包。而收邮件是没有走GRE通道的，所以收邮件是没问题的，如图：（图6 收SMTP不走GRE正常传输）终于知道出现问题的根源了，于是建议客户将GRE取消试一下。让发送SMTP不走GRE通道。果然，发送和接受正