sysctl namespace support

[unicell]

Currently the sysctl interface ipt-netflow exposes has no namespace support.

Symptom:

1. start docker container and set sysctl -w net.netflow.destination=127.0.0.1:9995 in container's namespace

Expected:

1. above setting can not be seen from host namespace
2. Netflow generated inside container's namespace should be reaching collector also running inside container network namespace

Actual:

1. sysctl net.netflow from docker host namespace also shows net.netflow.destination=127.0.0.1:9995
2. Netflow generated from inside container's namespace actually hitting collector in host namespace

[aabc]

1. Yes, ipt-netflow does not support namespaces. But unrelated to that your assumptions are wrong too.
2. "Netflow generated inside container's namespace should be reaching collector also running inside container network namespace" -- There is no logical relation between iptables rule being in namespace and exports configured via net.netflow.destination, because you configure net.netflow.destination option on the host, so it is expected be exported on the host, not in namespace.
3. To be exported in namespace there should be namespace dependent net.netflow.destination option. But, this also would create ambiguity in it's meaning, for example, if net.netflow.destination is inherited from the host, where should it be exported? 50% of people will think 'in namespace', 50% will think 'on the host' (because it was originally set on the host). To resolve this ambiguity ipt-netflow module should be initially unconfigured in new namespace, so user forced to set net.netflow.destination separately (which will be also not handy). But another 50% of users will assume net.netflow.destination to be inherited, and not expect, but have namespaced traffic to be lost.

So, besides it being not supported, there's also many points of view on how it should be.

[unicell]

Agree. The ability to have per namespace net.netflow.destination setting is the main thing I need. Regarding what should be the default value in namespace (inherited from host namespace, or not) is relatively trivial, as long as it gives option to override (at namespace level).

[aabc]

Would not you ruin Docker model if you run netflow in the same container as application? And also netflow collector in the same container?

[unicell]

I don't see why it is ruining Docker model. The idea of container is I can deploy and run everything inside an isolated sandbox. In my case, Netflow is the application, both exporter (ipt-netflow module) and collector count.

They don't necessarily run from the same container. For example, my planned deployment is based on Kubernetes, which allows me to put multiple sidecar containers inside a single Pod. In which all containers will be sharing the network namespace. So netflow collector runs from a container, my main application in another.

Whatever happening inside the container(s) should not be touching / changing host environment in any sense, that's why I think namespace support is a major gap.

[vel21ripn]

I have a version of ipt_netflow with netns support. But it is very different from the official version (1598 insertions(+), 1625 deletions(-)). Completely removed support for kernels up to 3.4. NAT support is completely rewritten. The code has so far been tested only on the kernel 4.11. The assembly was tested with the versions of the kernels 3.4.113, 3.10.107, 3.14.45, 3.18.44, 4.4.73, 4.9.33, 4.12.0 (from kernel.org)

[aabc]

@vel21ripn Thanks for developing project!

[unicell]

@vel21ripn Awesome! Is that the one in your fork's netns branch?

[vel21ripn]

@unicell netns removed. netns-v1 - first working branch. I'm only using version 5. I did not test the work of versions 9 and IPFIX. The minimum requirements for the kernel have changed (see README). Only in kernel 3.10 is it possible to handle events about changing the state of the interface, and without it you can not implement the destruction of netns.