6

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 239.255.0.1:30001, and the bar.pcap packets should be replayed on 239.255.0.2:30002.

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 239.255.0.1:30001, and then the first two packets from bar.pcap should go out on 239.255.0.2:30002, 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)

John Dibling
  • 163
  • 1
  • 6
  • 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 03 '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 03 '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 04 '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 05 '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 05 '14 at 19:19
  • @karyhead: That's an interesting idea. No, I don't want to replay the pcaps back to the same mcast group from which they were captured. I'll try out the method you recommend. If it works, and is performant enough for our needs, I think that will be our solution. – John Dibling Jul 05 '14 at 20:02

2 Answers2

5

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.

Ryan Foley
  • 5,479
  • 4
  • 23
  • 43
jwbensley
  • 5,290
  • 7
  • 37
  • 79
  • 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 06:49
  • Actually, I haven't used tcprewrite in a long time and looking at it now, I don't recognize the options so I wouldn't be confident that my answer would be accurate for rewriting mcast. – karyhead Jul 11 '14 at 07:03
4

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.

Jed Daniels
  • 156
  • 3