tcpreplay文档

tcpreplay 文档

关于 tcpreplay 的详细文档和用户手册可以参考 http://tcpreplay.synfin.net/trac/wiki/manual 。

1.      Overview

Tcpreplay 是 UNIX 系统下用来编辑和重放网络流量包的工具集合，这些流量包可以是通过 tcpdump 或 ethereal 等工具抓取的。 tcpreplay 提供了可靠的、可重复的方法来测试不同的网络设备，包括：交换机、路由器、防火墙、入侵检测系统 (IDS) 和入侵防御系统 (IPS) 。

 

Tcpreplay is a suite of utilities for UNIX systems for editing and replaying network traffic which was previously captured by tools like tcpdump and ethereal /wireshark . The goal of tcpreplay is to provide the means for providing reliable and repeatible means for testing a variety of network devices such as switches, router, firewalls, network intrusion detection and prevention systems (IDS and IPS).

Tcpreplay provides the ability to classify traffic as client or server, edit packets at layers 2-4 and replay the traffic at arbitrary speeds onto a network for sniffing or through a device.

 

Tcpreplay 工具包由三个部分组成

1)       tcpprep  相当于一个与处理程序，根据设定的参数与处理抓获的 pcap 文件，并生成 cache 文件，以备 tcprewrite 和 tcpreplay 调用。

2)       tcprewrite                   改写抓获的数据包

3)       tcpreplay            重放数据包

 

 

2.      tcpprep

2.1 Overview ¶

tcpprep is the pcap pre-processor for tcpreplay and tcprewrite . The purpose of tcpprep is to create a cache file which is used to "split" traffic into two sides (often called primary/secondary or client/server). If you are intending to use tcpreplay with two NIC's, then tcpprep is what decides which interface each packet will use. By using a seperate process to generate cache files, tcpreplay can send packets at a much higher rate then if it had to do the calculations to split traffic itself.

2.2 Details ¶

Depending on the contents of the pcap and where you are replaying, you will want to split traffic differently. The most important thing to remember, is that you want to make sure that the device(s) under test (DUT) between the two NIC's see the traffic so that a client connecting to a server will go through the DUT one way, and the responses will go through the DUT the other way.

2.3 Basic Usage ¶

tcpprep supports multiple "modes" of operation. Each mode uses different logic to split traffic differently. For example, if you want to pass traffic through a router, then router mode is probably best, if you're testing a bridge or other Layer 2 device then bridge mode may work better. The following modes are currently available:

• Auto/Bridge
• Auto/Router
• Auto/Client
• Auto/Server                         自动模式
• IPv4/v6 matching CIDR
• IPv4/v6 matching Regex
• TCP/UDP Port
• MAC address

Note that IPv6 support was introduced in 3.4.2 and as of this writing, the Auto modes do not yet support IPv6. As with tcprewrite IPv6 addresses must be enclosed in hard brackets like this: [2001::dead:beef]

 

在自动模式下，程序根据数据包的特征自动区分client 端和server 端数据。

Auto/Bridge ¶

In Auto/Bridge mode, tcpprep parses the pcap file and keeps track each time a host either behaves like a client or like a server.

Currently client behavior is defined by:

• Sending a TCP Syn packet to another host
• Making a DNS request
• Recieving an ICMP port unreachable

Server behavior is defined by:

• Sending a TCP Syn/Ack packet to another host
• Sending a DNS Reply
• Sending an ICMP port unreachable 、

client 端行为特征

1）  向另一个主机发送 syn tcp 包

2）  发出一个 DNS 请求

3）  收到 ICMP 端口不可达消息

Server 端行为特征：

1)       发送 Syn/Ack 包

2)       发送 DNS 回应包

3)       发送 ICMP 不可达消息

After all the packets have been processed, the totals for client-like behavior vs. server-like behavior are totalled and the server to client ratio (--ratio ) is applied to classify each IP. If there is any IP address which is unclassifiable, then tcpprep will fail with an error. By default the client/server ratio is set to 2.0. The ratio is the modifier to the number of client connections. Hence, by default, client connections are valued twice as high as server connections.

$ tcpprep --auto=bridge --pcap=input.pcap --cachefile=input.cache

If you want to change the client/server ratio then use the --ratio option:

$ tcpprep --auto=bridge --pcap=input.pcap --cachefile=input.cache --ratio=3.5

Note: The --ratio option is valid for all automatic processing modes.

