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