Merge "trex: Add support for burst traffic type"
[vswitchperf.git] / docs / testing / user / configguide / trafficgen.rst
index 32fd738..f9e2db1 100644 (file)
@@ -18,6 +18,7 @@ VSPERF supports the following traffic generators:
   * `Spirent TestCenter`_
   * `Xena Networks`_
   * MoonGen_
+  * Trex_
 
 To see the list of traffic gens from the cli:
 
@@ -38,12 +39,14 @@ and is configured as follows:
     TRAFFIC = {
         'traffic_type' : 'rfc2544_throughput',
         'frame_rate' : 100,
+        'burst_size' : 100,
         'bidir' : 'True',  # will be passed as string in title format to tgen
         'multistream' : 0,
         'stream_type' : 'L4',
         'pre_installed_flows' : 'No',           # used by vswitch implementation
         'flow_type' : 'port',                   # used by vswitch implementation
-
+        'flow_control' : False,                 # supported only by IxNet
+        'learning_frames' : True,               # supported only by IxNet
         'l2': {
             'framesize': 64,
             'srcmac': '00:00:00:00:00:00',
@@ -66,8 +69,29 @@ and is configured as follows:
             'priority': 0,
             'cfi': 0,
         },
+        'capture': {
+            'enabled': False,
+            'tx_ports' : [0],
+            'rx_ports' : [1],
+            'count': 1,
+            'filter': '',
+        },
+        'scapy': {
+            'enabled': False,
+            '0' : 'Ether(src={Ether_src}, dst={Ether_dst})/'
+                  'Dot1Q(prio={Dot1Q_prio}, id={Dot1Q_id}, vlan={Dot1Q_vlan})/'
+                  'IP(proto={IP_proto}, src={IP_src}, dst={IP_dst})/'
+                  '{IP_PROTO}(sport={IP_PROTO_sport}, dport={IP_PROTO_dport})',
+            '1' : 'Ether(src={Ether_dst}, dst={Ether_src})/'
+                  'Dot1Q(prio={Dot1Q_prio}, id={Dot1Q_id}, vlan={Dot1Q_vlan})/'
+                  'IP(proto={IP_proto}, src={IP_dst}, dst={IP_src})/'
+                  '{IP_PROTO}(sport={IP_PROTO_dport}, dport={IP_PROTO_sport})',
+        }
     }
 
+A detailed description of the ``TRAFFIC`` dictionary can be found at
+:ref:`configuration-of-traffic-dictionary`.
+
 The framesize parameter can be overridden from the configuration
 files by adding the following to your custom configuration file
 ``10_custom.conf``:
@@ -247,7 +271,7 @@ Ixia
 ----
 
 VSPERF can use both IxNetwork and IxExplorer TCL servers to control Ixia chassis.
-However usage of IxNetwork TCL server is a preferred option. Following sections
+However, usage of IxNetwork TCL server is a preferred option. The following sections
 will describe installation and configuration of IxNetwork components used by VSPERF.
 
 Installation
@@ -568,7 +592,7 @@ http://www.mono-project.com/docs/getting-started/install/linux/
 
     rpm --import "http://keyserver.ubuntu.com/pks/lookup?op=get&search=0x3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF"
     yum-config-manager --add-repo http://download.mono-project.com/repo/centos/
-    yum -y install mono-complete
+    yum -y install mono-complete-5.8.0.127-0.xamarin.3.epel7.x86_64
 
 To prevent gpg errors on future yum installation of packages the mono-project
 repo should be disabled once installed.
@@ -614,6 +638,37 @@ Each value modifies the behavior of rfc 2544 throughput testing. Refer to your
 Xena documentation to understand the behavior changes in modifying these
 values.
 
