Taps and Hubs, Part Deux

Yesterday I described why the scenario depicted above does not work. Notice, however, that the hub in the figure is an EN104TP 10 Mbps hub. Sensors plugged into the hub see erratic traffic.

If that 10 Mbps hub is replaced with a 10/100 Mbps hub, like the DS108, however, the situation changes.

With a 100 Mbps hub, each sensor can see traffic without any problems. Apparently the original issue involved the 10 Mbps hub not handling traffic from the single interface of the port aggregator tap, which must have operated at 100 Mbps and failed to autonegotiate to 10 Mbps properly.

We also previously explained why the next setup is a terrible idea:

In a very helpful comment to the last post, Joshua suggested the following setup:

This arrangement takes the output of a traditional two output tap and sends each output to a separate 100 Mbps hub. Sensors can then connect one output from each of their two sniffing interfaces to each hub. The sensor must take care of bonding the traffic on its two interfaces. This arranagement is novel because it allows more than one sensor to receive tap output. In the situation depicted, up to seven sensors could receive tap output.

So what is the bottom line? It remains true that hubs can never be used to combine the outputs of a traditional two output tap into a "single interface". However, it is possible to use them in the arrangements depicted in this post.


Stephen Reese said…
Any idea how to build a port aggregator tap?
You could create a bonded interface like bridge0 our of two physical interfaces, and then use Pf or Daemonlogger to send the output a third interface.
Anonymous said…
This comment has been removed by a blog administrator.

Popular posts from this blog

Five Reasons I Want China Running Its Own Software

Cybersecurity Domains Mind Map

A Brief History of the Internet in Northern Virginia