Etherate

Etherate - Linux CLI Ethernet and MPLS Testing Tool

Contents:
Overview - What is Etherate, what is it's purpose?
Basic Usage - Quick start guide
Etherate Features - A more detailed description of how each feature works
Etherate Usage Examples - The CLI examples page
FAQs - Check here if you're having problems
ChangeLog - Version and release notes
Download - Link to the Source Code (GitHub)
Bug Repots / Feature Request - Open a new issue on the GitHub page

Overview

Programs such as iPerf/jPerf/Ostinato/PathEth/Scapy (to name just a few) are excellent! They can saturate a link to measure throughput or simulate congestion and they allow the user to set custom DSCP values to test QoS (as well as many other features). They usually operate at layer 3 or 4 of the OSI model using either TCP or UDP for data transport. Some of them use sockets defined by the OS that rely on a convoluted OS TCP/IP stack, others use 3rd party libraries (such as libpcap, NetMap etc).

These programs are great for testing over a layer 3 boundary such as across the Internet, home broadband, client to server diagnostics etc. Etherate uses raw sockets within Linux operating directly over layer 2 to provide low level network analysis for Ethernet and MPLS connections without using any 3rd
party libraries or kernel bypass techniques.

The aim is free Ethernet and MPLS testing program that allows for advanced network analysis. With any modern day CPU and off the self NIC it should saturate up to a 10GigE link using 1500 byte frames and allow for the testing of various metro and carrier Ethernet features (such tag swapping, 802.1p QoS, ethertype parsing, and so on). This should all be achievable without the need to install any 3rd party libraries (see INSTALL for details). Etherate can simply be compiled and executed from the folder it was downloaded to and provide "quick and dirty" tests or advanced bespoke testing using custom frame files.

Etherate is a single threaded application, despite which 10G throughput can be achieved on a 2.4Ghz Intel CPU with 10G Intel NIC using 1500 byte frames. Etherate is not currently using NetMap, DPDK, VPP or other similar frameworks as it is intended to test the OS's native capabilities and be easily usable without any 3rd party requirements (apart from a recent Kernel!). If you want 64 byte packet line rate performance on Nx10G or Nx100G etc then Etherate is not for you. There are some great projects such as MoonGen and PtkGen which Etherate cannot compete with for performance. DPDK and PktGen or MoonGen require additional setup time and complexity which is the trade-off with Etherate. Etherate can load a custom frame from a file to transmit and test a traffic parsing graph or fill a specific ASIC queue with minimal effort.

 

Basic Usage

Etherate is designed to be run on two hosts, one host being the Tx (transmit) host and the other being the Rx (receive) host. This is because Etherate runs directly over Ethernet/layer 2 and since Ethernet is a "lossy" protocol Etherate sends a unidirectional [Ethernet] traffic flow from Tx to Rx and each host reports on sent/received/missing frames, speed, duration etc. A test can then be repeated with with the modes reversed so that the original Tx hosts is now running in Rx mode and the original Rx host runs in Tx mode, meaning traffic can be sent back in the other direction. This allows for the two directions of a physical or logical layer 2 connections to be tested individually. The CLI argument -r places a host into Rx mode, otherwise Etherate runs in Tx mode by default.

Etherate sends traffic directly over Ethernet so it goes without saying that all tests between Tx and Rx hosts are run within the same layer 2 broadcast domain, it can not test over a layer 3 boundary. Hopefully it also goes without saying that the Rx host should be started first and then the Tx host, one can not start transmitting test data before the Rx host is ready to receive it.

The Tx host is the "master" host. By default a speed test is run between the two hosts, if another test type is specified or a specific test setting is changed on the Tx host, the Tx host will tell the Rx host about the change before the test starts (changed settings on the Rx host are not communicated back to the Tx host). After the settings are "synchronised" from Tx to Rx, Etherate by default will try to calculate the delay between Tx and Rx hosts (unless explicitly told not to).

Etherate will by default try to use a common interface name like eth0 or en0. If it can't find one or it defaults to the wrong interface, any "up" interface can be specified by name using the -i flag or by interface index using the -I flag (upper case "i"). The -l flag (lower case "L") lists available interfaces. Etherate should only be used against a physical interface. Never use a VLAN tagged sub/logical interface like eth0.100 for example.

Etherate can also be used to transmit traffic without the need for an Rx host. For example, it is difficult for a service provide to understand just how badly their network will fail until they blast 1Gbps of broadcast frames or BPDUs into their VPLS platform; or to understand that control-plane protection features like Cisco's CoPP or Juniper's Loopback 0 filtering don't save you if 1Gbps of TCP packets to port 179 are being received, no genuine BGP UPDATES can be received also and so all genuine BGP sessions will dropped despite your best filtering efforts, until you test these cases! To transmit traffic "freely" without an Rx host use the -g and -G CLI arguments together which skip the settings synchronisation and delay calculation phases respectively.

 

---