1

I will be setting up a passive optical tap on a 10gig fiber line (OM3 50/125 multimode 850nm), and passing the two fiber cables from the monitor port to a linux server that will have an IDS (Snort or Suricata).

I have most things sorted out, but my problem is that IDS's don't function well (or at all) when traffic is split between two interfaces and especially at 10 gigabit speeds. Which is an issue because a passive tap is my requirement to keep the link as reliable and performant as possible.

I was thinking, since the tap creates two single fiber lines, why are there no SFP+ Modules that have two receiver inputs? Or PCIe cards that have two LC connectors that appear as a single interface to the host OS?

For hardware, this seems like something very possible (can't find anything on google), so there must be something I'm missing for why this isn't a thing. Is the firmware on the module and network card impossible to deal with two inputs for the same (connection) network traffic? It seems to me this type of physical layout would already occur with multiple conductive pairs in regular ethernet cable.

Do other environments only use these optical taps to analyze one direction at a time?

Am I missing some other way to economically combine two transmitting fibers into one interface? (Other than trying to use software bridging)

9
  • I don't have a specific answer for you but I am wondering about some of your assumptions/assertions. Are you sure the tap is outputting a split connection? If it is a normal optical tap, I would expect it to be a duplicate of the existing connection, basically it should work like the internet connection works. I also am unclear on why the IDS or any traffic capture software would have a problem with more than one interface. I would expect it could use as many interfaces as needed as long as it is coded to do so and the hardware (CPU etc.) support processing it. Jun 7 at 3:27
  • Passive optical taps output two fiber strands each with half of the network traffic. One has upstream traffic and one has down stream traffic. IDS run into trouble because in a TCP connection, the SYN packet would arrive on one interface and the SYN ACK on another interface.
    – user90006
    Jun 7 at 11:05
  • Bond the interfaces. (I'm sure that's documented on many of the how-to's for those packages.)
    – Ricky
    Jun 7 at 11:46
  • Perhaps I am still missing something here but isn't a tap for a single duplex fiber connection going to simply output a duplicated copy of the single duple fiber connection so you could just plug it into a normal duplex LC 10 gigabit network interface? The 'two cables' are just the normal duplex pair of fiber cables right? No need for a special piece of hardware for that since there is only one pair of fibers for the internet service going into the tap. Or am I missing something? Jun 7 at 21:04
  • Passive optical tap has a total of 6 LC fiber connectors, 4 of which are used for normal traffic flow. Of these 4, the tap passively copies the traffic from 2 of them. Thus the monitor port has 2 LC connectors both transmitting light out of the tap. On the IDS server a normal SFP module can only receive traffic on one fiber strand. Hard to explain in text only, there are better diagrams all over google.
    – user90006
    Jun 7 at 21:11

1 Answer 1

0

why are there no SFP+ Modules that have two receiver inputs?

A single SFP+ module cannot run two receivers as the port only supplies a single Rx lane. Many QSFP+ ports (like on a 40G NIC) support 'breaking out' their four lanes into four discrete ports though.

Or PCIe cards that have two LC connectors that appear as a single interface to the host OS?

A single 10G NIC cannot receive multiple frames simultaneously which is a requirement in your scenario. However, there are plenty of multi-port NICs around that you could use.

Is the firmware on the module and network card impossible to deal with two inputs for the same (connection) network traffic?

That's not possible: Two PHYs cannot connect into a single MAC. If you add a second MAC your NIC becomes dual ported.

It seems to me this type of physical layout would already occur with multiple conductive pairs in regular ethernet cable.

Multiple lanes in twisted-pair (or optical) cabling combine to a single PHY that connects into a single MAC. An exception is a QSFP+ NIC with break-out support that actually contains four MACs.

Do other environments only use these optical taps to analyze one direction at a time?

If you use a NIC for monitoring then you require one NIC (PHY + MAC) for each source.

If you try to use a managed switch to aggregate the tap frames then you need to take into account:

  • VLAN-tagged frames may require either a dedicated switch or QinQ
  • bursts from multiple ingress ports may momentarily exceed the egress capacity
  • mirroring multiple ports may cause frame drops (check technical specs)
  • control/management frames for STP, LLDP, etc might not get copied to the monitor port

Possibly the easiest solution is multiple NICs or multi-port NICs. Make sure the platform has sufficient I/O capacity (=PCIe lanes) and processing capability.

If you consider a switch for aggregation then you could most likely go without the optical tap and use port mirroring exclusively. (I'd use an optical tap for fringe diagnostics only and port mirroring routinely.)

3
  • Thank you for your detailed response. My original plan is two use a dual port SFP+ network card and use two simplex fiber cables to connect the monitor port of the tap to the IDS server. I was just wondering why a hardware solution doesn't exist to aggregate the two tap outputs into a single input (essentially a hardware enabled bond interface)
    – user90006
    Jun 7 at 11:06
  • Hardware DOES exist, but it's an ACTIVE device. (see also: aggregating network taps) They are also very expensive.
    – Ricky
    Jun 7 at 11:48
  • Dang, that is unfortunate. I suppose a software solution is my only path. Thank you for your help
    – user90006
    Jun 7 at 20:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.