TRex

From fd.io
Revision as of 19:28, 20 July 2023 by Dwallacelf (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
TRex Facts

Project Lead: Hanoch Haim
Committers:

  • Hanoch Haim
  • Itay Marom
  • Ido Barnea
  • Yaroslav Brustinov

Repository: git clone https://gerrit.fd.io/r/trex
Mailing List: trex-tgn@googlegroups.com
Jenkins: jenkins silo
Gerrit Patches: code patches/reviews
Bugs: tracked at Github


NOTE: This wiki is no longer maintained. See the github TRex Traffic Generator wiki for up to date information on TRex.

TRex Low-Cost, High-Speed Stateful Traffic Generator

New Stateless support was released see more in the folowing section

Traditionally, network infrastructure devices have been tested using commercial traffic generators, while performance was measured using metrics like packets per second (PPS) and No Drop Rate (NDR). As the network infrastructure functionality has become more complex, stateful traffic generators have become necessary in order to test with more realistic application traffic pattern scenarios. Realistic and Stateful traffic generators are needed in order to:

  • Test and provide more realistic performance numbers
  • Design and architecture of SW and HW based on realistic use cases

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

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

TRex addresses these problems through an innovative and extendable software implementation and by leveraging standard and open SW and x86/UCS HW.

TRex in a Nutshell

  • Cisco Pioneer Award Winner 2015
  • Fueled by DPDK
  • Generates and analyzes L4-7 traffic and able to provide in one tool capabilities provided by 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)
  • Low cost
  • Virtual interfaces support, enable TRex to be used in a fully virtual environment without physical NICs and the following example use cases:
    • Amazon AWS
    • TRex on your laptop
    • Self-contained packaging

Current Stateful TRex Feature sets

  • Support Intel DPDK 1/10/40Gbps interfaces
  • High scale of realistic traffic (number of clients, number of server, bandwidth)-up to 200Gb/sec in one UCS
  • Virtualization interfaces support (VMXNET3/E1000 )
  • Some stateless support for example IMIX traffic generation
  • Latency/Jitter measurements
  • Flow ordering checks
  • NAT, PAT dynamic translation learning
  • IPV6 inline replacement
  • Some cross flow support (e.g RTSP/SIP)
  • Python automation API
  • Windows GUI for real-time latency/jitter/flow order

New TRex Stateless feature sets

  • Large scale - Supports about 10-22 million packets per second (mpps) per core, scalable with the number of cores
  • Support for 1, 10, 25, 40 interfaces
  • Profile can support multiple streams, scalable to 10K parallel streams
  • Supported for each stream:
    • Packet template - ability to build any packet (including malformed) using Scapy (example: MPLS/IPv4/Ipv6/GRE/VXLAN/NSH)
    • Field engine program
      • Ability to change any field inside the packet (example: src_ip = 10.0.0.1-10.0.0.255)
      • Ability to change the packet size (example: random packet size 64-9K)
    • Mode - Continuous/Burst/Multi-burst support
    • Rate can be specified as:
      • Packets per second (example: 14MPPS)
      • L1/L2 bandwidth (example: 500Mb/sec)
      • Interface link percentage (example: 10%)
    • Support for HLTAPI-like profile definition
    • Action - stream can trigger a stream
  • Interactive support - Fast Console, GUI
  • Statistics per interface
  • Statistics per stream done in hardware
  • Latency and Jitter per stream
  • Blazingly fast automation support (Python 2.7/3.4)
  • Multi-user support

The following example shows three streams configured for Continuous, Burst, and Multi-burst traffic.

Stl streams example 02.png

A new JSON-RPC2 Architecture provides support for interactive mode

Trex architecture 01.png

more info can be found here Documentation

What it's not

  • There is no routing emulation support, for example, BGP/ISIS/ARP
  • There is no TCP stack.
  • Client only or Server Only.

What you can do with it

Stateful

  • Beanchmark/Stress stateful features :
    • NAT
    • DPI
    • Load Balancer
    • Network cache devices
    • FireWall
    • IPS/IDS
  • Mixing Application level traffic/profile (HTTP/SIP/Video)
  • Unlimited concurent flows, limited only by memory

Stateless

  • Beanchmark/Stress vSwitch RFC2544

Presentation

New Stateless support

DPDK summit 2015

Video DPDK summit 2015

Presentation

Documentation

Documentation

Wiki

Internal Wiki

YouTrack

Report bug/request feature YouTrack

Windows Stateful Client GUI

TrexViewer.png

Sandbox for evaluation

Try the new Devnet Sandbox TRex Sandbox

Contact Us

Follow us on TRex traffic generator google group,

Or contact via: Group mailing list (trex-tgn@googlegroups.com)

Or via Cisco Devnet portal Devnet

Roadmap

  • High speed TCP stack support