Stuff Spirent didn't cover at NFD6

Spirent presented their Avalanche NEXT product at Gestalt IT's Network Field Day 6 event in September of this year.

Disclaimers:

1. I attended the event, somebody else picked up the tab, yada yada.
2. I like Spirent. I've used their products, worked with their people and been to their offices several times, and have gradually become a fan. This fact might be coloring my opinions :)

What's Avalanche NEXT?

Avalanche NEXT is a software frontend for performing tests of security hardware (firewalls and whatnot). It's a modular system that allows simple creation of test components (clients, servers, subnets, protocols, etc...), mixing of modules to create various tests, scaling of the test, application fuzzing, etc... Check out 1:14 - 1:30 in the video below to get a flavor of how slick the interface is. I love that interactive pie chart.

This sort of testing is critical because security devices have some of the most misleading data sheets of anything we're likely to work with as network folks. Security box performance numbers depend heavily on what you're asking them to do. Will your current device survive if you enable SSL offload, application inspection, or similar features? You can try it out (fingers crossed!), or you can test.

If you're interested in the NFD presentation on Avalanche NEXT, check out the Tech Field Day page.

So, what didn't Spirent tell us at NFD6?
Two things jumped out at me as deserving more attention than they got during the presentation.

PCAP replay?
The Spirent folks explained that you could use the tool to run canned synthetic traffic through a firewall, or you could load your PCAPs of your own applications into the tool, and replay those.

It sounds straightforward, but I think they're underselling this feature, or at least glossing over how much is going on under the hood. This is nothing like dumping data onto the wire with TCPreplay, for example. Even in the simplest case of a generic TCP application, to play captured data through a firewall, they need to:

• Extract application transactions from the captured data
• Setup new transactions with unique 5-tuple identifiers
• Speak independently on behalf of both the client and server
• Process TCP and IP data independently, taking into account the mangling done to it by the device(s) under test: loss/fragmentation/segmentation/etc...

Factor in application-layer awareness, like rewriting SIP invites to include the correct synthetic client ID and you're dealing with new stuff throughout every layer of the stack, and (so they say), doing it at line rate with 10Gb/s interfaces.

It's way more complicated and interesting than merely "playing back pcaps" at high rates, and it's awesome.

VPN?

The Spirent guys focused their presentation on testing the transit ability (packet forwarding and deliberate dropping) of security appliances, but didn't mention that they can also do VPN stuff. Testing site-to-site VPN is obvious: just get two of the appliances, configure them, and blast application traffic through the tunnel.

It turns out that Spirent can also run these test suites from thousands of (simulated) VPN users. This is the capability that was most interesting to me because of a network I'm working on these days. Apparently they can simulate several types of VPN user, including Cisco AnyConnect clients. With this sort of test, the VPN believes that many users are online, and they all run the Spirent-controlled suite of application tests.

Tests I was previously familiar with include:

• Transit load testing (throughput/latency type stuff)
• Application server loading and fuzzing
• Synthetic network devices (1000 OSPF neighbors-in-a-box)

Synthetic VPN users, each running synthetic application load was a new one on me, and is relevant to my network.