This
Vnstat reads /proc/net/dev or netlink, 64-bit, no wrap in practical terms. Kernel dont lie, snmp poller lies by design at that interval
Contabo should be using 64-bit snmp but probably cheaped out on their monitoring stack
Member
Their switch counters are authoritative but their poller isn't
This is the whole thread in one sentence. I tell my WordPress people this all the time: the electricity meter on the pole is "authoritative" but if the guy reads it wrong every month, you're not paying the wrong number.
The contract says "our meter" but their meter is a software system with known failure modes. That's not the same as "the switch port never lies." The switch port never lies, the poller lying is routine.
I had a client on OVHcloud Gravelines with similar, their public cloud bandwidth meter was double-counting ingress as egress during live migrations. Took three tickets to get someone who understood what "live migration" meant. Got 4 months credit.
Fight it. The $90 is not the point.
Member
IPv4 is legacy. Legacy is bad.
Also legacy: 32-bit SNMP counters, RRDtool with 300s step, billing systems that don't understand counter wrap.
I run 10G at my Tokyo apartment with IIJ. They provide 64-bit counter graphs from their router, updated every 5 minutes but the underlying counters are 64-bit so wrap is not happening. The gap between "we poll every 5 minutes" and "our counters wrap" is a business decision, not physics.
Contabo has Tokyo and Singapore DCs now. Are they using the same broken poller there? Probably.
Member OP
1G plan, not 10G. So wrap should be less dramatic but still possible during bursts.
MRTG is running now. I also tcpdumped the SNMP traffic from their poller, they poll every 300s exactly, SNMP v2c, ifHighSpeed for rate but they're using ifHCInOctets/ifHCOutOctets which ARE 64-bit. So the counters themselves aren't wrapping.
But. Their CSV has negative values in some rows where the delta went backwards. They claim "our system accounts for this" but a negative delta in a rate calculation means either:
I didn't reboot except March 3. No firmware update. NIC counters didn't reset per vnstat.
Something is fishy in their math layer, not the counter itself.
ARM Enjoyer Ampere enjoyer. Watts are the real currency.
Your MRTG will help but also check if their poller IP changed mid-month. If they moved monitoring infrastructure, two systems with different counter baselines could produce exactly this: one starts where the other left off, but they merge the series wrong.
Worth asking in ticket: "did your monitoring system change in March?" Don't explain why. See if they volunteer it.
Adblock evangelist Block ads, save marriages
I did the RackNerd fight because their "accounting" was adding ingress+egress and calling it egress. My server was mostly download (updates, mirrors) and they billed me for upload that never happened. Their CSV had impossible symmetry, every 5-minute bucket was within 2% identical in/out. Real traffic isn't shaped like that.
Your negative deltas sound like a different bug but same category: math layer pretending to be measurement layer. Document everything, send the MRTG, and ask them to explain each negative row with the specific algorithm.
They won't be able to. That's the point.
Member
Tabs vs spaces started my divorce
I had similar with local Ukrainian provider, not worth naming. Their "accounting" was counting every packet twice because their mirror port was also in the bridge loop. Took me Wireshark of the mirror to prove it.
Your case sounds like bad math not double counting, but same principle: they built a system, it has bugs, they bill based on it, "authoritative" means "we don't want to look at this."
Kyiv to Nuremberg is decent latency, I use Contabo Nuremberg for some backup stuff. Cheap, you get what you pay for, but 30% overage on cheap base price is not cheap anymore.
Following for MRTG results.
SRE Wannabe I terraform therefore I am.
I terraform therefore I am.
Has anyone asked if this is actually a Contabo-specific problem vs standard industry practice? I use Hetzner for most things, their robot panel shows daily breakdowns from switch counters, and I've cross-checked with vnstat multiple times, always within 3-4%. That's measurement noise, not 30% systematic error.
Contabo's 300s with negative deltas is not standard. It's broken. "Standard SNMP polling with rrdtool defaults" like armstrongvds said would not produce negative values if configured correctly. RRDtool handles counter wrap explicitly with COUNTER type, and refuses to store negative rates unless you force it with DERIVE and allow-negative.
Somebody forced it. Somebody configured DERIVE without bounds. That's not default, that's a mistake.
This thread is why I pay for unmetered everything now. Life's too short.
That said, danfra, your MRTG experiment is the right move. Run it for a full billing cycle if you can, not just a week. You need statistical significance, not just "one week looked fine."
Also: are you sure your Pi mirror is seeing all packets? Port mirroring on cheap switches sometimes drops under load, or mirrors only one direction depending on config. Verify with a known large transfer and check both counters.
Not saying you're wrong, just saying your independent meter needs to be independently verified too. Trust but verify your verify.
Member OP
Good point on the mirror. The Pi is on a TP-Link TL-SG108E, mirror config is "both" directions. I'll do a controlled test: scp 100GB from another box, compare MRTG to vnstat to actual file size.
If they compute delta in Python or whatever and don't handle wrap, but also don't handle reset, you could get negatives from either. Then "our system accounts for this" might mean "we ignore negatives" or "we absolute-value them" — both wrong, both would explain overage.
I asked for raw counter values, not deltas. They said "we do not provide this information." Of course.
