TRex Emulation service

The objective is to implement client side L3 protocols i.e ARP, IPv6, ND, MLD, IGMP in order to simulate a scale of clients and servers. This project is not limited to client protocols, but it is a good start. The project provides a framework to implement and use client protocols.

The framework is fast enough for control plane protocols and will work with TRex server. Very fast L7 applications (on top of TCP/UDP) will run on TRex server. One single thread of TRex-EMU can achieve a high rate of client creation/teardown. Each of the aforementioned protocol is implemented as a plugin. These plugins are self contained and can signal events one to the other, or to the framework, using an event-bus. (e.g. DHCP signals that it has a new IPv6 address). The framework has an event driven architecture, this way it can scale. The framework also provides to a protocol plugin infrastructure, for example RPC, timers, packet parsers, simulation and more.

The main properties:

• Fast client creation/teardown. ~3K/sec for one thread.

• Number of active client/namespace is limited only by the memory on the server.

• Packet per second (PPS) in the range of 3-5 MPPS.

• Python 2.7/3.0 Client API exposed through JSON-RPC.

• Interactive support - Integrated with the TRex console.

• Modular design. Each plugin is self contained and can be tested on its own.

• TRex-EMU supports the following protocols:

Plug-in	Description
ARP	RFC 826
ICMP	RFC 777
DHCPv4	RFC 2131 client side
IGMP	IGMP v3/v2/v1 RFC3376
IPv6	IPv6 ND, RFC 4443, RFC 4861, RFC 4862 and MLD and MLDv2 RFC 3810
DHCPv6	RFC 8415 client side
DOT1X	EAP-MD5/EAP-MSCHAPv2 RFC 3748, IEEE 802.1X-2001
LLDP	IEEE 802.1AB
CDP	Cisco CDP
Netflow	Netflow v9, RFC 3954 and Netflow v10 (IPFix), RFC 7011
transport	user space TCP based on BSD (converted to native golang) and UDP
Cisco telemetry TDL	under tests simulate network device

TRex Architecture with TRex-EMU:

Figure 1. TRex Architecture

TRex-EMU can receive commands (RPC via JSON-RPC) from a Python client and send/receive packets via a ZMQ channel that connects it to the TRex server (RX core). Packets from the network (from a TRex server physical port) that match a filter (dynamic) are forwarded to the TRex-EMU process. Packets from the EMU process are packed into the ZMQ channel and sent directly to the TRex physical port.

TRex-EMU Architecture:

Figure 2. Emulation Server Architecture

Each TRex emulation process called thread can have a few Namespaces.

Each Namespace must have a unique tuple key, that is composed from {physical-port, dot1q, QinQ}. The namespace key could be extended to tunnels in the future.

Each Client can be associated with one Namespace.

Each Protocol Plugin can attach an opaque object at each level (thread, namespace, client) and run the protocol logic at that level. For example, DHCPv6 will be run mainly at the client level, while MLDv2 will run on a namespace context.

Different plugins and frameworks can communicate through an event bus. A plugin can register on a topic (Subscriber) and can send an event on a specific topic (Publisher) (e.g. DHCPv6 can send an event upon a change of a source IPv6).

Something to note in this model is that Clients can share information on the same Namespace, reducing multicast, broadcast and generally packet duplication.

Figure 3. ARP Plugin

The previous figure shows a shared IPv4 default gateway for many clients, which is resolved once and shared with all the respective clients. So ARP broadcast packets do not need to be duplicated for each client. In this example, if all the clients had the same default gateway 16.0.0.1, we will have only one entry in the ARP cache table and each client will have a pointer to it. This is an example on how scaling in the number of clients can be achieved.

How to build

Build

$cd scripts
$source ./b
$cd ../src/
$go install -v cmd/trex-emu.go

or use our script:

$cd scripts
$./utility_script build -v

Run Tests

$source ./b
$cd src/
$go test emu/core
$go test emu/plugins/ipv6
$go test emu/plugins/arp
$go test emu/plugins/igmp
$go test emu/plugins/ipv6
$go test emu/plugins/dhcpv6
$go test emu/plugins/dhcp

or use our script:

$cd scripts
$./utility_script test -v

Run

./$root/bin/trex-emu

VsCode

$source ./b
$export GO111MODULE=auto; code

VsCode plugin

"go.toolsGopath" : "/scratch/hhaim/vscode-gotools",
"go.inferGopath": true,
"go.useLanguageServer" :true,
"go.buildOnSave": true,
"go.vetOnSave": true,

Note	ZMQ was build to x86. You should add the share object to the LDD path for installing the package. See how to build it.