Etherate - Linux CLI Ethernet and MPLS Testing Tool

FAQs - See the FAQs page.

Etherate Usage Examples - See the CLI examples page

Versions - See the ChangeLog file

Downloads - See the Source Code (github)



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.



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 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.



Etherate has the following features;

  • Test a link with only one argument:
    By default Etherate assumes it is the transmitter so on one Linux machine execute: $./etherate -r to place one end into receive mode, then simply $./etherate on another machine to start transmitting and testing.

  • Easy to identify traffic:
    Etherate by default will use two MACs from an unassigned pool by IANA and a customer ethertype (0x3333) so it should be very easy to spot the traffic in MAC/TCAM tables, sniffers, taps etc, along the path. It also means you don't actually need to know the MAC address of both the testing hosts.

  • Custom Ethertype:
    The default Ethertype value set in the frame header is IPv4, you can specify any value though. Handy for testing at IXPs or leased wavelengths where Ethertype is often (should?) be restricted.

  • Custom or auto MAC addressing:
    Etherate will by default use two IANA unallocated MACs. You can also specific to use the burnt in MAC of the interface being used to transmit/receive, or any custom MAC that you like.

  • VLAN tagging/QinQ tagging:
    Etherate supports the sending of frames with one VLAN tag or multiple VLAN tags (QinQ) so it can be attached to a trunk port if required.

  • CoS/PCP bits:
    Etherate supports the use of Class of Service or Priority Code Point bits when sending both tagged and untagged frames.

  • DEI bit:
    Etherate can set the drop eligible indicator bit on frames to test congestion mechanisms.

  • Frame acknowledgement:
    Etherate can ACK back every frame it sends to test frame loss over Ethernet which is normally lossy.

  • Speed limits:
    For traffic load testing and monitoring testing Etherate can be limited in Mbps or Frames per second.

  • Frame size:
    The size of frames can be set to test tiny 64 byte frames or jumbo 9000 byte frames.

  • Transfer limit in MBs/GBs:
    To test transfer limits and monitoring software Etherate can generate traffic until a specific volume of traffic has been sent.

  • Test duration limit in seconds:
    To test transfer limits and monitoring software Etherate can generate traffic for a specified amount of time only.

  • BUM testing:
    Writing directly to the wire in promiscuous mode means any MAC can be sent to and received from. This means broadcast or multicast frames can be sent to simulate broadcast, unknown unicast, multicast storm (BUM) testing.

  • Latency measuring:
    Etherate will attempt to measure the latency from the Tx host to Rx host by default. It uses the Linux atomic clock request so that it should not change if there is an NTP update during the test and give a true value of the network delay between hosts (or very close to, there is obviously a small amount of computing time).

  • MTU testing:
    Etherate supports an MTU size up to 10,000 bytes so jumbo frame testing is possible and it has a sweep mode which it automatically detect the largest MTU supported between sender and receiver.

  • RTT and Jitter testing:
    Etherate can perform a link quality test during which the Tx host sends "ping" packets to the Rx host which "pongs" them back. The RTT is measures from Tx to Rx and back to Tx again and Rx reports the jitter between each received "ping".

  • MPLS labels stack testing:
    Etherate can push MPLS labels on to the frame to inject into an LSP for testing MPLS uRPF or VPN hopping, or the maximum label depth a router supports for load-balancing or popping etc

  • Pseudowire control-word imposition:
    Etherate can push a pseudowire control-word onto the frame, when coupled with the MPLS label option it can be used to inject data into an MPLS pseudowire LSP.

  • Customer Frame Payload:
    Etherate normally sends junk data are the main Ethernet frame payload so it is not cached or interpretable by WAN accelerators or predictable with regards to load balancing. However a custom frame can be loaded from file which will be sent instead.


Previous page: DPDK Notes
Next page: Etherate Examples and Use Cases