Auto/Router ¶

In Auto/Router mode hosts are first ranked as client or server using the same method as in Auto/Bridge mode. Then each host is placed in a small subnet which is expanded until either all the unknown hosts are included or the maximum newtork size is reached. This works best when clients and servers are on diffierent networks. The default starting network size is a /30 (2 valid IP addresses) and the maximum network is a /8 (Class A with over 16 million addresses). The following images hopefully better explain this process:

1. First each host is categorized as a client or server as best as possible, but sometimes one or more hosts are unclassifyable (denoted by a ? )
2. Each known host is placed in a subnet which is grown until all the unknown hosts are inside one of these subnets
3. Unknown hosts are classified in the same category (server or client ) based on which subnet they were in.

$ tcpprep --auto=router --pcap=input.pcap --cachefile=input.cache

tcpprep also allows you to override the starting and maximum nework size using the --minmask and --maxmask arguments.

$ tcpprep --minmask=24 --maxmask=16 --auto=router --pcap=input.pcap --cachefile=input.cache

Would start searching using a Class C network and max out with a Class B network.

Auto/Client ¶

Auto/Client mode works just like Auto/Bridge mode, but IP addresses which have not been classified as either client or server after the initial ranking are classified as clients.

$ tcpprep --auto=client --pcap=input.pcap --cachefile=input.cache

Auto/Server ¶

Auto/Client mode works just like Auto/Bridge mode, but IP addresses which have not been classified as either client or server after the initial ranking are classified as servers.

$ tcpprep --auto=server --pcap=input.pcap --cachefile=input.cache

CIDR ¶

