tcpreplay
Resend the package saved in PCAP file for performance or functional testing
Supplementary instructions
tcpreplay is used to replay the network traffic saved in the pcap file. It supports replaying the network traffic according to the speed of the packet when the pcap file is captured, or at a specified speed, as long as it is within the range of the hardware.
It can enable traffic to be split directly between two network cards, written to files, filtered, and edited in various ways as needed, thus providing a method for testing firewalls, NIDS, and other network devices.
Command parameters
-d number, --dbug=number
Enable debug output. This option can appear at most once. This option takes an integer as argument. The value of number is limited to: in the range of 0 to 5 The default input number for this option is: 0 If configured with --enable-debug, you can specify the verbosity level for debug output. The higher the number, the more detailed it is.
-q, --quiet
Silent mode. Print nothing except statistics at the end of the run
-T string, --timer=string
Select packet timing mode: select, ioport, gtod, nano. This option can appear at most once. The default string for this option is: gtod Allows you to select the packet timing method to use:
nano - using the nanosleep() API
select - using the select() API
ioport - Write to i386 IO port 0x80
gtod [default] - loop using gettimeofday()
--maxsleep=number
Set to sleep for no more than X milliseconds between packets. This option takes an integer as argument. The default input number for this option is: 0 Sets the limit on the maximum number of milliseconds tcpreplay sleeps between packets. Effectively prevents long delays between packets without affecting most packets. The default is disabled.
-v, --verbose
Print decoded packets to standard output via tcpdump. This option can appear at most 1 time
-A string, --decode=string
Parameters passed to the tcpdump decoder. This option can appear at most once. This option must be used previously with the -v parameter. When verbose mode (-v) is enabled, you can also specify one or more additional parameters to pass to tcpdump to modify how packets are decoded. By default, -n and -l are used. Make sure the string is enclosed in double quotes, such as: -A "-axxx", otherwise it will be misused as a parameter by tcpreplay. For a complete list of options, see the tcpdump(1) man page
-K, --preload-pcap
Preload packets into RAM before sending. This option loads the specified pcap into RAM before starting sending, in order to improve startup performance and therefore replay performance. Preloading can be done with or without --loop. This option also controls the collection of flow statistics for each iteration, which can significantly reduce memory usage. Predict flow statistics based on the options provided and statistics collected from the first loop iteration.
-c string, --cachefile=string
Split traffic through tcpprep cache files. This option can appear at most once. This option must be used with the following option: intf2. This option must not be used with the following option: dualfile. If you have a pcap file that you want to use to send bidirectional traffic through a device (firewall, router, IDS, etc.), then using tcpprep you can create a cache file that tcpreplay will use to split traffic between the two network interfaces.
-2, --dualfile
Replay two files at once from network tap. This option can appear at most once. This option must be used with the following option: intf2. This option must not be used with any of the following: cachefile. If you use a network tap to capture network traffic, then you end up with two pcap files - one for each direction. This option will replay both files simultaneously, one for each interface, and mix them using the timestamps in each file
-i string, --intf1=string
Client to server/RX/primary (primary) traffic output interface. This option can appear at most 1 time. The desired network interface to send all traffic or traffic marked as "primary" via tcpprep. Primary traffic is typically client-to-server or inbound (RX) traffic on the khial virtual interface.
-I string, --intf2=string
Server to client/TX/secondary (secondary) traffic output interface. This option may appear at most once.
Optional network interface used to send traffic marked as "secondary" via tcpprep. Secondary traffic is typically server to client or outbound (TX) on the khial virtual interface. In general, it only makes sense to use this option with --cachefile.
--listnics
List all available network cards and exit.
-l number, --loop=number
Loop through the captured file X times. This option can appear at most once. This option takes integers as input arguments. The value of number is limited to: Greater than or equal to 0, the default input number for this option is: 1
--loopdelay-ms=number
Delay between loops in milliseconds. This option must appear together with the following option: --loop. This option takes integers as input arguments. The value of number is limited to: greater than or equal to 0. The default input number for this option is: 0
--pktlen
Override snaplen and use the actual packet len. This option can appear at most once. By default, tcpreplay will send packets based on the size of "snaplen" stored in the pcap file, which is generally the correct thing to do. Occasionally, however, the tool will store more bytes. By specifying this option, tcpreplay will ignore the snaplen field and instead try to send the packet based on the original packet length. If this option is specified, an error may occur.
-L number, --limit=number
Limit the number of packets to be sent. This option can appear at most once. This option takes integers as input arguments. The value of number is limited to: greater than or equal to 1. The default input for this option is: -1 By default, tcpreplay will send all packets. Or manually specify the maximum number of packets to send.
--duration=number
Limit the number of seconds sent. This option can appear at most once. This option takes integers as input parameters. The value of number is limited to: greater than or equal to 1. The default number for this option is: -1 By default, tcpreplay will send all packets. Or manually specify the maximum number of seconds to transmit.
-x string, --multiplier=string
Modify the playback speed to the specified multiple. This option can appear at most once. This option must not appear with any of the following options: pps, mbps, oneatatime, topspeed. Specify a value to modify packet replay speed. example: 2.0: Traffic will be replayed at twice the capture speed 0.7: Traffic will be replayed at 70% of the captured speed
-p string, --pps=string
Replay packets at given packets/sec. This option can appear at most once. This option must not appear with any of the following options: multiplier, mbps, oneatatime, topspeed.. Specify a value to adjust packet replay to a specific packets/sec rate. example: 200: Traffic will be replayed at 200 packets per second 0.25: Traffic will be replayed at 15 packets per minute
-M string, --mbps=string
Replay packets at the given Mbps. This option can appear at most once. This option must not appear together with any of the following options: multiplier, pps, oneatatime, topspeed. You can set the Mbps rate at which tcpreplay sends data packets. This value can be specified as a floating point value.
-t, --topspeed
Replay packets as fast as possible. This option must not appear with any of the following options: mbps, multiplier, pps, oneatatime.
-o, --oneatatime
Replay each packet based on user input. This option must not appear together with any of the following options: mbps, pps, multiplier, topspeed. Allows you to step through one or more packets at a time.
--pps-multi=number
Specifies the number of packets to send per interval. This option must be used with the following option: pps. This option takes integers as input arguments. The value of number is limited to: greater than or equal to 1. The default value of this option is: 1 When trying to send packets at a very high rate, the time between each packet may be so short that it is impossible to sleep for exactly the required period of time. This option allows you to send multiple packets at once, allowing longer sleep times, which can be achieved more accurately.
--unique-ip
Modify the IP address for each loop iteration to generate a unique stream. This option must be used with the following option: loop. Ensures that IPv4 and IPv6 packets are unique for each --loop iteration. This is done in a way that does not change the packet CRC, so there is usually no impact on performance. This option will significantly increase the flow/sec generated by multiple loop iterations.
--unique-ip-loops=string
Number of --loop iterations before assigning a new unique IP. The default value is 1. Assume both --loop and --unique-ip are used.
--netmap
Write packets directly to a netmap-enabled network adapter. This feature will detect network drivers that support netmap on Linux and BSD systems. If detected, the network driver is bypassed during execution and the network buffer is written directly. This will allow you to achieve full line rates on commodity network adapters, similar to those achieved with commodity network traffic generators. Note that bypassing the network driver will break other applications connecting through the test interface.
This feature can also be enabled by specifying the interface as netmap:<intf> or vale:<intf>. For example, netmap:eth0 specifies the network map on interface eth0.
--nm-delay=number
Netmap startup delay. This option takes an integer as argument. The default input for this option is: 10 Number of seconds to delay after loading netmap. Make sure the interface is fully up and working before netmap transfer. Requires netmap option. The default value is 10 seconds.
--no-flow-stats
Block printing and track traffic, rates and expirations
Collecting and printing traffic statistics is prohibited. This option can improve performance when the --preload-pcap option is not used, otherwise its only function is to suppress printing.
The streaming function will track and print statistics for the stream being sent. Simply put, a flow is uniquely distinguished by a 5-tuple, namely source IP, destination IP, source port, destination port and protocol. If --loop is specified, the flow from one iteration to the next will not be unique unless packets are changed. Use --unique-ip or tcpreplay-edit to change packets between iterations.
--flow-expiry=number
The number of seconds of inactivity before a stream is considered expired. This option must not be used with the following option: no-flow-stats. This option takes integers as input parameters. The value of number is limited to: greater than or equal to 0 The default value for this option is: 0 This option will track and report expiration of streams based on their idle time. The timestamp in the pcap file is used to determine the expiration time, not the actual timestamp of the replayed packet. For example, a value of 30 means that if there is no traffic on the stream for 30 seconds, any subsequent traffic will be considered new traffic and thus will increase the flow and flows per second (fps) statistics.
(For example, a value of 30 means that if a flow does not see any traffic for 30 seconds, any subsequent traffic will be considered a new flow, thereby increasing the traffic and flows per second (fps) statistics.)
This option can be used to optimize the streaming timeout settings for streaming products. Setting the timeout low may cause traffic to be dropped when actual traffic is slow to respond. Configuring the traffic timeout too high may increase the resources required by the traffic product. Note that using this option when replaying at higher than original speeds may result in inflated traffic and fps counts. Default value is 0 (no expiration), typical value is 30-120 seconds
-P, --pid
Print the PID of tcpreplay on startup
--stats=number
Print statistics every X seconds, or every loop if '0'. This option takes integers as input arguments. The value of number is restricted to: greater than or equal to 0
Please note that timing latency is "best effort", long delays between sending packets may result in equally long delays between printing statistics.
-V, --version
Print version information
-h, --less-help
Print simple help information
-H, --help
Print help information
-!, --more-help
Print detailed help information
--save-opts [=cfgfile]
Save option status to cfgfile. The default is the last profile listed in the OPTION PRESETS section below. The command exits after updating the configuration file.
--load-opts=cfgfile, --no-load-opts
Load options from cfg file. The no-load-opts form will disable loading of older config/rc/ini files. --no-load-opts Process ahead of time, out of order.
Example
**1. Replay the packets on the client ftp connection **
a. Use ethereal to capture packets on the client and save them as ftp.pcap files.
b. Perform tcpprep operation on the ftp.pcap file to create a cache file.
[root@A ~]# tcpprep -an client -i ftp.pcap -o ftp.cache –vc. Connect the two interfaces of the DUT device to the two interfaces of the PC using network cables, and use tcpreplay to replay the message. Note that the firewall is configured in bridge (transparent) mode.
[root@A ~]# tcpreplay -c ftp.cache -i eth0 -j eth1 ftp.pcap -R –vThe -R parameter means sending at full speed, and -v displays printing information.
**2. Replay the packets on the client BT connection **
a. Download some Taiwanese entertainment programs and popular blockbusters in the laboratory BT, use ethereal to capture the packets, and save them as bt.pcap files. Pay attention to the control of pcap file size, which requires relatively high memory on the PC. It took me more than 40 minutes to save a pcap file of more than 600 MB. If necessary, you can copy it directly from the laboratory.
b. Perform tcpprep operation on the bt.pcap file to create a cache file.
[root@A ~]# tcpprep -an client -i bt.pcap -o bt.cache -C "100M BT Packet" –vCreate a cache file and write the comment "100M BT Packet" in the cache file.
c. Use tcpreplay to replay the message.
[root@A ~]# tcpreplay -c bt.cache -i eth0 -j eth1 bt.pcap -v –R**3. Replay the packets captured on the tftp server **
a. Use ethereal to capture packets on the tftp server and save them as a tftp.pcap file.
b. Perform tcpprep operation on the pcap file to create a cache file.
[root@A ~]# tcpprep -an server -i tftp.pcap -o tftp.cache –vNote: I made a mistake during the test. I used the tftp upgrade of the DUT for the experiment and replayed the message through the DUT. As a result, after the network card sent the message, the DUT's mac address responded, resulting in an interaction. The process did not pass through the DUT. This problem is quite funny. It took me a long time to find out the reason in the morning. At first, I thought that the UDP connection could not be replayed.
c. Use tcpreplay to replay the message.
[root@A ~]# tcpreplay -c tftp.cache -i eth0 -j eth1 tftp.pcap –v4. Replay the pcap packet and specify the rate and loop times
[root@A ~]# tcpreplay -i eth1 -M 10 -l 0 /home/demo/LSDK/LSDK.pcapReplay at a rate of 10Mbps, with 0 indicating an infinite loop.
