X-Git-Url: https://gerrit.opnfv.org/gerrit/gitweb?a=blobdiff_plain;f=docs%2Ftesting%2Fuser%2Fconfigguide%2Ftrafficgen.rst;h=f9e2db115d748d85dfb1caf505f122a7e071daa0;hb=7e263087c47e471fff47f204e79d7fe21a56eaa9;hp=32fd738b45303951890e4542fa36c8d9d2d5011a;hpb=83e0a9fb40ba17a2d617e03d1d67938f568d5e65;p=vswitchperf.git diff --git a/docs/testing/user/configguide/trafficgen.rst b/docs/testing/user/configguide/trafficgen.rst index 32fd738b..f9e2db11 100644 --- a/docs/testing/user/configguide/trafficgen.rst +++ b/docs/testing/user/configguide/trafficgen.rst @@ -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 + +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, + } +