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

案例背景

　　某农商总行生产前置机无法从人行生产服务器下载更新数据(约1M)，而开发前置机却能从开发服务器上正常下载数据，开发和生产前置交换机访问服务器的路径基本一致。

　　总行前置机访问人行服务器的数据走向为：前置机经过总行网络，访问到分行网络，然后由分行网络转发到人行网络，最后访问人行服务器。根据故障现象，选择在分行到总行的核心交换机出口部署科来网络回溯分析系统进行捕包分析。

　　案例分析

　　(一)故障通讯分析

　　对生产前置机下载更新数据的TCP会话进行解码分析，发现前置机发起请求数据包后，生产服务器马上响应了3个数据包，其中第一个携带60字节应用数据，第二、三个为1448字节，而客户端只是对第一个数据包进行了确认。

　　当服务器发出携带1030字节的第四个响应包后，前置机依然是对第一个数据包进行重复确认。根据TCP的重传机制，可以肯定当前置机收到第四个 响应数据包时，并没有收到第二个1448字节的数据包，因此服务器对此数据包进行了重传，但经过多次重传客户端依然没有收到此包。

　　从对故障会话的数据包交互过程来看，前置机无法收到服务器的第二个响应数据包，导致无法完整更新数据。前置机却能收到第一个和第四个响应包，从 数据包大小来看，这两个包携带的应用层数据较小，而第二个包携带的应用层数据为1448字节。从会话的TCP三次握手数据包来看，生产前置机和服务器协商 的MSS值为1460字节，加上数据包头，数据包的总长度为1500字节。

　　由于从数据捕获点到前置机之间没有防火墙，不会对包进行过滤，因此怀疑是中间设备的MTU值较小，导致大包数据无法正常传输。

　　(二)开发前置机通讯分析

　　对开发前置机正常通讯数据进行分析，从三次握手过程看到开发前置机和服务器所协商的MSS值为1380字节。而后续的数据传输过程中，数据包的 载荷数据都只有1368字节，但是这些数据却能够正常的发送到开发前置机。因此结合前面对生产前置机的故障会话分析，可以肯定中间某个设备的MTU值较 小，导致数据包无法分片被丢弃，从而影响生产前置机的正常数据下载。

　　(三)恢复正常后的会话数据分析

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

　　案例分析结论

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