故障發(fā)生后，售后工程師被派往現(xiàn)場進行診斷！在現(xiàn)場我們發(fā)現(xiàn)S7-1200無論是集成的PN口還是CP卡都無法與MES做S7連接，而S7-1500可以使用CP卡和MES做S7連接，集成的CPU的PN接口卻無法與MES通信。
為了測試這個故障，用戶在現(xiàn)場也放了一臺MES，與PLC的CP卡處在同一網段，無論是CPU還是CP卡，S7通信完全沒有問題。這證明第三方的驅動和西門子的PLC通信沒有問題。看到這里，大家會覺得故障的原因應該在工廠網絡的路由上。但是在IT中心Ping現(xiàn)場的PLC都是<1ms，這說明鏈路是非常好的！
接著售后工程師先查看PLC的連接資源和硬件組態(tài)，這些都沒有問題，也嘗試了使用西門子SCALANCEXC208，設置為本地路由的方式，連接本地的MES，設置IP地址為IT中心MES的IP地址進行路由測試，也沒有問題，到此這說明問題還是出現(xiàn)在IT中心的服務器出口到現(xiàn)場PLC之間的路徑上。
IT工程師也說他們可以和第三方的PLC通信完全沒有問題，所以仍然無法說明問題出現(xiàn)在IT網絡上。于是，售后工程師在服務器側使用Wireshark進行抓包，即在服務器上安裝Wireshark，使用本地網卡捕捉MES與PLC的進出數(shù)據(jù)；同時在PLC側使用XC208做端口鏡像進行報文捕捉，以查看報文是否存在異常。結果有了驚人的發(fā)現(xiàn)！
為了更好的解釋報文，現(xiàn)場應用的MES“服務器”這3個字不再提起，因為在協(xié)議上MES為S7客戶端，S7的服務器自然是PLC，端口默認為102，這一點好多網友都知道，所以報文中的客戶端和服務器指的是S7協(xié)議層上的客戶端和服務器。
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進行嘗試連接。問題出現(xiàn)，這似乎說明問題來自PLC，似乎是PLC的通信連接資源未準備好，于是通知S7客戶端不要進行此連接！
這時再來查看來自CPU側的報文，找到端口號Port:49576來自MES的報文，在序號840處。這里看到S7客戶端(MES)通過端口號Port：49576和1500CPU做了TCP的2次握手(840，841)這與MES側相同，下面問題發(fā)生了，S7服務器竟然收到了來自S7客戶端的RST請求，即序號842，然而這個報文沒有在MES側的報文中出現(xiàn)，那么這個報文是哪里來的？是不是非常有意外！但是從Seq和Ack號來看這個報文的就是MES側17591，問題是17591經過了路由為什么會從Ack變?yōu)镽ST，Ack？
先描述一下這一段TCP報文的含義，拋開這個異常出現(xiàn)的報文842從哪里來的問題，首先，正常關閉TCP連接4次揮手并不是唯一的選擇，RST也是關閉連接的一種方法，例如，如果主機認為對方或端口不可達，就會使用RST盡快關閉此連接。通常情況下使用RST報文，因為RST不是TCP通信連接的一部分。在842使用的RST，ACK報文是在3次握手連接中帶ACK確認標志。
接著是843號報文，該報文的長度是60個字節(jié)，與MES側的17591號報文對應，因為MES側是在本機抓包，出口的報文54會被填充最小長度的以太網報文，于是在843出現(xiàn)了60個字節(jié)的長度應答。
TCP Acked unseen segment表示客戶端10.61.3.110通知S7服務器10.18.61.8有數(shù)據(jù)包丟失，因為我們知道Ack號等于上一個TCP報文(服務器à客戶端)中順序號+Len，而在843號報文中的Ack=33554433，明顯不知道應該如何計算出來的，這表明服務器發(fā)送的數(shù)據(jù)包有丟失的，可是網絡狀況十分良好，不會存在擁堵的情況，這說明這是一個來自客戶端異常的報文。于是3次握手無法成功，導致連接無法建立，所以也就無法進行通信。(標藍部分一直顯示下面的圖片)
接著是查看 Port:49586這一組連接報文，MES側的18164到S7服務器側消失了，這報文丟失了嗎？網絡狀況完好的情況下到底時丟失了還是路由到甚至交換到其它地方？序號1011出現(xiàn)的TCP Out-Of-Order的原因表示1011的Seq=1比莫名其妙出現(xiàn)的1009號報文Seq=3的順序號小，這表明TCP通信出現(xiàn)亂序，可是亂序為什么出現(xiàn)在網絡狀況良好，且在連接階段呢？
再然后看這組報文中序號1010的目的IP地址為192.168.61.10，交換機網絡按照目的MAC地址轉發(fā)，為什么這里會出現(xiàn)不同的IP地址的單播報文？查看這個報文的MAC地址，該MAC地址竟然與10.18.61.8的MAC地址相同，怪不得會轉發(fā)到這個S7服務器端。
可是不同的模塊的MAC地址是不同的，為什么會出現(xiàn)相同的MAC地址？是來自S7客戶端側18164的變形嗎？(標藍兩段一直顯示下面圖片內容)
基于這樣的疑問，使用!ip.addr==10.16.3.110 &&!ip.addr==10.18.61.8過濾規(guī)則，查看其它的不屬于該終端的IP地址，發(fā)現(xiàn)了有些不屬于該終端的一些報文，黑色標識。特殊的是10.18.63.8這個IP地址并不存在于現(xiàn)場的設備中，但是報文中的MAC地址與192.168.61.8的MAC地址也相同。
還有一個需要注意的是2996號報文，實際上0網段的IP地址出現(xiàn)在集成的CPU上，可能是現(xiàn)場的接線有連接CP卡的地方，但是單播的IP報文通過交換機是怎么到達在10.18.63.8的CPU側的呢？兩者(192.168.0.219/192.168.0.203)的MAC地址與此CPU并不相同。
這一切都表明問題應該出現(xiàn)在虛擬機(MES)或者虛擬網絡，路由器以及交換機的設置上。根據(jù)用戶IT工程師描述，MES是在虛擬系統(tǒng)中，并且使用了虛擬網絡技術，以及超融合技術，這些我們實在是愛莫能助了，只能看到問題的現(xiàn)象，并不清楚IT中心的網絡是如何設計的，所以大家也可以在評論區(qū)分享你的相關經驗，歡迎交流！
作者：趙欣
