# sFlow data underreporting dramatically in Kibana/ElastiFlow compared to real traffic **URL:** \ **Category:** ElastiFlow Community\ **Created:** [May 20, 2026, 2:32pm UTC](https://forum.elastiflow.com/t/sflow-data-underreporting-dramatically-in-kibana-elastiflow-compared-to-real-traffic/393 "2026-05-20T14:32:15Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![nicolassteel](https://avatars.discourse-cdn.com/v4/letter/n/7ab992/32.png) [@nicolassteel](https://forum.elastiflow.com/u/nicolassteel)\ **Post date:** [May 20, 2026, 2:32pm UTC](https://forum.elastiflow.com/t/sflow-data-underreporting-dramatically-in-kibana-elastiflow-compared-to-real-traffic/393/1 "2026-05-20T14:32:16Z")
Hi everyone, I am facing a massive data discrepancy issue in my ElastiFlow/Kibana setup (running on AlmaLinux) regarding sFlow data from my Extreme Networks VOSS / Fabric Engine switches. **The Problem:** When performing a large file transfer (approx. **6.24 GB** via Windows SMB) from a File Server to a Client PC, Windows consistently shows a transfer rate of **102 MB/s** (utilizing the full 1G link). The transfer completes in just over a minute. However, looking at the ElastiFlow Dashboards (specifically the “Top Talkers” and “Flows” Sankey charts) during that exact time window (filtered down to the “Last 15 minutes”), the total volume for this client/server connection caps out stubbornly at **1.4 GB**. The Linux server running the ElastiFlow collector 7.20 shows **0 packet receive errors** and **0 receive buffer errors** via `netstat -su`, meaning the OS is not dropping any incoming sFlow UDP packets. Furthermore, checking `show qos cosq-stats cpu-port` on the edge switch confirms **0 active packet drops** on the CPU queues during the transfer. **My Switch Configuration (Extreme VOSS):** - **Edge Switch (1G Client Ports):** - **Core Switch (25G Server Ports):** Has anyone experienced this specific behavior where sFlow traffic gets scaled down or capped at a specific fraction (1.4 GB instead of 6.24 GB) in ElastiFlow? Any help or guidance on how to troubleshoot this would be highly appreciated. Thanks in advance! ---
**Author:** ![daniel.harada](https://avatars.discourse-cdn.com/v4/letter/d/d6d6ee/32.png) [@daniel.harada](https://forum.elastiflow.com/u/daniel.harada)\ **Post date:** [May 20, 2026, 4:53pm UTC](https://forum.elastiflow.com/t/sflow-data-underreporting-dramatically-in-kibana-elastiflow-compared-to-real-traffic/393/2 "2026-05-20T16:53:21Z")
Do you see lower than expected sizes across all devices, or is it limited to specific devices / device types? I would recommend checking the following: 1. In the Flow Records dashboard, filter to your impacted device, and then expand one of the flow records. Verify if any sample rate fields are being populated with the correct sample rate. In the Table view of the data you can search for fields 2. Check your configurations to see if the sample rate is being overwritten with a custom rate: [Sample Rate Adjustments | ElastiFlow Documentation](https://docs.elastiflow.com/flowcoll/configuration/flow-processing/sampling) 3. Verify if the packet counts seem accurate compared to the device packet counts or packets/s ---
**Author:** ![nicolassteel](https://avatars.discourse-cdn.com/v4/letter/n/7ab992/32.png) [@nicolassteel](https://forum.elastiflow.com/u/nicolassteel)\ **Post date:** [May 21, 2026, 11:59am UTC](https://forum.elastiflow.com/t/sflow-data-underreporting-dramatically-in-kibana-elastiflow-compared-to-real-traffic/393/3 "2026-05-21T11:59:52Z")
Hi Daniel, Thank you for the recommendations. Here are the step-by-step verification results based on your questions: **1. Scope of the Issue** The issue is **not** limited to a specific device, but rather affects the entire traffic path. Both the Edge switch (1G client ports) and the Core switches (25G server ports) show underreported traffic volumes inside the dashboards, sticking around the same ~1.4 GB mark for a 6.24 GB transfer. **2. Sample Rate Verification in Flow Records & Custom Config** I checked the `Flow Records` dashboard, expanded the raw documents, and verified the configurations: - **The** flow.in.packets **field:** In my ElastiFlow version shows a 1,024 value which is in my case correct. - **Custom Configuration:** To rule out any detection issues, I explicitly enabled the user-defined sample rate enrichment in `flowcoll.yaml`: ---
**Author:** ![daniel.harada](https://avatars.discourse-cdn.com/v4/letter/d/d6d6ee/32.png) [@daniel.harada](https://forum.elastiflow.com/u/daniel.harada)\ **Post date:** [May 21, 2026, 9:11pm UTC](https://forum.elastiflow.com/t/sflow-data-underreporting-dramatically-in-kibana-elastiflow-compared-to-real-traffic/393/4 "2026-05-21T21:11:23Z")
So the `flow.in.packets` field should be the total number of packets that that sflow record has details for, scaled by the sampling rate. The sampling rate should be shown in `flow.meter.packet_select.interval.packets`. To get the total number of bytes from the sflow records we’re using the frame length, which can get truncated. This [documentation](https://documentation.extremenetworks.com/VOSS/SW/86/VOSSUserGuide/GUID-B663788E-DE3F-4CD4-93E7-97AA9F663521.shtml) indicates that the default maximum header size is 128 bytes, which could result in truncated packets and inaccurate bytes counts. Can you try bumping this up to 256 bytes to see if your total reported byte size changes? ---
**Author:** ![system](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.elastiflow.com/system/32/59_2.png) [@system](https://forum.elastiflow.com/u/system)\ **Post date:** [June 26, 2026, 3:49pm UTC](https://forum.elastiflow.com/t/sflow-data-underreporting-dramatically-in-kibana-elastiflow-compared-to-real-traffic/393/6 "2026-06-26T15:49:22Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.