CIDR mode unlike the Auto/* modes does not use any automatic ranking system to classify IP addresses. Instead, it requires the user to specify on or more networks in CIDR notation which contain servers.

$ tcpprep --cidr=10.0.0.0/8,172.16.0.0/12 --pcap=input.pcap --cachefile=input.cache

Regex ¶

Regex mode works like CIDR mode, except that instead of providing a list of CIDR's, the user provides a regex which matches the source IP of the servers. In this case any IP starting with 10. or 20.

$ tcpprep --regex="(10|20)/..*" --pcap=input.pcap --cachefile=input.cache

Port ¶

Port mode is used when you want to use the source and destination port of TCP/UDP packets to classify hosts as client or server. Normally, ports 0-1023 are considered server ports and everything else a client port. You can create your own custom mapping file in the same format as /etc/services (see the services(5) man page for details) by specifying --services <file> .

$ tcpprep --port --services=/etc/services --pcap=input.pcap --cachefile=input.cache

MAC ¶

MAC address mode is used when you want to split traffic based on the source MAC address of the ethernet header. Frames with a source address matching one of the listed MAC addresses will be treated as a server. Multiple MAC addresses can be provided in a comma delimited format.

$ tcpprep --mac=00:21:00:55:23:AF,00:45:90:E0:CF:A2 --pcap=input.pcap --cachefile=input.cache

2.4 Skip Packets ¶

Instead of marking a packet as client/server, it can also mark the packet to be skipped when processed by tcpreplay and tcprewrite. Skipped packets are not sent by tcpreplay and not edited by tcprewrite. By default, all packets are processed and none of them are skipped. Include and Exclude filters support IPv6 addresses as of v3.4.2.

Include ¶

Change the default to be skip and only process packets which match the --include flag.

Source IP Match ¶

Only process packets with a matching source IP in the networks: 10.0.0.0/8 and 192.168.0.0/16:

$ tcpprep --include=S:10.0.0.0/8,192.168.0.0/16 --pcap=input.pcap --cachefile=input.cache <other args>

Destination IP Match ¶

Only process packets with a matching destination IP in the networks: 10.0.0.0/8 and 192.168.0.0/16:

$ tcpprep --include=D:10.0.0.0/8,192.168.0.0/16 --pcap=input.pcap --cachefile=input.cache <other args>

Both IP Match ¶

Only process packets which both source and destination IP matches the networks: 10.0.0.0/8 and 192.168.0.0/16:

$ tcpprep --include=B:10.0.0.0/8,192.168.0.0/16 --pcap=input.pcap --cachefile=input.cache <other args>

Either IP Match ¶

Only process packets which either the source or destination IP matches the networks: 10.0.0.0/8 and 192.168.0.0/16:

$ tcpprep --include=E:10.0.0.0/8,192.168.0.0/16 --pcap=input.pcap --cachefile=input.cache <other args>

Packet Number Match ¶

Only process packets numbered 1 thru 5, 9, 15 and 72 until the end of the file:

$ tcpprep --include=P:1-5,9,15,72- --pcap=input.pcap --cachefile=input.cache <other args>

BPF Filter Match ¶

Only process packets which match the BPF filter: tcp port 22

$ tcpprep --include=F:"tcp port 22" --pcap=input.pcap --cachefile=input.cache <other args>

Exclude ¶

Skip any packets which match the filter specified by the --exclude flag.

Source IP Negative Match ¶

Only process packets which don't match the source IP in the networks: 10.0.0.0/8 and 192.168.0.0/16:

$ tcpprep --exclude=S:10.0.0.0/8,192.168.0.0/16 --pcap=input.pcap --cachefile=input.cache <other args>

Destination IP Negative Match ¶

Only process packets which don't match the destination IP in the networks: 10.0.0.0/8 and 192.168.0.0/16:

$ tcpprep --exclude=D:10.0.0.0/8,192.168.0.0/16 --pcap=input.pcap --cachefile=input.cache <other args>

Both IP Negative Match ¶

Only process packets which neither source and destination IP matches the networks: 10.0.0.0/8 and 192.168.0.0/16:

$ tcpprep --exclude=B:10.0.0.0/8,192.168.0.0/16 --pcap=input.pcap --cachefile=input.cache <other args>

Either IP Negative Match ¶

Only process packets which neither the source or destination IP matches the networks: 10.0.0.0/8 and 192.168.0.0/16:

$ tcpprep --exclude=E:10.0.0.0/8,192.168.0.0/16 --pcap=input.pcap --cachefile=input.cache <other args>

Packet Number Negative Match ¶

Do not process packets numbered 1 thru 5, 9, 15 and 72 until the end of the file:

$ tcpprep --exclude=P:1-5,9,15,72- --pcap=input.pcap --cachefile=input.cache <other args>

2.5 Other Options ¶

Comments ¶

tcpprep allows you to embed comments in your cache file which you can then read at a later time. tcpprep also saves what the commands line arguments were when the cache file was generated. To save a comment, use the --comment flag. To read the comment, use the --print-comment flag:

$ tcpprep <args> --pcap=input.pcap --cachefile=input.cache --comment="This is our evil packet pcap"

$ tcpprep --print-comment=input.cache

Detailed Info ¶

tcpprep also allows you to view statistical information as well as detailed per-packet data.

To view the overall statistical info, use the --print-stats flag:

$ tcpprep --print-stats=input.cache

To view per-packet data, use the --print-info flag:

$ tcpprep --print-info=input.cache

Non-IP Traffic ¶

Many of tcpprep's modes rely on IP address information in the IPv4 header to determine wether the packet was sent by a "client" or "server". Of course, not all network packets are IPv4 and hence tcpprep in those cases has no way to determine which direction the packet is going. Hence, by default, tcpprep will send all non-IPv4 traffic out the client/secondary interface. You can change this to be the server/primary interface by using the --nonip flag. If of course you need to split non-IP traffic, then you should use the MAC address mode (--mac ).

 

3.      tcprewrite

Overview ¶

In version 3.0, all of the packet editing functionality in tcpreplay was moved to tcprewrite. In 3.4.1 this editing functionality was re-introduced in tcpreplay with the creation of tcpreplay-edit. Hence, all the options listed below are valid for both tcprewrite and tcpreplay-edit .

Basic Usage ¶

Running tcprewrite requires you to provide it an input pcap file and the name of the output pcap file (which will be overwritten).

$ tcprewrite --infile=input.pcap --outfile=output.pcap

Additional arguments for actually editing packets are described below.

Direction & Selection ¶

Before we get to packet editing, it is important to remember that some of these rewrite options allow you to edit packets differently depending on the direction of the packet. Packet direction is determined by consulting a tcpprep cache file, which allows you to define direction based on a variety critera.

Using tcpprep cache files, you can also mark packets as to be skipped during processing by tcprewrite. Use of this feature allows you to select which packets are edited and which packets are not. Since cache files are seperate from the actual pcap, you can use multiple cache files with different processing rules for multiple passes of tcprewrite.

To specify a tcpprep cache file to use during processing, use the --cachefile option.

Rewriting Layer 2 ¶

tcprewrite supports a lot of Layer 2 rewriting options to help you modify packets so that traffic can flow through switches, firewalls, routers, IPS's and many other forwarding devices.

DLT Plugins ¶

As of 3.0, tcprewrite uses plugins to support different DLT/Layer 2 types. This not only makes the code easier to maintain, but also helps make things clearer for users regarding what is and isn't supported. Each plugin may support reading and/or writing packets. By default, the plugin used to read packets is also used for output, but you can override the output plugin using the --dlt option. Changing the DLT plugin allows you to convert the packets from one DLT/Layer 2 type to another type. This allows you for example to capture traffic on say an Ethernet interface and replay over Cisco HDLC or capture on a BSD Loopback interface and replay over Ethernet.

Plugins supported in output mode:

• Ethernet (enet)
• Cisco HDLC (hdlc)
• User defined Layer 2 (user)

Plugins supported in input mode:

• Ethernet
• Cisco HDLC
• Linux SLL
• BSD Loopback
• BSD Null
• Raw IP
• 802.11
• Juniper Ethernet (version >= 4.0)

Hence, if you have a pcap in one of the supported input DLT types, you can convert it to one of the supported output DLT type by using the --dlt=<output> option. Depending on the input DLT you may need to provide additional DLT plugin flags.

DLT_EN10MB (Ethernet) ¶

The Ethernet plugin allows you to control the source and destination MAC addresses. Additionaly, you can add, remove and edit 802.1q VLAN tag headers.

Rewriting Source & Destination MAC addresses ¶

The most common layer 2 rewriting need is to change the source and destination MAC addresses of packets so that they will be processed by the correct device. By using the --enet-dmac and --enet-smac options you can specify what the new destination and source MAC addresses should be respectively.

The following would cause all traffic to have a destination MAC of 00:55:22:AF:C6:37 and a source MAC of 00:44:66:FC:29:AF:

$ tcprewrite --enet-dmac=00:55:22:AF:C6:37 --enet-smac=00:44:66:FC:29:AF --infile=input.pcap --outfile=output.pcap

Now, that's probably not very useful unless all your traffic is unidirectional. So what if you have bi-directional traffic that you want to send through a router who's MAC addresses are 00:55:22:AF:C6:37 and 00:44:66:FC:29:AF? We'll assume the client is 00:22:55:AC:DE:AC and the server is 00:66:AA:D1:32:C2. Well first you would need a tcpprep cache file which splits the traffic. Once you have that, you would run tcprewrite like this:

$ tcprewrite --enet-dmac=00:44:66:FC:29:AF,00:55:22:AF:C6:37 --enet-smac=00:66:AA:D1:32:C2,00:22:55:AC:DE:AC --cachefile=input.cache --infile=input.pcap --outfile=output.pcap

The important thing above is to remember that the first MAC addresses listed for the dmac/smac flag is for server traffic and the second addresses are for client traffic.

One very useful flag to keep in mind is --skipbroadcast which causes tcprewrite to skip rewriting MAC addresses which are broadcast (FF:FF:FF:FF:FF:FF) or multicast (first octet is odd). Rewriting broadcast/multicast MAC address break things like ARP and DHCP.

802.1q VLAN's ¶

tcprewrite also allows you to add or remove 802.1q VLAN tag information from ethernet frames. Removing the 802.1q tag information is as simple as specifying --vlan=del :

$ tcprewrite --enet-vlan=del --infile=input.pcap --outfile=output.pcap

You can also take non-tagged frames and make them tagged by using --enet-vlan=add and one or more of the following --enet-vlan-tag , --enet-vlan-cfi , --enet-vlan-pri

$ tcprewrite --enet-vlan=add --enet-vlan-tag=40 --enet-vlan-cfi=1 --enet-vlan-pri=4 --infile=input.pcap --outfile=output.pcap

will set the VLAN tag to be 40, the CFI value to 1 and a VLAN priority of 4.

DLT_CHDLC (Cisco HDLC) ¶

Cisco HDLC has two fields in the Layer 2 header: address and control. Both can be set using this plugin:

• --hdlc-address
• --hdlc-control

DLT_USER0 (User Defined) ¶

The user defined DLT option allows you to create any DLT/Layer2 header of your choosing by using the following two options:

• --user-dlt - Set pcap DLT type
• --user-dlink - Set packet layer 2 header

 

4.      tcpreplay

Overview ¶

tcpreplay has evolved quite a bit over the years. In the 1.x days, it merely read packets and sent then back on the wire. In 2.x, tcpreplay was enhanced significantly to add various rewriting functionality but at the cost of complexity, performance and bloat. Now in 3.x, tcpreplay has returned to its roots to be a lean packet sending machine and the editing functions have moved to tcprewrite and a powerful tcpreplay-edit which combines the two.

Basic Usage ¶

To replay a given pcap as it was captured all you need to do is specify the pcap file and the interface to send the traffic out interface 'eth0':

从eth0 发送数据包文件sample.pcap

# tcpreplay --intf1=eth0 sample.pcap

Replaying at different speeds ¶ 控制发送速度

You can also replay the traffic at different speeds then it was originally captured. Some examples:

To replay traffic as quickly as possible:

# tcpreplay --topspeed --intf1=eth0 sample.pcap

To replay traffic at a rate of 10Mbps:

# tcpreplay --mbps=10.0 --intf1=eth0 sample.pcap

To replay traffic 7.3 times as fast as it was captured:

# tcpreplay --multiplier=7.3 --intf1=eth0 sample.pcap

To replay traffic at half-speed:

# tcpreplay --multiplier=0.5 --intf1=eth0 sample.pcap

To replay at 25 packets per second:

# tcpreplay --pps=25 --intf1=eth0 sample.pcap

To replay packets, one at a time while decoding it (useful for debugging purposes):

# tcpreplay --oneatatime --verbose --intf1=eth0 sample.pcap

Replaying files multiple times ¶ 多次重复发送

Using the loop flag you can specify that a pcap file will be sent two or more times:

To replay the sample.pcap file 10 times:

# tcpreplay --loop=10 --intf1=eth0 sample.pcap

To replay the sample.pcap an infinitely or until CTRL-C is pressed:

# tcpreplay --loop=0 --intf1=eth0 sample.pcap

If the pcap files you are looping are small enough to fit in available RAM, consider using the --enable-file-cache option. This option caches each packet in RAM so that subsequent reads don't have to hit the slower disk. It does have a slight performance hit for the first iteration of the loop since it has to call malloc() for each packet, but after that it seems to improve performance by around 5-10%. Of course if you don't have enough free RAM, then this will cause your system to swap which will dramatically decrease performance.

Another useful option is --quiet . This suppresses printing out to the screen each time tcpreplay starts a new iteration. This can have a dramatic performance boost for systems with slower consoles.

Advanced Usage ¶

Splitting Traffic Between Two Interfaces ¶     

By utilizing tcpprep cache files, tcpreplay can split traffic between two interfaces. This allows tcpreplay to send traffic through a device and emulate both client and server sides of the connection, thereby maintaining state. Using a tcpprep cache file to split traffic between two interfaces (eth0 & eth1) with tcpreplay is simple:

# tcpreplay --cachefile=sample.prep --intf1=eth0 --intf2=eth1 sample.pcap

Viewing Packets as They are Sent ¶

The --verbose flag turns on basic tcpdump decoding of packets. If you would like to alter the way tcpreplay invokes tcpdump to decode packets, then you can use the --decode flag. Note: Use of the --verbose flag is not recommended when performance is important. Please see the tcpdump(1) man page for options to pass to the --decode flag.

Choosing a Timing Method ¶

tcpreplay as of v3.3.0 now supports multiple methods for creating delays between two packets.

First a refresher:

• There are 1,000 milliseconds (msec) in 1 second
• There are 1,000,000 microseconds (usec) in 1 second
• There are 1,000,000,000 nanoseconds (nsec) in 1 second

And a little math:

Let's say you want to send 125,000 packets/sec (pps). That means you need to send a packet on average every 8usec. That's doable on most hardware assuming you can find a timing method with 1usec accuracy. The problem gets a lot more difficult when you want to send at 130,000 pps- now you need 7.7usec delay, requiring .1usec accuracy! That's a 10x increase in accuracy for a small change in performance. Most timing methods on general purpose hardware/software can't do that.

So what are the expected accuracies of each timing method?

• nanosleep() - Theoretically 1nsec accuracy, but is probably closer to 1usec. Can be off by up to +/- 10msec depending on the operating system.
• gettimeofday() - 1usec accuracy at best
• OS X's AbsoluteTime() - 1nsec accuracy
• select() - Theoretically 1usec accuracy, but tends to be off by +/- 10msec
• IO Port 80 - 1usec accuracy, but can cause crashes with certain versions of hardware/OS's
• Intel/AMD/SPARC RDTSC - Theoretically better then 1usec accurate, but many recent multi-core Intel CPU's are horribly inaccurate and unusable
• Intel HPET - A 10Mhz timer giving .1usec accuracy

As you see above, only AbsoluteTime and the HPET provide the necessary resolution to hit our 130,000pps mark. Hence, if you're using one of the other methods, I'll use weighted averages or rounding to provide better accuracy. What that means is, when each packet is being sent at a constant rate (packets/sec) I'll sleep 8usec 7 times, and then 7usec 3 times to average out to the necessary 7.7usec. If you're using a variable timing method (Mbps or multiplier) then I'll round to the nearest 1usec (8usec in this case of 7.7usec)- the hope is that over many packets, it will average out correctly.

AbsoluteTime ¶

So what does this all mean? Well, if you're running OS X, then using --timer=abstime is the clear winner. After that it gets more complicated. AbsoluteTime is currently the only timing method which doesn't need weighted averages or rounding.

HPET/gettimeofday ¶

First, tcpreplay currently doesn't have native support for the Intel HPET. The good news is that some operating systems (like recent Linux kernels) use the HPET for calls to gettimeofday(). So while you loose some accuracy (gettimeofday() is accurate to 1usec no matter what the underlying implementation looks like), it's probably the best option for non-OS X users. If your gettimeofday() isn't backed by the HPET, you can still use it, just realize it might be a bit unreliable. Even if your gettimeofday() uses the HPET, you still only get 1usec accuracy, so part about using weighted averages and rounding still applies. Specify --timer=gtod to use gettimeofday()

nanosleep ¶

Some implimentations of nanosleep() are good, others are horrible- it even may depend on how long you're sleeping for since the implementation might switch between going to sleep (bad) or using a tight loop (good). Generally speaking it's worth trying: --timer=nano

RDTSC ¶

Using the RDTSC via --timer=rdtsc . This tends to work great on some hardware and is completely worthless for others. I've got an Intel P4 3.2Ghz box which it works great on, but my Core2Duo MacBook Pro is really bad. If you don't specify a --rdtsc-clicks value, tcpreplay will introduce a short delay on startup in order to calculate this value. If your hardware has a properly working RDTSC it's usually the speed of the processor (expressed in Mhz, so a 3.2Ghz CPU == --rdtsc-clicks=3200 ) or a fraction thereof.

IO Port 80 ¶

I don't have much experience with this, so give it a try and let me know what you find: --timer=ioport

select ¶

This is crap for 99% of the situations out there. Hence you probably don't want to specify --timer=select

Accelerating Time ¶

Regardless of which timing method you use, you can try specifying --sleep-accel to reduce the amount of time to sleep in usec. I've found this is useful for providing a "fudge factor" in some cases.

Tuning for High-Performance ¶

Choosing a Packet Interval Method ¶

The first recommendation is simple, use: --topspeed . This will always be the fastest method to send packets. If however you need some level of control, using --pps to specify packets/second is recommended. Using --pps-multi will cause multiple packets to be sent between each sleep interval, thus providing higher throughput potential then just --pps alone, but at the cost of traffic being more "spikey" then flat. Higher --pps-multi values improve performance and make the traffic more "spikey".

Using --mbps or --multiplier for high performance situations is not recommended as the overhead for calculating packet intervals tends to limit real world throughput.

Tuning your Operating System/Hardware ¶

Regardless of the size of physical memory, UNIX kernels will only allocate a static amount for network buffers. This includes packets sent via the "raw" interface, like with tcpreplay. Most kernels will allow you to tweak the size of these buffers, drastically increasing performance and accuracy.

NOTE: The following information is provided based upon my own experiences or the reported experiences of others. Depending on your hardware and specific hardware, it may or may not work for you. It may even make your system horribly unstable, corrupt your harddrive, or worse.

NOTE: Different operating systems, network card drivers, and even hardware can have an effect on the accuracy of packet timestamps that tcpdump or other capture utilities generate. And as you know: garbage in, garbage out.

NOTE: If you have information on tuning the kernel of an operating system not listed here, please send it to me so I can include it.

General Tips ¶

1. Use a good network card. This is probably the most important buying decision you can make. I recommend Intel e1000 series cards. El-cheapo cards like Realtek are known to give really crappy performance.
2. Tune your OS. See below for recommendations.
3. Faster is better. If you want really high-performance, make sure your disk I/O, CPU and the like is up to the task.
4. For more details, check out the FAQ
5. If you're looping file(s), make sure you have enough free RAM for the pcap file(s) and use --enable-file-cache
6. Use --quiet
7. Use --topspeed or --pps and a high value for --pps-multi
8. Use tcprewrite to pre-process all the packet editing instead of using tcpreplay-edit

Linux ¶

The following is known to apply to the 2.4.x and 2.6.x series of kernels. By default Linux's tcpreplay performance isn't all that stellar. However, with a simple tweak, relatively decent performance can be had on the right hardware. By default, Linux specifies a 64K buffer for sending packets. Increasing this buffer to about half a megabyte does a good job:

echo 524287 >/proc/sys/net/core/wmem_default 

echo 524287 >/proc/sys/net/core/wmem_max 

echo 524287 >/proc/sys/net/core/rmem_max 

echo 524287 >/proc/sys/net/core/rmem_default

On one system, we've seen a jump from 23.02 megabits/sec (5560 packets/sec) to 220.30 megabits/sec (53212 packets/sec) which is nearly a 10x increase in performance. Depending on your system and capture file, different numbers may provide different results.

*BSD ¶

*BSD systems typically allow you to specify the size of network buffers with the NMBCLUSTERS option in the kernel config file. Experiment with different sizes to see which yields the best performance. See the options(4) man page for more details.

 

5.      Usage Examples

a)      Passing Traffic Through an IPS/Transparent Device ¶

Problem ¶

You have a pcap file of HTTP client/server traffic captured from a different network that you want to replay through a IPS or other transparent inline device.

Solution ¶

There is a three step process for this:

1. Determine which packets are client->server and server->client
2. Rewrite IP addresses based on their direction
3. Send packets through inline device

1.       区分数据包的流向 client->server 还是 server->client

2.       根据流向重写 IP 地址

3.       发送数据包

Step 1 ¶

Use tcpprep to split traffic based on the source/destination port:

$ tcpprep --port --cachefile=example.cache --pcap=example.pcap

In this case, all the packets directed to a TCP or UDP port < 1024 are considered client->server, while other packets are server->client. This information is stored in a tcpprep cache file called example.cache for later use.

tcpprep 预处理数据包

—port 参数，根据端口号区分数据包的流向。

--cachefile 指定输出的 cache 文件的名字

--pcap    指定要处理的数据包文件

Note: tcpprep supports many other methods of splitting traffic then just port mode.

Step 2 ¶

Use tcprewrite to change the IP addresses to the local network:

$ tcprewrite --endpoints=172.16.0.1:172.16.5.35 --cachefile=example.cache --infile=example.pcap --outfile=new.pcap

Here, we want all traffic to appear to be between two hosts: 172.16.0.1 and 172.16.5.35. We want one IP to be the "client" and the other IP the "server", so we use the cache file created in the last step.

tcprewrite 改写数据包

         --endpoints 指定数据包的 client 、 server 端的 ip 地址

         --cachefiel         上一步预处理的输出文件

         --infile                输入 pcapfile

         --outfile             改写后的 pcap 文件

Step 3 ¶

Use tcpreplay to send the traffic through the IPS:

# tcpreplay --intf1=eth0 --intf2=eth1 --cachefile=example.cache new.pcap

Here we send the traffic. Since we want to split traffic between two interfaces (eth0 and eth1), we use the cache file created in Step #1 with the new.pcap created in Step #2. We can use the cache file for different pcap files because while the IP addresses of the packets have changed, their order and semantics have not.

最后，使用 tcpreplay 重放数据包

--intf1      

--intf2      

 

b)     Passing Traffic Through a Firewall/Router/Non-Transparent Device ¶

Problem ¶

You have a pcap file of HTTP client/server traffic captured from a different network that you want to replay through a device which routes or NAT's traffic.

Solution ¶

There is a five step process for this:

1. Determine which packets are client->server and server->client
2. Determine what the new IP and MAC addresses should be
3. Rewrite IP addresses
4. Rewrite MAC addresses based on their direction
5. Send packets through inline device

Step 1 ¶

Use tcpprep to split traffic based on the source/destination port:

$ tcpprep --port --cachefile=example.cache --pcap=example.pcap

In this case, all the packets directed to a TCP or UDP port < 1024 are considered client->server, while other packets are server->client. This information is stored in a tcpprep cache file called example.cache for later use.

Note: tcpprep supports many other methods of splitting traffic then just port mode.

Step 2 ¶

Determine the new IP and MAC address values.

This varies depending on the device and it's configuration. But the basic goal is to make sure the destination MAC addresses of the packets match the MAC addresses of the interfaces of the DUT and the IP addresses match the expected values. This means that for a router, you can use the --endpoints option, but for NAT devices we'll need to deal with the DUT changing the IP's. Using the following example:

Here, we'll assume eth2/Untrust's MAC address is 00:22:22:22:22:22 and eth1/DMZ is 00:11:11:11:11:11. Let's further assume that the firewall is NAT'ing traffic destined to 2.2.2.1 on the Untrust interface to 1.1.1.5 on the DMZ interface. It's important that the destination is not of the tcpreplay box itself or the IP stack of the system will interfear with the traffic.

Step 3 ¶

Use tcprewrite to change the IP addresses to match up what the firewall will expect.

Since the firewall in this example is NAT'ing the traffic, we need to be a bit sneaky. The problem is that the client side destination IP is different then the server side source IP. Hence we'll use the --srcipmap and --dstipmap options. In this case we'll assume the old traffic is Client:10.10.0.1 and Server:10.20.0.1.

First, rewrite the source IP's to be the new client and server:

$ tcprewrite --srcipmap=10.10.0.1/32:2.2.2.5/32,10.20.0.1/32:1.1.1.5/32 --infile=example.pcap --outfile=new.pcap

Second, rewrite the destination IP's to be the new cilent and NAT'd server addresses:

$ tcprewrite --dstipmap=10.10.0.1/32:2.2.2.5/32,10.20.0.1/32:2.2.2.1/32 --infile=new.pcap --outfile=new2.pcap

You could combine the two above commands together, but I've seperated them out for clarity.

Step 4 ¶

Use tcprewrite to change the MAC addresses to match up with the firewall.

$ tcprewrite --enet-dmac=00:11:11:11:11:11,00:22:22:22:22:22 --cachefile=example.cache --infile=new2.pacp --outfile=new3.pcap

Step 5 ¶

Use tcpreplay to send the traffic through the IPS:

# tcpreplay --intf1=eth0 --intf2=eth1 --cachefile=example.cache new3.pcap

Here we send the traffic. Since we want to split traffic between two interfaces (eth0 and eth1), we use the cache file created in Step #1 with the new3.pcap created in Steps #2-4. We can use the cache file for different pcap files because while the IP addresses of the packets have changed, their order and semantics have not.

c)      Rewriting TCP/UDP Ports ¶

Problem ¶

You have some HTTP traffic on port 80 that you would like to rewrite over port 8080.

Solution ¶

Use tcprewrite to remap the ports:

$ tcprewrite --infile=example.pcap --outfile=new.pcap --portmap=80:8080

The portmap option takes a comma delimited list of port pairs <oldport>:<newport>. Note that this option is protocol independant, so both TCP and UDP packets will be effected.

d)     Remove specific packets from a capture file ¶

Problem ¶

You have a pcap file containing some packets you do not want to send or edit.

Solution ¶

Use tcpdump!

Step 1 ¶

Let's assume that you have a pcap which has a bunch of traffic, but you only want to replay the tcp/80 (http) traffic. To do this, you would run:

$ tcpdump -r example.pcap -w http_only.pcap -s0 tcp port 80

Just adjust your BPF filter according to your needs.

e)     Sending Traffic to a Server ¶

Problem ¶

You have a pcap capture and would like to replay that traffic at another server.

Solution ¶

First, this will only work with ICMP and UDP traffic. Tcpreplay doesn't support sending TCP traffic at a server because it doesn't synchronize Syn/Ack numbers in the TCP stream.

That said, you'll need to change the destination IP and MAC addresses to match that of the target server. In this case, we'll assume the target server IP is 10.10.1.1 and it's MAC address is 00:01:02:03:04:05.

Step 1 ¶

Rewrite destination IP & MAC addresses

$ tcprewrite --infile=example.pcap --outfile=new.pcap --dstipmap=0.0.0.0/0:10.10.1.1/32 --enet-dmac=00:01:02:03:04:05