Etherate Features

Etherate Features

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. They must of course be inside the same VLAN / broadcast domain.
  
  
• 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 being used.
  
  
• Custom Ethertype:
  The default Ethertype value set in the frame header is 0x3333, one can specify any value though. Handy for testing at IXPs or leased wavelengths where Ethertype is often (should?) be restricted. 0x3333 it used to make Etherate traffic easy to filter for in tools like Wireshark or tcpdump.
  
  
• 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 or two VLAN tags (QinQ) which are user configurable,  so it can be attached to a switch trunk port or NNI if required. With two VLAN tags, the Linux Kernel will "absorb" the outter most tag. With a single VLAN tag the only VLAN tag is "absorbed" by the Kernel. Etherate should only be used on a physical interface and not bound to a VLAN or logical interface/sub-interface. For example "$ ./etherate -i eth0 -v 100" should be used to send traffic inside VLAN 100 from interface eth0 instead of binding to a VLAN logical interface such as eth0.100. If the VLAN tag isn't beng stripped before the traffic from the Tx host reaches the Rx host the -v flag is required on the Rx host to ensure it is in the same broadcast domain as the Tx host. The VLAN tag is not an option that is sent from the Tx host to the Rx host as they maybe in different tagged VLANs that are bridged (e.g. using DCI).
  
  
• 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. This will dramatically lower perfomance. When the Tx host sends a frame it waits for the timeout period before assuming the ACK from the Rx was lost/dropped.
  
  
• Speed limits:
  For traffic load testing and monitoring testing Etherate can be limited in Mbps, MBps or Frames per second. The speed limit counts the full frame; src & dst MAC, Ethertype, any VLAN tags + the payload. Not the CRC/FCS, inter-frame gap or start frame delimiter though.
  
  
• Frame size:
  The size of frames can be set to test tiny 64 byte frames or jumbo 9000 byte frames. A max MTU size of 10000 bytes is hard coded.
  
  
• 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 (specified in whole MBs).
  
  
• Test duration limit in seconds:
  To test transfer limits and monitoring software Etherate can generate traffic for a specified amount of time only (specified in whole seconds).
  
  
• 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). The two testing machines do not need to have the same time / clock source or the correct 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 with which it can automatically detect the largest MTU supported between sender and receiver. In this mode if the receiver goes 5 seconds without receiving an MTU test frame the Rx host ends the test.
  
  
• 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 measured 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. Some example files are provided, these are written in hex and start from the destination MAC address. A CRC is not required, this is calculated in hardware or by the Kernel.

 

---