實戰案例：西門子工業場景注意了！車間上了一波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再未出現丟包情況，正常與上位機通訊。