---

   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!