One of my coworkers, Guang Zhang, who is one of those quiet, smart, thoughtful people (more or less the opposite of your humble narrator), spent a fair amount of time putting together a really cool piece on designing and deploying visibility infrastructure in data center and virtualized environments, the Keysight Data Center Visibility Deployment Guide.

This is a good piece because it covers ground that many in the world of IT may not pay much attention to – network visibility. One of those things, like reporting, that all too often is left to do at the end of an implementation when it should in an ideal world really be baked into the plan up front. Much like security, but that is another story for another time.

Changes in the data center, particularly cloud/virtualization, have changed the way visibility works. In the past, it was relatively easy to put taps in a bunch of places, capture traffic, groom it with packet brokers and send it to your tools.

Virtualization has changed all that. What if your traffic is largely between VMs? It may never leave a particular rack. It might not even leave a particular server. Regardless, there is a pretty good likelihood that this east-west traffic may never cross your tap. What then?

The good news is that Keysight has you covered. While a lot of things have changed, some things, like the Battle of the Pointing Fingers and the difficulty many teams have when trying to figure out what the source of trouble is for some sick application that just isn’t performing right, have not. And that is where network visibility comes in. With visibility, you can troubleshoot faster, fix faster and in general deliver more uptime and have happier customers/end-users. Did I mention that we can do this in virtual environments too? Did I mention that is something Guang covers in the app note?

While we are here, let me take another shameless dig at a competitor. Gigamon is well known for their network packet brokers, the fancy switches that sit at the heart of any network visibility solution. That said, when we recently brought in the Tolly Group to do a bakeoff between the Vision X, our latest and greatest NPB, and the Gigamon GigaVUE HC3, we made some interesting discoveries.

Gigamon GigaVUE HC-3 vs Vision X – note how Gigamon struggled with deduplication and dropped packets.

Because of the way that most networks are built, any visibility solution is likely to generate a substantial amount of duplicate traffic. You could just shunt that duplicate traffic to your tools, which is wasteful at best and likely to break things at worst, or you can deduplicate that traffic. If you are feeding security tools, what you don’t want to do is drop any of that traffic. Once you start dropping traffic, you start creating blind spots and do that often enough and something unpleasant will slip through.

Knowing this, when we built the Vision X, we used dedicated hardware acceleration with FPGAs and a carefully architected system – line rate, no dropped packets. Some of our competitors, like Gigamon, did not take this approach. Their GigaVUE HC3 dropped packets in deduplication tests, something that you did not see with Vision X. Sure, some of the tougher use cases resulted in traffic being forwarded without deduplication, less than ideal but far better than just throwing away the traffic. Remember, the whole idea of a visibility fabric is to increase visibility, not create blindspots.

Anyway, tap or span, the importance of deduplication, filtering, encapsulation, application intelligence and a bunch of other interesting topics are included for your consideration in Guang’s app note. Check it out.