Posted by: Eric Siegel
(I see that today I'm just full of exclamation marks in my titles!)
Anyway...
I have a report coming out in a few weeks, "Network Tapping and Flow Tracing Tools" and a portion of it discusses network taps and "SPAN" (Switched Port Analyzer) ports, which are also called "mirror" or "monitor" ports.
A monitor port is a port on a switch, router, virtual machine processor, or other device that can be configured to copy (or “mirror”) the data from another of the device’s ports or from an otherwise inaccessible data path inside the device. A diagnostic or measurement tool can then be plugged into the monitor port to examine the data flow.
In contrast, a tap is not embedded in network or host equipment. Instead, it's a low-cost physical device that passively, and invisibly, intercepts traffic on a WAN or LAN link. Taps can be electrical, for copper WAN links and Ethernet, or they can be optical, splitting some of the light energy from an optical fiber.
Most enterprises don't install taps; instead, they use the existing monitor ports to connect monitoring equipment and intrusion detection and management equipment. This is a mistake.
While I was talking with tap vendors over the past few weeks, I was struck by how often they commented that enterprises just don't focus on the need for taps. So here are a few reasons that the small investment in a tap infrastructure pays BIG dividends, especially when you have a intrusion incident or diagnostic crisis:
- Taps do not drop packets. Monitor ports may drop frames, especially under heavy load, because they handle frame monitoring at a lower priority than their primary function. This can be irritating, because it always seems to happen precisely when your network is being flooded by a problem or intrusion.
- Taps do not remove errored frames (e.g., short frames, jabbers); the diagnostic tool can see exactly what is on the communications link, errors included. Monitor ports don't see errored frames because they're removed as they enter the switch or router, long before the monitor port sees them. If errored frames are causing congestion, your diagnostic tools won't see them at the monitor port.
- Most taps can multicast to multiple output ports, allowing more than one diagnostic tool to see the data flows. That's extremely useful! It's wildly irritating to race into a server room with screaming managers on your tail, and then discover that some mystery cable is plugged into the switch's sole monitor port. What does that cable do? If I unplug it, so that I can plug in my trace tool, what is going to break? Aaargh. Time wasted, tracing cables to figure out what is going on. It's much nicer to have an extra port on the tap!
- Some taps can filter the traffic, decreasing the volume that the diagnostic tool must cope with. They can provide that function without using a network device’s limited processing capabilities.
- Some taps can combine traffic from multiple sources into one output port for the monitoring tool, possibly adding source identification and hardware time stamping to the frames.
Well, there's a lot more about taps and monitor ports -- and about matrix switches, storage, and trace tools, etc. But you'll have to wait for the report! (If you desperately need it now, and you're a Burton Group client, send me an email and I'll give you a pre-publication copy, of course.)

When monitoring tools need 100% data capture (especially 24x7), there is no substitute for taps because they are passive, allow for permanent placement, and copy all the data flowing through the network link. It is true that most enterprises will use SPAN ports. Some times, SPAN ports are adequate when you only need a sampling of data (i.e. to get a snapshot of your network). Most of the times, people who monitor data are simply stuck with what they are given (SPAN ports)...it is an organizational decision. Chris Greer from Packet Pioneer did a really good expose of TAPs versus SPAN ports at: http://www.lovemytool.com/blog/2009/10/is-span-port-really-so-bad-by-chris-greer.html. I also just wrote a paper geared towards VoIP analysis that hammers home the need for data capture infrastructure to be built into the monitoring environment: http://www.datacomsystems.com/partners/auth/content/VoIP-White-Paper.pdf. Ultimately, the biggest problem with SPAN ports is: there's just not enough of them!
Posted by: Matt Shuff | March 30, 2010 at 09:07 AM
In my opinion our industry is transforming from providing low-cost physical devices that are passive in nature to deliver more sophisticated solutions to address customer needs. My company, that is known for its taps is positioned as “Data Access Company”, Providing intelligent monitoring access for security and network management applications.
I believe that some industry verticals are more mature with their use of taps which is driven by specific application requirements: performance monitoring, lawful Interception, activity monitoring and network instrumentation.
Sharon
Net Optics.
Posted by: Sharon Besser | March 31, 2010 at 09:57 AM