Allow setting observation domain ID based on local hostname

[bc-davidb]

I have a use-case where a collector is getting flows from multiple exporters, but isn't able to use the source IP address to distinguish between exporters.

Inside ipt_NETFLOW.c, engine_id is a static int set to 0 (and never changed), which is then used to set Engine ID (v5), Source ID (v9) and Observation Domain ID (IPFIX).

This PR adds the option --enable-source-id-from-hostname at build time, which sets engine_id to a hash of the system hostname during module init. It also masks engine_id to 8 bits when sending out a v5 PDU because of the smaller allocated space.

There should be no effect if the option isn't enabled at compile time.

[aabc]

Thanks. Interesting idea, never thought anybody need engine id, but, it seems your patch is for v5 only, also, too long option, and I think, it's should be possible to set engine id manually, because your hash is prone to birthday paradox, maybe, we should abandon hash idea altogether, also, there should be support for v9/ipfix (but, I remember there is some complicacy in ipfix treatment of non-zero Observation Domain, not accidentally I choose number 0, instead of 1, for example).

I will think about it, a bit later.

[bc-davidb]

It's actually working fine for v9/IPFix as the engine_id variable is being used to populate v9 source ID and IPFix observationDomainID (I'm using v9 at the moment)

I see what you mean with hash collisions though (especially with v5 which is only 8 bits not 32). It would probably be better to just be able to set the value through a module option/sysctl if needed.

[aabc]

It's actually working fine for v9/IPFix as the engine_id variable is being used to populate v9 source ID and IPFix observationDomainID (I'm using v9 at the moment)

Ah, you are right!

[aabc]

fc4f5f3

I didn't (quickly) found in RFCs any side effects of non-zero observationDomainID (which I vaguely remember it should have).

Thanks!

[bc-davidb]

Thanks!