科来：某商业银行前置机故障分析案例

Cerrie · 发表于 2015-8-4 16:46:02

一、案例背景
   某农商总行生产前置机无法从人行生产服务器下载更新数据（约1M），而开发前置机却能从开发服务器上正常下载数据，开发和生产前置交换机访问服务器的路径基本一致。
   总行前置机访问人行服务器的数据走向为：前置机经过总行网络，访问到分行网络，然后由分行网络转发到人行网络，最后访问人行服务器。根据故障现象，选择在分行到总行的核心交换机出口捕包分析。
二、故障分析
1.故障通讯分析
   部署科来网络分析系统，对生产前置机下载更新数据的TCP会话进行解码分析，发现前置机发起请求数据包后，生产服务器马上响应了3个数据包，其中第一个携带60字节应用数据，第二、三个为1448字节，而客户端只是对第一个数据包进行了确认。

数据包交易时序图

当服务器发出携带1030字节的第四个响应包后，前置机依然是对第一个数据包进行重复确认。根据TCP的重传机制，可以肯定当前置机收到第四个响应数据包时，并没有收到第二个1448字节的数据包，因此服务器对此数据包进行了重传，但经过多次重传客户端依然没有收到此包。
   从对故障会话的数据包交互过程来看，前置机无法收到服务器的第二个响应数据包，导致无法完整更新数据。前置机却能收到第一个和第四个响应包，从数据包大小来看，这两个包携带的应用层数据较小，而第二个包携带的应用层数据为1448字节。从会话的TCP三次握手数据包来看，生产前置机和服务器协商的MSS值为1460字节，加上数据包头，数据包的总长度为1500字节。
   由于从数据捕获点到前置机之间没有防火墙，不会对包进行过滤，因此怀疑是中间设备的MTU值较小，导致大包数据无法正常传输。
2. 开发前置机分析
   对开发前置机正常通讯数据进行分析，从三次握手过程看到开发前置机和服务器所协商的MSS值为1380字节。而后续的数据传输过程中，数据包的载荷数据都只有1368字节，但是这些数据却能够正常的发送到开发前置机。因此结合前面对生产前置机的故障会话分析，可以肯定中间某个设备的MTU值较小，导致数据包无法分片被丢弃，从而影响生产前置机的正常数据下载。

3. 恢复正常后的数据分析
   根据所定位的故障原因，再修改生产前置机的MTU值为1300字节后，数据通讯恢复正常，能够正常的下载更新数据包。

三、案例分析结论
   总行网络中某台网络设备的MTU值设置较小，导致大包数据无法正常传输，从而影响更新数据包的下载。

科来：某商业银行前置机故障分析案例

本帖子中包含更多资源