Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
andrei123
New Contributor

Throughput problem with FGT 60D and PPPoE connection

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

 

 

 

1 Solution
freb
New Contributor

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.

View solution in original post

43 REPLIES 43
rdumitrescu
New Contributor III

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?

Dave_Hall
Honored Contributor

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

NSE4/FMG-VM64/FortiAnalyzer-VM/6.0 (FWF30E/FW92D/FGT200D/FGT101E/FGT81E)/ FAP220B/221C
ede_pfau
SuperUser
SuperUser

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.

Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
andrei123
New Contributor

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

 

 

Dave_Hall
Honored Contributor

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

NSE4/FMG-VM64/FortiAnalyzer-VM/6.0 (FWF30E/FW92D/FGT200D/FGT101E/FGT81E)/ FAP220B/221C
ede_pfau
SuperUser
SuperUser

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.

Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
andrei123
New Contributor

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

 

sylr
New Contributor

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.

emnoc
Esteemed Contributor III

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  

PCNSE NSE StrongSwan
Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors