Passive Tap Documentation

Note: This page is currently under construction...

• Generating a copy of the packet to be sent to the monitor
• Store-and-forward layer-2 devices
• Cut-through layer-2 devices
• Splitting the Ethernet signal
• Ethernet cable standards
• Passive tap connections
• PCB development
• References

With the availability of the DAG 3.5E card the requirement for an external passive tap is no longer necessary, as the DAG 3.5E card contains its own internal passive tap. However as we still retain an older DAG 3.2E card, which does not have this feature, the design of a passive tap is necessary for accurate monitoring of network traffic.

A network traffic monitor is ideally meant to be a non-invasive, passive sink on a network which has no effect on the traffic that it monitors, it only sees the packet traffic accurately and has no influence over the packets itself. However, this is hard to achieve in practice.

A fundamental problem in creating a non-invasive monitor is that the packets have to be sent in two different streams, the network link (from source to destination) and sunk to the monitor, when they only originally travelled on one, the network link. There are two ways of achieving the sink to the monitor, it can be done by either:

1. Generating a copy of the packet to be sent to the monitor; or
2. Electrically splitting the packet signal to both the monitor and the network link.

However there are significant pros and cons for each method and these will be discussed below.

Generating a copy of the packet to be sent to the monitor

10/100 Base-T Ethernet hub

The connection of a probing computer to an Ethernet hub whereby the hub is connected to an Ethernet switch and is tapped off to a measuring device such as the DAG PCI card (as previosuly described) is an example of electrically generating a copy of the original packet. This would not be a problem if the packet was copied instantaneously from a connection point on the network, but the introduction of any network device will create some latency.

The Ethernet hub is a layer-2 (OSI data-link layer) device which interacts with IEEE 802.3 Ethernet frames (64 to 1500 bytes). It is important to note that while the frames themselves may contain IP packet information, this is invisible to the hub itself. The hub acts as a packet forwarding device, redirecting packets to their destination based on the destination Medium Access Control (MAC) address field (2 or 6 bytes) contained in the MAC header of the frame.

Note that traceroute operates on the layer-3 (OSI network/IP layer) as it relies upon layer-3 devices (such as routers and layer-3 switches) decrementing the Time-To-live (TTL) field of the IP packet header in order to generate an ICMP Time exceeded response and hence deduce the address of the device and calculate the round trip time for that hop.

As layer-2 devices do not interact at all with the layer-3 IP packets they are often described as being 'invisible' to active probing techniques such as traceroute and Variable Packet Size (VPS) probing methods such as pathchar and clink, that use ICMP responses to detect 'IP' hops.

Prasad, Dovrolis and Mah (2002) make a further distinction on the operation of layer-2 devices, categorising them as either store-and-forward devices or cut-through devices.

Store-and-forward layer-2 devices

'A store-and-forward device receives and buffers the entire frame before forwarding it to the next link' (Prasad et. al., p.4). This technique is often used as it gives the device an opportunity to evaluate the frame before forwarding it, hence reducing network traffic by not forwarding corrupted frames. But, this means that a further serialisation latency proportional to the frame size will be added to the round trip time as calculated by traceroute - the larger the frame size the longer the delay. This will always result in an over-estimation in the round trip time.

Cut-through layer-2 devices

A cut-through device needs only to receive a frame's header before it starts forwarding the packet to the next link (Prasad et. al., 2002), ie. enough of the frame's information (particularly the destination address) has been received so a forwarding decision can be made. This means that cut-through devices overlap the receipt and transmission of frames and as such will avoid most of the serialisation latency.

Also, for the purposes of traceroute with our measurement setup the header will always be of a fixed size as we are forwarding frames between the same Ethernet switch and the network card on the probing machine, as such the destination and source addresses are always the same and hence the same size. This means that if we had a cut-through layer-2 device forwarding Ethernet frames that this serialisation latency would effectively cancel out for round trip time calcualtions as the frame would experience the same delay being both sent and received from the probing machine

