First attempt to upgrade to 3: Multiple interfaces

Welp...out of luck so far:

/opt/zeek/bin/zeek -C -i eth0 -i eth1 --filter '<redacted>' local "Site::local_nets += { 192.168.1.0/24 }"

gets me:

ERROR: Only a single interface option (-i) is allowed.

I didn't have this issue with 2. Any reason why only one interface is allowed now? Unless something radical has changed with the resources that zeekctl uses I have no desire to use it. I'm dead in the water with Zeek as of now. Thank you.

James

If you don’t really need the latest and greatest cutting edge changes to 3.1, version 3.0.x still supports multiple interfaces. That feature was removed in 3.1 due to the wide changes to the IO Loop architecture, and you’re honestly the first user I’ve heard from that has noticed it missing. It was removed to make that work easier to accomplish, but we can certainly investigate bringing it back if there’s enough of a use case for it.

Tim

If you don’t really need the latest and greatest cutting edge changes to 3.1, version 3.0.x still supports multiple interfaces. That feature was removed in 3.1 due to the wide changes to the IO Loop architecture, and you’re honestly the first user I’ve heard from that has noticed it missing. It was removed to make that work easier to accomplish, but we can certainly investigate bringing it back if there’s enough of a use case for it.

Another option, I think would be to bond/bridge the interfaces and listen on that. If that would work for you,

-s

Appreciate the responses. These interfaces are an external on the internet, and an internal with a localnet (this devices is classified as router), so bonding them isn't an option. The only reason I'm running in this manner as apposed to just letting zeekctl handle it all is the process count and memory usage. I guess I'll test out zeekctl and see where I sit....might have to fallback to 3.0. Thank you.

James

All,

I’m please to report that using zeekctl method of running is so far working well…resource usage is so far manageable. Thanks for the assistance.

James

From what you’re describing, you’re running Zeek on a resource constraints device.

You might want to actually use the newest version - not sure where Justin fixes for the packet processing loop went in, but they should help a lot.

There are also some scripts to avoid, like the scan.zeek one and basically anything using SumStats. These can eat a lot of memory.

BTW kill all unnecessary processes. I can take a look if you send a process tree.

Good luck!

Oh hah, I don’t need any credit for all of that work. I had an old patch against 2.4/5/6 that would relax the polling loop interval so it wouldn’t eat up a lot of cpu on smaller devices, but it wasn’t a fix. Tim completely rewrote the IO loop so now zeek on a raspberry pi should use 0% cpu when there’s no traffic.

Thanks again...resources look great:

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
11360 root 20 0 830360 258148 151156 S 0.3 3.2 7:42.42 zeek
11362 root 20 0 827852 254540 150568 S 0.3 3.2 10:19.57 zeek

Also pleased to note that the trickle of traffic cpu usage has been fixed so thumbs up to that.

James

Please bring back the multiple interface option. I have two Gigamon’s (each has a 10 G interface ) Feeding Zeek on our IDS.

Or else Zeek is a No Go for me as well.

Yes… I need the multiple interface option !

Thank you,

Hi Don,

just to pull over the questions from Slack here:

could you please detail a little bit how you are currently running Zeek.

Since it sounds like you are handling a lot of traffic - you typically should already have to run zeek in cluster mode using zeekctl/broctl. At which point this problem does not apply anymore - since in a cluster you can have a zeek process (or - typically - several zeek processes) for each interface.

If you are currently running a single standalone zeek process on several 10G interfaces - did you check your packet loss? Because it seems unlikely to me that this setup is not loosing a ton of traffic.

Thank you :slight_smile:
  Johanna

Btw, just for the record, before doing such breaking changes we tend
to ask here on mailing list for feedback. In this case, see here:
http://mailman.icsi.berkeley.edu/pipermail/zeek/2019-August/014484.html.
I don't think I heard any concerns in response to that.

Robin