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 |
Netflow |
Netflow v9, RFC 3954 and Netflow v10 (IPFix), RFC 7011 |
transport |
user space TCP based on BSD (converted to native golang) and UDP |
TRex Architecture with TRex-EMU:
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:
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.
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.
$cd scripts $source ./b $cd ../src/ $go install -v cmd/trex-emu.go or use our script: $cd scripts $./utility_script build -v
$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
./$root/bin/trex-emu
$source ./b $export GO111MODULE=auto; code
"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. |