In the last few weeks, we’ve seen some new announcements around Network TAPs and network packet brokers. For example, in this SearchNetworking piece, the editor created a nice pro-and-con analysis of adding more functionality into a network switch through SDN and whether that threated an adjacent market.

Why are SDN-driven network TAPs such a big deal?

First, network TAPs are costly and not programmable.  When you have to “dump” infrastructure that can’t be tweaked as your needs change, that becomes a tough purchase decision. You can see where the idea of vendors pitching future-proofing comes from and why they want to demonstrate and highlight an extensible technology model. So what degree of programmability and flexibility is required for your data center?  And what is a “God Box?”

The networking industry is littered with the carcasses of companies that tried to put too much into one box. In the late 1990s, the “God Box” phrase was used to describe the all-encompassing device that was touted as being capable of consolidating several other smaller devices. A solution where packets go in, and no matter what you want done to that traffic, the right things magically happen.

At some point, however, the perception of having too much functionality then and now still causes failure for two key reasons.  First, the functionality crosses silo team responsibilities. For example, responsibilities for routing and transport fall to two separate organizations and that can certainly cause miscommunication—or worse conflict—between the network and storage teams in the data center. Secondly, the concern over too many tools in one toolkit causes others to believe that functionality can’t scale or the combined value is simply too expensive for the IT team.

How can we judge this very gray and fuzzy line between value-added functionality and too much integration?   It is indeed a good question, especially with SDN causing everyone to rethink traditional boundaries.

Let’s look at some basic facts:

• Network TAPs are separate devices because that was the only way to mirror the traffic in the early days. Because networks have to scale more today, the old way is no longer as cost effective or innately flexible.
• Network packet brokers have much more feature richness than a standard switch with 20% of the features at a marginal incremental cost.  As Arista points out, $350 to $400 per port compared to $2,500 to $4,000 per port means customers will consider that kind of trade off of 20% of features available for 80% less cost.
• SDN opens the door for more ideas like this because we can now tune or program ports to specific ad hoc needs and then tear those ports down when finished. This makes the fixed device much more utilitarian and “future proofed.”

Some conclusions and comments

• Will IT managers wholeheartedly support the production network to also be an analytics tool?  Not in today’s enterprise, but some cloud service providers might try.
• Would network architects see this as a game changer or a “nice-to-have” in a production switch? Again, some cloud service providers may agree, but not in today’s enterprise.
• Does the typical IT team have time to relearn something new?  Sometimes, if the pain is high; yes, if the cost savings are huge. Even cloud service providers have limited developer resources.

What does this mean? If you are a cloud provider, this might make sense and may offer some additional value.  But I would not discount the network packet brokers too soon, as they continue to innovate and continue to show that their 80% extra features have significant value.

If you support OpenFlow (especially version 1.2) on your switch, you have all the pieces today to create a network TAP—and potentially the first ‘’killer app’’ for OpenFlow.