Talk:Network tap

From Wikipedia, the free encyclopedia
Jump to: navigation, search

Fix required: The first reference links to a Sociology paper, not a paper about "Practical quantum key distribution".

— Preceding unsigned comment added by (talk) 14:51, 25 March 2014 (UTC)

According to Datacom Systems, network taps are physical layer devices that allow network and security personnel to create permanent test access ports (TAPs) throughout the network, eliminating the need for network connectors to be disconnected and reconnected each time a network segment needs to be monitored by a network management or security appliance. Therefore, the network never needs to be disconnected and the physical wires always can stayy in place.

Network taps are what is known as "passive" devices and typically pass all seven layers of OSI network traffic. Taps do not interfere with the performance and integrity of the network or the data that flows across it.

A network tap will pass full duplex traffic at "line rate", whereas some network management and security devices when deployed In-Line may cause a delay when copying packets or converting data signals from electrical to optical format on networks with both copper and fiber media types. The same problem can occur when network switches are deployed for network devices to monitor their SPAN (or mirror) ports.

Since most taps are passive devices, they are perfect solutions for "In-Line" deployment where they allow network monitoring tools to have permanent and real-time access to network links without introducing a point of failure.

Deploying network taps for use with security and management devices should conserve network resources. They require no management, configuration, and can connect any two network devices

Above comments are not attributed.

I suspect test access port is a bacronym. tap has been a common network term for many years, dating back at least to the vampire taps used for 10base5. Morty abzug 03:15, 30 May 2006 (UTC)

Most current network taps introduce less of a point of failure than the network cables themselves. Fiber taps are more vulnerable to being physically damaged than most other types.

"Span Ports" really tend to slow switches down and in turn, generally slow the entire network down, since the ideal monitoring point is usually a network backbone. A "span port" steals valuable resources from the switch, especially in high traffic environments where memory must be used to buffer full-duplex traffic beyond the speed of the single interface. This can bring an entire network down very quickly.

Network taps generally do not require "channel-bonding", as suggested. Most modern network monitoring software allows multiple interfaces (often unlimited) to be monitored simultaneously.

It is generally more desirable to use "dumb" network monitoring devices (e.g. no snmp), as they are not hackable and are not detectable on the network. This is actually a requirement under current CALEA laws.

Although this is a well written article overall, some of the statements really make one wonder how much network monitoring the author(s) has/have actually done lately. Perhaps this article has not been updated in a very long time? Most of this information was true several years ago.

As I am obiously not the best writer, I will leave this up to someone else to update as they see fit - or not...

—The preceding unsigned comment was added by (talk) 21:50, August 21, 2007 (UTC)

This segment:

"Network taps are commonly used for network intrusion detection systems, network probes, RMON probes, packet sniffers, and other monitoring and collection devices and software that require access to a network segment. Taps are used in security applications because they are non-obtrusive, are not detectable on the network, can deal with full-duplex and non-shared networks, and will usually pass-through traffic even if the tap stops working or loses power."

Is the same as used on this product page: Neither seems to cite the other as a source. —Preceding unsigned comment added by (talk) 23:02, 15 November 2007 (UTC)

External links[edit]