背景介紹

客戶企業(yè)是一家300人左右規(guī)模的衣服零售單位，總部在深圳、分部在海口，為了打通總、分之間內(nèi)網(wǎng)互聯(lián)，企業(yè)購買了一條100M企業(yè)專線，并在出口某J路由器上做IPSEC VPN以打通兩端內(nèi)網(wǎng)。大致拓?fù)淙缦聢D所示：

(1) 典型拓?fù)?/strong>

(2) 目前問題

總分之間拷文件的速度僅有20Mbps吃不滿專線百兆的帶寬。而咨詢了某J路由器的廠商IPSEC VPN吞吐能力可達(dá)200Mbps，不存在設(shè)備瓶頸問題。

排障分析

第一步：確認(rèn)問題現(xiàn)象

通過FTP或者SMB2，總部PC1去拉取分支PC2的文件速率：

拷文件確實(shí)是20M上下，吃不滿百兆專線。下一步看看是不是PC自己的問題，即總-分兩邊自己的內(nèi)網(wǎng)拷貝測(cè)試。

第二步：確認(rèn)總-分自己內(nèi)網(wǎng)傳輸是否正常

總-分本地局域網(wǎng)拷貝的情況如下：

可以看到總-分部全千兆局域網(wǎng)中FTP或者SMB2拷貝是能達(dá)千兆的，兩端PC確認(rèn)均無問題。但我想說的是，其實(shí)局域網(wǎng)跑流和跨IPSEC跑流是有本質(zhì)區(qū)別的：

• 局域網(wǎng)交換機(jī)跑流是硬件轉(zhuǎn)發(fā)，有加速；
• IPSEC隧道保留是隧道封裝CPU軟件轉(zhuǎn)發(fā)，無加速。

CPU轉(zhuǎn)發(fā)的跑流問題一般和會(huì)話數(shù)有關(guān)，會(huì)話數(shù)越高能跑的總吞吐也就越高，因?yàn)闀?huì)話流會(huì)基于不同CPU核多線程處理。而硬件轉(zhuǎn)發(fā)則是高速轉(zhuǎn)發(fā)，無需多會(huì)話整體吞吐量也能跑上去。下一步看下SMB2流會(huì)話數(shù)。

第三步：確認(rèn)拷文件SMB2的數(shù)據(jù)流

抓取總-分通過VPN隧道傳文件流并分析會(huì)話數(shù)：

可以看到拷文件只有1條會(huì)話流，由于IPSEC隧道是經(jīng)出口路由器封裝后的CPU轉(zhuǎn)發(fā)，所以會(huì)話數(shù)太少吞吐量就起不來。對(duì)此下一步通過IPerf3跑流測(cè)試。

第四步：IPerf3多會(huì)話跑流測(cè)試

拓?fù)湟廊皇强?分兩臺(tái)PC，一端作為IPerf3服務(wù)器一端為客戶端，互跑TCP流測(cè)試如下：

可以看到10條TCP流同時(shí)跑的情況下是可以吃滿百兆專線帶寬的。

總結(jié)及解決方案

(1) 小結(jié)如下

由于總-分拷文件會(huì)話數(shù)只有1條，經(jīng)由IPSEC VPN隧道轉(zhuǎn)發(fā)吞吐量低符合預(yù)期，多會(huì)話流同時(shí)跑才會(huì)打到更高的性能瓶頸。

(2) 解決方案

無問題無需解決，要想跑滿專線帶寬，多臺(tái)PC同時(shí)傳文件就可以了，一對(duì)一是不行的。