Ixia, which is known for its high-performing test tools, started its presentations at Networking Field Day 13 (#NFD13) by making the point that their testing tools let them load test their gear for dropped packets. In sports terms, that’s like the concept that having a good defense leads to a good offense.
This blog shares some thoughts about Network Packet Broker products and fabrics. Admittedly, it’s not something I’ve been deeply involved with, although last year I did get asked for my consulting opinion on the topic. If you have information or opinions, please add comments to this blog, so I can learn from your experiences!
Let’s call the Network Packet Broker devices with ports that can do forwarding “NPB boxes.” “Switches” would be a bit misleading. And “Network Packet Brokers” sounds like people trading packets, or maybe the control software for a NPB fabric.
About Tap Fabrics
Basic Network Packet Broker 101: Put in taps, feed them into a NPB box, steer traffic out a port to your favorite packet analyzer tool, IDS, etc. You can now see what’s going on, without competing for Cisco SPAN, RSPAN or ERSPAN use. You can even feed SPAN ports to the NPB box and easily share them with multiple consumers. I get that. It certainly can make life easier, both for troubleshooting and for feeding data to security tools.
There are those who claim that Murphy’s Law applies: Taps will find a way to fail so as to not pass traffic. I lack data on that. Do taps make a network less reliable?
You’d better do a good job of documenting which tap location feeds which packet broker device port (overlaid on that rare beast, an accurate network diagram?).
I’ve seen some security designs, proposing to tap almost everywhere. That seems to me to violate any sense of priorities, and can add considerable cost. I’ll concede having taps on both sides of a firewall might help you troubleshoot firewall rule problems. My personal experience is that looking at packets is inherently very slow to yield useful information. To me, doing packet captures is a last resort most of the time — it’s just too slow. Pervasive taP Positioning Permits Profligate Packet Perusal? I guess it works for some, so I shouldn’t judge. I’ll concede good tools beat trying to set up an in-device filter for router or firewall packet capture/analysis, or saving to .PCAP file and then having to pull that off the device.
NPB 201: The Fabric. Some people like to interconnect the NPB boxes. Using OpenFlow or proprietary mechanisms, one can then copy packets, merge packet streams, and connect a set of source ports to selected destination ports. That creates a NPB fabric.
That could certainly be convenient. It’s necessary when you have a costly security or other tool or appliance that needs to be fed packets.
My problem with that is cost, which depends on what your topology looks like, speeds, and feeds. As people tap more and more points on the network, you’re going to be aggregating traffic as you feed it into the fabric. You either will oversubscribe the fabric links, or need to start investing in 40 or 100 Gbps fabric links and forwarding capability. If you feed all that collected traffic to a central security box, it will need to have very high speed capacity as well.
Does that end up being cheaper or more convenient than, say, connecting a next-gen IDS to a port on each NPB box? Not at all clear. This resembles some of the discussions around “fog computing” — processing near the data source can greatly reduce the traffic sent to the central or cloud processing engine.
If you can arrange filtering to only forward packets of interest across the fabric, that helps, although it may cost you a little time. That’s where smart NPB software comes in: If the NPB box can analyze traffic, e.g. with NetFlow-like data, and then make it easy to drill down, see what’s going on, and build filters, that could help.
The bottom line: This is a situation where distributing processing and analysis really has to help, both with performance and cost. I’m waiting for NFV functionality, where the NPB box lets one run VMs on its CPU. Right now, that is partly here, in that some NPB boxes have add-on packet filtering and other tools, for a price.
Conclusion: “Visibility” tools are rather handy. I’d want some in my network. I’d want to prioritize where I put taps, and understand my objectives and monitoring intentions, versus tapping everything in sight. I’m on the fence about connecting them into a fabric; I’d like to understand the use cases driving that better, justification versus cost.
About Ixia Network Packet Broker, Etc.
Cutting to the chase, it looks like Ixia has been working on some neat NBP capabilities. Ixia is a vendor of test applications, and security and visibility products. They presented at #NFD13, via both slides and demos, all captured in video, here. The products certainly demo well!
Rather than going on at length here, I’m going to point you at some links, so you can look for yourself and make up your own mind.
Ixia (and the competition) have named the product category “Visibility.” You can read about their Network Packet Broker products here. The Vision One product provides “intelligent out-of-band packet analysis and inline security functionality.” It runs the Application Threat and Intelligence Processor (ATIP), filtering and visualizing both Layer 2-4 and application Layer 7 traffic.
Ixia also talked about their cloud plans and products, under the name CloudLens.
Competition
The NPB market has a number of vendors with varying capabilities. Among them are:
Links and other blogs
The blogs by my fellow #NFD13 delegates might also be of interest:
- Ixia Vision ONE — Tap the Planet
- See in the Fog With Ixia CloudLens
- Ixia Works Out Its Network Trust Issues
- Capture, Filter, See — Ixia Vision ONE
- Trust But Verify: Lossless End-to-End Visibility From Ixia
For some general advice regarding NPBs, visit this blog.
Comments
Comments are welcome, both in agreement or constructive disagreement about the above. I enjoy hearing from readers and carrying on deeper discussion via comments. Thanks in advance!
