TRex

From fd.io

Revision as of 11:03, 16 February 2017 by Hhaim (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-dev@lists.fd.io Jenkins: jenkins silo Gerrit Patches: code patches/reviews Bugs: TREX bugs

1 TRex Low-Cost, High-Speed Stateful Traffic Generator

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.

A new JSON-RPC2 Architecture provides support for interactive mode

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