Hi, this is Mike Danseglio and today I am going to talk to you a little about network traffic and simulation with network traffic. We all know there is value in testing with real network traffic and there is value in testing with simulated network traffic. But there are very different approaches and very different tool sets and methodologies around doing the different types of network testing depending on how you want to do it, and how realistic you want that test to be. For example, one of the major categories of network testing is to actually record a bunch of traffic on segments, analyze these to see if they are relatively typical, and then play them back.
As you can see I have one the most common network traffic recording applications up here. Its Wireshark. Wireshark actually is commonly used. (Network Monitor I have shown in previous demonstrations is the other most commonly used application, so I thought I would balance it out.) I’ve got a brief capture here of a promiscuous network client on a network and its sniffing around: A lot of broadcasts, some SSO negotiations, you can see the different clients going on and so forth. I might decide that this is a relatively good sample of what’s happening on my network but now what do I do with it? I can analyze it, I can find out what kind of traffic is going on, but how do I play it back to a test network? How do I isolate it and play it back out to see what happens to the infrastructure, and maybe to amplify it by playing it 5, 10, 15 simultaneous threads?
That is a difficult problem to solve and the reason its difficult is because the playback tools are not built in to pretty much any of the common commercial applications for network sniffing. You can record traffic, you can analyze traffic, you can output traffic to different kinds of things like excel spread sheets or reports but you can’t just stick it back on the wire. You tend to have to hunt around and find attacker tools or hacker tools, shady companies, individual people that actually put out these tools themselves. Often run at the command line, you don’t know what they are doing, a little bit less confidences building to be honest, then a lot of the other tools that are out there. So, while recording and analyzing is still an extremely valuable way to test the network, playing back that traffic is not always the best thing to do.
In the past we have also seen a traditional approach of acquiring a hardware-based traffic generator and sticking that on the network and telling it to generate certain types of traffic. Here’s the interesting thing about that, I got some pictures to show you. Here are three very typical types of network traffic generating devices, with the names removed so you don’t go out and hunt down who they are, but they are fairly easy to find. These are pretty much used for a single purpose, they monitor the network and generate traffic. They are limited in that they are extremely hard to use in most cases there is a steep learning curve and they are terribly expensive. These devices often go into the 6-figures and between the difficulty in using the device, the difficulty in learning how to use the device, and the single taskness of the device it can only really be used for one thing in your environment. I see very few people actually investing in this unless they are doing very broad worldwide network implementations. So these, however interesting, are not as interesting as some of the other tools out there.
More interesting are things around software traffic generations, software can actually come up and broadcast the traffic that you want based on the configuration I want. I want 50% VoIP, 25% file transfer traffic, 10% image transfer traffic, 5% email traffic and so forth. Being able to run a number of those commodity instances of the software traffic generation is probably the most useful approach that exists today.
Blueprinting a network or finding out what is going on the network and then actually generating a type of traffic pattern similar to that just exponentially larger until something breaks is the recommended approach and I am going to take you through that in a future webcast when I show you bit-by-bit how to implement that. So, this webcast is a little more about the things you should be careful about investing in before you actually understand how to do the next bit, which is to use the software simulation.