---

   trafgen    ( 8 )

---

Примечание (Note)

trafgen can saturate a Gigabit Ethernet link without problems. As always, of course, this depends on your hardware as well. Not everywhere where it says Gigabit Ethernet on the box, will you reach almost physical line rate! Please also read the netsniff-ng(8) man page, section NOTE for further details about tuning your system e.g. with tuned(8).

If you intend to use trafgen on a 10-Gbit/s Ethernet NIC, make sure you are using a multiqueue tc(8) discipline, and make sure that the packets you generate with trafgen will have a good distribution among tx_hashes so that you'll actually make use of multiqueues.

For introducing bit errors, delays with random variation and more, there is no built-in option in trafgen. Rather, one should reuse existing methods for that which integrate nicely with trafgen, such as tc(8) with its different disciplines, i.e. netem.

For more complex packet configurations, it is recommended to use high-level scripting for generating trafgen packet configurations in a more automated way, i.e. also to create different traffic distributions that are common for industrial benchmarking:

Traffic model Distribution

IMIX 64:7, 570:4, 1518:1 Tolly 64:55, 78:5, 576:17, 1518:23 Cisco 64:7, 594:4, 1518:1 RPR Trimodal 64:60, 512:20, 1518:20 RPR Quadrimodal 64:50, 512:15, 1518:15, 9218:20

The low-level nature of trafgen makes trafgen rather protocol independent and therefore useful in many scenarios when stress testing is needed, for instance. However, if a traffic generator with higher level packet descriptions is desired, netsniff-ng's mausezahn(8) can be of good use as well.

For smoke/fuzz testing with trafgen, it is recommended to have a direct link between the host you want to analyze (''victim'' machine) and the host you run trafgen on (''attacker'' machine). If the ICMP reply from the victim fails, we assume that probably its kernel crashed, thus we print the last sent packet together with the seed and quit probing. It might be very unlikely to find such a ping-of-death on modern Linux systems. However, there might be a good chance to find it on some proprietary (e.g. embedded) systems or buggy driver firmwares that are in the wild. Also, fuzz testing can be done on raw 802.11 frames, of course. In case you find a ping-of-death, please mention that you were using trafgen in your commit message of the fix!