We capture many pcap files every day on many different multicast groups. For the purposes of testing & benchmarking, we wish to replay these files in an isolated environment and in a controlled way. These pcap files are captured simultaneously, but on different multicast groups & ports.

I want to replay these files back on to the network (possibly with ttl=0 or 1) in the order in which the packets were recorded, and on different (and specifyable) multicast groups. This ordering must be synchronized accross all of the files being played back.

For example, suppose we have two capture files, foo.pcap and bar.pcap. We want to replay foo.pcap packets on mcast group, and the bar.pcap packets should be replayed on

foo.pcap has packets recorded at time offsets 0, 1, and 5. bar.pcap has packets recorded at time offsets (relative to foo.pcap) 3, 4, and 5.

So what I'm looking for is a way to replay these packets in an order synchronized accross both foo.pcap and bar.pcap. In other words, the first 2 packets from foo.pcap should go out on to, and then the first two packets from bar.pcap should go out on, and then the past packet from foo.pcap should go out at the same time (or close to it) as the last packet from bar.pcap.

We also need to be able to tune the rate at which packets are replayed. eg, at recorded speed; 10x recorded speed; 1 GB/sec; etc.

How can I accomplish this?

I have looked in to tools such as tcpreplay and bittwist, but these tools either won't send on different groups, or won't synchronize the egress order across all the files.

I will be working in Linux only (RHEL 6.5 primarily & also Ubuntu 12.04)

  • 1
    Investing in testing tools like Spirent or Ixia would be a better idea if this is a long term plan. These devices can achieve this very easily.
    – BHV
    Commented Jul 3, 2014 at 16:12
  • @BHV: Thanks for the pointers. I'll look a little more closely at those products. Unfortunately, I have neither the time nor the (presumed) money to pursue those solutions now. Commented Jul 3, 2014 at 16:17
  • 1
    If the devices that are doing the capturing have their clocks in sync via NTP or some other method, then I don't see why you couldn't merge the pcaps into a single file. By default mergecap will merge the frames in chronological order. Then you could use tcpreplay to send 'em out at whatever speed you desire. Does that sound like it would work for you?
    – karyhead
    Commented Jul 4, 2014 at 22:31
  • @karyhead: I need to be able to broadcast each cap file in to a different mcast group, so it doesn't sound like it. Commented Jul 5, 2014 at 14:01
  • 1
    So you don't want to reply the original mcast group? Perhaps you could tcprewrite each pcap to the mcast group you want, then merge them together.
    – karyhead
    Commented Jul 5, 2014 at 19:19

2 Answers 2


I've done this sort of thing before using tcpreplay and mergecap (one of the tools that is distributed with Wireshark). The first step is to use tcprewrite (part of tcpreplay) to edit the destination IPs of foo.pcap to be first address you are looking to send as, and bar.pcap to be the second. Then use mergecap to merge the packets chronologically so you get them interleaved the way that you want. Note that when using mergecap, you might need to first edit the timestamps of the packets (e.g. if you took foo.pcap a day before bar.pcap, they won't interleave). In that case, you can use editcap (another tool from wireshark) to modify the packet times.

The really difficult part is going to be playing them back with the timing options that you want. Depending on the speed of the original captures, and your tolerance for variance, you might be all set simply using tcpreplay --multiplier=XXX. But if the traffic rate is fast, or you need it to be really precise, then you are going to be out of luck until you invest in special hardware from vendors like Spirent or Ixia. Note that if you do buy one of those tools, they have utilities that can do all the packet manipulation for you as part of the setup process.


My thoughts on this are that firstly if you capture the traffic in one place (if you are able to, if you have one capture machine/device joint to both mcast groups) you don't have the complexity of having to replay two different captures files in time with each other.

Secondly you can edit packet captures so that when you "play" them back the packets are sent to a re-written destination addresses (different mcast groups).

Can you perhaps look at how you are capturing and replaying the packets to see if this scenario can be simplified? Even if you have to separate capture files you can just play them back from the same machine/device; one which has two connections back to the mcast network so it can play into two different mcast groups.

I think you need to refine your problem further with some additional research on the problem and existing solutions. Otherwise the info above is my answer.

  • So as it happens, the solution we are pursuing is to rcprewrite files to different mcast groups, mergecap them together (we need to combing them in different ways depending on what we're doing), and then tcpreplay this one big capture file on to the network. I should have updated my post with this as an answer. Commented Jul 10, 2014 at 18:24
  • We do have to capture the groups seperately, because we won't always want to replay the same groups every time. Sometimes we'll combine group A with group B, sometimes A+C, etc. Commented Jul 10, 2014 at 18:25
  • Good to clarify :)
    – Baldrick
    Commented Jul 10, 2014 at 18:55
  • 1
    To clarify my clarify, I decided upon this solution only after reading @karyhead's comment in my OP. Commented Jul 10, 2014 at 19:03
  • Ah yeah, I kinda forgot to write this up as an answer, Reckon I could.
    – karyhead
    Commented Jul 11, 2014 at 6:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.