今天写这篇文章，目的有2个，一个是想描述现场的故障信息，并向大家讨教解决方案，二是总结一下OEM用户/甲方的网络设计的粗粗建议，同样也希望大家给我一些建议。

前几天，我和另外一位西门子高级专家冯学卫一道去一家生产锂电池的高科技公司做了一次现场诊断，现场的设备提供来自一家国内知名的OEM厂商。

我和大家描述一下现场的故障，MES位于IT中心，使用第三方的驱动和现场的装置S7-1200和S7-1500通过工厂IT网络的路由做数据采集。对于S7-1200，无论是集成的PN口还是CP卡都无法与MES做S7连接，而S7-1500可以使用CP卡和MES做S7连接（实际上现场也出现过其中一个1500CP卡不通的），集成的CPU的PN接口却无法与MES通信。而为了测试这个故障，用户在现场也放了一台MES，与PLC的CP卡处在同一网段，无论是CPU还是CP卡，S7通信完全没有问题。这证明第三方的驱动和西门子的PLC通信没有问题。看到这里，大家会觉得故障的原因应该在工厂网络的路由上。但是在IT中心Ping现场的PLC都是<1ms，这说明链路是非常好的。

在现场我们先查看PLC的连接资源和硬件组态，这些都没有问题。我们也尝试了使用西门子SCALANCE XC208，设置为本地路由的方式，连接本地的MES，设置IP地址为IT中心MES的IP地址进行路由测试，也没有问题，到此这说明问题还是出现在IT中心的服务器出口到现场PLC之间的路径上。然后我们和IT工程师沟通，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/17954 MES竟然收到了来自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）或者虚拟网络，路由器以及交换机的设置上。RST报文是哪里产生的？路由的过程中为什么会丢失了报文？为什么出现相同MAC地址不同IP的报文？为什么会出现与此终端无关的单播报文？根据用户IT工程师描述，MES是在虚拟系统中，并且使用了虚拟网络技术，以及超融合技术，这些我们是在是爱莫能助了，只能看到问题的现象，不知道IT中心的网络是如何设计的，所以请求大家看看有没有先关经验分享交流一下。

结合现场我们在诊断过程中所遇到的网络问题，我觉得给OEM用户一些网络上建议。去过很多现场或者和用户交流，发现10个用户有9个用户无法提供现场网络的拓扑结构。在现场时，我想知道网络的连接，但是用户使用第三方非管理型的交换机，使用PRONETA无法浏览到网路的拓扑，还好用户的网络简单，装置全部是单机PLC，要么1200要么1500，直接连接到这个非管理型交换机上。但是我想抓包的时候却出现了问题，我无法做到使用报文来诊断，因为那个是非管型交换机，于是我只能向附近区域同事邮递借一台SCALANCE XC208，这样现场的时间就耽误了。所以我建议OEM用户，即使使用的是PLC单机设备，但是在车间汇聚的交换机建议使用管理型的交换机，例如SCALANCE XC224，因为管理型的交换机可以承担部分的网络管理功能，可以展现现场的完整的网络拓扑，可以查看现场的网络状态和带宽占用情况，可以检查网线的连接状态，可以设置VLAN和路由，这样的好处就是与其它网络隔离，责任分清！最后就是可以使用端口镜像进行报文捕捉进行分析。好处多多，极大的提高现场的生产效率。当然我相信论坛还是有很多OEM用户的，大家有没有一些更加具体的建议，我们在这里进行交流一下。

以上就是现场的诊断过程和向大家求助的两个话题，知识能力有限，可能有分析错误，欢迎大家给我们一些建议和指正，先行感谢！