实战案例：西门子工业场景注意了！车间上了一波PLC组态后致网络卡顿，原因是它！
本期分享的案例是有线/无线网络的相关问题。
客户是一家铝加工自动化产线的制造商，使用某P品牌的工业级产品（交换机、收发器、AP、CPE等）作为网络传输，目前在安徽某车间现场有网络问题，直接表现为上位机与PLC之间通信的丢包率高，影响业务运行停机。整个工业自动化采用的是Siemens（西门子）完成组态。
项目规模比较大，数百台网络设备，现场简化拓扑如下：
规划配置如下：
傻瓜式网络，网段为：172.20.240.0/24所有的路由器、交换机全部都是管理型设备问题现象有线侧的上位机和PC等设备，ping PLC等工业终端出现丢包3%以上丢包，业务通信经常告警。
排查思路针对这个丢包问题，一般我们考虑两种情况：
中间链路丢包：这个最常见，像这个拓扑就是交换机丢包终端设备收不过来：比较少见，比如这个拓扑中存在PLC收包异常导致无法响应，所以上位机ping其丢包及交互异常。基于此，我们需要一步步的从对比测试等步骤开始分析。
排查分析第一步：对比同一交换机下的PC是否丢包
将监控PC直接插在和PLC连接的接入交换机上，同时接入对照PC2作为对照组
监控PC分别ping PLC（172.20.240.71）和PC2（172.20.240.248）
测试结论：监控PC测试目标PLC丢包3%以上，ping PC2不丢包。大致能猜到实际是PLC收包或者回包异常，而非中间交换机链路的转发问题。
那么为什么会造成这样呢？
根据我们与现场人员的沟通了解到，是因为车间增加了许多PLC、I/O模块等，近期才会出现这种比较明显的问题。基本能推断，网络流量有变化，PLC可能收到了“某些东西“才会有这种表现，下来抓包。
第二步：分析抓取的网络环境包
通过对接入交换机连接PLC等设备的端口做“端口监控”：
我们发现网络中泛洪着大量的PN-PTCP这种报文：
该报文是二层报文，目的MAC是个组播MAC：01:80:c2:00:00:0e，也就是说网络中组播泛洪了。经了解，PN-PTCP即Profinet TCP，西门子私有协议，而我们看到的这种组播PN-PTCP则是西门子组态中用到的“时序同步”报文，基本上每个西门子PLC都会发。
第三步：流量分析
我们大概看了下，每台西门子PLC发PN-PTCP报文的速率是300个/秒，整网共有十几台西门子PLC，随意组播叠加总量在5000包/秒
所以我们有理由相信交换机对这些报文无条件转发，PLC彼此收到后导致自己的收包/发包性能异常了。如何解决？自然是控制转发了——做“组播抑制”！
解决方案从上文可知：西门子PLC收到了大量的PN-PTCP报文后自身收包/发包异常，需要在上联交换机做“组播抑制”，为了方便，全端口做。
完成配置后效果如下：
PN-PTCP报文泛洪抑制到了260包/秒，ping PLC再未出现丢包情况，正常与上位机通信。
