Home / server / Questions / 418355
Accepted
Scott Pack
Asked: 2012-08-17 11:13:42 +0800 CST

Aggregating NICs for receive only connections on Linux

  • 772

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?

linux

2 Answers

  1. 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.

    • 5
  2. Best Answer

    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.

    • 4