By Owen O’Neil
History of Ethernet and TAP development
Understanding TAPs requires a brief background on the development of the Ethernet topology, as it is deployed in Local Area Networks. The earliest Ethernet deployment, standardized in 1982, was known as 10Base5. It utilized a Bus design with a single collision domain for all devices on the network. All attached devices “listened” to all traffic and transmitted when the network had no traffic present, then backed off for random intervals and retried the transmission if a collision occurred. Attachment to the “Thicknet” coax cable was done by attaching a “vampire tap” which was screwed onto the cable and penetrated the sheathing to make connection. This system was unwieldy and difficult to manage. It was followed by 10Base2, which utilized thinner more easily manageable cable and 10 Mbps data rates. In order to “tap” and monitor this type of network, the user needed only to connect a vampire tap and attach a PC that was running the earliest version of packet sniffer software – the DOS based Network General Corporation Sniffer™ software.
10Base2 was quickly replaced by 10BaseT, which initially utilized Category 3 UTP (unshielded twisted pair wiring – similar to telephone wire) and 10 Mbps shared media hubs. In the hub design, all connected devices listened at all times, and collisions/retransmits still occurred, but there could now be multiple collision domains separated by “bridges”. Packet sniffers needed only to be plugged into a hub to monitor all data on that network segment – TAPs were not necessary. An advantage to the hub system was that if a single attached device went down – it did not prevent communication between the devices that. In the Bus design, the devices on either side of the break could not communicate with one another. The hub system did have a shortcoming: the frequency of collisions and resulting slowdowns in data transmission made it impractical for higher speeds and a high density of devices on any single network segment.
The first 10BaseT Ethernet switches for practical and widespread commercial deployment were introduced around 1993 and began to gain marketplace traction by 1995. These switches soon also supported 100BaseT (100 Mbps aka “Fast Ethernet”).
Ethernet switches offered many advantages but introduced another major shortcoming: all traffic between devices on a single network switch occurred inside the switch on its backplane, thus reducing visibility. For example, traffic between users and serves connected to the same switch could be monitored only if a device allowing the physical cables between switch and devices to be accessed were utilized. Links between switches that were connected by bridges were also subject to this limitation.
Enter the Network TAP: In its earliest incarnations, the tap was conceptually akin to adding Y connections to each of the two Ethernet wiring pairs (1,2 and 3,6) – allowing copies of the Tx and Rx data to be handed off from a separate pair of “monitor ports” on the small device. “Network ports” allowed the connection from switch to server or switch to user to be completed, with the data being monitored by a packet sniffer. This also allowed a convenient method for utilizing early RMON Probes. Unlike the packet sniffer, which could analyze traffic flow and identify problems in real-time at the site where the issue was occurring – RMON Probes (also called “bit buckets” during that era) simply listened and collected data. It was then retrieved remotely and brought to a central location where the Monitor portion of the system could analyze the data to provide big picture analytics of network performance.
Switch manufacturers quickly saw the need for better visibility and added a dedicated port or ports that would allow users to select a port or group of ports on the switch and see all traffic in the selected areas. Generically referred to as mirror ports, Cisco Systems designated these as SPAN ports (Switch Port Analyzer) – a term which is now the de facto industry description for the monitoring port of a network switch. SPAN ports enable both the Rx and Tx copies of data streams to be merged together, allowing packet capture or monitoring devices to listen with only a single capture interface. SPAN ports did and still do have several significant shortcomings:
1) Layer 1 and Layer 2 errors such as CRC’s, Runts, and Fragments are discarded by SPAN ports. These are often critical indicators pointing to network communication issues, and typically need to be investigated.
2) Network switch design mandates that when a switch is heavily utilized, packet copies (i.e. data being sent out the SPAN port) can be discarded to prevent packet loss in the real-time traffic.
3) SPAN ports can easily be oversubscribed if too large a volume of data is steered to them. Unlike two way communication between regular network devices, in which TCP checks on dropped packets and requests re-transmits via IP, SPAN ports transmit only, and typical monitoring devices are used in “promiscuous mode”; the capture device only listens and does not transmit.
This fact prompted increased use of copper network Ethernet TAPs and drove further developments and refinements in designs and features. The original Ethernet switch designs utilized half duplex transmission: any device that had a pathway through the switch to any other device could transmit data only when the other device was not transmitting. Both Ethernet wiring pairs were used, but the two devices could not communicate simultaneously. Full duplex transmission became increasingly more common as the 1990’s progressed. By allowing two devices to send and receive data at the same time, the effective bandwidth of a single 100BaseT link was doubled – maximum possible utilization now allowed up to 200 Mbps of data to be carried on a link rather than just 100 Mbps.
Gigabit Ethernet on copper is also full duplex but adds another layer of complexity: rather than just using two wiring pairs, all four pairs (8 wires) inside the cable are used at all times, with Rx and Tx occurring simultaneously. The Ethernet PHY is able to sort out and discard error information resulting from this simultaneous Rx and Tx transmission on all 8 wires, but this complexity adds a wrinkle to TAP design.
In recent years, 10 Gigabit copper Ethernet has made an appearance. It requires higher quality cabling (Category 6A or 7 vs Category 5e or Category 6) to accommodate the increase in transmission speed and higher frequency of 10 Gigabit transmission. Often used for short connections inside data centers, it has also been adapted for use in the Automotive Ethernet topology, enabling the increasingly complex communication and control systems of modern vehicles to function optimally (note: 2.5G and 5G are also used in this context.)
Datacom Systems Copper TAPs Provide Solutions for Real World Problems
Before presenting these solutions, some definitions are needed for context:
- Non-Aggregated TAP (also called a Break-Out TAP): hands off separate copies of the Rx and Tx data and requires that the user have a monitoring device with two capture NICs and software allowing the data to be recombined. This enables the user to view the original duplex conversation (Requests and Acknowledgements etc.) in a single window.
- Aggregated TAP: merges or aggregates the Rx and Tx data by using a switch chip inside the tap, thus allowing devices with a single capture NIC to receive all of the data in a single stream. Examples of devices benefitting from this include Wireshark – a popular open source packet sniffer software, and Snort – a widely used IDS (Intrusion Detection System) software.
- Regeneration TAP: allows multiple copies of the tapped data to be replicated, enabling more than one monitoring tool to listen to or capture from the same link.
- Passive: a design in which the TAP is unpowered (i.e. Fiber Optic TAPs work exclusively in the optical realm) OR can lose power without creating any impact on the tapped link.
- Power Fault tolerant: certain topologies – e.g. copper Ethernet at 1 Gigabit and faster –
have a level of complexity that has thus far prevented development of a truly passive TAP design for them. The standard solution to this issue is to utilize copper relay bypass systems. If a power fault tolerant TAP loses power, the relays move into position, allowing both link endpoints to re-establish link with one another through the unpowered TAP. Upon power loss, there is a brief interruption of the link during the negotiation process (3.2 seconds for Datacom TAPs.) When power is restored, there is another brief interruption (3 seconds for Datacom TAPs.) All Datacom TAPs include redundant load sharing power supplies with MTBF in excess of 60,000 hours. There is extremely minimal risk of a Datacom copper Gigabit TAP losing power!
NOTES:
- There is not now nor has there ever been a truly passive copper Gigabit Ethernet tap – with or without aggregation.
- The two Network ports that allow the endpoints to connect to the tap do not have IP addresses or Mac addresses. Once each endpoint negotiates link with the port it is connected to, the tap is transparent to the network.
10/100 TAPs
Datacom offers one specific passive TAP model for 10/100 links only – the 10/100-AT. Magnetic induction allows copies of the data passing on the two Ethernet pairs. If the tap loses power there is zero impact on the link. It is truly passive and uses a non-aggregated design.
10/100/1000 TAPs
The 10/100/1000-TAP is unique to the industry. A simple selector switch allows the user to select truly passive mode for 10/100 links, but also supports power fault tolerant mode for 1G links. It provides non-aggregated output only.
The CTP-1000 is the industry’s most secure copper TAP. It is a non -managed device, having no Management port, no user interface that can be hacked, and no internal path that could allow access from the TAP back on the link itself. A rear slider switch allows the user to select Aggregated or Non-Aggregated output. It is auto-sensing and supports use with 10/100/1000 links and tools.
10/100/1000 Aggregation TAPs
Datacom’s SINGLEstream™ series of TAPS are available in two categories:
SINGLEstream Single, Dual, and Quad link TAPs with 1G output
These models utilize a switch chip optimized for the sole purpose of borrowing copies of the data and passing it out the monitor ports as aggregated or non-aggregated data. This allows the user to configure for aggregated or non-aggregated output to as few as two and up to as many as four monitor ports. Intended for use in links with aggregate total traffic loads not exceeding 1G, they are compact and affordable. Secure SSH is used for remote management. An intuitive CLI is provided for configuration and control. SNMP v2/v3 traps can be enabled to provide alerts if there is an issue with a power supply or a link goes down.
SINGLEstream “G” series high density TAPs
Looking to tap multiple links all in one physical location, with higher bandwidth requirements and higher speed tools? The “G” series provide that can provide tapping for as many as eight links in a single compact chassis (one half of a rack width and 1RU in height.) The data from all of the links can be aggregated into a single stream or split up into groups. All models provide four SFP+ receptacles, enabling Monitor Ports that support 10/100/1000 and 10G copper or 1G/10G fiber. The SNMP v2/v3 traps are more sophisticated in this series – allowing notifications for fan failure, out of specification temperatures inside the unit, in addition to power supply and link status alerts. (NOTE: two of the three models also have additional 10/100/1000 copper pots that may be used as inputs or outputs.)
Network engineers have long been accustomed to using post-capture display filters in products such as Wireshark. Display filters mask traffic of no interest to the viewer, allowing for easier analysis of issues. Display filters are convenient but not useful in real-time troubleshooting.
Capture filters, on the other hand, allow real-time filtering of the data as it is being captured. This enables certain user selected protocols, VLANs, IP Addresses, MAC addresses etc. to be captured by the monitoring tool and excludes data not of interest to the user. In products like Wireshark and other monitoring tools, this is software based filtering; it is an extremely processor intensive activity that dramatically impacts the potential throughput capacity of the tool. Software based filtering requires the monitoring tool itself to inspect all data and determine which packets to keep or discard.
The “G” series TAPs offer hardware based filtering. This feature allows the resources of the TAP itself to be used for filtering – allowing packet filtering to occur at full line rate. In addition to excluding data of no interest – e.g. duplicate traffic copies that being sent to a backup system or a Disaster Recovery Center, hardware based filtering allows tools to have only the data directed to them that is pertinent for their applications. Examples include TCP Ports 80, 8080 and 443 data sent to Web monitoring systems, Port 1521 data to tools used for monitoring Oracle database traffic, etc. This allows tools to operate at maximum efficiency, with optimal throughput and more effective use of their drive storage space.
10G Copper TAPs
The CTP-10G is the newest entry in Datacom’s product line. It is a robust and secure non-managed product and is the next evolutionary from the CTP-1000. It provides non-aggregated output. Unique to the industry, it supports Auto-sensing on the Network Ports and Monitor Ports – allowing use in 1G, 2.5G, 5G, and 10G links, and support of monitoring tools at any of those speeds.
The Datacom Systems Sales Team and Sales Engineers are available at your convenience to provide pricing or analysis of your copper Ethernet TAP needs.
