某单位无法发送大附件邮件的故障分析案例

5225

该单位近两个月内发现邮件发送异常，具体表现为：
邮件发送很慢，但接收正常。空头信或文字较少的邮件能正常发送，但文字较多或携带超过15KB以上的附件则无法正常发送。使用web邮件收发正常，使用outlook 和foxmail 等客户端出现异常。


网络拓扑：如下图，用户使用outlook 等客户端发送邮件的基本路径为：用户----接入交换机----核心交换机-----邮件服务器----邮件网关----防火墙---路由器-----SP。邮件服务器位于FW的 DMZ区。而通过WEB 发送邮件则不通过邮件服务器和邮件网关。

                    （图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通道。果然，发送和接受正常大附件邮件顺利发送。


取消GRE通道配置
修改GRE通道的MTU，使其保证能通过1518byte的数据包
SMTP服务器设置准许邮件数据包分片。

skram

居然没人顶？分析得很到位的嘛！！

281763302

SMTP不允许分片么--！
SMTP基于TCP为什么又有UDP数据需要分片而分片不成功了。

nadou3

好好分析下了

smlq

分析和处理的不错，类似现象在工作中时常可以遇到。

kpking

我们这里就有这个问题。但看不明白怎么搞？有人可以教教吗