+Xena RFC2544 testing inside VSPerf also includes a final verification option.
+This option allows for a faster binary search with a longer final verification
+of the binary search result. This feature can be enabled in the configuration
+files as well as the length of the final verification in seconds.
+
+..code-block:: python
+
+    TRAFFICGEN_XENA_RFC2544_VERIFY = False
+    TRAFFICGEN_XENA_RFC2544_VERIFY_DURATION = 120
+
+If the final verification does not pass the test with the lossrate specified
+it will continue the binary search from its previous point. If the smart search
+option is enabled the search will continue by taking the current pass rate minus
+the minimum and divided by 2. The maximum is set to the last pass rate minus the
+threshold value set.
+
+For example if the settings are as follows
+
+..code-block:: python
+
+    TRAFFICGEN_XENA_RFC2544_BINARY_RESTART_SMART_SEARCH = True
+    TRAFFICGEN_XENA_2544_TPUT_MIN_VALUE = '0.5'
+    TRAFFICGEN_XENA_2544_TPUT_VALUE_RESOLUTION = '0.5'
+
+and the verification attempt was 64.5, smart search would take 64.5 - 0.5 / 2.
+This would continue the search at 32 but still have a maximum possible value of
+64.
+
+If smart is not enabled it will just resume at the last pass rate minus the
+threshold value.
+
 Continuous Traffic Testing
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -643,11 +698,15 @@ https://github.com/emmericp/MoonGen
 For VSPERF use, MoonGen should be cloned from here (as opposed to the
 previously mentioned GitHub):
 
-git clone https://github.com/atheurer/lua-trafficgen
+.. code-block:: console
+
+    git clone https://github.com/atheurer/lua-trafficgen
 
 and use the master branch:
 
-git checkout master
+.. code-block:: console
+
+    git checkout master
 
 VSPERF uses a particular Lua script with the MoonGen project:
 
@@ -683,3 +742,267 @@ set to allow for proper connections to the host with MoonGen.
     TRAFFICGEN_MOONGEN_BASE_DIR = ""
     TRAFFICGEN_MOONGEN_PORTS = ""
     TRAFFICGEN_MOONGEN_LINE_SPEED_GBPS = ""
