Difference between revisions of "TRex"
m (Valderrv moved page TRex to Archived-TRex) |
Jwagantall (Talk | contribs) m (Jwagantall moved page Archived-TRex to TRex over redirect) |
(No difference)
|
Revision as of 19:24, 29 July 2021
TRex Facts |
Project Lead: Hanoch Haim
Repository: git clone https://gerrit.fd.io/r/trex |
Contents
- 1 TRex Low-Cost, High-Speed Stateful Traffic Generator
- 1.1 Current Challenges
- 1.2 Implications
- 1.3 TRex in a Nutshell
- 1.4 Current Stateful TRex Feature sets
- 1.5 New TRex Stateless feature sets
- 1.6 What it's not
- 1.7 What you can do with it
- 1.8 Presentation
- 1.9 Documentation
- 1.10 Wiki
- 1.11 YouTrack
- 1.12 Windows Stateful Client GUI
- 1.13 Sandbox for evaluation
- 1.14 Contact Us
- 1.15 Roadmap
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
Stateless
- Beanchmark/Stress vSwitch RFC2544
Presentation
Documentation
Wiki
Internal Wiki
YouTrack
Report bug/request feature YouTrack
Windows Stateful Client GUI
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