本期分享的案例是有線/無線網絡的相關問題。

背景介紹

客戶是一家鋁加工自動化產線的制造商，使用某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模塊等，近期才會出現這種比較明顯的問題?；灸芡茢啵W絡流量有變化，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再未出現丟包情況，正常與上位機通信。