TAPs and NPBs are certainly on a collision course and their functionality and use cases are overlapping more and more. Traditionally TAPs were relatively unintelligent – providing pass-through monitoring points (possibly with very limited filtering), passing a copy of the data seen on the network ports straight off to the network intelligence tools (e.g. IDS). NPBs on the other hand offered much more sophisticated techniques such as advanced and deep packet filtering, packet slicing (excessive payload discard), time stamp insertion (for latency measurements), de-duplication and high-traffic burst buffering – all of which allows load reduction and/or greater capacity for the network intelligence layer.
There is a place in most networks for both TAPs and NPBs – TAPs for feeding NPBs or simply where throughput is lower and all packets are ‘interesting’ – e.g. at the WAN edge. NPBs are needed where higher traffic throughput is required and/or smart filtering and packet modification is needed to allow the network intelligence applications to adequately handle the load.
The need for TAPs / NPBs is further complicated with SDN where flows can be directly ‘steered’ towards the network intelligence applications and with vSwitches providing virtual SPAN ports.
NPBs have traditionally been significantly more expensive than TAPs, but with the trends toward less expensive NPBs and more functionally rich TAPs, these two technologies are on a collision course. From a customers’ point of view this is good news, it reduces cost and allows for more widespread network monitoring. At the moment TAPs are still less functionally rich than NPBs, but if the additional functionality isn’t needed or is only needed in certain locations TAPs are appealing, and TAPs are continuing to close the gap.
Some other thoughts on this from Jim Duffy at Network World: