Bandwidth overage dispute, their meter vs my meter differs 30%

Contabo claims 24TB outbound for March. My vnstat shows 18.2TB. That's 6TB difference, and they're billing $90 overage.

My setup:

• Single Debian 12 box, bridge interface
• vnstat on eth0, rebooted once on March 3
• No other interfaces active
• No Docker, no VMs, bare metal

Contabo's response: "our switch port counters are authoritative." They sent a CSV of 5-minute samples. Summing their numbers gives 24TB. But their sampling is 300-second intervals, and I see negative values in some rows where counter wrapped.

I asked about counter wrap handling. They said "our system accounts for this." No details.

My vnstat database shows no wraps, clean increment. I've run vnstat for 4 years on multiple boxes, never seen 30% error.

What measurement methodology do providers typically use for billing? Is 300-second polling standard? Should I be running independent MRTG or similar as evidence?

Not paying $90 on principle if their meter is broken.

Insane value that you're fighting this!

But honestly their meter is probably just standard SNMP polling with rrdtool defaults. 300s is standard, yes. The counter wrap bug is real though, especially on 32-bit SNMP counters at 1Gbps+

What NIC do you have? Some Intel cards have known counter issues where they reset on certain power states. Not saying that's it, but could explain a gap if vnstat missed it

If it were me I'd set up independent MRTG with 64-bit counters and log everything. Runs circles around "trust the provider" as a strategy

The real issue is theyre billing on sampled data not actual bytes

Vnstat reads kernel counters direct, kernel dont lie

Their snmp poller probably drops packets or misses wraps, 300s is way too long for 10g anyway

You figure it out, run yr own mrtg and make them explain every discrepency

I had same thing with OVHcloud once, 40% differnce, turned out their aggregation server was double counting during maint windows

Never got the money back tho

Dear/madam,

I am suggesting kindly to install independent monitoring itself. The MRTG or Cacti will provide evidence only. The provider's meter is authoritative in contract terms only, but your own data is necessary for dispute.

I have faced similar issue with Vultr only — https://www.vultr.com. Their meter showed 22TB, my vnstat showed 19TB. I raised ticket with MRTG logs attached. They adjusted billing after review.

The 30% difference is significant. Kindly do not pay without evidence from your side. Your time is worth more than $90, but principle itself is important.

Regards,

Just pay it, your time is worth more

NO WAIT

Actually fight it on principle, 30% is theft with extra steps

Set up MRTG on a separate box sniffing the same port if you can, or mirror the switch port at your rack if you have access

Their 300s sampling is probably missing bursts and their wrap math is WRONG

Document everything, send them graphs, escalate to billing manager

I did this with RackNerd once, took 6 weeks but got $140 back and they "fixed" their poller (probably just stopped double counting lol)

What NIC model is it, Intel i340?

Their switch counters are authoritative but their poller isn't

Which kernel version, 6.1 or backports?

It's an Intel X710, not i340. Kernel is 6.1.0-18-amd64 from Debian 12 backports.

I set up MRTG on a spare Pi 4 last night, SNMP v2c 64-bit counters polling every 60s. Will run parallel for a week and see. The Pi is on a dedicated switch port mirroring eth0, so completely independent path.

Still annoyed they won't explain the wrap math. "Our system accounts for this" is not an algorithm.

X710, good card. The counter reset on EEE is firmware-bound like you said, 23.x should be fine.

More interesting: are you on 10G or 1G with Contabo? Their dedicated line is usually 1G unmetered or 10G with overage, but the 10G plans are newer. If you're on 10G, 32-bit SNMP wraps every ~3.4 seconds at line rate. At 300s sampling that's guaranteed multiple wraps during any burst. Their "accounting" would need to be perfect.

vnstat uses 64-bit kernel counters direct, so it doesn't care about wrap frequency. That's your 30% right there probably.