Skip to main content
localhost
Visitor III
March 1, 2017
Question

diagnose traffictest

  • March 1, 2017
  • 1 reply
  • 86144 views

Since version 5.2.5 Fortinet has added the 'diagnose traffictest' command.

 

It appears to be an iperf3 running on the Fortigate.

But it seems you can only measure bandwith between interfaces on the Fortigate itself.

 

I tested some boxes:

 

FWF60D: 314 Mbit/s (wan1-internalswitch)

FG200b: 1.3GB/s (internal-port9)

FG400D: 15.2 GB/s (port9-port14)

 

I guess this should proof the firewall throughput? Is there a way to measure troughput between two Fortigates or even another iperf3 instance running on a non-fortinet device?

    1 reply

    AlexFeren
    New Member
    November 6, 2017

    > Is there a way to measure throughput between two Fortigates

    I don't know how, since "diagnose traffictest" is an iPerf v3 client (not server).

     

    > .. or even another iperf3 instance running on a non-fortinet device?

    Yes.

    1. set (remote) port to iPerf v3 default listening port 5201

    2. set server-intf to interface used to reach remote iPerf server

    3. use "diagnose traffictest run -c <remote_IPerf_ip>" (Don't ask why Fortinet didn't document "-c <ip>" argument - perhaps they thought it obvious.)

     

    Example:

    On Windows host:

    d:\Temp\iperf\iperf-3.1.3-win64>iperf3 -s ----------------------------------------------------------- Server listening on 5201 -----------------------------------------------------------

     

    On Fortigate:

    FWF61E # diagnose traffictest show server-intf:    lan client-intf:    wan1 port:   5201 proto:  TCP

    (Note: it don't matter what interface the client-inf is set to as long as it's got an IP address.)

    FWF61E # diagnose traffictest run -c 192.168.3.110 Connecting to host 192.168.3.110, port 5201 [  8] local 192.168.1.13 port 24762 connected to 192.168.3.110 port 5201 [ ID] Interval           Transfer     Bandwidth       Retr  Cwnd [  8]   0.00-1.01   sec  8.87 MBytes  73.9 Mbits/sec    0    209 KBytes        [  8]   1.01-2.00   sec  10.2 MBytes  86.0 Mbits/sec    0    214 KBytes        [  8]   2.00-3.01   sec  10.2 MBytes  85.3 Mbits/sec    0    214 KBytes        [  8]   3.01-4.01   sec  10.1 MBytes  84.8 Mbits/sec    0    214 KBytes        [  8]   4.01-5.01   sec  10.5 MBytes  88.0 Mbits/sec    0    214 KBytes        [  8]   5.01-6.01   sec  10.2 MBytes  85.6 Mbits/sec    0    214 KBytes        [  8]   6.01-7.01   sec  10.1 MBytes  84.4 Mbits/sec    0    214 KBytes        [  8]   7.01-8.01   sec  10.2 MBytes  85.2 Mbits/sec    0    214 KBytes        [  8]   8.01-9.01   sec  9.82 MBytes  82.4 Mbits/sec    0    214 KBytes        [  8]   9.01-10.00  sec  10.2 MBytes  85.9 Mbits/sec    0    214 KBytes        - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval           Transfer     Bandwidth       Retr [  8]   0.00-10.00  sec   100 MBytes  84.1 Mbits/sec    0             sender [  8]   0.00-10.00  sec   100 MBytes  84.1 Mbits/sec                  receiver iperf Done. iperf3: interrupt - the server has terminated

     

    BTW, I think non-zero receiver statistic is a bug - as iPerf client, Fortigate will act as a sender, not receiver. You can verify this using '--get-server-output' argument.

    emnoc
    New Member
    November 6, 2017

    I found the diag traffictest does not work very good or correct when subinterfaces and LAGs are built.

     

    fwiw to  toggle between TCP/UDP use proto 0 ( tcp )  or 1 ( udp )

     

    YMMV

     

    Ken

     

    localhost
    localhostAuthor
    Visitor III
    November 6, 2017

    Very cool!

     

    The problem that server mode (-s) is not working, is because there are apparently already some arguments passed through by the FortiOS to the iperf binary:

    "iperf3: parameter error - cannot be both server and client"

     

    Anyway, with -R you can also test the opposite direction:

    FW-1# diagnose traffictest run -c 1.2.3.4 -t 60 -R

    Connecting to host 1.2.3.4, port 4430 Reverse mode, remote host 1.2.3.4 is sending

     

    I had no issues with LAG and VLANs on a 400D running 5.2.10.