4 ms·

We've developed packet BRICKS for this: https://github.com/bro/packet-bricks https://github.com/bro/packet-bricks Packet BRICKS is a Linux/FreeBSD daemon that

by mavam 11y ago

We've developed packet BRICKS for this: https://github.com/bro/packet-bricks https://github.com/bro/packet-bricks Packet BRICKS is a Linux/FreeBSD daemon that is capable of receiving and distributing ingress traffic to userland applications. Its main responsibilities may include (i) load-balancing, (ii) duplicating and/or (iii) filtering ingress traffic across all registered applications. The distribution is flow-aware (i.e. packets of one connection will always end up in the same application). At the moment, packet-bricks uses netmap packet I/O framework for receiving packets. It employs netmap pipes to forward packets to end host applications. (Credit goes to Asim Jamshed, who pulled this off as part of an internship at ICSI.)

tinco 11y ago
So is the advantage that it's more performant than iptables+virtual interfaces? If I use iptables to distribute traffic over virtual interfaces do IP headers get parsed twice by the kernel in some inefficient way?
- mavam 11y ago
  Iptables sits in the kernel and is also not available on non-Linux platforms like FreeBSD. With packet bricks you bypass the kernel and expose "virtual" interfaces to your applications by means of a simple configuration. Here's an example from the README: bricks> lb = Brick.new("LoadBalancer", 2) bricks> lb:connect_input("eth3") bricks> lb:connect_output("eth3{0", "eth3{1", "eth3{2", "eth3{3", "eth2") bricks> pe:link(lb) This binds pkteng pe with LoadBalancer brick and asks the system to read ingress packets from eth3 and split them flow-wise based on the 2-tuple (src & dst IP addresses) metadata of the packet header. The "lb:connect_output(...)" command creates four netmap-specific pipes named "netmap:eth3{x" where 0 <= x < 4 and an egress interface named "eth2". The traffic is evenly split between all five channels based on the 2 tuple header as previously mentioned. Userland applications can now use packet-bricks to get their fair share of ingress traffic. The brick is finally linked with the packet engine.
  - eikenberry 11y ago
    So the goals of packet bricks are portability and ease of configuration, not performance gains?
    - mavam 11y ago
      The goal is to have both. In fact, the whole point of kernel bypass is performance, so just having ease of configuration would defeat the point. We're using packet bricks primarily for high-performance network monitoring in environments with more than 10 Gbps aggregate upstream traffic.
technion 11y ago
Incredibly interesting project. Are you aware of any experiences using this with nginx or HAProxy on the load balancing side and the impact it may have had?

by mavam 11y ago

tinco 11y ago

So is the advantage that it's more performant than iptables+virtual interfaces? If I use iptables to distribute traffic over virtual interfaces do IP headers get parsed twice by the kernel in some inefficient way?

mavam 11y ago
Iptables sits in the kernel and is also not available on non-Linux platforms like FreeBSD. With packet bricks you bypass the kernel and expose "virtual" interfaces to your applications by means of a simple configuration. Here's an example from the README: bricks> lb = Brick.new("LoadBalancer", 2) bricks> lb:connect_input("eth3") bricks> lb:connect_output("eth3{0", "eth3{1", "eth3{2", "eth3{3", "eth2") bricks> pe:link(lb) This binds pkteng pe with LoadBalancer brick and asks the system to read ingress packets from eth3 and split them flow-wise based on the 2-tuple (src & dst IP addresses) metadata of the packet header. The "lb:connect_output(...)" command creates four netmap-specific pipes named "netmap:eth3{x" where 0 <= x < 4 and an egress interface named "eth2". The traffic is evenly split between all five channels based on the 2 tuple header as previously mentioned. Userland applications can now use packet-bricks to get their fair share of ingress traffic. The brick is finally linked with the packet engine.
- eikenberry 11y ago
  So the goals of packet bricks are portability and ease of configuration, not performance gains?
  - mavam 11y ago
    The goal is to have both. In fact, the whole point of kernel bypass is performance, so just having ease of configuration would defeat the point. We're using packet bricks primarily for high-performance network monitoring in environments with more than 10 Gbps aggregate upstream traffic.

technion 11y ago

Incredibly interesting project. Are you aware of any experiences using this with nginx or HAProxy on the load balancing side and the impact it may have had?