But there will always be delays in layer-2 switching devices due to queing effects (at the data-link layer level) and the fact that both of the above techniques still do not instantaneously forward frames the moment that they are received, however the latter is not a problem for cut-through devices concerned with measuring round trip times.

Splitting the Ethernet signal

The other alternative to regenerating the signal is to split it. We have created a 'passive tap' which is essentially a signal splitter, here at CUBINlab. As the tap operates at a purely electrical level there is no analysis of the Ethernet frames that are sent/received on the network. Hence this solution represents the least invasive solution for network monitoring as frames are not forwarded after a degree of analysis on their contents, they are directly electrically forwarded to the relevant ports on the tap.

But such a splitting of the Ethernet signal will result in a degradation of both signal quality and strength. There is no regeneration of the signal here only a drain upon it. As such, the passive tap has to be designed carefully to ensure that the impedance between the pins on the RJ45 tap ports are not too high, or else frames will be lost.

As far as error control goes all that IEEE 802 LANs offer is a best-effort datagram service (Tanenbaum, 1996), which is enough for the delivery of IP packets whereby no guarantee of the packets delivery is required or even expected.  An IP packet can just be inserted into an 802 payload field and sent on its way, if it gets lost then nothing is done at the layer-2 level as the layer-3 service does not require its reliable transmission.  For traceroute this means that a round trip time is unable to be calculated  for this packet query and this is undesirable.

Protocols such as the Logical Link Protocol (LLC) offer an acknowledged datagram service and a reliable connection oriented service for layer-2 frames, whereby the 802.x frames contain a source address, a destination address, a sequence number, an acknowledgement number and a few miscellaneous bits (Tanenbaum, 1996). This means that a frame lost over an Ethernet network will be re-transmitted until an acknowledgement is received, thereby guaranteeing the frame's delivery. But this is also undesirable for traceroute and VPS tools as it will result in additional latency being experienced by IP packets transmitted on such mediums, hence skewing round trip times and capacity calculations.

The fact that some packets will be lost is a trade-off for non-invasive monitoring.

Ethernet cable standards

The 10/100 Base-T Ethernet cabling standard consists of four twisted pair wires which are allocated to a transmit pair (Tx+/Tx-) and receive pair (Rx+/Rx-) as shown in the table below:

Pinouts for 10/100 Base-T Ethernet cable

Name	Pin	Wire Color
TX+	1	White/Orange
TX-	2	Orange
RX+	3	White/Green
Not used	4	Blue
Not used	5	White/Blue
RX-	6	Green
Not used	7	White/Brown
Not used	8	Brown

Note that there are four wires that are not used for 10/100 Base-T Ethernet, as such these pins have not been connected on our tap. However for other Ethernet transmission standards such as 100 Base-T4 all 8 pins are used for data transmission.

Here is a front view of the RJ45 male pin with the top locking clip. Note that the pins are counted from left to right

The object of the pin connections in the passive tap was that from any connection to another there would be equal 'matched' resistance providing by summing two equal resistors in a Y-configuration. This means that the impedance across all of the paths in the tap are equal and as such signal reflections caused by unmatched resistor combinations are minimised. As such all the resistors must be of the same resistance.

Initially, the resistors selected to perform this function were chosen to be 51 Ohms in an effort to match as closely as possible the Ethernet 10/100 Base-T Ethernet line impedance of 100 Ohms, ie. 51+51=102 Ohms. However it was quickly found that many IP packets were being lost through the tap and that this matching of the line impedance actually was a connection of resistors in series to the line, giving an intolerable Switch to PC NIC impedance of approximately 202 Ohms. Hence the resistors used should be as small as possible and with 4.7 ohm resistors very few packets (if any) are lost.

