Network tap issues

Hi all,

I have Bro 2.5 configured on a RHEL 7.3 server and have a network tap question, which I know isn’t totally Bro related, but I figured the Bro community would be able to advise. The tap I have is a passive fiber tap (OM3/4, 850mm, 50/50) enabled for up to 10Gb throughput. The connection in port A is coming from Level 3 internet and the connection in port B is going to a network switch. The monitor port is connected to my Bro server. The problem is that I am seeing no traffic at all coming from the monitor, and the light on the server NIC doesn’t even light up. However, I am still able to access the internet from my server, despite receiving no traffic from the monitor. Basically the connection from A to B works, but the monitor is not mirroring traffic. We have tested the tap before in other areas of our network, and it was working, so I’m not sure why it is not working in this location. Any and all help is appreciated!

Thank you,

Dan Manzo

Thanks for the response! Unfortunately, we have tried that, but still no luck. I’m not sure what else could be wrong.

I'm confused on what you mean by "the monitor port". A passive fiber tap has two rx/tx input ports and two tx only output ports, one for each direction.

The two outputs need to be connected to the rx ports on two separate NICs, you can't just connect them to a single nic, as you'd be connecting one of the tx ports from the tap to a tx port on the NIC.

Sorry for the confusion, I am referring to the two TX output ports as a duplex "monitor" port. We have a duplex cable going from the two TX output ports to the NIC, so perhaps we can split the cable and plug each individual fiber into its own SFP. However, shouldn't I be seeing some sort of traffic on the NIC? Since both fibers of the duplex are transmitting, either one of them has to be in the rx port on the NIC, so I would then be seeing some packets, correct? If you think splitting the duplex cable from the TX output ports would fix the problem, then I will do so.

I’ve dealt with this before although I don’t really understand it technically. Some sort of layer1-ish protocol… the only way I can explain it is something like Cisco’s UDLD… the NIC detects a fault in the circuit due to a half connected state and shuts down the laser/LED for safety reasons.

You might find some obscure low-level setting for the NIC to force it into a special monitor mode similar to how wifi monitor mode works.

What happens if you force the interface up and run tcpdump ?

Based on what I’ve seen, I think you might be right about the NIC detecting a fault due to a half connected state. I forced the interface up and put it in “promiscuous” mode, then ran tcp dump. Unfortunately, it reported back with no packets captured L

Seems your options are buy a dedicated capture card like Myricom or hack the driver.

Seems your options are buy a dedicated capture card like Myricom or hack
the driver.

Or run the tap connections to a 10G switch that can do magic tap
aggregation like SPAN.

Hi Mark,

As others have mentioned, the connection from the output of your tap to the
capture nic needs some attention. Unlike a switch port, both sides of the
duplex output port are outputs (light comes out). If you plug this into a
nic with a duplex fiber, you'll blast light into the internet <-> switch
link, which is definitely not going to do you any favors.

You'll have to split the capture side of the fiber pair, and plug the
single fiber into the RX port on the. For now, leave the other end
dangling until you decide how to aggregate the two; this is just for testing.

A reminder to never look into the end of a fiber, or into a port, even if
you think it's off or shut down. You can do some permanent damage to your
retinas, especially with LR optics, which use an invisible laser. Been
there, done that, still got the scarring. These days, I use the camera on
my cell phone, which has no direct optical path to the screen, plus it
picks up near infra-red wavelengths, used in LR optics. Not that I suggest
using this technique; the proper tool for light-path diagnostics is a light

With that in mind, do the optics in the capture nic match the optics in the
switch behind the tap? In most cases, an SR optic won't respond to LR
light and vice-versa. The link led will come on if the interface is up
(ifconfig up) and the RX side receives properly-coded light of sufficient
brightness. Thus, assuming the interface is up and the light-path is
otherwise good, you might have a mismatch, or a bad optic in the capture nic.

Good luck!