hsflowd and mod_tcp using docker

[Iulisloi Zacarias]

Hi All,

First of all, thanks for the amazing software.
I have a question regarding host-sflow (https://sflow.net/). I am not sure whether this is the right place to ask...

I am using mininet and containernet to perform some experiments. What I really want is the tcp_info data (like tcprtt).

I have tried multiple setups

- running hsflowd inside the docker container

- running hsflowd in the host machine and monitoring the docker0 interface

- running hsflowd in the mininet emulated host

It looks like none of the previous setups worked out. I am using hsflowd version 2.1.08 and I compiled it with FEATURES="NFLOG PCAP DOCKER OVS TCP"

Here is the configuration file that I am using

sflow{
  collector { ip = 127.0.0.1 }
  pcap { dev=docker0 }
  tcp { }
  ovs { }
}

(I am checking the data received with sflowtool). I actually can see data coming from mininet or local machine)

Any idea why I cannot get tcp_info data?

Thank you in advance

Iuli

[neil....@inmon.com]

I suggest you bring this up on the host-sflow discussion group,  or as an issue on the host-sflow github project.  As you guessed, it's not really an sFlow-RT question :)

But here is a short answer anyway:

Unfortunately the Docker networking SNAT/DNAT steps that may be hidden from hsflowd behind a MASQUERADE firewall rule can make it difficult (or impractical, or inefficient) to figure out what key mod_tcp should use to look up the INET_DIAG netlink table.  Even when you sample packets at the docker bridge ports as you have done here.  You can use the ss(1) command within the container or at the host networking level to see what the keys in the kernel table actually are, but there is a  good chance that one or both of the layer-4 ports are not easily knowable from the perspective of mod_tcp. This article might help to explain why:

https://argus-sec.com/blog/engineering-blog/docker-networking-behind-the-scenes/