- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
FortiGate 60D L2L IPSec Performance
Hello all, I' m testing L2L IPsec VPN performance between two 60D units (v5.2.1,build618) with traffic test (512B packets) using JSDU tools. Maximum bandwith I reached is appr. 53Mbps which is IMO too low compared to Fortinet docs (1Gbps - http://www.fortinet.com/sites/default/files/productdatasheets/FortiGate-60D.pdf). The unit is impossible to manage because of no response = 99% sys usage. The performance doesnt depend on which ISAKMP policy is in use (AES256-SHA1 or 3DES-SHA1). I' m not usiny ANY of the UTMs profiles. Does anyone have any idea to tune performance of 60D ? Thank you in advance.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
chances are that NPU offloading is off. A high CPU load is indicative of this. Please check using the CLI:
config vpn ipsec phase1-interface
edit some_phase1
set npu-offload enable
end
Did you mention which FortiOS version you are using? In v5.0.7 there seems to be a bug affecting IPsec performance. In this case give v5.2.1 a try.
Edit: OK, you're already using v5.2.1.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
thank you for the reply. I find out that there is a performance problem even on view of routing (routing between 2 WAN IF). JDSU tools generate packets with IP protocol No 254, which I suppose fortigate doesnt process by ASIC but CPU, causes high CPU load ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, I guess that's true. TCP and UDP are accelerated among others but not every arbitrary IP protocol. I would run tests with iperf/jperf to see what to expect for regular traffic.
Besides, the 60D is built using a System-on-chip (SoC2) which integrates a RISC CPU core with the Fortinet CP ASIC. As such the CPU performance is weak. As an indicator get the product matrix from Fortinet and compare SSL VPN performance. I've found that it correlates with CPU performance nicely. Except for the latest, greatest Fortigates which can accelerate SSL traffic as well.
If you need your FGT for non-TCP traffic throughput I'd rather consider replacing the model with a 80C or 80D (not 70D, 90D).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Funny that you mention that, I did testing with terremark and fortinet using the IXIA back in 2008 and we seen the same thing ( non vpn ) but un-recognized protocol#s generate higher CPU cycles. In our case it was proto# 255 iirc which didn't exist and probably still doesn't exists. I would test with expect traffic over the connection ( tcp #6, udp #14, or icmp #1 etc.....) kenJDSU tools generate packets with IP protocol No 254, which I suppose fortigate doesnt process by ASIC but CPU, causes high CPU load ?
PCNSE
NSE
StrongSwan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
emnoc wrote:Yep, I was curious whats going on :-). Anyway, my initial purpose of this was GRE over IPsec performance, so encrypting IP#47. I used iperf in the end, I reached 120Mbps @ 64kB TCP window, imo quite decent for my usage:-).
Funny that you mention that,
