Candela Technologies Logo
Network Testing and Emulation Solutions

Using Flent to Generate Traffic

Goal: Set up virtual stations using a LANforge system, connect them to an AP under test, set up Flent, and run tests.


In this test scenario a LANforge system is used to create both the wireless stations and Flent test setup. The tests can then be configured to use Flent to generate upload or download traffic.

FLENT - FLExible Network Tester is a set of python scripts that use various open-source tools to generate traffic and collect test data. Flent is developed and maintained by Toke Høiland-Jørgensen (@toke_dk)

One advantage to using Flent on LANforge is that a single LANforge box can send traffic to itself which eliminates the need for multiple systems to run client/server test traffic against a DUT.

 
  1. Install packages required to run Flent on Fedora-30.
    Additional packages may need to be installed. See flent.org for more info.
    1. Install automake and texinfo  
      sudo dnf install automake texinfo
    2. Flent  
      git clone https://github.com/tohojo/flent.git
      cd flent
      sudo python3 setup.py install
    3. Flent GUI - only necessary to view flent output graphs
      sudo dnf install python3-matplotlib python3-matplotlib-qt5
      sudo dnf install python3-qt5 python3-PyQt5 python3-QtPy
      sudo dnf install pyside2 pyside2-tools python3-pyside2
    4. Netperf/Netserver  
      git clone https://github.com/HewlettPackard/netperf.git
      cd netperf
      sudo ./autogen.sh
      sudo ./configure --enable-demo=yes
      sudo make
      sudo make install
    5. Fping  
      git clone https://github.com/schweikert/fping.com
      cd fping
      sudo ./autogen.sh
      sudo ./configure
      sudo make
      sudo make install
  2. To view a list of possible Flent tests, or run Flent by command line, open a terminal window.

    [lanforge@ct523c-0b29 ~]$ flent --list-tests 
    Available tests:
    bursts : Latency measurements under intermittent UDP bursts
    bursts_11e : 802.11e Latency measurements under intermittent UDP bursts
    cisco_5tcpup : RTT Fair Realtime Response Under Load
    cisco_5tcpup_2udpflood : Cisco 5TCP up + 2 6Mbit UDP
    cubic_bbr : Cubic VS BBR smackdown
    cubic_cdg : Cubic VS CDG smackdown
    cubic_dctcp : Cubic VS DCTCP smackdown
    cubic_ledbat : Cubic VS Ledbat smackdown
    cubic_ledbat_1 : Cubic vs LEDBAT upload streams w/ping
    cubic_reno : Cubic VS Reno smackdown
    cubic_westwood : Cubic VS Westwood
    dslreports_8dn : 8 down - dslreports dsl test equivalent
    http : HTTP latency test
    http-1down : HTTP get latency with competing TCP download stream
    http-1up : HTTP get latency with competing TCP upload stream
    http-rrul : HTTP get latency with competing RRUL test
    iterated_bidirectional : Iterated TCP bidirectional transfers example
    ledbat_cubic_1 : Cubic vs LEDBAT upload streams w/ping
    ping : Ping test (ICMP and UDP)
    qdisc-stats : Capture qdisc stats
    reno_cubic_westwood_cdg : Realtime Response Under Load
    (with different congestion control algs)
    reno_cubic_westwood_ledbat : Realtime Response Under Load
    (with different congestion control algs)
    reno_cubic_westwood_lp : Realtime Response Under Load
    (with different congestion control algs)
    rrul : Realtime Response Under Load
    rrul46 : Realtime Response Under Load - Mixed IPv4/6
    rrul46compete : Realtime Response Under Load - Mixed v4/v6 compete
    rrul_100_up : 100 up vs 1 down - exclusively Best Effort
    rrul_50_down : 50 down vs 1 up - exclusively Best Effort
    rrul_50_up : 50 up vs 1 down - exclusively Best Effort
    rrul_be : Realtime Response Under Load - exclusively Best Effort
    rrul_be_iperf : Realtime Response Under Load - exclusively Best Effort (Iperf TCP)
    rrul_be_nflows : Realtime Response Under Load - Best Effort, configurable no of flows
    rrul_cs8 : Realtime Response Under Load CS8, one flow per CS/precedence level
    rrul_icmp : Realtime Response Under Load - Best Effort, only ICMP ping
    rrul_noclassification : Realtime Response Under Load - no classification on data flows
    rrul_prio : Realtime Response Under Load - Test Prio Queue
    rrul_torrent : Torrent-like competition
    rrul_up : Realtime Response Under Load - upload only
    rrul_var : Realtime Response Under Load - variable configurable streams
    rtt_fair : RTT Fair Realtime Response Under Load
    rtt_fair4be : RTT Fair Realtime Response Under Load
    rtt_fair6be : RTT Fair Realtime Response Under Load
    rtt_fair_up : RTT Fair upstream only
    rtt_fair_var : RTT Fair - variable number of hosts
    rtt_fair_var_down : RTT Fair - variable number of hosts (download only)
    rtt_fair_var_mixed : RTT Fair - variable number of hosts (mixed up and down)
    rtt_fair_var_up : RTT Fair - variable number of hosts (upload only)
    sctp_vs_tcp : SCTP vs TCP
    tcp_12down : TCP download - 12 streams w/ping
    tcp_12up : TCP upload - 12 streams w/ping
    tcp_1down : Single TCP download stream w/ping
    tcp_1up : Single TCP upload stream w/ping
    tcp_1up_noping : Single TCP upload stream
    tcp_2down : TCP download - 2 streams w/ping
    tcp_2up : TCP upload - 2 streams w/ping
    tcp_2up_delay : Two TCP upload streams; 2nd stream started delayed
    tcp_2up_square : Two TCP upload streams; 2nd stream started delayed
    tcp_2up_square_westwood : Two TCP upload streams; 2nd stream started delayed
    tcp_4down : TCP download - 4 streams w/ping
    tcp_4up : TCP upload - 4 streams w/ping
    tcp_4up_squarewave : Four TCP upload streams; 2nd streams started delayed, cubic vs BBR
    tcp_6down : TCP download - 6 streams w/ping
    tcp_6up : TCP upload - 6 streams w/ping
    tcp_8down : TCP download - 8 streams w/ping
    tcp_8up : TCP upload - 8 streams w/ping
    tcp_bidirectional : Bidirectional TCP streams w/ping
    tcp_download : TCP download stream w/ping
    tcp_ndown : TCP download - N streams w/ping
    tcp_nup : TCP upload - N streams w/ping
    tcp_upload : TCP upload stream w/ping
    tcp_upload_1000 : 1000 up - exclusively Best Effort
    tcp_upload_prio : TCP upload stream w/ToS prio bits
    udp_flood : UDP flood w/ping
    udp_flood_var_up : UDP flood w/ping - variable number of hosts
    udp_flood_var_up_stagger : UDP flood w/ping - variable number of hosts, staggered start
    voip : VoIP one-way stream test
    voip-1up : VoIP one-way stream test with competing TCP stream
    voip-rrul : VoIP one-way stream test with competing RRUL test
  3. Enter interface names to be used in Flent tests into the /etc/hosts file.
    This is necessary for some of the Flent tools that can only use an interface name rather than IP address. screenshot
  4. To run Flent tests by command line:
    1. Run netserver. This will start the netserver program which is the traffic server for the other Flent tools specifically netperf.
      [lanforge@ct523c-0b29 ~]$ netserver
      Starting netserver with host 'IN(6)ADDR_ANY' port '12865' and family AF_UNSPEC
    2. Run one of the available tests. Because LANforge is using vrf, use the vrf_exec.bash script to specify which interface to run the test. The direction of the test is from the perspective of the wired interface. Use the --swap-up-down option to change the direction to the host interface which is the wireless station sta00000 in this example. screenshot
  5. To run Flent tests from the LANforge GUI, select the Generic tab from the main GUI window. screenshot
  6. Create the Flent netserver.
    Here it is useful to create one Generic endpoint to start netserver and one to stop it because the netserver program runs in the background once it is started. screenshot
  7. Create the Flent test or tests. screenshot
  8. To start any Flent test, start the netserver first, then start the tests one at a time. screenshot
  9. Use the Flent GUI to view Flent test results.
    [lanforge@ct523c-0b29 ~]$ flent-gui rtt_fair_var-2020-04-15T130555.781338.flent.gz
    screenshot
  10. Use the Flent GUI to compare Flent test results.
    [lanforge@ct523c-0b29 ~]$ flent-gui tcp_download-2020-04-15T112442.452934.flent.gz tcp_download-2020-04-15T113910.591355.flent.gz
    screenshot
  11. Flent batch files can be setup to run consecutive and repeated tests.

    [lanforge@ct523c-0b29 ~]$ cat flent-batch.txt

    [Batch::tcp-down]
    test_name = tcp_download
    hosts = sta00000
    title = sta00000-tcp-down rep:${repetition}
    filename_extra = sta00000-tcp-down-${repetition}
    repetitions = 5
    [Batch::tcp-up]
    test_name = tcp_upload
    hosts = sta00000
    title = sta00000-tcp-up rep:${repetition}
    filename_extra = sta00000-tcp-up-${repetition}
    repetitions = 5
    [Batch::rrul]
    test_name = rrul
    hosts = sta00000
    title = sta00000-rrul rep:${repetition}
    filename_extra = sta00000-rrul-${repetition}
    repetitions = 5\
    screenshot
  12. Flent batch results for rrul.
    The rrul test is the Realtime Response Under Load test which attempts to completely use up the link with four upstream TCP connections and four downstream TCP connections each with a different IP ToS setting plus ping and UDP to measure latency all running simultaneously for the purpose of exposing bufferbloat in the network under test. screenshot
  13. Flent batch results for five rrul repetitions. screenshot

Candela  Technologies, 2417 Main Street, Suite 201, Ferndale, WA 98248, USA
www.candelatech.com | sales@candelatech.com | +1.360.380.1618
Facebook | LinkedIn | Blog