Practical example: Why is the VPN file transfer speed only 20M? My corporate headquarters-branch has a 100M dedicated line!
Background
The client company is a clothing retail unit with about 300 employees, with its headquarters in Shenzhen and its branch in Haikou. In order to connect the headquarters and branches, the company purchased a 100M enterprise dedicated line and built an IPSEC VPN on a J router at the export to connect the two intranets. The general topology is shown in the figure below:
(1) Typical topology
(2) Current issues
The speed of copying files between the main and branch offices is only 20Mbps, which is not enough to meet the bandwidth of the dedicated line of 100M. However, after consulting a certain J router manufacturer, the IPSEC VPN throughput capacity can reach 200Mbps, so there is no equipment bottleneck problem.
Troubleshooting Analysis
Step 1: Confirm the problem
The speed at which the headquarters PC1 pulls files from the branch PC2 via FTP or SMB2:
The file is indeed around 20M, which is not enough for the 100M dedicated line. The next step is to see if it is a problem with the PC itself, that is, to test the intranet copy on both sides.
Step 2: Confirm whether the intranet transmission between the master and the branch is normal
The total-part local area network copy situation is as follows:
It can be seen that the FTP or SMB2 copy in the Gigabit LAN of the headquarters and branches can reach Gigabit, and the PCs at both ends confirm that there is no problem. But what I want to say is that there is a fundamental difference between running traffic in the LAN and running traffic across IPSEC:
- The LAN switch traffic is forwarded by hardware and has acceleration.
- IPSEC tunnel reservation is tunnel encapsulation CPU software forwarding, without acceleration.
The flow running problem of CPU forwarding is generally related to the number of sessions. The higher the number of sessions, the higher the total throughput can be, because the session flow will be processed by multiple threads based on different CPU cores. Hardware forwarding is high-speed forwarding, and the overall throughput can be increased without multiple sessions. The next step is to look at the number of SMB2 flow sessions.
Step 3: Confirm the data stream of SMB2 file copy
Capture the total-point file flow through the VPN tunnel and analyze the number of sessions:
It can be seen that there is only one session flow when copying files. Since the IPSEC tunnel is encapsulated by the egress router and then forwarded by the CPU, the throughput cannot be achieved if the number of sessions is too small. The next step is to run the IPerf3 flow test.
Step 4: IPerf3 multi-session flow test
The topology is still total-split into two PCs, one end is used as the IPerf3 server and the other end is the client, and the TCP flow test between them is as follows:
direction | Number of sessions | Throughput |
Headquarters -> Branch | 1 | 20Mbps up and down |
Headquarters -> Branch | 5 | Around 60Mbps |
Headquarters -> Branch | 10 | 100Mbps full dedicated line |
Headquarters<—Branch | 1 | 20Mbps up and down |
Headquarters<—Branch | 5 | Around 60Mbps |
Headquarters<—Branch | 10 | 100Mbps full dedicated line |
It can be seen that when 10 TCP flows are running simultaneously, the full 100M dedicated line bandwidth can be utilized.
Summary and solutions
(1) The summary is as follows
Since there is only one session for total-to-sub-copy files, the low forwarding throughput through the IPSEC VPN tunnel is in line with expectations. Running multiple session streams simultaneously will hit a higher performance bottleneck.
(2) Solution
There is no need to solve the problem. If you want to fully utilize the dedicated line bandwidth, multiple PCs can transfer files simultaneously. One-to-one is not enough.