+
+Trex
+----
+
+Installation
+~~~~~~~~~~~~
+
+Trex architecture overview and general installation instructions
+can be found here:
+
+https://trex-tgn.cisco.com/trex/doc/trex_stateless.html
+
+You can directly download from GitHub:
+
+.. code-block:: console
+
+    git clone https://github.com/cisco-system-traffic-generator/trex-core
+
+and use the same Trex version for both server and client API.
+
+**NOTE:** The Trex API version used by VSPERF is defined by variable ``TREX_TAG``
+in file ``src/package-list.mk``.
+
+.. code-block:: console
+
+    git checkout v2.38
+
+or Trex latest release you can download from here:
+
+.. code-block:: console
+
+    wget --no-cache http://trex-tgn.cisco.com/trex/release/latest
+
+After download, Trex repo has to be built:
+
+.. code-block:: console
+
+   cd trex-core/linux_dpdk
+   ./b configure   (run only once)
+   ./b build
+
+Next step is to create a minimum configuration file. It can be created by script ``dpdk_setup_ports.py``.
+The script with parameter ``-i`` will run in interactive mode and it will create file ``/etc/trex_cfg.yaml``.
+
+.. code-block:: console
+
+   cd trex-core/scripts
+   sudo ./dpdk_setup_ports.py -i
+
+Or example of configuration file can be found at location below, but it must be updated manually:
+
+.. code-block:: console
+
+   cp trex-core/scripts/cfg/simple_cfg /etc/trex_cfg.yaml
+
+For additional information about configuration file see official documentation (chapter 3.1.2):
+
+https://trex-tgn.cisco.com/trex/doc/trex_manual.html#_creating_minimum_configuration_file
+
+After compilation and configuration it is possible to run trex server in stateless mode.
+It is neccesary for proper connection between Trex server and VSPERF.
+
+.. code-block:: console
+
+   cd trex-core/scripts/
+   ./t-rex-64 -i
+
+**NOTE:** Please check your firewall settings at both DUT and T-Rex server.
+Firewall must allow a connection from DUT (VSPERF) to the T-Rex server running
+at TCP port 4501.
+
+**NOTE:** For high speed cards it may be advantageous to start T-Rex with more transmit queues/cores.
+
+.. code-block:: console
+
+   cd trex-cores/scripts/
+   ./t-rex-64 -i -c 10
+
+For additional information about Trex stateless mode see Trex stateless documentation:
+
+https://trex-tgn.cisco.com/trex/doc/trex_stateless.html
+
+**NOTE:** One will need to set up ssh login to not use passwords between the server
+running Trex and the device under test (running the VSPERF test
+infrastructure). This is because VSPERF on one server uses 'ssh' to
+configure and run Trex upon the other server.
+
+One can set up this ssh access by doing the following on both servers:
+
+.. code-block:: console
+
+    ssh-keygen -b 2048 -t rsa
+    ssh-copy-id <other server>
+
+Configuration
+~~~~~~~~~~~~~
+
+Connection information for Trex must be supplied inside the custom configuration
+file. The following parameters must be set to allow for proper connections to the host with Trex.
+Example of this configuration is in conf/03_traffic.conf or conf/10_custom.conf.
+
+.. code-block:: console
+
+    TRAFFICGEN_TREX_HOST_IP_ADDR = ''
+    TRAFFICGEN_TREX_USER = ''
+    TRAFFICGEN_TREX_BASE_DIR = ''
+
+TRAFFICGEN_TREX_USER has to have sudo permission and password-less access.
+TRAFFICGEN_TREX_BASE_DIR is the place, where is stored 't-rex-64' file.
+
+It is possible to specify the accuracy of RFC2544 Throughput measurement.
+Threshold below defines maximal difference between frame rate of successful
+(i.e. defined frameloss was reached) and unsuccessful (i.e. frameloss was
+exceeded) iterations.
+
+Default value of this parameter is defined in conf/03_traffic.conf as follows:
+
+.. code-block:: console
+
+    TRAFFICGEN_TREX_RFC2544_TPUT_THRESHOLD = ''
+
+T-Rex can have learning packets enabled. For certain tests it may be beneficial
+to send some packets before starting test traffic to allow switch learning to take
+place. This can be adjusted with the following configurations:
+
+.. code-block:: console
+
+    TRAFFICGEN_TREX_LEARNING_MODE=True
+    TRAFFICGEN_TREX_LEARNING_DURATION=5
+
+Latency measurements have impact on T-Rex performance. Thus vswitchperf uses a separate
+latency stream for each direction with limited speed. This workaround is used for RFC2544
+**Throughput** and **Continuous** traffic types. In case of **Burst** traffic type,
+the latency statistics are measured for all frames in the burst. Collection of latency
+statistics is driven by configuration option ``TRAFFICGEN_TREX_LATENCY_PPS`` as follows:
+
+    * value ``0`` - disables latency measurements
+    * non zero integer value - enables latency measurements; In case of Throughput
+        and Continuous traffic types, it specifies a speed of latency specific stream
+        in PPS. In case of burst traffic type, it enables latency measurements for all frames.
+
+.. code-block:: console
+
+    TRAFFICGEN_TREX_LATENCY_PPS = 1000
+
+SR-IOV and Multistream layer 2
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+T-Rex by default only accepts packets on the receive side if the destination mac matches the
+MAC address specified in the /etc/trex-cfg.yaml on the server side. For SR-IOV this creates
+challenges with modifying the MAC address in the traffic profile to correctly flow packets
+through specified VFs. To remove this limitation enable promiscuous mode on T-Rex to allow
+all packets regardless of the destination mac to be accepted.
+
+This also creates problems when doing multistream at layer 2 since the source macs will be
+modified. Enable Promiscuous mode when doing multistream at layer 2 testing with T-Rex.
+
+.. code-block:: console
+
+    TRAFFICGEN_TREX_PROMISCUOUS=True
+
+Card Bandwidth Options
+~~~~~~~~~~~~~~~~~~~~~~
+
+T-Rex API will attempt to retrieve the highest possible speed from the card using internal
+calls to port information. If you are using two separate cards then it will take the lowest
+of the two cards as the max speed. If necessary you can try to force the API to use a
+specific maximum speed per port. The below configurations can be adjusted to enable this.
+
+.. code-block:: console
+
+    TRAFFICGEN_TREX_FORCE_PORT_SPEED = True
+    TRAFFICGEN_TREX_PORT_SPEED = 40000 # 40 gig
+
+**Note::** Setting higher than possible speeds will result in unpredictable behavior when running
+tests such as duration inaccuracy and/or complete test failure.
+
+RFC2544 Validation
+~~~~~~~~~~~~~~~~~~
+
+T-Rex can perform a verification run for a longer duration once the binary search of the
+RFC2544 trials have completed. This duration should be at least 60 seconds. This is similar
+to other traffic generator functionality where a more sustained time can be attempted to
+verify longer runs from the result of the search. This can be configured with the following
+params
+
+.. code-block:: console
+
+    TRAFFICGEN_TREX_VERIFICATION_MODE = False
+    TRAFFICGEN_TREX_VERIFICATION_DURATION = 60
+    TRAFFICGEN_TREX_MAXIMUM_VERIFICATION_TRIALS = 10
+
+The duration and maximum number of attempted verification trials can be set to change the
+behavior of this step. If the verification step fails, it will resume the binary search
+with new values where the maximum output will be the last attempted frame rate minus the
+current set thresh hold.
+
+Scapy frame definition
+~~~~~~~~~~~~~~~~~~~~~~
+
+It is possible to use a SCAPY frame definition to generate various network protocols
+by the **T-Rex** traffic generator. In case that particular network protocol layer
+is disabled by the TRAFFIC dictionary (e.g. TRAFFIC['vlan']['enabled'] = False),
+then disabled layer will be removed from the scapy format definition by VSPERF.
+
+The scapy frame definition can refer to values defined by the TRAFFIC dictionary
+by following keywords. These keywords are used in next examples.
+
+* ``Ether_src`` - refers to ``TRAFFIC['l2']['srcmac']``
+* ``Ether_dst`` - refers to ``TRAFFIC['l2']['dstmac']``
+* ``IP_proto`` - refers to ``TRAFFIC['l3']['proto']``
+* ``IP_PROTO`` - refers to upper case version of ``TRAFFIC['l3']['proto']``
+* ``IP_src`` - refers to ``TRAFFIC['l3']['srcip']``
+* ``IP_dst`` - refers to ``TRAFFIC['l3']['dstip']``
+* ``IP_PROTO_sport`` - refers to ``TRAFFIC['l4']['srcport']``
+* ``IP_PROTO_dport`` - refers to ``TRAFFIC['l4']['dstport']``
+* ``Dot1Q_prio`` - refers to ``TRAFFIC['vlan']['priority']``
+* ``Dot1Q_id`` - refers to ``TRAFFIC['vlan']['cfi']``
+* ``Dot1Q_vlan`` - refers to ``TRAFFIC['vlan']['id']``
+
+In following examples of SCAPY frame definition only relevant parts of TRAFFIC
+dictionary are shown. The rest of the TRAFFIC dictionary is set to default values
+as they are defined in ``conf/03_traffic.conf``.
+
+Please check official documentation of SCAPY project for details about SCAPY frame
+definition and supported network layers at: http://www.secdev.org/projects/scapy
+
+#. Generate ICMP frames:
+
+   .. code-block:: console
+
+        'scapy': {
+            'enabled': True,
+            '0' : 'Ether(src={Ether_src}, dst={Ether_dst})/IP(proto={IP_proto}, src={IP_src}, dst={IP_dst})/ICMP()',
+            '1' : 'Ether(src={Ether_dst}, dst={Ether_src})/IP(proto={IP_proto}, src={IP_dst}, dst={IP_src})/ICMP()',
+        }
+
+#. Generate IPv6 ICMP Echo Request
+
+   .. code-block:: console
+
+        'l3' : {
+            'srcip': 'feed::01',
+            'dstip': 'feed::02',
+        },
+        'scapy': {
+            'enabled': True,
+            '0' : 'Ether(src={Ether_src}, dst={Ether_dst})/IPv6(src={IP_src}, dst={IP_dst})/ICMPv6EchoRequest()',
+            '1' : 'Ether(src={Ether_dst}, dst={Ether_src})/IPv6(src={IP_dst}, dst={IP_src})/ICMPv6EchoRequest()',
+        }
+
+#. Generate SCTP frames:
+
+   Example uses default SCAPY frame definition, which can reflect ``TRAFFIC['l3']['proto']`` settings. The same
+   approach can be used to generate other protocols, e.g. TCP.
+
+   .. code-block:: console
+
+        'l3' : {
+            'proto' : 'sctp',
+        },
+        'scapy': {
+            'enabled': True,
+        }
+