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 Jul 3 '14 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. – John Dibling Jul 3 '14 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 Jul 4 '14 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. – John Dibling Jul 5 '14 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 Jul 5 '14 at 19:19

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.

| improve this answer | |

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.

| improve this 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. – John Dibling Jul 10 '14 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. – John Dibling Jul 10 '14 at 18:25
  • Good to clarify :) – jwbensley Jul 10 '14 at 18:55
  • 1
    To clarify my clarify, I decided upon this solution only after reading @karyhead's comment in my OP. – John Dibling Jul 10 '14 at 19:03
  • Ah yeah, I kinda forgot to write this up as an answer, Reckon I could. – karyhead Jul 11 '14 at 6:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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