winscp传文件到centos服务器，出现主机超过15秒无通信，文件发送中断问题排查过程

  有同事反馈，说自己在楼下的pc用虚拟机的scp命令或者winscp给centos服务器传文件出现中断现象，询问是否交换机有啥流量限制？如下图：

 

  文件传输失败。

   已知网络环境如下图：

告知他，这可能是网络tcp层出现问题，让他长ping同时测试，反馈长ping正常，但就是传输文件不行。

    同事反馈传1G以下的文件没有问题，但超过1G就会出现问题？奇怪？

自己在下载组网图中的205交换机下进行测试，搞了一个1.7G的文件发送，发现现象一致，搜网上的各种方法，关闭优化连接缓冲大小，刷新远程桌面间隔，服务器sshd的配置文件等都无效。

跟了一下winscp的日志发现有下面的记录：

Waiting for dispatching send buffer timed out, asking user what to do. .

等待调度缓冲区超时，明显是tcp层出现丢包导致此问题。可能是网络原因，觉得应该直接接在服务器的网口上，撇开各级交换机排除一下交换机环境的影响。

   在服务器的网口上直连笔记本测试，多次发送1.7G文件winscp没有出现中断现象，交换机环境有问题？

   之前用wireshark使用多文件抓包，问题出现后，停止抓包，用于观察。

        本来想同时在服务器上抓包，然后进行包对比，但考虑包数量太大，不好操作。同事反馈6月十几号以后，出版本时发现的问题，以前没有出现过问题，而且1G以下下文件没问题，大于1G的文件会出出现问题。查找网络维护日志，发现有添加acl的记录，如下图：

 

具体的acl语句如下图：

 acl原本是想根据frame的偏移量，放行对应的目的ip的arp请求，拦截其他非本网段的arp请求，但可能误伤了其他协议的包。

拦截的从二层帧frame38byte处是0x0a，ac，c0就是10,172,192开头的包。

检查wireshark多文件抓包里中断时间段的包发现有ssh协议frame[38]==0a有很多包。

 

看统计数据

看占比1.5%左右。看正常时候是否有同样的包？

发现正常的50m的抓包里没有这个包，确定问题是acl拦截tcp包38位是0x0a的包造成的问题，导致服务器收到包不全造成问题。

看看有tcp的frame的第38byte即0x26是啥东西？

 

 

 

 

明白 了，当文件小于1g，ssh的tcp层序列号不会到0a打头，所以没有拦截，而当大于1g后，ssh的tcp的序号打头大于了0a 00 00 00，导致这些包无法进入核心交换机，测试环境中的服务器收到的包不全，无法给出正常的确认消息，导致winscp软件无法向缓冲区发数据，导致问题发出。

放开acl拦截后，让同事测试，反馈问题解决。

为拦截arp消息，把acl进行修改，把二层acl语句加入目的mac地址后四段

看wireshark的统计里图表的flow（tcp）的情况

 

下来后，复现抓pc和服务器侧的包进行比对，发现有丢包

 

结论：二层acl造成拦截了ssh的序号为0a打头的包导致winscp或者scp命令出现15秒无通信终端。