背景介紹

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

(1) 典型拓撲

(2) 目前問題

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

排障分析

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

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

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

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

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

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

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

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

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

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

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

第四步：IPerf3多會話跑流測試

拓撲依然是總-分兩臺PC，一端作為IPerf3服務器一端為客戶端，互跑TCP流測試如下：

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

總結(jié)及解決方案

(1) 小結(jié)如下

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

(2) 解決方案

無問題無需解決，要想跑滿專線帶寬，多臺PC同時傳文件就可以了，一對一是不行的。