End Pointless Testing; Realistic and Blended App Traffic Is A True Test

I’m Mike Hamilton, BreakingPoint’s Director of Product Management. My first blog post centers around a familiar topic, the importance of testing with realistic application traffic. BreakingPoint supports more than 75 application protocols, and we constantly add additional protocols to help our customers build better, faster, and more reliable products. Understanding these protocols is important as you look to test more realistically. Today I am introducing a new series of resources, one page documents describing each of the 75+ application protocols we support natively, starting with Citrix. This series of “Application Protocol Briefs” will help you to understand why it is important to test with each of these protocols.

Frequently I am asked about UDP “packet blasting”, IMIX, RFC 2544 and other testing procedures. My answer is always the same; these testing “methodologies” are not realistic. Testing a firewall with 100% stateless UDP traffic is pointless when the actual traffic it will see consists of a wide variety of applications over both UDP and TCP.

Let me make an analogy based on my past experiences rock climbing. Climbing up a rock face I’m attached to a rope to prevent a long fall to my death. The rope has been tested with a 5 lb weight dropped from 10 feet. Pointless! This testing tells me nothing about how my rope is going to behave when all 200 lbs of me fall from 15 feet. Testing under realistic conditions is critical, not only for keeping me safe when I fall, but keeping your network equipment performing at a high and secure level.

Realistic traffic begins at the application layer. Each day at work I’m connecting to a network running HTTP, AIM, Jabber IM, Citrix ICA, Windows Live Messenger, database, FTP, SSH, Telnet, SMB/CIFS, NFS, BitTorrent (don’t tell RIAA!), DNS and more. Some of these run over UDP. Most of them don’t. And the traffic is much more than simply HTTP. I want network devices that have been tested with my particular mix of traffic. Unless you enjoy network downtime, lost productivity and general frustration, you should demand the same.

Once you determine the mix of traffic hitting your device, you also need to make sure it is realistic. The best definition of a realistic protocol I’ve heard came from my CTO Dennis Cox, “A realistic protocol is one that can actually talk to a real server”. This makes perfect sense. If my test harness can actually talk to a RADIUS server, I have a pretty good feeling that my RADIUS traffic is realistic. The interesting aspect of this definition is that it removes capture/replay/recreate from consideration in the realism category.

Another important aspect to realistic traffic is the configurability. If my test harness can talk to a real server but is only able to issue a GET / HTTP 1.1, it simply isn’t realistic. I should be able to request any URI, provide any additional headers, and emulate many different types of browsers (Safari, Chrome, FireFox, IE). This argument excludes the use of capture/replay/recreate for realism purposes as well. Nobody wants to capture traffic requesting hundreds of different URI’s from (at least) four different browsers. The problem grows exponentially. Your test tool should do this for you.

See exactly what I mean in our Citrix Application Protocol Brief and look for a new brief every few days.