The unit is set up with FortiOS 5.2.2 and has the wan1 port connected to the ISP with PPPoE (1Gb subscription).
If I connect the laptop or computer directly with PPPoE to the ISP I get ~800 Mb throughput (tested with speedtest, ISP's own speedtest and torrents). When I connect the Fortigate unit the throughput is capped at ~190 Mb (~140 with 5.2.5) and the unit stops responding (CPU 100%).
I tried the following configurations:
- internal lan in switch mode or in interface mode (hardware switch)
- tried with firmwares 5.0.10 and 5.2.1
The MTU for the PPPoE is 1492 so I also tried with mtu-overrride 1492 and still the same
The unit behaves the same in every situation high cpu and capped througput.
All the UTM features are turned off. All the tests are done with the basic configuration, just a policy from internal to wan1..
Also another strange thing is that when I test with the download limited ~100Mb so that the unit doesn't completely freeze I can see from the top command that the CPU is 50% hogged by the system, however there is no process in the list with that high of a load (if you add all the processes they add up to max 10%).
Any ideas would be greatly appreciated ..
I also noticed that the traffic is not going through the NP4Lite so I guess the 'Supports firewall acceleration across all packet sizes for maximum throughput' on the FGT 60D spec sheet on Fortinet website might be false advertising.
Update: There is no way that I found for a 60D to reach gigabit speeds on PPPoE connection. Max throughput is 140 Mb.
A workaround is to have another router in front of the 60D to do the PPPoe connection ( i got a Ubiquiti Edgemax Lite router for 100E that works amazing)
Best regards,
Andrei
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
I had the same issue with the 60d and gigabit internet with PPPOE. I never found a good solution, so I decided to upgrade. After weighing my options, sticking with an upgraded Fortigate seemed like the best bet (as opposed to going with a PFSense box, which would probably have been at least as expensive, or a Ubiquity EdgeRouter). My only question was would the 60e be able to handle the traffic.
I ended up going with the 80e for the extra ports, but the 60e should perform similarly. And yes, this device can more than handle PPPOE encapsulation and hit gigabit speeds without coming close to maxing out.
Hope that helps anyone considering an upgrade but not wanting to because they don't know if it will solve their bottleneck.
Hi,
perform a "diag hardware deviceinfo nic <interface name>" on the CLI and check for any errors.
Can you post the full config of the PPPoE port?
I'm suspecting the Fortigate's "WAN" interface may be is set for 100 Full duplex; as Radu indicated performing a "diag hardware deviceinfo nic <interface name>" on the CLI will show you what speed the "WAN" interface is set at and whether there are any errors. Also, it may be rare, but the MTU could be actually smaller, like 1452 or less.
You can try forcing the duplex/speed to 1000 full duplex, like so...
config system interface
edit "<interface>"
set speed 1000full
next
end
100% CPU usage doesn't sound normal. Do you have any of the interface ports in a software switch? I don't have access to a 60D, but from pics of it, it kinda looks like ports 1 through 5 is the internal switch interface and port 6/7 are "stand alones". Or is all 1-7 ports all part of the same interface?
Edit: CPU usage may be due to the interface "flapping" (wrong duplex/speed set on WAN interface). But one other thing you should try (if all possible) is to login/check the modem/gateway's own logs while the Fortigate is connected to it.
NSE4/FMG-VM64/FortiAnalyzer-VM/6.0 (FWF30E/FW92D/FGT200D/FGT101E/FGT81E)/ FAP220B/221C
Just my 2 cents as I'm using such a setup often:
- the 60D does have a hardware switch, for ports 1-7
- PPPoE as a protocol doesn't need much CPU power as it only negotiates once a day or so
but...if the PPP connection is disrupted for whatever reason after a few seconds then the FGT has to negotiate constantly, which in turn may cause high CPU.
So, I'd have a look at the modem while running, check the PPP daemon's output (diag deb app ppp -1) and try to hardwire the speed&duplex settings.
This is the result. It seems that the speed is negotiated ok:
diag hardware deviceinfo nic wan1
Driver Name :Fortinet NP4Lite Driver
Version :1.0.1
Admin :up
Current_HWaddr xx:xx:xx:xx:xx:xx
Permanent_HWaddr xx:xx:xx:xx:xx:xx
Status :up
Speed :1000
Duplex :Full
Host Rx Pkts :5944903
Host Rx Bytes :3656995896
Host Tx Pkts :4371030
Host Tx Bytes :1731860886
Rx Pkts :5959305
Rx Bytes :3761988324
Tx Pkts :4371030
Tx Bytes :1688262335
rx_buffer_len :2048
Hidden :No
cmd_in_list : 0
promiscuous : 1
interface configuration:
name : wan1
vdom : root
cli-conn-status : 2
mode : pppoe
distance : 5
priority : 0
dhcp-relay-service : disable
ip : 86.xx.74.xx 255.255.255.255
allowaccess : ping
fail-detect : disable
arpforward : enable
broadcast-forward : disable
bfd : global
l2forward : disable
icmp-redirect : enable
vlanforward : enable
stpforward : disable
ips-sniffer-mode : disable
ident-accept : disable
ipmac : disable
subst : disable
substitute-dst-mac : 00:00:00:00:00:00
status : up
netbios-forward : disable
wins-ip : 0.0.0.0
type : physical
netflow-sampler : disable
sflow-sampler : disable
sample-rate : 2000
polling-interval : 20
sample-direction : both
explicit-web-proxy : disable
explicit-ftp-proxy : disable
tcp-mss : 0
inbandwidth : 0
outbandwidth : 0
spillover-threshold : 0
weight : 0
external : disable
devindex : 5
description :
alias : xxx
l2tp-client : disable
security-mode : none
device-identification: disable
listen-forticlient-connection: disable
vrrp-virtual-mac : disable
vrrp:
--More-- snmp-index : 2
ipv6:
ip6-mode : static
ip6-allowaccess :
ip6-reachable-time : 0
ip6-retrans-time : 0
ip6-hop-limit : 0
ip6-address : ::/0
ip6-extra-addr:
ip6-send-adv : disable
autoconf : disable
dhcp6-relay-service : disable
dhcp-relay-ip :
dhcp-relay-type : regular
ipunnumbered : 0.0.0.0
username : xx
password : xx
idle-timeout : 0
detected-peer-mtu : 1452
disc-retry-timeout : 1
padt-retry-timeout : 1
service-name :
ac-name :
lcp-echo-interval : 5
--More-- lcp-max-echo-fails : 3
defaultgw : enable
PPPOE Gateway : 10.0.0.1
dns-server-override : enable
Acquired DNS1 : xx.231.xx.1
Acquired DNS2 : xx.154.xx.1
auth-type : auto
macaddr : xx:xx:xx:xx:xx:xx
speed : 1000full
mtu-override : enable
mtu : 1452
wccp : disable
drop-overlapped-fragment: disable
drop-fragment : disable
I never saw anything than 1000 Full. I hardcoded it but it's the same. Also I tried to lower the MTU to 1452 and no change. There are also no disconnects on the PPPoE....
And no errors on the interface:
wan1 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1488 Metric:1
RX packets:5960038 errors:0 dropped:0 overruns:0 frame:0
TX packets:4371743 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:8057309378 (7.5 GB) TX bytes:1688421832 (1.6 GB)
Unfortunately I am not able to check the gateway's logs because I don't have access to it.
I have left the internal interface now in switch mode.
Also, in the Fortiview/all sessions, the FortiASIC column is empty for all the entries so maybe hardware acceleration is not working and the traffic is processed by the CPU and not NPLite...
Thank you all
Has your ISP provided any of the information provided below? Usually you can find this in the modem/gw device settings (another list found here).
NSE4/FMG-VM64/FortiAnalyzer-VM/6.0 (FWF30E/FW92D/FGT200D/FGT101E/FGT81E)/ FAP220B/221C
Picking up the idea that ASIC offloading is not enabled:
for regular traffic you can only disable NPU offloading per policy. Offloading is enabled by default.
Check the 'internal' to 'wan' policy for this setting:
config firewall policy
set auto-asci-offload enable
endIMHO this is quite farfetched.
If you have started out after a 'factoryreset' then offloading will work by default.
Dave, the connection is a fiber directly into the ISP's router which is a Huawei and from that a gigabit link to the FGT. I don't have the VPI/VCI information but it seems that is specific to DSL connections.
The auto-asic-offload option is enabled in the policy configuration but even if it is enabled there it may not work. As stated in the hardware acceleration booklet from Fortinet there are several reasons why it may not work but I didn't identify any of those in my situation.
BR,
Andrei
I have the exact same problem with the same equipment FGT60D (fw 5.2.2) and my French fiber ISP Orange.
With the router given by my ISP I get 480mbit/s in download and 190mbit/s in upload. With the 60D in pppoe I have 180mbit/s in download max and the administration interface gets completely frozen while I'm hitting this throughput (both web and console).
Regards.
I'm consulting in Africa with a Orange provider, what I would do is look at the mtu again and then work with the ISP on any PPPoE counters and concentrate on looking for errors related to PPPoE. I believe you should be looking at a mtu setting of "1432" and not "1492". You can look at this with wireshark if your bored.
Now on to other issues and things to considered;
1: have you ran iperf/jperf testing between a local machine and the provider ( hopefully they have a local iperf server )
2: can you request this and run both udp and tcp tests and see the differences with these two layer4 protocols
3: When you used the computer, what was the MTU interface setting
4: can you downgrade the unit to an older code
5: you mention a direct fiber so that means something is used between you and the huawei Edge that gives you copper , can you clarify that
PCNSE
NSE
StrongSwan
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1516 | |
1013 | |
749 | |
443 | |
209 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.