Parsing Error in Wireshark & sFlow Trend-Pro

[Ingmar Koecher]

We're trying to gather sFlow data from a Linux Ubuntu test machine (Linux xyz 4.4.0-109-generic #132-Ubuntu SMP Tue Jan 9 19:52:39 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux)) were we just installed Host-sFlow via the hsflowd-ubuntu16_2.0.11-1_amd64.deb package.

Our sFlow collector didn't show any data, so we fired up Wireshark to see if data is coming in. Wireshark showed incoming sFlow packets, but it's also reporting parsing errors including the following:

Malformed Packet: sFlow

Exception occurred

To make sure it's not an issue with our collector, I downloaded and installed the free sFlow Trend-Pro, which is also not displaying any incoming data (although the logs are quiet about any parsing errors). The configuration of the Host-sFlow is pretty basic (we're not familiar with that product yet) and pretty much just consists of the following lines:

sflow {
       polling = 5
       sampling = 400
     pcap { speed=1G-1T }
}

I'm pretty surprised that a standard setup would result in malformed packets - am I misunderstanding something basic? I tried removing the line about pcap with the same results.

[Ingmar Koecher]

I forgot to include a key line in the configuration file, it of course includes a collector (IP changed):

 collector { ip=172.26.112.28 udpport=6343 }

The sender only has one interface with one IP.

[Neil McKee]

Your config looks OK.

Not sure about the Wireshark decoder.  It was written some time ago and new structures have been added since.  It should skip over anything it doesn't recognize,  but maybe not.  For a more recent decoder that just prints the raw data I suggest you run it through sflowtool instead:

http://github.com/sflow/sflowtool

You can also do this to run hsflowd manually with debugging output to stdout/stderr:

sudo systemctl stop hsflowd

sudo hsflowd -ddd

For example,  to focus on the pcap module and make sure it is finding what it is looking for:

sudo hsflowd -ddd 2>&1 | grep -i pcap

If hsflowd does not pick up the NIC ifSpeed correctly then your current config will not enable any packet sampling.  You might try something like:

pcap { dev=eth0 }

as an alternative.

On the other hand, it may be finding a 10G interface and using the default 1-in-10000 sampling-rate.  To override that you need this in the config:

sampling.10G = 400

The "sampling = 400" setting that you have at the moment will only be used as a fallback -- e.g. for interfaces that have no ifSpeed.

Hope this is clear.  Let me know what you find.

Regards,

Neil

------
Neil McKee
InMon Corp.
http://www.inmon.com

--
You received this message because you are subscribed to the Google Groups "Host-sFlow" group.
To unsubscribe from this group and stop receiving emails from it, send an email to host-sflow+unsubscribe@googlegroups.com.
To post to this group, send email to host-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/host-sflow/d6b65475-f5b0-4ac5-a0e7-4f563d6c1ee5%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Ingmar Koecher]

Thanks for the pointer to the sflowtool. I had to make a few changes so that it compiled on Windows, but it does print the incoming data. Of course that doesn't help me since that is the only tool that can interpret it, but it's a start. It looks like the remote sFlow sender is transmitting a lot of data - including things like CPU usage, memory usage, disk space and so forth (I had literally no idea that sFlow could be used for that), which I'm suspecting is throwing off our parser. Is there a way to have the sFlow agent on the Linux box only send network-related data, much like a switch or firewall would?

I commented out the lines for the sampling rate for the other interface speeds, thanks for clarifying that.

I'm not sure what the pcap directive is good for though - what is the purpose behind that?

I think at this point we need to look into why our parser is not accepting the data unless the sender can be configured to only send the bare minimum ....

Thanks for the quick reply!

On Tuesday, March 6, 2018 at 8:33:25 PM UTC-6, Neil McKee wrote:

Your config looks OK.

Not sure about the Wireshark decoder.  It was written some time ago and new structures have been added since.  It should skip over anything it doesn't recognize,  but maybe not.  For a more recent decoder that just prints the raw data I suggest you run it through sflowtool instead:

http://github.com/sflow/sflowtool

You can also do this to run hsflowd manually with debugging output to stdout/stderr:

sudo systemctl stop hsflowd

sudo hsflowd -ddd

For example,  to focus on the pcap module and make sure it is finding what it is looking for:

sudo hsflowd -ddd 2>&1 | grep -i pcap

If hsflowd does not pick up the NIC ifSpeed correctly then your current config will not enable any packet sampling.  You might try something like:

pcap { dev=eth0 }

as an alternative.

On the other hand, it may be finding a 10G interface and using the default 1-in-10000 sampling-rate.  To override that you need this in the config:

sampling.10G = 400

The "sampling = 400" setting that you have at the moment will only be used as a fallback -- e.g. for interfaces that have no ifSpeed.

Hope this is clear.  Let me know what you find.

Regards,

Neil

------
Neil McKee
InMon Corp.
http://www.inmon.com

[Neil McKee]

You can't turn off the CPU/mem etc. stats (they are important for switches too!),  but an sFlow parser should be able to skip over them.  It's all TLV.

The pcap{} section is one of several ways to get packet-samples from the kernel (others being ovs{} nflog{} and ulog{}). That triggers the "switch-like" behavior of reporting traffic samples and counters for each interface.  If you get that working,  and generate some traffic,  then you should see traffic graphs in sFlowTrend.

An easy way to generate steady traffic on Linux is to do this:

ping -i 0.01 <remoteIP>

If this still doesn't work, then please send the output from "hsflowd -ddd 2>&1 | grep -i pcap".

More general comment:  the sFlow data feed is very "raw",  so just asciifying it with Wireshark or sflowtool is not likely to get you very far.  Collectors more like sFlowTrend that understand how to scale,  deduplicate, store and present the data correctly for the whole network are recommended.

------
Neil McKee
InMon Corp.
http://www.inmon.com

--

You received this message because you are subscribed to the Google Groups "Host-sFlow" group.
To unsubscribe from this group and stop receiving emails from it, send an email to host-sflow+unsubscribe@googlegroups.com.
To post to this group, send email to host-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/host-sflow/580be863-d76d-4601-99a5-e06f79830f80%40googlegroups.com.