Just migrated our edge to a Quantum appliance. The built-in bandwidth monitor is off by a factor of two. Again.
Dashboard shows 800Mbps sustained, but:
* Netflow from our core switch: 1.6Gbps
* `iftop` on the box itself: ~1.5Gbps
* SNMP polls to the interfaces: same.
Checked the obvious:
* Is it averaging over a weird period? Set to 5-minute intervals, same junk.
* Are we looking at the right policy/rule? Yes.
Their support says "use the built-in tool, it's accurate." It's not. Anyone else had to pull real numbers the hard way? I'm about to script around it with `clish` and `sar`.
-- old school
-- old school
Oh man, that's frustrating. I've seen weird averaging in other vendor dashboards where it uses a 95th percentile or something similar for "sustained" and calls it real usage. Could it be factoring in overhead or something? That factor of two is too perfect to be random.
Have you checked if the appliance's tool is maybe only counting one direction of traffic, like just ingress, and halving the total? I ran into a Grafana panel once that was set to kilobytes instead of kilobits, gave me a nice consistent 8x error.
Scripting around it with clish sounds like the right move, honestly. Let us know what you find? I'm curious if the sar method lines up.
Learning by breaking
Of course it's wrong. Those shiny dashboard numbers are always cooked, usually to make the appliance look like it's not sweating. I'd bet good money their "bandwidth" is some proprietary metric like "policy-processed traffic after deduplication" or some nonsense.
Skip the support script. `clish` into a cron job that dumps raw counters every minute, pipe it into a simple script that does the actual math. I did that on a Nova box last year and suddenly our billing disputes with the ISP vanished.
If three independent sources say 1.6Gbps and the magic box says 800, the box is lying.
null
That factor of two error pattern is a classic sign. I've seen this in other vendor gear where the reporting tool counts payload bytes only, stripping all layer 2 overhead. Ethernet, VLAN tags, and CRC can easily add that ~5-10% overhead, but a consistent 50% reduction suggests they might be counting only one side of a full-duplex conversation and calling it "total bandwidth."
Scripting with `clish` is the correct diagnostic step. Before you build a permanent solution, run a parallel test for an hour: log the raw interface counters from `clish` every 30 seconds and compare the delta against a simultaneous `iftop` sample. If they match, you've confirmed the dashboard's algorithm is the problem, not the underlying data source. Then you can present support with the evidence.