故障发生后，售后工程师被派往现场进行诊断！在现场我们发现S7-1200无论是集成的PN口还是CP卡都无法与MES做S7连接，而S7-1500可以使用CP卡和MES做S7连接，集成的CPU的PN接口却无法与MES通信。
为了测试这个故障，用户在现场也放了一台MES，与PLC的CP卡处在同一网段，无论是CPU还是CP卡，S7通信完全没有问题。这证明第三方的驱动和西门子的PLC通信没有问题。看到这里，大家会觉得故障的原因应该在工厂网络的路由上。但是在IT中心Ping现场的PLC都是<1ms，这说明链路是非常好的！
接着售后工程师先查看PLC的连接资源和硬件组态，这些都没有问题，也尝试了使用西门子SCALANCEXC208，设置为本地路由的方式，连接本地的MES，设置IP地址为IT中心MES的IP地址进行路由测试，也没有问题，到此这说明问题还是出现在IT中心的服务器出口到现场PLC之间的路径上。
IT工程师也说他们可以和第三方的PLC通信完全没有问题，所以仍然无法说明问题出现在IT网络上。于是，售后工程师在服务器侧使用Wireshark进行抓包，即在服务器上安装Wireshark，使用本地网卡捕捉MES与PLC的进出数据；同时在PLC侧使用XC208做端口镜像进行报文捕捉，以查看报文是否存在异常。结果有了惊人的发现！
为了更好的解释报文，现场应用的MES“服务器”这3个字不再提起，因为在协议上MES为S7客户端，S7的服务器自然是PLC，端口默认为102，这一点好多网友都知道，所以报文中的客户端和服务器指的是S7协议层上的客户端和服务器。
MES侧的报文如下，其中MES的IP地址10.16.3.110，1500PLC集成接口CPU的IP地址10.18.61.8，这两个IP地址需要通过工厂IT网络进行路由。从开始尝试与CPU进行连接的报文开始看，从17586开始，S7客户端(MES)通过端口号Port：49576和1500CPU做了TCP的3次握手(17586，17590，17591)，17592进行S7应用层连接，这些都是正常的报文，但是在17953/17954MES竟然收到了来自1500CPU对该客户端及端口的应用进行复位RST请求。
RST的目的就是关闭这个连接请求，于是S7客户端(MES)只能使用新的端口号Port：49586进行尝试连接。问题出现，这似乎说明问题来自PLC，似乎是PLC的通信连接资源未准备好，于是通知S7客户端不要进行此连接！
这时再来查看来自CPU侧的报文，找到端口号Port:49576来自MES的报文，在序号840处。这里看到S7客户端(MES)通过端口号Port：49576和1500CPU做了TCP的2次握手(840，841)这与MES侧相同，下面问题发生了，S7服务器竟然收到了来自S7客户端的RST请求，即序号842，然而这个报文没有在MES侧的报文中出现，那么这个报文是哪里来的？是不是非常有意外！但是从Seq和Ack号来看这个报文的就是MES侧17591，问题是17591经过了路由为什么会从Ack变为RST，Ack？
先描述一下这一段TCP报文的含义，抛开这个异常出现的报文842从哪里来的问题，首先，正常关闭TCP连接4次挥手并不是唯一的选择，RST也是关闭连接的一种方法，例如，如果主机认为对方或端口不可达，就会使用RST尽快关闭此连接。通常情况下使用RST报文，因为RST不是TCP通信连接的一部分。在842使用的RST，ACK报文是在3次握手连接中带ACK确认标志。
接着是843号报文，该报文的长度是60个字节，与MES侧的17591号报文对应，因为MES侧是在本机抓包，出口的报文54会被填充最小长度的以太网报文，于是在843出现了60个字节的长度应答。
TCP Acked unseen segment表示客户端10.61.3.110通知S7服务器10.18.61.8有数据包丢失，因为我们知道Ack号等于上一个TCP报文(服务器à客户端)中顺序号+Len，而在843号报文中的Ack=33554433，明显不知道应该如何计算出来的，这表明服务器发送的数据包有丢失的，可是网络状况十分良好，不会存在拥堵的情况，这说明这是一个来自客户端异常的报文。于是3次握手无法成功，导致连接无法建立，所以也就无法进行通信。(标蓝部分一直显示下面的图片)
接着是查看 Port:49586这一组连接报文，MES侧的18164到S7服务器侧消失了，这报文丢失了吗？网络状况完好的情况下到底时丢失了还是路由到甚至交换到其它地方？序号1011出现的TCP Out-Of-Order的原因表示1011的Seq=1比莫名其妙出现的1009号报文Seq=3的顺序号小，这表明TCP通信出现乱序，可是乱序为什么出现在网络状况良好，且在连接阶段呢？
再然后看这组报文中序号1010的目的IP地址为192.168.61.10，交换机网络按照目的MAC地址转发，为什么这里会出现不同的IP地址的单播报文？查看这个报文的MAC地址，该MAC地址竟然与10.18.61.8的MAC地址相同，怪不得会转发到这个S7服务器端。
可是不同的模块的MAC地址是不同的，为什么会出现相同的MAC地址？是来自S7客户端侧18164的变形吗？(标蓝两段一直显示下面图片内容)
基于这样的疑问，使用!ip.addr==10.16.3.110 &&!ip.addr==10.18.61.8过滤规则，查看其它的不属于该终端的IP地址，发现了有些不属于该终端的一些报文，黑色标识。特殊的是10.18.63.8这个IP地址并不存在于现场的设备中，但是报文中的MAC地址与192.168.61.8的MAC地址也相同。
还有一个需要注意的是2996号报文，实际上0网段的IP地址出现在集成的CPU上，可能是现场的接线有连接CP卡的地方，但是单播的IP报文通过交换机是怎么到达在10.18.63.8的CPU侧的呢？两者(192.168.0.219/192.168.0.203)的MAC地址与此CPU并不相同。
这一切都表明问题应该出现在虚拟机(MES)或者虚拟网络，路由器以及交换机的设置上。根据用户IT工程师描述，MES是在虚拟系统中，并且使用了虚拟网络技术，以及超融合技术，这些我们实在是爱莫能助了，只能看到问题的现象，并不清楚IT中心的网络是如何设计的，所以大家也可以在评论区分享你的相关经验，欢迎交流！
作者：赵欣
