{"id":20074227,"url":"https://github.com/juniper/warp17","last_synced_at":"2025-04-05T08:07:07.667Z","repository":{"id":41432241,"uuid":"59734760","full_name":"Juniper/warp17","owner":"Juniper","description":"The Stateful Traffic Generator for Layer 1 to Layer 7","archived":false,"fork":false,"pushed_at":"2022-10-02T04:27:13.000Z","size":2892,"stargazers_count":430,"open_issues_count":35,"forks_count":81,"subscribers_count":50,"default_branch":"dev/common","last_synced_at":"2025-03-29T07:06:44.808Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"C","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"bsd-3-clause","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/Juniper.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2016-05-26T08:47:40.000Z","updated_at":"2025-03-22T08:29:47.000Z","dependencies_parsed_at":"2023-01-19T01:46:04.826Z","dependency_job_id":null,"html_url":"https://github.com/Juniper/warp17","commit_stats":null,"previous_names":[],"tags_count":9,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Juniper%2Fwarp17","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Juniper%2Fwarp17/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Juniper%2Fwarp17/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Juniper%2Fwarp17/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/Juniper","download_url":"https://codeload.github.com/Juniper/warp17/tar.gz/refs/heads/dev/common","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":247305934,"owners_count":20917208,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-13T14:49:58.740Z","updated_at":"2025-04-05T08:07:07.633Z","avatar_url":"https://github.com/Juniper.png","language":"C","funding_links":[],"categories":[],"sub_categories":[],"readme":"\u003cdiv align=\"center\"\u003e\n  \u003cimg src=\"images/logo.png\" width=\"40%\" alt=\"WARP17, The Stateful Traffic Generator\"\u003e\n\u003c/div\u003e\n\n\u003cp\u003e\n\u003cdiv align=\"center\"\u003e\n  \u003cimg src=\"https://travis-ci.org/Juniper/warp17.svg?branch=dev%2Fcommon\" alt=\"Build status\"\u003e\n\u003c/div\u003e\n\u003c/p\u003e\n\n_WARP17, The Stateful Traffic Generator for L1-L7_ is a lightweight solution\nfor generating high volumes of session based traffic with very high setup\nrates. WARP17 currently focuses on L5-L7 application traffic (e.g., _HTTP_)\nrunning on top of TCP as this kind of traffic requires a complete TCP\nimplementation.\nNevertheless, WARP17 also supports application traffic running on top of UDP.\n\nDeveloping network components or services usually requires expensive\nproprietary solutions for validating the implemented functionalities and\nscalability or performance requirements.\nWARP17 is a platform agnostic tool based on [DPDK](http://dpdk.org/) which:\n\n* allows extremely fast generation and sustaining of stateful sessions\n* offers configurable TCP/UDP infrastructure which can be used for generating\n  high connection setup and data rates for application traffic\n* is [Linux](https://kernel.org/) based so all the openly available tools can\n  be integrated by the users of WARP17.\n\nThe WARP17 TCP/IP implementation runs completely in user-space thus avoiding\nthe additional latency in the kernel stack. From a hardware perspective,\nWARP17 will be able to run on all the platforms that are supported by DPDK.\n\n# Performance benchmarks\n\nYou can find all the performance tests descriptions and the reference\nhardware architecture details in the [doc folder](./doc/Performance.md).\n\n## TCP setup and data rates for RAW application traffic\n\n__NOTE__: In the case when we only want to test the TCP control implementation\n(i.e., the TCP 3-way handshake and TCP CLOSE sequence), WARP17 achieved the\nmaximum setup rate of 8.5M clients/s and 8.5M servers/s, __so a total of\n17M TCP sessions are handled every second__.\n\nThe tests set up 20 million TCP sessions (i.e., 10 million TCP clients and 10\nmillion TCP servers) on which clients continuously send fixed size requests\n(with random payload) and wait for fixed size responses from the servers.\n\n* TCP raw traffic link utilization reaches line rate (40Gbps) as we increase\n  the size of the requests and responses. When line rate is achieved the number\n  of packets that actually make it on the wire decreases (due to the link\n  bandwidth):\n\n\u003cdiv align=\"center\"\u003e\n  \u003cimg src=\"./benchmarks/tcp_raw_link_usage.png\" width=\"49%\" alt=\"TCP raw link usage\"\u003e\n  \u003cimg src=\"./benchmarks/tcp_raw_pps.png\" width=\"49%\" alt=\"TCP raw pps\"\u003e\n\u003c/div\u003e\n\n* TCP raw traffic setup rate is stable at approximately\n  __7M sessions per second__ (3.5M TCP clients and 3.5M TCP servers per second)\n\n\u003cdiv align=\"center\"\u003e\n  \u003cimg src=\"./benchmarks/tcp_raw_setup.png\" width=\"49%\" alt=\"TCP raw setup rate\"\u003e\n\u003c/div\u003e\n\n## TCP setup and data rates for HTTP application traffic\n\nThe tests set up 20 million TCP sessions (i.e., 10 million TCP clients and 10\nmillion TCP servers) on which the clients continuously send _HTTP GET_\nrequests and wait for the _HTTP_ responses from the servers.\n\n* HTTP traffic link utilization reaches line rate (40Gbps) as we increase the\n  size of the requests and responses. When line rate is achieved the number\n  of packets that actually make it on the wire decreases (due to the link\n  bandwidth):\n\n\u003cdiv align=\"center\"\u003e\n  \u003cimg src=\"./benchmarks/tcp_http_link_usage.png\" width=\"49%\" alt=\"HTTP link usage\"\u003e\n  \u003cimg src=\"./benchmarks/tcp_http_pps.png\" width=\"49%\" alt=\"HTTP pps\"\u003e\n\u003c/div\u003e\n\n* HTTP traffic setup rate is stable at approximately\n  __7M sessions per second__ (3.5M HTTP clients and 3.5M HTTP servers per\n  second)\n\n\u003cdiv align=\"center\"\u003e\n  \u003cimg src=\"./benchmarks/tcp_http_setup.png\" width=\"49%\" alt=\"HTTP setup rate\"\u003e\n\u003c/div\u003e\n\n## UDP setup and data rates for RAW application traffic\n\nThe tests continuously send UDP fixed size packets (with random\npayload) from 10 million clients which are processed on the receing side by\n10 million UDP listeners.\n\n* UDP packets are generated at approximately __22 Mpps__ (for small packets) and\n  as we reach the link bandwidth the rate decreases.\n\n\u003cdiv align=\"center\"\u003e\n  \u003cimg src=\"./benchmarks/udp_raw_link_usage.png\" width=\"49%\" alt=\"UDP raw link usage\"\u003e\n  \u003cimg src=\"./benchmarks/udp_raw_pps.png\" width=\"49%\" alt=\"UDP raw pps\"\u003e\n\u003c/div\u003e\n\n# Installing and configuring\n\n## Prerequisites\n\nAny 64 bit Linux distribution will do, however we have been testing this with\nUbuntu Server 18.04 LTS. In addition we have made an OVF virtual machine image\navailable, details can be found in the respective [documentation](ovf/README.md).\n\n### Install DPDK\n\nRun the automated script with `\u003cversion\u003e` as 19.11.3 (the latest LTS supported by warp17)\n\n```\n# ./build_dpdk.sh -v \u003cversion\u003e\n```\n\n### Install Google Protocol Buffers\n\nRun `dep_install.sh` as root from the source folder\n\n```\n# ./dep_install.sh\n```\n\n## Get WARP17\nGet the `warp17-\u003cver\u003e.tgz` archive or clone the desired\n[release](https://github.com/Juniper/warp17/releases).\n\n## Compile WARP17\n\n```\ntar xfz warp17-\u003cver\u003e.tgz\ncd warp17-\u003cver\u003e\nmake\n```\n\n## Configure Python virtualenv (on Ubuntu)\n\n```\nsudo apt-get install python3-pip\nsudo pip install virtualenv\nvirtualenv warp17-venv\nsource warp17-venv/bin/activate\npip install -r python/requirements.txt\n```\n\nOnce installed, whenever python tests need to run the virtual environment must\nbe activated:\n\n```\nsource warp17-venv/bin/activate\n```\n\nTo exit the virtual environment and return to the default python interpretor\nand libraries:\n\n```\ndeactivate\n```\n\n## Configure DPDK ports\n\nUse the `$RTE_SDK/usertools/dpdk-setup.sh` script (as described in the\n[DPDK Guide](http://dpdk.org/doc/guides/linux_gsg/quick_start.html)). Select\nwhich ports to be controlled by the IGB UIO module: option `Bind\nEthernet/Crypto device to IGB UIO module`.\n\n# How to run\n\nFrom the top directory of WARP17:\n\n```\n./build/warp17 \u003cdpdk-command-line-args\u003e -- \u003cwarp17-command-line-args\u003e\n```\n\n## Running as non-root\n\nAfter compiling WARP17 change the owner of the binary to `root` (in order to\nallow access to `/proc/self/pagemap`:):\n\n```\nsudo chown root build/warp17\n```\n\nSet the `suid` bit on the binary in order to allow the user to keep\npermissions:\n\n```\nsudo chmod u+s build/warp17\n```\n\n## Command-line arguments\n\n### DPDK command-line arguments\n\n* `-c \u003chex_mask\u003e`: bitmask specifying which physical cores the application\n  will use. Each bit corresponds to a physical core (0-`\u003cmax_cores\u003e`).\n* `-n \u003cchan_no\u003e` : number of memory channels to be used.\n* `-m \u003cmem_in_MB\u003e`: total memory available to the application (in MB).\n\nPlease check section 3.1 of the\n[DPDK App Guide](http://dpdk.org/doc/guides/testpmd_app_ug/run_app.html) for\nmore info about DPDK command-line arguments.\n\n__NOTE: For now WARP17 supports at most 64 cores.__\n\n### WARP17 command-line arguments\n\n* `--version`: prints version and exit.\n* `--help`: prints the help and exit.\n* `--qmap \u003cport\u003e.\u003chex_mask\u003e`: bitmask specifying which physical cores will\n  control the physical port \u003ceth_port\u003e.\n* `--qmap-default max-c`: maximize the number of independent cores handling\n  each physical port.\n* `--qmap-default max-q`: maximize the number of transmit queues per physical\n  port.\n* `--tcb-pool-sz`: configure the size of the TCP control block pool (one TCB is\n  used per TCP connection endpoint). The size of the pool will be given by the\n  argument of this option multiplied by 1024. By default 10M TCBs are\n  allocated.\n* `--ucb-pool-sz`: configure the size of the UDP control block pool (one UCB is\n  used per UDP connection endpoint). The size of the pool will be given by the\n  argument of this option multiplied by 1024. By default 10M UCBs are\n  allocated.\n* `--mbuf-pool-sz`: configure the size of the packet pool. The size of the\n  pool will be given by the argument of this option multiplied by 1024. By\n  default 768K packets are allocated.\n* `--mbuf-sz`: configure the size of a packet fragment (mbuf) in bytes. By\n  default fragments are 2048 bytes.\n* `--mbuf-hdr-pool-sz`: configure the size of the packet headers pool. The\n  size of the pool will be given by the argument of this option multiplied by\n  1024. By default 512K packet headers are allocated.\n* `--mpool-any-sock`: configure if memory pools should be created from\n  any available memory if the local socket memory is exhausted. By default\n  this feature is disabled as it might affect performance.\n* `--ring-if-pairs`: configure the number of _in-memory-ring-based_ interfaces.\n  __NOTE: please check section\n  [Using In-Memory-Ring-Based Interfaces](#using-in-memory-ring-based-interfaces)\n  for more information.__\n* `--kni-ifs`: configure the number of _kni_ interfaces.\n  __NOTE: please check section\n  [Using Kernel Network Interface (KNI) Interfaces](#using-kernel-network-interface-kni-interfaces) for more information.__\n\n* `--cmd-file=\u003cfile\u003e`: CLI command file to be executed when the application\n  starts\n\n__NOTE: Options qmap, qmap-default max-c/max-q, cannot be combined. Only one can\nbe passed at a given time.__\n\n__NOTE: Users are encouraged to use the \"qmap-default max-q\" option whenever\nethernet ports are on the same socket as the PKT cores as this usually gives\nthe best performance!__\n\n__NOTE: The lowest two cores will be dedicated to CLI and management processing,\nand can not be assigned to a physical port for packet processing using the\n`--qmap` option!__\n\n### Example (on a x86 server with 32G RAM for WARP17 and 4 memory channels):\n\n* Determine the number of physical cores:\n\n\t```\n\t$ lscpu | grep \"CPU(s)\"\n\tCPU(s):                12\n\t```\n\n\tDecide how many cores WARP17 should use. In this example we consider WARP17\n    uses 8 cores:\n\t- cores 6, 7, 8, 9, 10, 11 for packet processing\n\t- cores 0, 1 for CLI and management\n\n\tBased on that we determine the bitmask corresponding to the ids of the cores\n    we would like to use. The bit index in the bit mask corresponds to the core\n    id:\n\n\t```\n\tBitmask:  0  0  0  0      1   1  1  1     1  1  0  0     0  0  1  1 =\u003e 0xFC3\n\tBit idx: 15 14 13 12     11  10  9  8     7  6  5  4     3  2  1  0\n\t```\n\n\tThis corresponds to the `-c` command line argument.\n\n* Determine the number of memory channels:\n\n\t```\n\t$ dmidecode | grep Channel\n\t    Bank Locator: P0_Node0_Channel0_Dimm0\n\t    Bank Locator: P0_Node0_Channel1_Dimm0\n\t    Bank Locator: P0_Node0_Channel2_Dimm0\n\t    Bank Locator: P0_Node0_Channel3_Dimm0  \u003c\u003c\u003c\u003c the system has 4 channels (0-3)\n\t```\n\n\tThe `-n` command line argument should be usually set to the max number of\n\tchannels available in the system.\n\n    WARP17 should be using 32G of memory in this example so the `-m` command\n    line argument should be set to 32768.\n\n\tIn order for WARP17 to use the default core to port mapping while\n\tmaximizing the number of transmit queues the `--qmap-default` command line\n\targument should be set to `max-q`.\n\n* _Optional_: the startup commands file can be specified through the `--cmd-file`\ncommand line argument.\n\nFor our example this translates into the following command:\n\n```\n./build/warp17 -c FC3 -n 4  -m 32768 -- --qmap-default max-q --tcb-pool-sz 32768 --cmd-file cfg.txt\n```\n\nwhich will start WARP17 with:\n\n* 8 cores to be used by the application (`-c FC3`):\n    - 2 cores will be used by CLI and MGMT\n    - 6 cores for processing packets\n* 4 mem channels (`-n 4`)\n* 32G of available memory (`-m 32768`)\n* all 6 PKT cores will process all physical ports (`--qmap-default max-q`)\n* allocates 32 million TCBs (`--tcb-pool-sz 32768`): for the configs in the\n  examples sections we need 20M TCBs, i.e., 10M clients and 10M servers.\n* will execute the CLI commands in file cfg.txt after starting WARP17\n\n### Using In-Memory-Ring-Based Interfaces\n\nWARP17 can also be run when no physical interface is available. This is\nespecially useful when developing new features as it removes the requirement\nof a specific hardware configuration. It also allows users to quickly try out\nWARP17 on their own laptop/VM.\n\n_In-Memory-Ring-Based Interfaces_ (let's just call them _ring interfaces_)\nare always created in pairs. The two interfaces in a pair act as if they\nwould be physical interfaces connected back to back.\n\nBy default the support for ring interfaces is disabled. However the user can\neasily enable it by compiling WARP17 with the following command:\n\n```\nmake all-ring-if\n```\n\nUsing the `--ring-if-pairs \u003cnumber\u003e` command line argument the user can\nspecify the number of ring interface pairs that WARP17 will create. Updating\nthe previous command line example we end up with:\n\n```\n./build/warp17 -c FC3 -n 4  -m 32768 -- --qmap-default max-q --tcb-pool-sz 32768 --ring-if-pairs 1 --cmd-file cfg.txt\n```\n\nThis will start WARP17 and add a pair of ring interfaces connected back to\nback.\n\nThe user can also use custom queue mappings for ring interfaces. The ring\ninterface pairs are always created after physical interfaces. This means that\ntheir IDs will be allocated in order after physical IDs. For example:\n\n```\n./build/warp17 -c FC3 -n 4  -m 32768 -w 0000:82:00.0 -- --ring-if-pairs 1\n```\n\nThis will start WARP17 with three interfaces (one physical and two ring\ninterfaces). The physical interface (`0000:82:00.0`) will have ID 0 while\nthe two ring interfaces will have IDs 1 and 2.\n\n__NOTE: There's a restriction in place when using ring interfaces: the user\nmust make sure that the same number of TX/RX queues is created through qmaps\nfor both ring interfaces in a pair. Otherwise the command line will be\nrejected.__\n\n### Using Kernel Network Interface (KNI) Interfaces\n\nWARP17 can also be run with a virtual interface into the Linux kernel. This\nis especially useful when developing a new protocol and you want to test it\nagains a known working server or client. See the HTTP example below.\n\nBy default the support for KNI interfaces is disabled. However the user can\neasily enable it by compiling WARP17 with the following command:\n\n```\nmake all-kni-if\n```\n\nUsing the `--kni-ifs \u003cnumber\u003e` command line argument the user can specify\nthe number of KNI interfaces that WARP17 will create. Updating\nthe previous command line example we end up with:\n\n```\n./build/warp17 -c FC3 -n 4  -m 32768 -- --qmap-default max-q --tcb-pool-sz 32768 --kni-ifs 2 --cmd-file cfg.txt\n```\n\nThe user can also use custom queue mappings for KNI interfaces, however they\ncan only be assigned to a single core. The KNI interfaces are always created\nafter the physical and ring interfaces. This means that\ntheir IDs will be allocated in order after physical IDs. For example:\n\n```\n./build/warp17 -c FC3 -n 4  -m 32768 -w 0000:82:00.0 -- --ring-if-pairs 1 --kni-ifs 2\n```\n\nThis will start WARP17 with five interfaces (one physical, two ring\ninterfaces and two KNI interfaces). The physical interface (`0000:82:00.0`)\nwill have ID 0, the two ring interfaces will have IDs 1 and 2, and the two\nKNI interfaces will have IDs 3 and 4.\n\nFor the example above the two Kernel interfaces will be named `warp3` and `warp4`,\nso the naming convention is `warp\u003ceth_port\u003e`\n\nThe following example will show how to use the KNI interface to get some HTTP\ndata from the built in HTTP server trough Linux. We assume no physical ports\nare configured, if you have them make sure you increase all the referenced\nports:\n\n* Load the `rte_kni` DPDK module (if needed), either as shown below or by\n  running the `$RTE_SDK/usertools/dpdk-setup.sh` script and selecting option\n  `Insert KNI module`:\n\n```\nsudo modprobe rte_kni\n```\n\n* Start WARP17 while blacklisting all physical devices (just for the purpose of\n  this test as otherwise the KNI interface name might differ):\n\n```\n./build/warp17 -c FC3 -n 4  -m 32768 -w 0000:00:00.0 -- --kni-ifs 1\n```\n\n* Configure the Linux kernel interface:\n\n```\nsudo ip link set warp0 up\nsudo ip addr add 172.16.1.1/24 dev warp0\n```\n\n* Configure WARP17 as follows:\n\n```\nadd tests l3_intf port 0 ip 172.16.1.2 mask 255.255.255.0\nadd tests l3_gw port 0 gw 172.16.1.1\nadd tests server tcp port 0 test-case-id 0 src 172.16.1.2 172.16.1.2 sport 80 80\nset tests server http port 0 test-case-id 0 200-OK resp-size 2000\nstart tests port 0\n```\n\n* Now do a HTTP request using wget:\n\n```\n[WARP17:~]$ wget 172.16.1.2\n--2016-10-25 11:40:43--  http://172.16.1.2/\nConnecting to 172.16.1.2:80... connected.\nHTTP request sent, awaiting response... 200 OK\nLength: 2000 (2.0K)\nSaving to: ‘index.html’\n\nindex.html                         100%[================================================================\u003e]   1.95K  --.-KB/s   in 0s\n\n2016-10-25 11:40:43 (478 MB/s) - ‘index.html’ saved [2000/2000]\n```\n\n\n# CLI\n\n## Test configuration commands\n\n__NOTE: Only IPv4 is supported for now!__\n\n* __Configure Ethernet Port MTU__:\n\n\t```\n\tset tests mtu port \u003ceth_port\u003e \u003cmtu-value\u003e\n\t```\n\n* __Add L3 interfaces__: configure an IP interface with the specified `ip`\n  address and `mask`. Currently only 10 IP interfaces are supported per port.\n\n\t```\n\tadd tests l3_intf port \u003ceth_port\u003e ip \u003cip\u003e mask \u003cmask\u003e\n\t```\n\n* __Add L3 default gateway__: configure 'gw' as the default gateway for\n  `eth_port`. There is only one default GW per port.\n\n\t```\n\tadd tests l3_gw port \u003ceth_port\u003e gw \u003cgw_ip\u003e\n\t```\n\n* __Add L3 interfaces with specific VLAN and GW__: Configure interfaces (Upto 10)\n  with a specified `ip` address/mask, `vlan-id` and `gw`. Each interface can be\n  in a different subnet and an unique vlan-id and gateway can be configured for\n  each.\n\n\t```\n\tadd tests l3_intf port \u003ceth_port\u003e ip \u003cip\u003e mask \u003cmask\u003e vlan-id \u003cvlan-id\u003e gw \u003cgw\u003e\n\t```\n\n  - The Grat Arp Req/Reply for the interfaces will be sent using the vlan-id configured.\n  - ARP request will be sent to the GW using the configured vlan-id.\n  - ARP reply packets will use the vlan-id from the ARP req packet.\n  - A per port per vlan-id GW table is maintained. The traffic streams will use this table\n    for next-hop GW lookup based on its vlan-id configurations (vlan-options per test-case-id).\n    A quick lookup is done on the per port per vlan id GW table; if no match is found then\n    the default GW configured for the port will be used.\n  - Currently only 10 IP interfaces are supported per port.\n\n* __Configure server test cases__: configure a server test case with ID\n  `test-case-id` on `eth_port`. The underlying L4 traffic can be TCP or UDP.\n  `ip_range` and `port_range` define the `\u003cip:port\u003e` sockets on which the\n  servers will be listening. By default, the application (L5-L7) traffic will\n  be RAW traffic.\n\n\t```\n\tadd tests server tcp|udp port \u003ceth_port\u003e test-case-id \u003ctcid\u003e\n\t                 src \u003cip_range\u003e sport \u003cport_range\u003e\n\t```\n\n* __Configure client test cases (per port)__: configure a client test case with\n  ID `test-case-id` on `eth_port`. The underlying L4 traffic can be TCP or UDP.\n  The source IP/l4-port and destination IP/l4-port ranges define the\n  `\u003csrc_ip, src_port:dst_ip, dst_port\u003e` TCP/UDP connections that will be\n  established. By default, the application (L5-L7) traffic will be RAW traffic.\n\n\t```\n\tadd tests client tcp|udp port \u003ceth_port\u003e test-case-id \u003ctcid\u003e\n\t                 src \u003cip-range\u003e sport \u003cl4-ports\u003e\n\t                 dest \u003cip-range\u003e dport \u003cl4-ports\u003e\n\t```\n\n* __Configure multicast source test cases (per port)__: configure a multicast\n  source test case with ID `test-case-id` on `eth_port`. The underlying L4\n  traffic can only be UDP. The source IP/l4-port and destination IP/l4-port\n  ranges define the `\u003csrc_ip, src_port:dst_ip, dst_port\u003e` UDP multicast streams\n  that will be generated. By default, the application (L5-L7) traffic will be\n  RAW traffic. Destination IP ranges must be valid IP Multicast ranges.\n\n\t```\n\tadd tests multicast-src udp port \u003ceth_port\u003e test-case-id \u003ctcid\u003e\n\t                        src \u003cip-range\u003e sport \u003cl4-ports\u003e\n\t                        dest \u003cip-mcast-range\u003e dport \u003cl4-ports\u003e\n\t```\n\n* __Configure test profile timeouts__: each test has a specific timeout profile\n  which is defined by the initial delay after which client connections are\n  initiated, how long a connection should live and how long a connection should\n  stay down (after closing) before the client reconnects.\n\n    - __initial_delay__: amount of time (in seconds) the clients defined in the\n      test should wait before initiating a connection. `infinite` is allowed but\n      doesn't really make sense for the initial delay as it would cause the\n      clients to never initiate a connection.\n\n\t\t```\n\t\tset tests timeouts port \u003ceth_port\u003e test-case-id \u003ctcid\u003e init \u003ctimeout\u003e|infinite\n\t\t```\n    - __conn_uptime__: amount of time (in seconds) the clients defined in the\n      test should keep the connection up (and send application traffic) before\n      initiating a close. `infinite` allows the clients to stay up forever.\n\n\t\t```\n\t\tset tests timeouts port \u003ceth_port\u003e test-case-id \u003ctcid\u003e uptime \u003ctimeout\u003e|infinite\n\t\t```\n    - __conn_downtime__: amount of time (in seconds) the clients defined in the\n      test should keep the connection down after a closebefore initiating a\n      reconnect. `infinite` allows the clients to stay down forever.\n\n\t\t```\n\t\tset tests timeouts port \u003ceth_port\u003e test-case-id \u003ctcid\u003e downtime \u003ctimeout\u003e|infinite\n\t\t```\n\n* __Configure test profile rates__: each test has a specific rate limiting\n  profile which is defined by the connection open, close and send rate.\n\n    - __setup rate__: number of connections that the clients in the test are\n      allowed to initiate __per second__. `infinite` removes any rate limiting\n      for initiating sessions (i.e., WARP17 will try to do it as fast as possible).\n\n\t\t```\n\t\tset tests rate port \u003ceth_port\u003e test-case-id \u003ctcid\u003e open \u003crate\u003e|infinite\n\t\t```\n    - __close rate__: number of connections that the clients in the test are\n      allowed to close __per second__. `infinite` removes any rate limiting for\n      closing sessions (i.e., WARP17 will try to do it as fast as possible).\n\n\t\t```\n\t\tset tests rate port \u003ceth_port\u003e test-case-id \u003ctcid\u003e close \u003crate\u003e|infinite\n\t\t```\n    - __data rate__: number of connections that the clients in the test are\n      allowed to send traffic on __per second__. `infinite` removes any rate\n      limiting for sending traffic (i.e., WARP17 will try to do it as fast as\n      possible).\n\n\t\t```\n\t\tset tests rate port \u003ceth_port\u003e test-case-id \u003ctcid\u003e send \u003crate\u003e|infinite\n\t\t```\n\n* __Configure test criteria__: different criteria can be configured for each\n  test case. The criteria will be used for declaring a test as _PASSED_ or\n  _FAILED_.\n    - __run-time__: declare the test case with ID `tcid` as _PASSED_ after\n      `value` seconds.\n\n\t\t```\n\t\tset tests criteria port \u003ceth_port\u003e test-case-id \u003ctcid\u003e run-time \u003ccount\u003e\n\t\t```\n    - __servers-up__: declare the test case with ID `tcid` as _PASSED_ when\n      `count` servers are UP (listening for incoming connections).\n\n\t\t```\n\t\tset tests criteria port \u003ceth_port\u003e test-case-id \u003ctcid\u003e servers-up \u003ccount\u003e\n\t\t```\n    - __clients-up__: declare the test case with ID `tcid` as _PASSED_ when\n      `count` clients are UP (ready to initiate a connection).\n\n\t\t```\n\t\tset tests criteria port \u003ceth_port\u003e test-case-id \u003ctcid\u003e clients-up \u003ccount\u003e\n\t\t```\n    - __clients-established__: declare the test case with ID `tcid` as _PASSED_\n      when `count` clients have established a connection.\n\n\t\t```\n\t\tset tests criteria port \u003ceth_port\u003e test-case-id \u003ctcid\u003e clients-estab \u003ccount\u003e\n\t\t```\n    - __data-MB__: declare the test case with ID `tcid` as _PASSED_ when\n      `count` MB of data have been sent. __NOTE: NOT supported yet!__\n\n\t\t```\n\t\tset tests criteria port \u003ceth_port\u003e test-case-id \u003ctcid\u003e data-MB \u003ccount\u003e\n\t\t```\n\n* __Configure tests as _asynchronous_:__ if multiple test cases are defined on\n  the same `eth_port`, by default, they will be executed in sequence (when a\n  test case ends the next one is started). To change the behaviour the user can\n  mark a test case as _async_ forcing the test engine to advance to the next\n  configured test case without waiting for the current one to finish.\n\n\t```\n\tset tests async port \u003ceth_port\u003e test-case-id \u003ctcid\u003e\n\t```\n\n* __Delete test cases__: delete a configured test case with ID `tcid` from port\n  `eth_port`.\n\n\t__NOTE: if a test case is already running it has to be stopped\n\tbefore it can be deleted!__\n\n\t```\n\tdel tests port \u003ceth_port\u003e test-case-id \u003ctcid\u003e\n\t```\n\n* __Start tests__: start all the test cases configured on `eth_port`. Test\n  cases will be started in sequence (after the previous test case ended) except\n  for the ones that are marked as _async_.\n\n\t```\n\tstart tests port \u003ceth_port\u003e\n\t```\n\n* __Stop tests__: stop all the test cases currently running on `eth_port`.\n\n\t```\n\tstop tests port \u003ceth_port\u003e\n\t```\n\n* __Customize TCP stack settings__: customize the behavior of the TCP stack\n  running on test case with ID `tcid` on port `eth_port`. The following\n  settings are customizable:\n\n  \t- `win-size`: the size of the TCP send window.\n\n\t\t```\n\t\tset tests tcp-options port \u003ceth_port\u003e test-case-id \u003ctcid\u003e win-size \u003csize\u003e\n\t\t```\n\n  \t- `syn-retry`: number of times to retry sending `SYN` packets before\n  \t  aborting the connection.\n\n\t\t```\n\t\tset tests tcp-options port \u003ceth_port\u003e test-case-id \u003ctcid\u003e syn-retry \u003ccnt\u003e\n\t\t```\n\n  \t- `syn-ack-retry`: number of times to retry sending `SYN + ACK` packets\n  \t  before aborting the connection.\n\n\t\t```\n\t\tset tests tcp-options port \u003ceth_port\u003e test-case-id \u003ctcid\u003e syn-ack-retry \u003ccnt\u003e\n\t\t```\n\n  \t- `data-retry`: number of times to retry sending data packets before\n  \t  aborting the connection.\n\n\t\t```\n\t\tset tests tcp-options port \u003ceth_port\u003e test-case-id \u003ctcid\u003e data-retry \u003ccnt\u003e\n\t\t```\n\n  \t- `retry`: number of times to retry sending other control packets before\n  \t  aborting the connection.\n\n\t\t```\n\t\tset tests tcp-options port \u003ceth_port\u003e test-case-id \u003ctcid\u003e retry \u003ccnt\u003e\n\t\t```\n\n  \t- `rto`: retransmission timeout (in ms) to be used before retransmitting\n  \t  a packet.\n\n\t\t```\n\t\tset tests tcp-options port \u003ceth_port\u003e test-case-id \u003ctcid\u003e rto \u003crto_ms\u003e\n\t\t```\n\n  \t- `fin-to`: `FIN` timeout (in ms) in order to avoid staying in state\n  \t  `FIN-WAIT-II` forever.\n\n\t\t```\n\t\tset tests tcp-options port \u003ceth_port\u003e test-case-id \u003ctcid\u003e fin-to \u003cfin_to_ms\u003e\n\t\t```\n\n  \t- `twait-to`: `TIME-WAIT` timeout (in ms) to wait before cleaning up the\n  \t  connection.\n\n\t\t```\n\t\tset tests tcp-options port \u003ceth_port\u003e test-case-id \u003ctcid\u003e twait-to \u003ctwait_to_ms\u003e\n\t\t```\n\n    - `orphan-to`: `ORPHAN` timeout (in ms) in order to avoid staying in state\n      `FIN-WAIT-I` forever.\n\n\t\t```\n\t\tset tests tcp-options port \u003ceth_port\u003e test-case-id \u003ctcid\u003e orphan-to \u003corphan_to_us\u003e\n\t\t```\n\n    - `twait_skip`: boolean to decide if state `TIME-WAIT` should be skipped or\n      not.\n\n\t\t```\n\t\tset tests tcp-options port \u003ceth_port\u003e test-case-id \u003ctcid\u003e twait-skip \u003c1|0\u003e\n\t\t```\n\n    - `ack-delay`: boolean to decide if `ACK` should be delayed (according to\n       [RFC1122, section 4.2.3.2](https://tools.ietf.org/html/rfc1122#section-4.2.3.2))\n       or not. By default `ACK` delay will be __disabled__.\n\n\t\t```\n\t\tset tests tcp-options port \u003ceth_port\u003e test-case-id \u003ctcid\u003e ack-delay \u003c1|0\u003e\n\t\t```\n\n* __Customize IPv4 stack settings__: customize the behavior of the IPv4 layer\n  running on test case with ID `tcid` on port `eth_port`. The following\n\tsettings are customizable:\n\n  \t- `tos`: the TOS field of the IPv4 header\n\n\t\t```\n\t\tset tests ipv4-options port \u003ceth_port\u003e test-case-id \u003ctcid\u003e tos \u003ctos-value\u003e\n\t\t```\n\n  \t- `dscp` and `ecn`: the DSCP/ECN field of the IPv4 header\n\n\t\t```\n\t\tset tests ipv4-options port \u003ceth_port\u003e test-case-id \u003ctcid\u003e dscp \u003cdscp-name\u003e ecn \u003cecn-name\u003e\n\t\t```\n\n  \t- `tx-timestamp` and `rx-timestamp`: allow warp17 to write/read timestamp\n  \toption in the IPv4 header (Warp17 will store timestamps according to\n  \t[RFC791, section 3.1](https://tools.ietf.org/html/rfc1122#page-36)).\n  \tWhen RX timestamping is enabled, latency statistics will also be computed.\n\n\t\t__NOTE: This might incur a small performance penalty.__\n\n\t\t```\n\t\tset tests ipv4-options port \u003ceth_port\u003e test-case-id \u003ctcid\u003e tx-timestamp|rx-timestamp \u003c0|1\u003e\"\n\t\t```\n\n* __Latency__: latency computation can be enabled on top of all the application\n  types using _IPv4 options_ or RAW timestamping. The latency config consists\n  of the following optional fields:\n\n    - `max` latency threshold: all incoming packets with a measured latency\n      higher than the configured `max` will be counted as\n      _threshold violations_.\n    - `max-avg` latency threshold: every time the average measured latency\n\t\t  is over the configured `max-avg` a new _threshold violation_ will be\n      counted.\n    - `samples` count: the number of __recent__ samples used for computing\n      recent statistics. __Global__ statistics are computed per test case using\n      all the received samples (not only the most recent ones).\n\n\t```\n\tset tests latency port \u003ceth_port\u003e test-case-id \u003ctcid\u003e max \u003cvalue\u003e max-avg\n\t \u003cvalue\u003e samples \u003cvalue\u003e\n\t```\n\n\t__NOTE: Latency configs make sense only if RX timestamping is enabled for the\n  same test case.__\n\n* __Customize Vlan Settings__: By default VLAN fields will not be set. VLANs can be enabled on\n    top of all the application types using _vlan-options_ configuration cli. Please also\n    take a look at __Add L3 (sub)interfaces with specific VLAN and GW__ section as well.\n    The vlan-id of the testcases should match with any of the interface level l3_intf\n    vlan-id configurations.\n\n    The vlan-options config consists of the following fields.\n    - `vlan-id`   : VLAN id to be used; Value from 1-4094 can be provided.\n\n    - `vlan-pri`  : VLAN priority field to be set; Value from 0-7 can be provided.\n\n        ```\n            set tests vlan-options port \u003ceth_port\u003e test-case-id \u003ctcid\u003e vlan-id \u003c1-4094\u003e vlan-pri \u003c0-7\u003e\"\n        ```\n        __NOTE-1: ```show tests vlan-options port \u003ceth_port\u003e test-case-id \u003ctcid\u003e``` can be used to\n        check the current vlan configuration.__\n\n        __NOTE-1: ```show tests config port \u003ceth_port\u003e``` can be used to\n        check the current vlan configuration on the l3_intf as well as testcases.__\n\n     __Example-1: To give vlan id of 100 to all the configured sessions on port 0 test-case 0\n                  please use the configuration as shown below.__\n     ```\n         add tests l3_intf port 0 ip 19.1.1.2 mask 255.255.255.0 vlan-id 100 gw 19.1.1.1\n         add tests client udp port 0 test-case-id 0 src 2.1.1.1 2.1.1.1 sport 1026 1026 dest 3.1.1.1 3.1.1.1 dport 1026 1026\n         set tests client raw port 0 test-case-id 0 data-req-plen 64 data-resp-plen 0\n         set tests vlan-options port 0 test-case-id 0 vlan-id 100 vlan-pri 7\n     ```\n\n     __Example-2: To send all the configured sessions on port 0 test-case 0\n                  without any VLANs using default-gw, please use the configuration as shown below.__\n\n     ```\n         add tests l3_intf port 0 ip 12.1.1.2 mask 255.255.255.0\n         add tests l3_gw port 0 gw 12.1.1.1\n         add tests client udp port 0 test-case-id 0 src 2.1.1.1 2.1.1.1 sport 1026 1026 dest 3.1.1.1 3.1.1.1 dport 1026 1026\n         set tests client raw port 0 test-case-id 0 data-req-plen 64 data-resp-plen 0\n     ```\n\n     __Example-3: Alternate way of doing Example-2.__\n\n     ```\n         add tests l3_intf port 0 ip 12.1.1.2 mask 255.255.255.0 vlan-id 0 gw 12.1.1.1\n         add tests client udp port 0 test-case-id 0 src 2.1.1.1 2.1.1.1 sport 1026 1026 dest 3.1.1.1 3.1.1.1 dport 1026 1026\n         set tests client raw port 0 test-case-id 0 data-req-plen 64 data-resp-plen 0\n     ```\n\n     __Example-4: To make each test-case-id 0 to use GW without a VLAN (12.1.1.1), test-case-id 1 to\n                  use GW with vlan-id 1000 (13.1.1.1), and test-case-id 1 to use GW with\n                  vlan-id 1001 (14.1.1.1)__\n\n     ```\n         add tests l3_intf port 0 ip 12.1.1.2 mask 255.255.255.0\n         add tests l3_gw port 0 gw 12.1.1.1\n         add tests l3_intf port 0 ip 13.1.1.2 mask 255.255.255.0 vlan-id 1000 gw 13.1.1.1\n         add tests l3_intf port 0 ip 14.1.1.2 mask 255.255.255.0 vlan-id 1001 gw 14.1.1.1\n         add tests client udp port 0 test-case-id 0 src 2.1.1.1 2.1.1.1 sport 1026 1026 dest 3.1.1.1 3.1.1.1 dport 1026 1026\n         set tests client raw port 0 test-case-id 0 data-req-plen 64 data-resp-plen 0\n         add tests client udp port 0 test-case-id 1 src 4.1.1.1 4.1.1.1 sport 1026 1026 dest 5.1.1.1 5.1.1.1 dport 1026 1026\n         set tests client raw port 0 test-case-id 1 data-req-plen 64 data-resp-plen 0\n         set tests vlan-options port 0 test-case-id 1 vlan-id 1000 vlan-pri 7\n         add tests client udp port 0 test-case-id 2 src 7.1.1.1 7.1.1.1 sport 1026 1026 dest 8.1.1.1 8.1.1.1 dport 1026 1026\n         set tests client raw port 0 test-case-id 2 data-req-plen 64 data-resp-plen 0\n         set tests vlan-options port 0 test-case-id 2 vlan-id 1001 vlan-pri 7\n     ```\n\n## Application configuration and statistics commands\n\nCurrently only _RAW TCP_ (L5-L7 payload is random) and a sub-set of _HTTP 1.1_\n(_GET_/_HEAD_ and _200 OK_/_404 NOT FOUND_) traffic is supported.\n\nBefore configuring the application behavior the user must have previously\ndefined the client or server test cases.\n\n* __HTTP 1.1 application traffic__: the _HTTP 1.1_ application allows the user\n  to simulate different types of HTTP requests (for clients) and responses\n  (for servers):\n    - __HTTP 1.1 client configuration__: _GET_/_HEAD_ requests are supported. A\n      `req-size` must also be specified (0 is also valid) in order to define\n      the size of the body of the HTTP request.\n\n\t\t```\n\t\tset tests client http port \u003ceth_port\u003e test-case-id \u003ctcid\u003e GET|HEAD \u003chost-name\u003e \u003cobj-name\u003e req-size \u003creq-size\u003e\n\t\t```\n\n    - __HTTP 1.1 request fields__: Any user specified fields can be added to the\n      HTTP request. The only constraint is that `Content-Length` cannot be\n      explicitly set by the user. Use a `set` command for each of the HTTP\n      fields that need to be set:\n\n\t\t```\n\t\tset tests client http port \u003ceth_port\u003e test-case-id \u003ctcid\u003e http-field \u003cplain text HTTP field\u003e\n\t\t```\n\n    - __HTTP 1.1 server configuration__: _200 OK_/_404 NOT FOUND_ responses are\n      supported. A `resp-size` must also be specified (0 is also valid) in order\n      to define the size of the body of the HTTP response.\n\n\t\t```\n\t\tset tests server http port \u003ceth_port\u003e test-case-id \u003ctcid\u003e 200-OK|404-NOT-FOUND resp-size \u003cresp-size\u003e\n\t\t```\n\n    - __HTTP 1.1 response fields__: Any user specified fields can be added to\n      the HTTP response. The only constraint is that `Content-Length` cannot be\n      explicitly set by the user. Use a `set` command for each of the HTTP\n      fields that need to be set:\n\n\t\t```\n\t\tset tests server http port \u003ceth_port\u003e test-case-id \u003ctcid\u003e http-field \u003cplain text HTTP field\u003e\n\t\t```\n\n    - __HTTP 1.1 global stats__: display (detailed) statistics for the ethernet ports\n      currently in use (e.g., allocation errors/parse errors). If detailed\n      stats are requested then the information is displayed per port + lcore.\n\n\t\t```\n\t\tshow http statistics [details]\n\t\t```\n\n* __RAW application traffic__: the RAW application emulates _request_ and\n  _response_ traffic. The client sends a request packet of a fixed configured\n  size and waits for a fixed size response packet from the server. The user\n  should configure the _request_/_response_ size for both client and server\n  test cases.\n\n\t__NOTE: the user has to make sure that the _request_/_response_\n\tsizes match between clients and servers!__\n\n\t```\n\tset tests client raw port \u003ceth_port\u003e test-case-id \u003ctcid\u003edata-req-plen \u003clen\u003e data-resp-plen \u003clen\u003e [rx-timestamp] [tx-timestamp]\n\t```\n\n\t```\n\tset tests server raw port \u003ceth_port\u003e test-case-id \u003ctcid\u003edata-req-plen \u003clen\u003e data-resp-plen \u003clen\u003e [rx-timestamp] [tx-timestamp]\n\t```\n\n  Both CLI commands support additional RX/TX timestamping options. If\n  `rx-timestamp` is set, the Warp17 traffic engine will timestamp packets at\n  ingress and the RAW application will compute latency statistics when\n  incoming packets have TX timestamp information embedded in their payload. If\n  `tx-timestamp` is set RAW application clients will embed TX timestamps in the\n  first 16 bytes of the application payload. The RX/TX timestamps are both\n  computed early in the packet loop in order to be as precise as possible when\n  measuring latency.\n\n* __IMIX application traffic__: multiple application configurations can be\n  grouped in IMIX groups (i.e., Internet Mix traffic). Each application within\n  a group has an associated weight. When an IMIX test starts the weights of\n  each application are taken into account for determining how often the\n  application will be represented in the final traffic profile. Test case\n  rates (i.e., open, send, close) are also enforced according to the weights\n  of each application.\n\n\t```\n\tset tests imix app-index \u003capp-index\u003e \u003capplication-configuration\u003e\n\t```\n\n  The user can associate an application configuration to an IMIX application\n  index. Then the user should associate a weight with the given IMIX\n\tapplication index:\n\n\t```\n\tset tests imix app-index \u003capp-index\u003e weight \u003cweight\u003e\n\t```\n\n\tFinally, multiple IMIX application indices can be used within an IMIX group:\n\n\t```\n\tadd tests imix-id \u003cimix-group-id\u003e app \u003clist-of-imix-app-indices\u003e\n\t```\n\n  The IMIX group can be used as an application configuration for a traffic\n  test case:\n\n\t```\n\tset tests imix port \u003ceth-port\u003e test-case-id \u003ctest-case-id\u003e imix-id \u003cimix-group-id\u003e\n\t```\n\n\n## Displaying test information\n\n* __Current test configuration__: the current test configuration (including per\n  port L3 interfaces and default gateway) will be displayed for a given ethernet\n  port.\n\n\t```\n\tshow tests config port \u003ceth_port\u003e\n\t```\n\n* __Current test state__: the current test state (including per test case\n  quick statistics) will be displayed for a given ethernet port.\n\n\t```\n\tshow tests state port \u003ceth_port\u003e\n\t```\n\n* __Detailed test statistics__: the detailed test staistics will be displayed\nfor a given ethernet port and test-case.\n\n\t```\n\tshow tests stats port \u003ceth_port\u003e test-case-id \u003ctcid\u003e\n\t```\n\n## Statistics and operational information\n\nDifferent types of statistics can be dumped from the CLI. Currently all these\nstats are not directly linked to any test case ID but they are aggregate per\nethernet port.\n\n* __Port information and statistics__\n    - __Port information__: display general port information.\n\n\t\t```\n\t\tshow port info\n\t\t```\n\n    - __Port-core mappings__: display the mappings between ethernet port RX/TX\n      queues and lcore IDs. The socket IDs of the ports and lcores are also\n      displayed.\n\n\t\t__NOTE: Having lcores handling ports that have their PCI bus on a different\n\t\tsocket than the lcore will affect performance!__\n\n\t\t```\n\t\tshow port map\n\t\t```\n\n    - __Port link information__: display the current link status of the ethernet\n      ports.\n\n\t\t```\n\t\tshow port link\n\t\t```\n\n    - __Port statistics__: display (detailed) statistics for the ethernet ports\n      currently in use (e.g., _received/transmitted packets/bytes_). If detailed\n      stats are requested then the information is displayed per port + lcore.\n\n\t\t```\n\t\tshow port statistics [details]\n\t\t```\n\n* __Ethernet statistics__: display (detailed) statistics regarding the Ethernet\n  layer processing (e.g., _ethernet type, errors_). If detailed stats are\n  requested then the information is displayed per port + lcore.\n\n\t```\n\tshow ethernet statistics [details]\n\t```\n\n* __ARP information and statistics__\n    - __ARP tables__: display the ARP tables for each ethernet port currently in\n      use. For now L3 interfaces are defined per ethernet port and not per test\n      case ID. This enforces a unique ARP table per port.\n\n\t\t__NOTE: The current ARP implementation is limited in the sense that whenever tests\n\t\tare started on a port, gratuituous ARPs are sent for all the L3 interfaces that were\n\t\tdefined on that port and an ARP request is sent for the default gateway.\n\t\tAll ARP requests and replies are properly processed but there is no timeout\n\t\tmechanism in place for aging entries!__\n\n\t\t```\n\t\tshow arp entries\n\t\t```\n\n    - __ARP statistics__:  display (detailed) statistics regarding ARP\n      processing (e.g., _request/response count, errors_). If detailed stats\n      are requested then the information is displayed per port + lcore.\n\n\t\t```\n\t\tshow arp statistics [details]\n\t\t```\n\n* __Route statistics__: display (detailed) statistics for the routing module\n  (e.g., _interface/gateway creation/deletion count, errors_). The current\n  routing implementation is minimal and only handles L3 interface\n  creation/deletion and default gateways.\n\n\t```\n\tshow route statistics [details]\n\t```\n\n* __IPv4 statistics__: display (detailed) statistics regarding IPv4 processing\n  (e.g., _received packet/bytes counts, per L4 protocol counters, errors_). If\n  detailed stats are requested then the information is displayed per\n  port + lcore.\n\n\t```\n\tshow ipv4 statistics [details]\n\t```\n\n* __TCP statistics__: display (detailed) statistics regarding TCP processing\n  (e.g., _received packets/bytes counts, sent control/data packets/bytes counts,\n  allocation counters, errors_). If detailed stats are requested then the\n  information is displayed per port + lcore.\n\n\t```\n\tshow tcp statistics [details]\n\t```\n\n* __TCP state machine statistics__: display (detailed) statistics regarding\n  TCP state machine processing (e.g., _per TCP state counters, retransmission\n  counters, missing sequence counters_). If detailed stats are requested then\n  the information is displayed per port + lcore.\n\n\t```\n\tshow tsm statistics [details]\n\t```\n\n* __UDP statistics__: display (detailed) statistics regarding UDP processing\n  (e.g., _received packets/bytes counts, sent packets/bytes counts, allocation\n  counters, errors_). If detailed stats are requested then the information\n  is displayed per port + lcore.\n\n\t```\n\tshow udp statistics [details]\n\t```\n\n* __Timer statistics__: there are currently three types of supported timers:\n  _fast_ retransmission timers, slow_ timers (e.g., TIME-WAIT) and _test_\n  timers. _Test_ timers are used by the test engine and the others are used\n  by the TCP/UDP stack implementations. The command displays (detailed)\n  statistics regarding these types of timers. If detailed stats are requested\n  then the information is displayed per port + lcore.\n\n\t```\n\tshow timer statistics [details]\n\t```\n\n## Infrastructure statistics\n\n* __Message queues statistics__: all communication between lcores (PKT or CLI)\n  is done by means of message passing. Each lcore has two message queues (a\n  local and a global queue storing messages based on the originator of the\n  message). The command displays (detailed) statistics regarding the message\n  queues (e.g., _messages sent/received/allocated, errors_). If detailed stats\n  are requested then the information is displayed per port + lcore.\n\n\t```\n\tshow msg statistics [details]\n\t```\n\n* __Memory statistics__: most of the memory used during the tests is allocated\n  from different mempools (mbufs, TCP/UDP control blocks). The command displays\n  (detailed) statistics regarding the usage of the memory pools. If detailed\n  stats are requested then the information is displayed per port + lcore.\n\n\t```\n\tshow memory statistics [details]\n\t```\n\n* __Modifying Log Levels__: allow the user to change the syslog verbosity.\n\n    ```\n    set syslog \u003clevel\u003e\n    ```\n\n    Available log levels (corresponding to DPDK log levels):\n    - `EMERG`: System is unusable.\n    - `ALERT`: Action must be taken immediately.\n    - `CRIT`: Critical conditions.\n    - `ERR`: Error conditions.\n    - `WARNING`: Warning conditions.\n    - `NOTICE`: Normal but significant condition.\n    - `INFO`: Informational.\n    - `DEBUG`: Debug-level messages.\n\n# UI\n\n`show tests ui` displays an UI which allows monitoring the test execution.\n\nThe UI is split in 4 main areas:\n\n* test status area\n* detailed test statistics area: Open/Closed/Send statistics and Application\n  statistics are displayed for the currently selected test case.\n* detailed test configuration area: display the complete configuration of the\n  currently selected test case. The user can navigate between test cases\n  by pressing `n` for moving to the next test case and `b` for moving to the\n  previous test case. Switching between the configuration view and statistics\n  view can be done using the `c` and `s` keys.\n* statistics area: for each of the ethernet ports various statistics will be\n  displayed for all levels of the TCP/IP stack.\n\n# Example run\nSome example configuration files can be found in the `examples/` directory. The\nconfiguration files can either be passed as a command-line argument, `--cmd-file=\u003cfile\u003e`, when running\nWARP17 or executed directly in the CLI.\n\n* __examples/test\\_1\\_raw\\_tcp\\_connection.cfg__: single TCP client-server\n  connection on a back to back setup using _RAW_ application data (requests of\n  size 100 and responses of size 200 bytes). The client connects immediately\n  when the test starts and sends requests continuously (and waits for responses)\n  until the `uptime` expires (5 seconds), closes the connection and reconnects\n  after the `downtime` expires (15 seconds).\n\n* __examples/test\\_2\\_raw\\_udp\\_connection.cfg__: single UDP client-server\n  connection on a back to back setup using _RAW_ application data (requests of\n  size 100 and responses of size 200 bytes). The client connects with a delay\n  of 10 seconds (`init`) then sends requests continuously (and waits for\n  responses) until the `uptime` expires (5 seconds), closes the connection and\n  reconnects `downtime` expires (15 seconds).\n\n* __examples/test\\_3\\_http\\_multiple.cfg__: two client test cases each with a\n  single HTTP client. The first client test case sends _GET_ requests while\n  the second one sends _HEAD_ requests. The first test case is marked as\n  _async_ which will determine WARP17 to start both of them in parallel. The\n  HTTP server test case is configured to reply with _200 OK_.\n\n* __examples/test\\_4\\_http\\_10M_sessions.cfg__: single test case per port\n  configuring 10M HTTP sessions. The test case on port 0 will establish\n  connections from `10.0.0.1:[10000, 60000)` to `10.0.0.253:[6000, 6200)`.\n  On each of those connections HTTP _GET_ requests will be sent continuously\n  until the `uptime` of 30 seconds expires. Then the connections are closed.\n  After another 15 seconds of `downtime` the clients reconnect and start over.\n\n* __examples/test\\_5\\_raw\\_10M\\_sessions.cfg__: single test case per port\n  configuring 10M RAW sessions. The test case on port 0 will establish\n  connections from `10.0.0.1:[10000, 60000)` to `10.0.0.253:[6000, 6200)`.\n  On each of those connections RAW requests of size 1K will be sent\n  continuously. `uptime` is configured as `infinite` so the clients will\n  stay UP forever. If the connection goes down (e.g., TCP session fails)\n  then the client will reconnect after a `downtime` of 10 seconds.\n  The RAW servers reply with responses of size 4K. The clients are also rate\n  limited to 1M sessions/s `open` and 900K sess/s `send` rate (clients will)\n\n* __examples/test\\_6\\_http\\_40M\\_sessions.cfg__: single test case per port\n  configuring __40M HTTP sessions__. The test case on port 0 will establish\n  connections from `[10.0.0.1, 10.0.0.4]:[10000, 60000)` to\n  `10.0.0.253:[6000, 6200)`. On each of those connections HTTP _GET_\n  requests will be sent continuously.\n\n* __examples/test\\_7\\_routing\\_raw\\_8M\\_sesssions.cfg__: example config to\n  be used when having (multiple) routers in between the client and server\n  ports.\n\n* __examples/test\\_8\\_http\\_fields.cfg__: example showing how to configure\n  various HTTP fields in the requests/responses (e.g., `Content-Type`).\n\n* __examples/test\\_9\\_ipv4\\_tos.cfg__: example showing how to configure\n  various TOS or DSCP/ECN values as part of the IPv4 options of the test cases.\n\n* __examples/test\\_10\\_ipv4\\_mcast.cfg__: example showing how to configure\n  UDP Multicast Source test cases. The example combines UDP Unicast traffic with\n  UDP Multicast traffic.\n\n* __examples/test\\_11\\_ipv4\\_latency.cfg__: example showing how to configure\n  latency measurement on a TCP test case. _Maximum_ and _average_ thresholds\n  are configured.\n\n* __examples/test\\_12\\_raw\\_latency.cfg__: example showing how to configure\n  latency measurement using application layer timestamping on TCP and UDP\n  test cases.\n\n* __examples/test\\_13\\_vlan\\_udp.cfg__: example showing how to configure\n  vlan information and per vlan gateways.\n\n* __examples/test\\_14\\_imix.cfg__: example showing how to combine multiple\n  L5 applications inside IMIX groups. Applications have different weights\n  which are used for computing how often the apps will be represented in\n  the traffic profile.\n\n# Python scripting API\nWARP17 offers an RPC-based API which allows users to write scripts and automate\nthe tests that WARP17 would run. WARP17 listens to incoming RPC connections on TCP\nport `42424`.\n\nThe RPC object definitions can be found in the `api/*.proto` files. The main\nRPC interface is defined in `api/warp17-service.proto`. All `*.proto` files are\ncompiled into Python classes when building WARP17. The generated code is saved\nin the `api/generated/py` directory (one `.py` file for each `.proto`\ndefinition file).\n\nA short example about how to use the Python API can be found in\n`examples/python/test_1_http_4M.py`. The example sets up 4M _HTTP_ clients\nand servers, polls for statistics and stops the tests after a while.\n\n# Perl scripting API\nWARP17 can also be scripted through Perl by using the `Inline::Python` module.\nA short example about how to use Perl to script WARP17 can be found in\n`examples/perl/test_1_http_4M.pl`. Requirements for running the Perl scripts:\n\n```\nsudo apt-get install python2.7-dev cpanminus\nsudo cpanm Inline::Python\n```\n\n```\nsudo perl -I ./perl/ examples/perl/test_1_http_4M.pl\n```\n\n# Contributing a new L7 Application implementation\nYou can find how to contribute to our project and how to add new L7\napplication implementations [here](./doc/Contributing.md).\n\n# Release notes\nFor a summary of the currently supported functionalities please check the\n[RELEASE_NOTES](./RELEASE_NOTES) file.\n\n# Roadmap for future releases\n\n* Additional L7 application implementations (e.g., _FTP_, _TFTP_, _SIP_).\n* Socket API.\n* Fault injection at various levels in the L2-L7 stack.\n\n# Contact\nFeel free to also check out the [WARP17 google group](https://groups.google.com/forum/#!forum/warp17).\n\nFor a list of maintainers and contributors please check the MAINTAINERS and\nCONTRIBUTORS files.\n\n# License\n\nWARP17 is released under BSD 3-Clause license.\nThe license file can be found [here](./LICENSE).\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fjuniper%2Fwarp17","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fjuniper%2Fwarp17","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fjuniper%2Fwarp17/lists"}