Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am setting up a network monitoring system on RedHat 6 that will be receiving the packet feed from an inline tap. One of the functions of this device will be running Snort. Putting two NICs in the system for the tap is no problem, however since each instance of snortd can only operate on a single interface, monitoring the two interfaces separately will break a lot of the stream reassembly and flow tracking.

Since these NICs are receive only, is bonding the right way to aggregate these interfaces? The documentation almost seems to imply to me that, since I couldn't care less about transmitting packets, any mode will do what I need. Is this a valid assumption? Are there any oddities that I would need to watch out for if I do use bonding for this?

share|improve this question
up vote 4 down vote accepted

Caveat: I've never configured such a beast in practice.

What you're proposing should be fine -- as long as the bonded interface is receive only any bonding mode that allows you to receive on both interfaces will do what you want.
I would suggest balance-xor or balance-rr simply because you don't need to assign an IP (you'll be listening in promiscuous mode to every packet) and you won't be transmitting so the potential downsides of Round-Robin or XOR balancing won't affect you, and the benefits of any other method are meaningless.

There are a few bonding modes I'd avoid for this implementation:

  • Mode 1 (active-backup)
    This mode places one NIC in a "standby" mode. You need to use a bonding mode where both NICs are "active" (or at least receiving packets) for what you're trying to do.

  • Mode 3 (broadcast -- Everything transmitted goes out every interface)
    Even though a proper tap won't let you put data onto the network you're monitoring it's better to be safe than sorry. This mode can really mess with your day if one of the interfaces gets connected to something that will accept packets.

  • Mode 4 (802.3ad Link Aggregation)
    Since this requires a switch that understands 802.3ad link aggregation, and you're plugging in to a tap, this probably won't work properly.

An alternate option would be to use something like the Netgraph system (the one2many module is the best candidate) to construct a virtual interface that reassembles the traffic (and ultimately sends it out to a black hole, with your IDS listening in at the output end). This would be a more viable solution on the BSD family of operating systems, though there are Netgraph implementations available for Linux.

share|improve this answer
Your recommendations pretty well match my interpretations of the docs so I'm going to assume you're correct. :) – Scott Pack Aug 17 '12 at 0:12

You are correct that nearly any mode will do.

If you were not using a tap, then the important configuration would be in your network switch. You would have to pick a load balancing option that would split as evenly as possible the load between your 2 nics. Per packet round robin should result in the best split but most switches don't support that. Next best option would be IP if the hosts your are monitoring are mostly on a different subnet, or mac address if they are mostly on the same subnet.

Since you are using a tap, no additional configuration should be needed other than bonding the nics.

share|improve this answer
The switch configuration doesn't matter since, as stated in the question, the feeds are coming off a passive tap. The way those things work is that is placed in-band of a link. Then the RX pins of the input are connected to the TX pins of one of the TAP outputs, then the TX pins of the input are connected to the TX pins of the second TAP output. – Scott Pack Aug 16 '12 at 19:22
Ha, you're right. I completely skipped right over that part! I will update my answer. – longneck Aug 16 '12 at 19:23

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.