Taps compatibility

[Alexander Dupuy <alex.dupuy () mac com>]

David Moron asked:

> I want to monitor a Gigabit Multimode(SX) Fiber link. If use a Network
> Tap then:
>         - Using one SX NIC: Can Libpcap capture packets from TX and RX NIC's
> connector?
>         - Have I to use 2 different NICs to connect the fibers to the RX
> connectors and don't use the TX ones? ¿Configuring the NIC's
> autonegotation would work?
>
> I Would want not to use an aggregation tap because of $$ and do the
> aggregation process inside de Linux box.
>  

You can use channel bonding to perform aggregation of multiple Gb 
links.  You would have pcap open the bond0 interface after enslaving the 
eth0/eth1 interfaces to it.

I don't think you can receive packets on the Tx fiber interface, the 
hardware won't support this (unless you have very unusual hardware) - 
you will need to use two interfaces.  The fiber interfaces only support 
Gb so there's no autonegotiation as there is for copper, you can leave 
the Tx interfaces unconnected and still use the Rx links (this is very 
handy if you want to make absolutely sure that there's no way a passive 
monitor can be active.

Michael Bernstein replied:

> So you want to use a Linux box as an in-line tap. You might have to configure it for bridging or bonding, not exactly 
> sure how to accomplish this, however, i my self am also interested in something like this.

I think that this is a misunderstanding of David's question, but it is 
an interesting issue as well.  In an in-line tap, the idea is that you 
"splice" the device in the middle of an existing fiber link and observe 
the traffic passing through without modifying it, simply transmitting 
exactly what you receive.  The intention is for the device to be as 
passive as possible - ideally this could be done in a completely 
undetectable manner.

You could not do this with bonding, since that combines multiple inputs, 
and can multiplex multiple outputs in different ways, but does not 
repeat inputs to outputs.  You could almost do this with bridging, since 
that will propagate traffic from one side to the other, but it is not 
passive (the bridge will transmit spanning tree protocol traffic) and 
doesn't replicate all traffic (if it has observed a MAC address as a 
source on one side it will not propagate traffic to that MAC unless it 
is coming from the other side).  Furthermore, this requires that you tap 
both directions of the link - I don't think you could tap a single fiber 
(unidirectional) link effectively.

If you wanted to do this, the best solution would be a specialized NIC 
or driver software that was able to set the fiber interface in "echo" or 
"relay" mode where it transmitted everything it received back out (while 
delivering a copy to the kernel network interface for observation).  I 
am not aware of any such software or NIC cards, but would also be quite 
interested to learn of any such.

Failing a hardware/NIC driver solution, your best bet would be to use 
the PF_RING kernel driver for Linux (http://www.ntop.org/PF_RING.html).  
The PF_RING driver has a special "reflector" mode that will literally 
echo any traffic received on one interface to another one; this happens 
just above the network driver (and below all the generic Linux 
networking) so if any software solution will be able to keep up with a 
fully loaded Gb link on your hardware, this is it.  The reflector mode 
is not well documented; you have to read the source to see how to set 
this up, but the following code snippet from libpfring (the 
administrative user-land support for the PF_RING driver) shows how it is 
done, and you can follow the details in the rest of the source code, 
notably the kernel support for SO_SET_REFLECTOR:

int pfring_set_reflector(pfring *ring, char *reflectorDevice) {
 return(ring ?
        setsockopt(ring->fd, 0, SO_SET_REFLECTOR,
                   &reflectorDevice, strlen(reflectorDevice)) : -1);
}

With the PF_RING reflector support, you could use two fiber NICs, 
attaching the PF_RING driver to the interface with the Rx connector 
attached and setting the second interface (with the Tx connector 
attached) as the reflector for the first, so that everything on one 
fiber is sent out the other (and delivered to a patched version of 
libpcap with PF_RING support).  This would create a single-fiber 
(unidirectional) inline tap - you could get a bidirectional tap by 
setting the PF_RING reflector for eth0 to be eth1, and vice versa.

If you do set up something like this, I would be very interested to hear 
from you how it went, and any difficulties or problems you ran into.

@alex

--
mailto:alex.dupuy () mac com

-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.