====
:author: hhaim
-:revnumber: 2.0
+:revnumber: 2.1
:quotes.++:
:numbered:
:web_server_url: http://trex-tgn.cisco.com/trex
typically has been measured using packets per second (PPS) metrics. As router functionality and
services have become more complex, stateful traffic generators have become necessary to
provide more realistic application traffic scenarios.
-The advantages of realistic traffic generators are:
-* Providing more accurate performance numbers
-* Finding real bottlenecks
+Advantages of realistic traffic generators:
+
+* Accurate performance metrics
+* Discovering bottlenecks in realistic traffic scenarios
==== Current Challenges:
-* *Cost* : Commercial State-full traffic generators are expensive
-* *Scale* : Bandwidth does not scale up well with features complexity
-* *Standardization* : Lack of standardization of traffic patterns and methodologies
-* *Flexibility* : Commercial tools do not allow agility when flexibility and changes are needed
+* *Cost*: Commercial stateful traffic generators are expensive
+* *Scale*: Bandwidth does not scale up well with feature complexity
+* *Standardization*: Lack of standardization of traffic patterns and methodologies
+* *Flexibility*: Commercial tools do not allow agility when flexibility and changes are needed
==== Implications
-* High capital expenditure (capex) spent by different teams
-* Testing in low scale and extrapolation became a common practice, it is not accurate, and hides real life bottlenecks and quality issues
-* Different feature / platform teams benchmark and results methodology
-* Delays in development and testing due to testing tools features dependency
-* Resource and effort investment in developing different ad hoc tools and test methodologies
+* High capital expenditure (capex) spent by different teams.
+* Testing in low scale and extrapolation became a common practice. This is non-ideal and fails to indicate bottlenecks that appear in real-world scenarios.
+* Teams use different benchmark methodologies, so results are not standardized.
+* Delays in development and testing due to dependence on testing tool features.
+* Resource and effort investment in developing different ad hoc tools and test methodologies.
=== Overview of TRex
-TRex addresses these problems through an innovative and extendable software implementation and by leveraging standard and open SW and x86/UCS HW.
+TRex addresses these problems through an innovative and extendable software implementation and by leveraging standard and open software and x86/UCS hardware.
-* Generates and analyzes L4-7 traffic and able to provide in one tool capabilities provided by commercial L7 tools.
+* Generates and analyzes L4-7 traffic. In one package, provides capabilities of commercial L7 tools.
* Stateful traffic generator based on pre-processing and smart replay of real traffic templates.
* Generates and *amplifies* both client and server side traffic.
* Customized functionality can be added.
-* Scale to 200Gb/sec for one UCS ( using Intel 40Gb/sec NICS)
+* Scales to 200Gb/sec for one UCS (using Intel 40Gb/sec NICs)
* Low cost
-* Virtual interfaces support, enable TRex to be used in a fully virtual environment without physical NICs and the following example use cases:
+* Self-contained package that can be easily installed and deployed
+* Virtual interface support enables TRex to be used in a fully virtual environment without physical NICs. Example use cases:
** Amazon AWS
** Cisco LaaS
+// Which LaaS is this? Location as a service? Linux?
** TRex on your laptop
-** Self-contained packaging that can be easily installed and deployed
+
.TRex Hardware
=== Purpose of this guide
-This guide explains the use of TRex internals and the use of TRex in conjunction with Cisco ASR1000 Series routers. The examples illustrate novel traffic generation techniques made possible by TRex.
+This guide explains the use of TRex internals and the use of TRex together with Cisco ASR1000 Series routers. The examples illustrate novel traffic generation techniques made possible by TRex.
== Download and installation
-=== Hardware recommendation
+=== Hardware recommendations
TRex operates in a Linux application environment, interacting with Linux kernel modules.
-TRex curretly works on x86 architecture and can operates well on Cisco UCS hardware. The following platforms have been tested and are recommended for operating TRex.
+TRex curretly works on x86 architecture and can operate well on Cisco UCS hardware. The following platforms have been tested and are recommended for operating TRex.
[NOTE]
=====================================
[NOTE]
=====================================
-Not all supported DPDK interfaces are supported by TRex
+ Not all supported DPDK interfaces are supported by TRex
=====================================
-.Preferred UCS
+.Preferred UCS hardware
[options="header",cols="1,3"]
|=================
| UCS Type | Comments
-| UCS C220 M3/M4 | *Prefered, Low-End*, Supports up to 40Gb/sec with 540-D2 and with newer Intel NIC 80Gb/sec with 1RU, recommended
-| UCS C200| Early UCS model
-| UCS C210 M2 | Supports up to 40Gb/sec PCIe3.0
-| UCS C240 M3/M4 | *Prefered, High-End* Supports up to 200Gb/sec. 6x XL710 NICS (PCIex8) or 2xFM10K (PCIex16)
-| UCS C260M2 | Supports up to 30Gb/sec due to V2 PCIe.
+| UCS C220 M3/M4 | *Preferred Low-End*. Supports up to 40Gb/sec with 540-D2. With newer Intel NIC (recommended), supports 80Gb/sec with 1RU. See table below describing components.
+| UCS C200| Early UCS model.
+| UCS C210 M2 | Supports up to 40Gb/sec PCIe3.0.
+| UCS C240 M3/M4 | *Preferred, High-End* Supports up to 200Gb/sec. 6x XL710 NICS (PCIex8) or 2xFM10K (PCIex16). See table below describing components.
+| UCS C260M2 | Supports up to 30Gb/sec (limited by V2 PCIe).
|=================
-.Internal Components Low-End C220M4
+.Low-End UCS C220 M4 - Internal components
[options="header",cols="1,2",width="60%"]
|=================
| Components | Details
-| CPU | 2x CPU E5-2620/2.0 GHz
-| CPU Configuration | 2-Socket CPU configurations (can also work with one CPU)
-| Memory | 2x4 banks for each CPU. Total of 8 BANKS ==> 32GB
-| NO RAID | NO RAID
+| CPU | 2x E5-2620 @ 2.0 GHz.
+| CPU Configuration | 2-Socket CPU configurations (also works with 1 CPU).
+| Memory | 2x4 banks f.or each CPU. Total of 32GB in 8 banks.
+| RAID | No RAID.
|=================
-.Internal Components High-End C240M4
+.High-End C240 M4 - Internal components
[options="header",cols="1,2",width="60%"]
|=================
| Components | Details
-| CPU | 2x CPU E5-2667 /3.20 GHz
-| PCIe | 1x ,Riser PCI expantion card option A PID UCSC-PCI-1A-240M4 this will give the option to have two PCIex16
-| CPU Configuration | 2-Socket CPU configurations (can also work with one CPU)
-| Memory | 2x4 banks for each CPU. Total of 8 BANKS ==> 32GB
-| NO RAID | NO RAID
+| CPU | 2x E5-2667 @ 3.20 GHz.
+| PCIe | 1x Riser PCI expansion card option A PID UCSC-PCI-1A-240M4 enables 2 PCIex16.
+| CPU Configuration | 2-Socket CPU configurations (also works with 1 CPU).
+| Memory | 2x4 banks for each CPU. Total of 32GB in 8 banks.
+| RAID | No RAID.
|=================
-.Supported NICS
+.Supported NICs
[options="header",cols="1,1,2",width="50%"]
|=================
| Bandwidth | Chipset | Example
| 1Gb/sec | Intel I350 | Intel 4x1GE 350-T4 NIC
| 10Gb/sec | Intel 82599| Intel x520-D2 Cisco Order tool 2X Intel N2XX-AIPCI01, Intel X520 Dual Port 10Gb SFP+ Adapter
-| 10Gb/sec | Intel X710 | SFP+, *Preferred* support per stream stats in hardware link:http://www.silicom-usa.com/PE310G4i71L_Quad_Port_Fiber_SFP+_10_Gigabit_Ethernet_PCI_Express_Server_Adapter_49[PE310G4i71L]
-| 40Gb/sec | Intel XL710 | QSFP+ (copper/optical)
-| 100Gb/sec | Intel Intel FM10420 | QSFP28, by Silicom link:http://www.silicom-usa.com/100_Gigabit_Dual_Port_Fiber_Ethernet_PCI_Express_PE3100G2DQiR_96[PE3100G2DQiR_96] *under dev*
+| 10Gb/sec | Intel X710 | link:https://en.wikipedia.org/wiki/Small_form-factor_pluggable_transceiver[SFP+], *Preferred* support per stream stats in hardware link:http://www.silicom-usa.com/PE310G4i71L_Quad_Port_Fiber_SFP+_10_Gigabit_Ethernet_PCI_Express_Server_Adapter_49[Silicom PE310G4i71L]
+| 40Gb/sec | Intel XL710 | link:https://en.wikipedia.org/wiki/QSFP[QSFP+] (copper/optical)
+| 100Gb/sec | Intel Intel FM10420 | QSFP28, by Silicom link:http://www.silicom-usa.com/100_Gigabit_Dual_Port_Fiber_Ethernet_PCI_Express_PE3100G2DQiR_96[Silicom PE3100G2DQiR_96] (*in development*)
| VMXNET / +
-VMXNET3 (read notes) | VMware paravirtualize | connect using vmWare vSwitch
-| E1000 | paravirtualize | vmWare/KVM/VirtualBox
+VMXNET3 (see notes) | VMware paravirtualized | Connect using VMware vSwitch
+| E1000 | paravirtualized | VMware/KVM/VirtualBox
|=================
-.X710 SFP+ support (*for Silicom PE310G4i71L with Open Optic*)
+// in table above, is it correct to list "paravirtualized" as chipset? Also, what is QSFP28? It does not appear on the lined URL. Clarify: is Intel X710 the preferred NIC?
+
+.Intel X710 SFP+ support (for link:http://www.silicom-usa.com/PE310G4i71L_Quad_Port_Fiber_SFP+_10_Gigabit_Ethernet_PCI_Express_Server_Adapter_49[Silicom PE310G4i71L] with Open Optic)
[options="header",cols="1,1",width="70%"]
|=================
-| SFP+ | Example
-| Cisco SFP-10G-SR | see link:http://www.cisco.com/c/en/us/products/collateral/interfaces-modules/transceiver-modules/data_sheet_c78-455693.html[here]
-| Cisco SFP-10G-LR | see link:http://www.cisco.com/c/en/us/products/collateral/interfaces-modules/transceiver-modules/data_sheet_c78-455693.html[here]
-| Cisco SFP-H10GB-CU1M | see link:http://www.cisco.com/c/en/us/products/collateral/interfaces-modules/transceiver-modules/data_sheet_c78-455693.html[here]
-| Cisco SFP-10G-AOC1M | see link:http://www.cisco.com/c/en/us/products/collateral/interfaces-modules/transceiver-modules/data_sheet_c78-455693.html[here]
+| link:https://en.wikipedia.org/wiki/Small_form-factor_pluggable_transceiver[SFP+] | Notes
+| Cisco SFP-10G-SR | link:http://www.cisco.com/c/en/us/products/collateral/interfaces-modules/transceiver-modules/data_sheet_c78-455693.html[Info]
+| Cisco SFP-10G-LR | link:http://www.cisco.com/c/en/us/products/collateral/interfaces-modules/transceiver-modules/data_sheet_c78-455693.html[Info]
+| Cisco SFP-H10GB-CU1M | link:http://www.cisco.com/c/en/us/products/collateral/interfaces-modules/transceiver-modules/data_sheet_c78-455693.html[Info]
+| Cisco SFP-10G-AOC1M | link:http://www.cisco.com/c/en/us/products/collateral/interfaces-modules/transceiver-modules/data_sheet_c78-455693.html[Info]
|=================
-WARNING: Intel X710 NIC for example FH X710DA4FHBLK will work *only* with Intel SFP+. In case you like an open optic buy Silicom PE310G4i71L NIC
+[NOTE]
+=====================================
+ Intel X710 NIC (example: FH X710DA4FHBLK) operates *only* with Intel SFP+. For open optic, use the link:http://www.silicom-usa.com/PE310G4i71L_Quad_Port_Fiber_SFP+_10_Gigabit_Ethernet_PCI_Express_Server_Adapter_49[Silicom PE310G4i71L] NIC.
+=====================================
+
+// clarify above table and note
-.XL710 QSFP+ support
+.Intel XL710 QSFP+ support
[options="header",cols="1,1",width="70%"]
|=================
-| QSFP+ | Example
-| QSFP+ SR4 optics | APPROVED OPTICS For Intel NICS, Cisco QSFP-40G-SR4-S does *not* work link:http://www.cisco.com/c/en/us/products/collateral/interfaces-modules/transceiver-modules/data_sheet_c78-660083.html[here]
-| QSFP+ LR-4 Optics | APPROVED OPTICS For Intel NICS , Cisco QSFP-40G-LR4-S does *not* work link:http://www.cisco.com/c/en/us/products/collateral/interfaces-modules/transceiver-modules/data_sheet_c78-660083.html[here]
-| QSFP Active Optical Cables (AoC) | QSFP-H40G-AOC link:http://www.cisco.com/c/en/us/products/collateral/interfaces-modules/transceiver-modules/data_sheet_c78-660083.html[here]
+| link:https://en.wikipedia.org/wiki/QSFP[QSFP+] | Notes
+| QSFP+ SR4 optics | APPROVED OPTICS For Intel NICS, Cisco QSFP-40G-SR4-S does *not* work link:http://www.cisco.com/c/en/us/products/collateral/interfaces-modules/transceiver-modules/data_sheet_c78-660083.html[here]
+| QSFP+ LR-4 Optics | APPROVED OPTICS For Intel NICS , Cisco QSFP-40G-LR4-S does *not* work link:http://www.cisco.com/c/en/us/products/collateral/interfaces-modules/transceiver-modules/data_sheet_c78-660083.html[here]
+| QSFP Active Optical Cables (AoC) | QSFP-H40G-AOC link:http://www.cisco.com/c/en/us/products/collateral/interfaces-modules/transceiver-modules/data_sheet_c78-660083.html[here]
| QSFP+ Intel Ethernet Modular Optics |
| QSFP+ DA twin-ax cables |
-| Active QSFP+ Copper Cables | Cisco QSFP-4SFP10G-CU link:http://www.cisco.com/c/en/us/products/collateral/interfaces-modules/transceiver-modules/data_sheet_c78-660083.html[here]
+| Active QSFP+ Copper Cables | Cisco QSFP-4SFP10G-CU link:http://www.cisco.com/c/en/us/products/collateral/interfaces-modules/transceiver-modules/data_sheet_c78-660083.html[here]
|=================
[NOTE]
=====================================
- For Intel XL710 NICS, Cisco SR4/LR QSFP+ won't work you can buy Silicom with Open Optic
+ For Intel XL710 NICs, Cisco SR4/LR QSFP+ does not operate. Use Silicom with Open Optic.
=====================================
+// clarify above table and note. let's discuss.
+
.FM10K QSFP28 support
[options="header",cols="1,1",width="70%"]
|=================
| todo | todo
|=================
+// do we want to show "todo"? maybe "pending"
+
[IMPORTANT]
=====================================
-* For VMXNET3 use Ubuntu and *not* Fedora 18. Fedora 18 will crash.
-* Intel SFP+ 10Gb/Sec is the only one supported by default on the standard Linux driver. TRex also supports Cisco 10Gb/sec SFP+.
-* Using different NUMA for different NIC is very important when getting to high speeds, such as using several Intel XL710 40Gb/sec. +
- One can verify NUMA and NIC topology with following command: lstopo (yum install hwloc) +
- NUMAs-CPUs relation is determined with following command: lscpu +
- See real example of NUMA usage xref:numa-example[here]
-* Using Intel XL710 with Fedora 18 requires updating Kernel:
-** > sudo yum update kernel
-** > sudo yum update kernel-devel
-** > sudo yum update kernel-headers
-* For Intel XL710 NICs there is a need to verify the NVM is v4.42 or v4.53 see xref:xl710-firmware[here] for more info
-** > sudo ./t-rex-64 -f cap2/dns.yaml -d 0 *-v 6* --nc | grep NVM +
- PMD: FW 4.22 API 1.2 *NVM 04.04.02* eetrack 800013fc +
- PMD: FW 4.22 API 1.2 *NVM 04.04.02* eetrack 800013fc +
- PMD: FW 4.22 API 1.2 *NVM 04.04.02* eetrack 800013fc +
- PMD: FW 4.22 API 1.2 *NVM 04.04.02* eetrack 800013fc
+* For VMXNET3, use Ubuntu. Fedora 18 is not supported and causes crash.
+* Intel SFP+ 10Gb/sec is the only one supported by default on the standard Linux driver. TRex also supports Cisco 10Gb/sec SFP+.
+// above, replace "only one" with "only mode"?
+* For operating high speed throughput (example: several Intel XL710 40Gb/sec), use different link:https://en.wikipedia.org/wiki/Non-uniform_memory_access[NUMA] nodes for different NICs. +
+ To verify NUMA and NIC topology: `lstopo (yum install hwloc)` +
+ To display CPU info, including NUMA node: `lscpu` +
+ NUMA usage xref:numa-example[example]
+* Using Intel XL710 with Fedora 18 requires updating kernel:
+** `> sudo yum update kernel`
+** `> sudo yum update kernel-devel`
+** `> sudo yum update kernel-headers`
+* For Intel XL710 NICs, verify that the NVM is v4.42 or v4.53. xref:xl710-firmware[Info].
+** `> sudo ./t-rex-64 -f cap2/dns.yaml -d 0 *-v 6* --nc | grep NVM` +
+ `PMD: FW 4.22 API 1.2 *NVM 04.04.02* eetrack 800013fc` +
+ `PMD: FW 4.22 API 1.2 *NVM 04.04.02* eetrack 800013fc` +
+ `PMD: FW 4.22 API 1.2 *NVM 04.04.02* eetrack 800013fc` +
+ `PMD: FW 4.22 API 1.2 *NVM 04.04.02* eetrack 800013fc`
=====================================
-.Sample order for low-end UCSC-C220-M3S with 4x10Gb ports
-[options="header",cols="2,1^",width="50%"]
+// above, maybe rename the bullet points "NIC usage notes"? should we create a subsection for NICs? Maybe it would be under "2.1 Hardware recommendations" as a subsection.
+
+
+.Sample order for recommended low-end Cisco UCSC-C220-M3S with 4x10Gb ports
+[options="header",cols="1,1",width="70%"]
+|=================
+| Component | Quantity
+| UCSC-C220-M3S | 1
+| UCS-CPU-E5-2650 | 2
+| UCS-MR-1X041RY-A | 8
+| A03-D500GC3 | 1
+| N2XX-AIPCI01 | 2
+| UCSC-PSU-650W | 1
+| SFS-250V-10A-IS | 1
+| UCSC-CMA1 | 1
+| UCSC-HS-C220M3 | 2
+| N20-BBLKD | 7
+| UCSC-PSU-BLKP | 1
+| UCSC-RAIL1 | 1
|=================
-| Component | Amount
-| UCSC-C220-M3S | 1
-| UCS-CPU-E5-2650 | 2
-| UCS-MR-1X041RY-A | 8
-| A03-D500GC3 | 1
-| N2XX-AIPCI01 | 2
-| UCSC-PSU-650W | 1
-| SFS-250V-10A-IS | 1
-| UCSC-CMA1 | 1
-| UCSC-HS-C220M3 | 2
-| N20-BBLKD | 7
-| UCSC-PSU-BLKP | 1
-| UCSC-RAIL1 | 1
-|========================
-
-NOTE: You should buy seperatly the 10Gb/sec SFP+, Cisco would be fine with TRex (but not for plain Linux driver).
-
-=== Install OS
+
+// should table above say "low-end Cisco UCS C220 M3S" instead of "low-end USCS-C220-M3S"?
+
+NOTE: Purchase the 10Gb/sec SFP+ separately. Cisco would be fine with TRex (but not for plain Linux driver).
+// does note above mean "TRex operates with 10Gb/sec SFP+ components, but plain Linux does not provide drivers."? if so, how does purchasing separately solve this? where do they get drivers?
+
+=== Installing OS
==== Supported versions
-Fedora 18-20 , and Ubuntu 14.04.1 LTS are the Linux OS supported.
-You should install the *64bit* Kernel version.
-More 64bit OS could be supported by compiling the drivers.
+Supported Linux versions:
+* Fedora 18-20, 64-bit kernel (not 32-bit)
+* Ubuntu 14.04.1 LTS, 64-bit kernel (not 32-bit)
-WARNING: Only *64bit* Kernels are supported
+NOTE: Additional OS version may be supported by compiling the necessary drivers.
+// we should indicate exactly which drivers this means
-To verify that your kernel is 64bit version try this
+To check whether a kernel is 64-bit, verify that the ouput of the following command is `x86_64`.
[source,bash]
----
$uname -m
-x86_64 #<1>
+x86_64
----
-<1> x86_64 is the desired output
-
+==== Download Linux
-==== Download ISO file
-
-The ISO images of the described Linux OS can be downloaded from the following links:
+ISO images for supported Linux releases can be downloaded from:
.Supported Linux ISO image links
[options="header",cols="1^,2^",width="50%"]
| http://old-releases.ubuntu.com/releases/14.04.1/SHA256SUMS[Ubuntu 14.04 CHECKSUM]
|======================================
-For Fedora, you can get link close to your location at: +
+For Fedora downloads...
+
+* Select a mirror close to your location: +
https://admin.fedoraproject.org/mirrormanager/mirrors/Fedora +
Choose: "Fedora Linux http" -> releases -> <version number> -> Server -> x86_64 -> iso -> Fedora-Server-DVD-x86_64-<version number>.iso
-Then, verify the checksum of the downloaded file matches the linked checksum values with the `sha256sum` command. For example:
+* Verify the checksum of the downloaded file matches the linked checksum values with the `sha256sum` command. Example:
[source,bash]
----
$sha256sum Fedora-18-x86_64-DVD.iso
91c5f0aca391acf76a047e284144f90d66d3d5f5dcd26b01f368a43236832c03 #<1>
----
-<1> Should be equal to the sha256 values described in the linked CHECKSUM files.
+<1> Should be equal to the link:https://en.wikipedia.org/wiki/SHA-2[SHA-256] values described in the linked checksum files.
==== Install Linux
xref:fedora21_example[Example of installing Fedora 21 Server]
-IMPORTANT: To use TRex, you should have sudo on this machine or root password.
-WARNING: Upgrading the linux Kernel using `yum upgrade` require to build the TRex drivers.
+[NOTE]
+=====================================
+ * To use TRex, you should have sudo on the machine or the root password.
+ * Upgrading the linux Kernel using `yum upgrade` requires building the TRex drivers.
+=====================================
==== Verify Intel NIC installation
-The following is an example of 4x10Gb/sec TRex with I350 management port and four x520-D2 (82599 chipset):
+Use `lspci` to verify the NIC installation.
+
+Example 4x 10Gb/sec TRex configuration (see output below):
+
+* I350 management port
+
+* 4x Intel Ethernet Converged Network Adapter model x520-D2 (82599 chipset)
[source,bash]
----
----
<1> Management port
<2> CIMC port
-<3> 10Gb/sec traffic ports ( Intel 82599EB)
+<3> 10Gb/sec traffic ports (Intel 82599EB)
=== Obtaining the TRex package
-Connect by ssh to the TRex machine and do the following:
+Connect by `ssh` to the TRex machine and execute the commands described below.
-assuming *$WEB_URL* is *{web_server_url}* or *{local_web_server_url}* (cisco internal)
+NOTE: Prerequisite: *$WEB_URL* is *{web_server_url}* or *{local_web_server_url}* (Cisco internal)
+Latest release:
[source,bash]
----
$mkdir trex
----
-to take the bleeding edge version
+Bleeding edge version:
[source,bash]
----
$wget --no-cache $WEB_URL/release/be_latest
$wget --no-cache $WEB_URL/release/vX.XX.tar.gz #<1>
----
-<1> X.XX = The version number
+<1> X.XX = Version number
=== Running TRex for the first time in loopback
-If you have 10Gb/sec TRex (based on Intel 520-D2 NICs) you can verify that it works correctly by loopback the ports.
+If you have a 10Gb/sec TRex (based on Intel 520-D2 NICs), you can verify that it works correctly by loopback on the ports.
You can install Intel SFP+ or Cisco SFP+, but you cannot connect ports that are on the same NIC to each other (it might not sync).
-If you have only one NIC of 10gb/sec you cannot perform this test beacause the ports will not have valid link.
-Another option for loopback is to use Cisco twinax copper cable see link:http://www.fiberopticshare.com/tag/cisco-10g-twinax[here]
+If you have only one NIC of 10gb/sec you cannot perform this test because the ports will not have a valid link.
+Another option for loopback is to use link:http://www.fiberopticshare.com/tag/cisco-10g-twinax[Cisco twinax copper cable].
//TBD: perhaps rephase, using a "Prerequisites" or "Required" heading. The requirement here would be: Two (2) 10gb/sec NICs
//[hh] it is not accurate beacuse with 1Gb/sec you can have this test
.Wrong loopback
image:images/loopback_wrong.png[title="rigt"]
-In case you have 1Gb/Sec Intel NIC (I350) or XL710/X710 NIC you can do anything you like from the loopback perspective *but* you must filter the management port before see xref:trex_config[here].
+If you have a 1Gb/Sec Intel NIC (I350) or XL710/X710 NIC, you can do anything you like from the loopback perspective *but* first filter the management port - see xref:trex_config[TRex Configuration].
+
+// above, clarify "you can do anything you like from the loopback perspective"
==== Identify the ports
<3> TRex interface #3 before unbinding
<4> TRex interface #4 before unbinding
-Now choose the port you want to use and follow the next section by creating a configuration file.
+Choose a port to use and follow instructions in the next section to create a configuration file.
==== Create minimum configuration file
-Create a configuration file in `/etc/trex_cfg.yaml`.
+Create a configuration file: `/etc/trex_cfg.yaml`.
-You could copy a basic configuration file from cfg folder by running this command.
+You can copy a basic configuration file from cfg folder by running this command...
[source,bash]
----
$cp cfg/simple_cfg.yaml /etc/trex_cfg.yaml
----
-Now edit the configuration file with the right values from the previous section
+...and edit the configuration file with the desired values.
+
+Example:
[source,bash]
----
version : 2 #<2>
interfaces : ["03:00.0","03:00.1","13:00.1","13:00.0"] #<3>
----
-<1> the number of ports
-<2> must add version 2 to the configuration file
-<3> The list of interface from `#>sudo ./dpdk_setup_ports.py -s`, in this example it was taken
+<1> Mumber of ports
+<2> Must add version 2 to the configuration file
+<3> List of interfaces displayed by `#>sudo ./dpdk_setup_ports.py -s`
-When working with VM, you must set the destination mac of one port as the source or the other for loopback the port in the vSwitch
+When working with a VM, set the destination MAC of one port as the source or the other for loopback the port in the vSwitch
and you should take the right value from the hypervisor (in case of a physical NIC you can set the MAC address with virtual you can't and you should take it from the hypervisor)
and example
+// Clarify paragraph above.
+
[source,python]
----
- port_limit : 2
- dest_mac : [0x2,0x0,0x0,0x2,0x0,0x00] # port 1 <1>
src_mac : [0x1,0x0,0x0,0x1,0x0,0x00]
----
-<1> Source mac is like destination mac (this should be set or taken from vmware). the mac was taken from hypervisor
-<2> Currently TRex has a limitation and support only one type of NIC at a time. You can't mix different type of NIC in one config file. see here for more info link:http://trex-tgn.cisco.com/youtrack/issue/trex-197[trex-201]
+<1> Source MAC is like destination MAC (this should be set or taken from VMware). The MAC was taken from the hypervisor.
+<2> Currently TRex supports only one type of NIC at a time. You cannot mix different NIC types in one config file. For more info, see link:http://trex-tgn.cisco.com/youtrack/issue/trex-197[trex-201].
+
+// where can we describe this limitation (TRex supports only one type of NIC at a time. You cannot mix different NIC types in one config file.) and other limitations?
-==== Running TRex
+==== Run TRex
-Run this for 4x10Gb/sec TRex:
+Use the following command to begin operation of a 4x 10Gb/sec TRex:
[source,bash]
----
$sudo ./t-rex-64 -f cap2/dns.yaml -c 4 -m 1 -d 100 -l 1000
----
-NOTE: For 10Gb/sec TRex with 2,6, or 8 ports, add --limit-ports [number of ports] *or* follow xref:trex_config[this] to configure the TRex.
-//TBD: recommend bold for the 2 commands.
+NOTE: For a 10Gb/sec TRex with 2, 6, or 8 ports, add `--limit-ports [number of ports]` *or* follow xref:trex_config[these instructions] to configure TRex.
If successful, the output will be similar to the following:
<3> Total Rx must be the same as Tx
<4> Tx_ok == Rx_ok
<5> Tx_ok == Rx_ok
-<6> Number of TRex active "flows". Could be diffrent than the Router flows due to aging issues. Usualy TRex number of active flows is much lower that router.
+<6> Number of TRex active "flows". Could be different than the number of router flows, due to aging issues. Usualy the TRex number of active flows is much lower that of the router.
<7> Number of TRex flows from startup.
<8> Drop rate.
-<9> Expected Packet Per Second (without the latency packets).
-<10> Expected Connection Per Second (without the latency packets).
-<11> Expected Bit Per Second (without the latency packets).
+<9> Expected packets per second (calculated without latency packets).
+<10> Expected connections per second (calculated without latency packets).
+<11> Expected bits per second (calculated without latency packets).
<12> Average CPU utilization of transmitters threads. For best results it should be lower than 80%.
-<13> Gb/sec generated per core of DP. Higer is better.
+<13> Gb/sec generated per core of DP. Higher is better.
<14> Rx and latency thread CPU utilization.
-More statistic information:
+More statistics information:
-*socket*:: same as the active flows.
+*socket*:: Same as the active flows.
-*Socket/Clients*:: is equal active_flows/#clients, average of active flow per client.
+*Socket/Clients*:: Average of active flows per client, calculated as active_flows/#clients.
-*Socket-util*:: is equal to ~(100*active_flows/#clients)/64K equal to (average active flows per client*100/64K ) in words, it give an estimation of how many socket ports are used per client IP. Utilization of more than 50% means that TRex is generating too many flows per one client and you need to add more clients.
+*Socket-util*:: Estimate of how many socket ports are used per client IP. This is approximately ~(100*active_flows/#clients)/64K, calculated as (average active flows per client*100/64K). Utilization of more than 50% means that TRex is generating too many flows per single client, and that more clients must be added.
+// clarify above, especially the formula
-*Max window*:: shows a momentary maximum latency for a time window of 500msec. There are a few numbers per number of windows that are shown.
+*Max window*:: Momentary maximum latency for a time window of 500 msec. There are a few numbers per number of windows that are shown.
The new number (the last 500msec) is the right number. The oldest in the left number. This can help to identify spikes of high latency that after a time clear.in a contrast the maximum latency will stuck at the maximum value for all the test.
+//clarify above
-*Platform_factor*:: There are cases that we duplicate the traffic using splitter/Switch and we would like all the number to be multiplied by this factor (e.g. x2)
-
+*Platform_factor*:: There are cases that we duplicate the traffic using splitter/switch and we would like all the number to be multiplied by this factor (e.g. x2)
+//clarify above
WARNING: If you don't see rx packets, revisit your MAC address configuration.
+//clarify above
==== Running TRex for the first time with ESXi:
-* Virtual NICs can be used to bridge between TRex and non-supported NICs or get some basic impression/testing. Bandwidth is limited by vSwitch, has ipv6 issues.
+* Virtual NICs can be used to bridge between TRex and non-supported NICs, or for basic testing. Bandwidth is limited by vSwitch, has IPv6 issues.
+// clarify, especially what IPv6 issues
-1. Click on the host machine, enter Configuration -> Networking.
+1. Click the host machine, enter Configuration -> Networking.
-a. One of the NICs should be connected to the main vSwitch network to get "outside" connection, for the TRex client and ssh: +
+a. One of the NICs should be connected to the main vSwitch network to get an "outside" connection, for the TRex client and ssh: +
image:images/vSwitch_main.png[title="vSwitch_main"]
b. Other NICs that are used for TRex traffic should be in distinguish vSwitch: +
image:images/vSwitch_loopback.png[title="vSwitch_loopback"]
-2. Right click on guest machine -> Edit settings -> Ensure the NICs are set to their networks: +
+2. Right-click guest machine -> Edit settings -> Ensure the NICs are set to their networks: +
image:images/vSwitch_networks.png[title="vSwitch_networks"]
[NOTE]
=====================================================================
-Current limitation: following command will not work as excepted:
+Current limitation: The following command does not function as expected:
....
sudo ./t-rex-64 -f cap2/dns.yaml --lm 1 --lo -l 1000 -d 100
....
-vSwitch can't know where to "route" the packet, it supposed to be fixed once TRex supports ARP
+The vSwitch does not "know" where to route the packet. This is expected to be fixed when TRex supports ARP.
=====================================================================
-* Pass-through is the way to use directly the NICs from host machine inside the VM. Has no limitations except the NIC/hardware itself. The only difference via bare-metal OS is seldom spikes of latency (~10ms). Passthrough settings can't be saved to OVA.
+* Pass-through is the way to use directly the NICs from host machine inside the VM. Has no limitations except the NIC/hardware itself. The only difference via bare-metal OS is occasional spikes of latency (~10ms). Passthrough settings cannot be saved to OVA.
-1. Click on the host machine, enter Configuration -> Advanced settings -> Edit. Mark the wanted NICs. Reboot the ESXi to apply. +
+1. Click on the host machine. Enter Configuration -> Advanced settings -> Edit. Mark the desired NICs. Reboot the ESXi to apply. +
image:images/passthrough_marking.png[title="passthrough_marking"]
-2. Right click on guest machine -> Edit settings -> Add -> *PCI device* -> Choose the NICs one by one. +
+2. Right click on guest machine. Edit settings -> Add -> *PCI device* -> Choose the NICs one by one. +
image:images/passthrough_adding.png[title="passthrough_adding"]
==== Running TRex for the first time with router
You can follow this presentation: link:trex_config_guide.html[first time TRex configuration]
-//TBD: Note that the link does not work correctly in PDF rendition
or continue reading.
Without config file, TRex sets source MAC of all ports to `00:00:00:01:00:00` and expects to receive packets with this destination MAC address.
So, you just need to configure your router with static ARP entry pointing to the above MAC address.
=== VLAN Trunk support anchor:trex_valn[]
-The VLAN Trunk TRex feature attempts to solve the router port bandwidth limitation when the traffic profile is asymmetric. Example: SFR profile is asymmetric and was the first usecase.
+The VLAN Trunk TRex feature attempts to solve the router port bandwidth limitation when the traffic profile is asymmetric. Example: Asymmetric SFR profile.
This feature converts asymmetric traffic to symmetric, from the port perspective, using router sub-interfaces.
-This feature requires TRex to send the traffic on two VLANs. The following describes how this works.
+This requires TRex to send the traffic on two VLANs, as described below.
.YAML format
[source,python]
- duration : 0.1
vlan : { enable : 1 , vlan0 : 100 , vlan1 : 200 } <1>
----
-<1> enable VLAN feature , valn0==100 , valn1==200
+<1> Enable VLAN feature, valn0==100 , valn1==200
*Problem definition:*::
-Assuming a TRex with two ports and an SFR traffic profile.
+Scenario: TRex with two ports and an SFR traffic profile.
.Without VLAN/sub interfaces
[source,python]
----
0 ( client) -> [ ] - 1 ( server)
----
-Without VLAN support it is not symmetric. From port 0 (client side), it sends 10%, from and port 1 (server) sends 90%. Port 1 become the bottlneck (10Gb/s limit) before port 0
+Without VLAN support the traffic is asymmetric. 10% of the traffic is sent from port 0 (client side), 90% is from port 1 (server). Port 1 become the bottlneck (10Gb/s limit) before port 0.
.With VLAN/sub interfaces
[source,python]
port 0 ( server VLAN1) <-> | | <-> port 1 ( client-VLAN1)
----
-In this case both ports will have the same amount of traffic.
+In this case both ports have the same amount of traffic.
*Router configuation:*::
[source,python]
set ip next-hop 11.88.11.12
!
----
-<1> Disable the IP on the main port it is important
+<1> Disable the IP on the main port it is important.
+// above, clarify what's important
<2> Enable VLAN1
<3> PBR configuration
<4> Enable VLAN2
<5> PBR configuration
-<6> TRex MAC-address destination port
+<6> TRex destination port MAC address
<7> PBR configuration rules
=== Static source MAC address setting
With this feature, TRex replaces the source MAC address with the client IP address.
-Note: This feature was requested by the Cisco ISG group.
+
+ Note: This feature was requested by the Cisco ISG group.
*YAML:*::
..
mac_override_by_ip : true <1>
----
-<1> In this case, the client side MAC address will be look like this:
+<1> In this case, the client side MAC address looks like this:
SRC_MAC = IPV4(IP) + 00:00
-=== IPv6 support ( `--ipv6`);
+=== IPv6 support (`--ipv6`)
Support for IPv6 includes:
1. Support for pcap files containing IPv6 packets
2. Ability to generate IPv6 traffic from pcap files containing IPv4 packets
The following switch enables this feature: `--ipv6`
-Two new keywords (src_ipv6, dst_ipv6) have been added to the YAML
-file to specify the most significant 96-bits of the IPv6 address - for example:
+Two new keywords (`src_ipv6`, `dst_ipv6`) have been added to the YAML file to specify the most significant 96 bits of the IPv6 address - for example:
[source,python]
----
is to form IPv4-compatible addresses (where the most signifcant 96-bits
are zero).
-There is a support for all plugins (control flows that needed to be change).
+There is a support for all plugins (control flows that needed to be changed).
-*An example:*::
+*Example:*::
[source,bash]
----
$sudo ./t-rex-64 -f cap2l/sfr_delay_10_1g.yaml -c 4 -p -l 100 -d 100000 -m 30 --ipv6
*Limitations:*::
-* TRex cannot generate both IPv4 and IPv6 traffic. The --ipv6 switch must be specified even when using a pcap file containing only IPv6 packets
+* TRex cannot generate both IPv4 and IPv6 traffic. The `--ipv6` switch must be specified even when using a pcap file containing only IPv6 packets.
*Router configuration:*::
asr1k(config)#ipv6 route 4000::/64 2001::2
asr1k(config)#ipv6 route 5000::/64 3001::2
----
-<1> enable ipv6
-<2> add pbr
-<3> enable ipv6 routing
-<4> mac-addr setting should be like TRex
+<1> Enable IPv6
+<2> Add pbr
+<3> Enable IPv6 routing
+<4> MAC address setting should be like TRex
<5> PBR configuraion
-=== Source MAC-address mapping using a file
+=== Source MAC address mapping using a file
-Extending the source MAC-address replacment capability.
-It is possible to have a mapping betwean IPv4->MAC using the new `--mac` CLI switch
-file format is YAML.
+Extends the source MAC address replacment capability. Enables mapping between IPv4->MAC using the new `--mac` CLI switch. The file format is YAML.
-*An example:*::
+*Example:*::
[source,bash]
----
$sudo ./t-rex-64 -f cap2/sfr_delay_10_1g.yaml -c 4 -l 100 -d 100000 -m 30 --mac cap2/test_example.yaml
*Limitations:*::
-. It is assumed that most of the clients has MAC addrees. at least 90% of the IP should have a MAC addrees mapping.
+. It is assumed that most clients have a MAC address. At least 90% of IPs should have MAC address mapping.
-=== Destination mac address spreadings anchor:mac_spread[]
+=== Destination MAC address spreading anchor:mac_spread[]
-Using this option, one can send traffic to few destination devices. In normal mode all the packets are sent to the port destination mac-address.
-to enable this option add `--mac-spread` to the command line.
+Using this option, one can send traffic to few destination devices. In normal mode, all packets are sent to the port destination MAC address.
+To enable this option, add `--mac-spread` to the command line.
-example:
+Example:
[source,bash]
----
$sudo ./t-rex-64 -f cap2/http_simple.yaml -d 1000 -m 1000 -c 4 -l 100 --mac-spread 2
----
-In this case TRex will send to port destination mac and port destination mac +1
-using a switch you could connect TRex to a few DUT.
-All the DUTs should return the traffic only to right port source address
+In this example, TRex sends to port destination MAC and port destination MAC +1. Using a switch, you can connect TRex to multiple devices under test (DUTs).
+All of the DUTs return the traffic only to the correct port source address.
+// above, i removed "should" - verify accuracy
[source,bash]
----
=== NAT support
TRex can learn dynamic NAT/PAT translation. To enable this feature add `--learn-mode <mode>` to the command line.
-In order to learn the NAT translation, TRex must embed information describing the flow a packet belongs to, in the first
+To learn the NAT translation, TRex must embed information describing the flow a packet belongs to, in the first
packet of each flow. This can be done in two different methods, depending on the chosen <mode>.
*mode 1:*::
Flow info is embedded in the ACK of the first TCP SYN.
-In this mode, there is a limitation that bidirectional UDP templates (e.g. DNS) are not supported.
-This mode was developed for testing NAT with firewalls (which usually can't work with mode 2).
+In this mode, there is a limitation that bidirectional UDP templates (for example, DNS) are not supported.
+This mode was developed for testing NAT with firewalls (which usually do not work with mode 2).
*mode 2:*::
<1> The number of translations with timeout should be zero. Usually this occurs when the router drops the flow due to NAT.
<2> Translation not found. This can occur when there is large latency in the router input/output queue.
<3> Active number of TRex traslation flows, should be low in the case of low RTT.
-<4> A total of TRex translation. May be different from the total number of flows in case template is uni-directional (and such does not need translation).
+<4> A total of TRex translation. May be different from the total number of flows if template is uni-directional (and consequently does not need translation).
*Configuration for Cisco ASR1000 Series:*::
-The feature was tested with the following configuration and sfr_delay_10_1g_no_bundeling. yaml traffic profile.
-Clients address range is 16.0.0.1-16.0.0.255
+This feature was tested with the following configuration and sfr_delay_10_1g_no_bundeling. yaml traffic profile.
+Client address range is 16.0.0.1 to 16.0.0.255
[source,python]
----
ip nat inside source list 8 pool my overload <6>
access-list 8 permit 17.0.0.0 0.0.0.255
----
-<1> Should be connected to TRex Client port (router inside port)
+<1> Must be connected to TRex Client port (router inside port)
<2> NAT inside
<3> NAT outside
<4> Pool of outside address with overload
-<5> Should match TRex YAML client range
-<6> In case of dual port TRex.
+<5> Match TRex YAML client range
+<6> In case of dual port TRex
+
+// verify 1 and 5 above; rephrased
*Limitations:*::
. The IPv6-IPv6 NAT feature does not exist on routers, so this feature can work on IPv4 only.
. Does not support NAT64.
-. Bundeling/plugin support is not fully supported. This means that sfr_delay_10.yaml can't work.Use sfr_delay_10_no_bundeling.yaml instead.
+. Bundling/plugin support is not fully supported. Consequently, sfr_delay_10.yaml does not work. Use sfr_delay_10_no_bundeling.yaml instead.
+// verify file name "sfr_delay_10_no_bundeling.yaml" above. english spelling is bundling but maybe the filename has the "e"
[NOTE]
=====================================================================
-* `--learn-verify` is a debug TRex mechanism for testing the TRex learn mechanism.
+* `--learn-verify` is a TRex debug mechanism for testing the TRex learn mechanism.
* If the router is configured without NAT, it will verify that the inside_ip==outside_ip and inside_port==outside_port.
=====================================================================
=== Flow order/latency verification ( `--rx-check` )
-In normal mode (without this feature enabled), received traffic is not checked by software. It is only counted by hardware (Intel NIC) for drop packets verification at the end of the test. The only exception is the Latency/Jitter packets.
-This is one of the reasons that with TRex, you *cannot* check features that terminate traffic (for example TCP Proxy).
-To enable this feature, you should add `--rx-check <sample>` to the command line options, where sample is the sample rate.
-1/sample of the flows will be sent to the software for verification. For 40Gb/Sec traffic you can use a sample of 1/128. Watch for Rx CPU% utilization.
+In normal mode (without this feature enabled), received traffic is not checked by software. Hardware (Intel NIC) testin for dropped packets occurs at the end of the test. The only exception is the Latency/Jitter packets.
+This is one reason that with TRex, you *cannot* check features that terminate traffic (for example TCP Proxy).
+To enable this feature, add `--rx-check <sample>` to the command line options, where <sample> is the sample rate.
+The number of flows that will be sent to the software for verification is (1/(sample_rate). For 40Gb/sec traffic you can use a sample rate of 1/128. Watch for Rx CPU% utilization.
-INFO : This feature changes the TTL of the sampled flows to 255 and expects to get packets with TTL 254 or 255 (one routing hop). If you have more than one hop in your setup, use `--hops` to change it to a higher value. More than one hop is possible if there are number of routers betwean TRex client side and TRex server side.
+ INFO: This feature changes the TTL of the sampled flows to 255 and expects to receive packets with TTL 254 or 255 (one routing hop). If you have more than one hop in your setup, use `--hops` to change it to a higher value. More than one hop is possible if there are number of routers betwean TRex client side and TRex server side.
-With this feature enabled, you can verify that:
+This feature ensures that:
-* Packets get out of DUT in order (from each flow perspective)
-* There are no packet drops (No need to wait for the end of the test). Without this flag, you must wait for the end of the test in order to identify packet drops, because there is always a difference between TX and Rx, due to RTT.
+* Packets get out of DUT in order (from each flow perspective).
+* There are no packet drops (no need to wait for the end of the test). Without this flag, you must wait for the end of the test in order to identify packet drops, because there is always a difference between TX and Rx, due to RTT.
.Full example
active flows: <6> 10, fif: <5> 308, drop: 0, errors: 0 <4>
-------------------------------------------------------------------------------------------
----
-<1> CPU% of the Rx thread. If it is too high *increase* the sample rate.
+<1> CPU% of the Rx thread. If it is too high, *increase* the sample rate.
<2> Rx Check section. For more detailed info, press 'r' during the test or at the end of the test.
<3> Average latency, max latency, jitter on the template flows in microseconds. This is usually *higher* than the latency check packet because the feature works more on this packet.
<4> Drop counters and errors counter should be zero. If not, press 'r' to see the full report or view the report at the end of the test.
-<5> First in flow (fif)- number of new flows handled by rx thread
+<5> fif - First in flow. Number of new flows handled by the Rx thread.
<6> active flows - number of active flows handled by rx thread
-.Full report by pressing 'r'
+.Press R to Display Full Report
[source,python]
----
m_total_rx : 2
cnt : 2
high_cnt : 2
max_d_time : 1041 usec
- sliding_average : 1 usec <3>
+ sliding_average : 1 usec <2>
precent : 100.0 %
histogram
-----------
h[1000] : 2
- tempate_id_ 0 , errors: 0, jitter: 61 <2>
+ tempate_id_ 0 , errors: 0, jitter: 61 <3>
tempate_id_ 1 , errors: 0, jitter: 0
tempate_id_ 2 , errors: 0, jitter: 0
tempate_id_ 3 , errors: 0, jitter: 0
m_st_stop : 1
m_st_handle : 0
----
-<1> Any errors shown here
-<2> Error per template info
-<3> low pass filter on the active average of latency events
+<1> Errors, if any, shown here
+<2> Low pass filter on the active average of latency events
+<3> Error per template info
+
+// IGNORE: this line added to help rendition. Without this line, the "Notes and Limitations" section below does not appear.
-*Limitation:*::
+*Notes and Limitations:*::
-** This feature must be enabled with a latency check (-l).
+** This feature must be enabled with a latency check (`-l`).
** To receive the packets TRex does the following:
-*** Changes the TTL to 0xff and expects 0xFF (loopback) or oxFE (route). ( use --hop to tune this number)
-*** Adds 24 bytes of metadata as ipv4/ipv6 option header
+*** Changes the TTL to 0xff and expects 0xFF (loopback) or oxFE (route). (Use `--hop` to configure this value.)
+*** Adds 24 bytes of metadata as ipv4/ipv6 option header.
+// clarify "ipv4/ipv6 option header" above
== Reference
cap_ipg_min : 30 <5>
cap_override_ipg : 200 <6>
----
-<1> Duration of the test (seconds). Can override using the `-d` option.
+<1> Test duration (seconds). Can override using the `-d` option.
<2> See the generator section.
+// what does note 2 mean? see somewhere else? isn't this simply the generator section?
<3> Default source/destination MAC address. The configuration file can override the defaults.
<4> TRUE indicates that the IPG is taken from pcap file.
-<5> The following two options can set the min ipg in microseconds: ( if (pkt_ipg<cap_ipg_min) { pkt_ipg=cap_override_ipg) }
+<5> The following two options can set the min ipg in microseconds: (if (pkt_ipg<cap_ipg_min) { pkt_ipg=cap_override_ipg) }
+// in note 5 above, the parentheses and braces ( "(" and "{" ) are mismatched
<6> Value to override (microseconds).
-<7> Enable valn feature. See xref:trex_valn[here] for info.
-<8> Enable MAC address replacement by Client IP.
+// in note 6, clarify "override"
+<7> Enable valn feature. See xref:trex_valn[trex_valn section] for info.
+<8> Enable MAC address replacement by client IP.
==== Per template section
+// clarify "per template"
[source,python]
----
one_app_server : true <7>
----
-<1> The name of the template pcap file. It can be relative to the t-rex-64 image or absolute path. The pcap file can include one flow. (Exception: in case of plug-ins).
+<1> The name of the template pcap file. Can be a relative path, based on the t-rex-64 image directory, or an absolute path. The pcap file can include one flow. (Exception: in case of plug-ins).
<2> Connection per second for m==1
<3> If the global section of the YAML file does not include `cap_ipg : true`, this line sets the inter-packet gap in microseconds.
<4> Should be set to the same value as ipg (microseconds).
Code Review / trex.git / commitdiff