search

zeek / zeek-af_packet-plugin

Plugin providing native AF_Packet support for Zeek.
Other
33 stars 30 forks source link

Un-hardcode frame-size, block-timeout and block-size #37

Closed awelzel closed 2 years ago

awelzel commented 2 years ago

(This compares with Suricata a lot and may read as if their config should be copied, but is mostly meant for contrasting - they do provide more knobs and don't hard-code things though)

Suricata supports configuration of the AF_PACKET block-size, ring-size and block-timeout. This plugin currently hard-codes the block_size to 4 * PAGE_SIZE = 16KB, and the timeout to 100msec.

When running Zeek and Suricata in parallel monitoring the same traffic, it might be beneficial to align these values. As Suricata high-performance docs [1] mention block sizes of 1MB as a good starting point, the 16KB used here should most likely become configurable (A block here only fits 8 or so packets with a 2KB frame size). The default for block-timeout for Suricata is 10msec, while this plugin hard-codes it to 100msec. This should also become configurable as with much large block sizes, there may be latency considerations involved.

The ring-size (tp_frame_nr) in this plugin is derived from the configurable buffer_size and also the hard-coded frame-size (2048). Suricata instead provides a ring-size (and also default-packet-size) and the resulting buffer size is computed. Minimally, this plugin should make the packet-size configurable. The comment that it has no effect seems a bit suspect, and it does influence the ring-size computation.

[1] https://suricata.readthedocs.io/en/suricata-6.0.2/performance/high-performance-config.html

J-Gras commented 2 years ago

I agree that we should expose the relevant parameters so that it is possible to adapt the ring layout without touching the code. Maybe even more important: The plugin should use the established default values for the ring layout (see also #20).

Minimally, this plugin should make the packet-size configurable.

I might be missing something important here, but my understanding is that TPACKET_V3 implements variable length frame sizes. Thus, the packet size would actually be the one thing we don't need to put any thought in, unless it is importnat to allow truncating packets at a certain cap len.

awelzel commented 2 years ago

I might be missing something important here, but my understanding is that TPACKET_V3 implements variable length frame sizes. Thus, the packet size would actually be the one thing we don't need to put any thought in, unless it is importnat to allow truncating packets at a certain cap len.

Ah, thanks - I had no clue. I'm even confused now if it acts in anyway like a snaplen. The current 2K may be a bit on the low side, but if it had any effect someone would've probably complained.

EDIT: Okay, so the block-size is essentially the max frame size for TPACKET_V3 and frame_size doesn't seem relevant.

https://github.com/torvalds/linux/blob/0066f1b0e27556381402db3ff31f85d2a2265858/net/packet/af_packet.c#L640

https://github.com/torvalds/linux/blob/0066f1b0e27556381402db3ff31f85d2a2265858/net/packet/af_packet.c#L625