Due to the DAG 3.2E's single port only monitoring capability it was desirable to produce a TAP-OUT stream which had both the receive and transmit signals available on the one port. Through much experimentation with different configurations it was found that this was not possible to achieve without additional, more complicated electronic components (such as a specific IC). The problem is that both Tx+/Tx- and Rx+/Rx- must be connected to the corresponding polarity Rx+/Rx- port on the TAP-OUT monitor port. However due to Ethernet's voltage mode signalling it is not possible to receive both streams simultaneously on the same port without the aid of an IC. When we connected the Tx+/Rx+ to Rx+ on the TAP-OUT port, we were essentially directly connecting the Tx+ stream to the Rx+ stream. This configuration hence caused network traffic collisions between the probing computer's port and the switch's port on the Passive Tap and was as such inoperable. Another ill-fated configuration was connecting the Tx+ and Tx- streams available on the network connections to the TAP-OUT port. This was not desirable as we only want to receive the transmit and receive signals at the monitor. We do need nor want the monitor to communicate with the other connections. In fact when using this configuration with the DAG 3.2E monitor the Passive Tap was inoperable.

Tap connections

The D and C Tap has the following connections:

• Ethernet switch to the tap;
• Probing computer's Network Interface Card (NIC) to the tap;
• Ethernet frames received (Rx) to the monitor; and
• Ethernet frames sent (Tx) to the monitor.

With this setup the probing computer's NIC is connected directly through to the Ethernet switch and the user has the choice of tapping off either the sent or received traffic (or both with a dual port monitor) that passes through the tap, providing for quite a flexible set of monitoring capabilities. Note that a cross-over cable must be used to tap off the frames sent/received to the monitor which is the DAG for our particular setup.

An example setup of the passive tap and the connections which allow for monitoring of both sent and received traffic from the switch and the probing machine is shown in the table and corresponding figure below:

Connection	Cable Type
DAG card (upper port) to Tap's Rx or Tx port	Crossover cable
Probing machine to Tap's PC NIC port	Straight cable
Switch to Tap's Switch Port	Straight cable

Passive tap connection setup with DAG 3.2E monitor

PCB development

The passive-tap was designed through the CAD PCB development tool, Protel 99 SE a proprietary software package which is also available in a demonstration version on Protel's website.

The Protel 99 SE project files can be downloaded here:

• Database file (contains entire project including RJ45 port):    DandC-Tap.ddb
• Library file (contains RJ45 8-way connector port):                  DandC-Tap.lib.gz

The schematic for the passive tap is shown below:

With high speed digital design the impedance of the transmission line, in this case being a Microstrip PCB transmission line (with one-layer) is important. The propagation delay of any transmission line is related to a trace's series inductance per unit length and its parallel capacitance per unit length. It is important to note that any section of a transmission line has a parasitic series inductance and nearby conductors will share some mutual capacitance so there will always be some element of inductance and capacitance on any PCB trace. In a transmission line both of these factors are proportional to length and their fine balance is responsible for the distornless propagation of signals (Johnson and Graham, 1993) and hence the retention of Ethernet frames.

Careful attention to the trace lengths and their routing on the PCB will prevent large characteristic impedances and hence the delay of the microstrip transmission line from distorting the signals. For example inefficient routing which adds 90 degree turns in the trace will cause and added delay that is not necesary. The longest trace in our PCB is approximately 3 inches which is not very large at all. As a basis of comparision consider the standard trace length for the PCI clock (33/66 MHz) which is 2.5 ± 0.1 inches. As such our traces are not too long and we will not experience a large characteristic impedance or delays with signal transmission.

The PCB layout based upon the schematic above is shown below.

A photograph of the completed D and C tap is due to appear here soon....

References:

1. H. Johnson and M. Graham. (1993). High Speed Digital Design: A Handbook of Black Magic. Prentice Hall.
   
2. R. Prasad, C. Dovrolis and B. Mah, 2002, "The effect of layer-2 store-and-forward devices on per-hop capacity estimation.".
3. Tanenbaum, A. (1996). Computer Networks. 3rd Ed. Prentice Hall, New Jersey.