Weathermap links only measure one direction (A tx / Z rx), reverse flow never queried #57
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Problem
scripts/generate_weathermap.py::build_weathermapbuilds each link's twosides as:
Both queries describe the same physical flow (A → Z), just measured from
each end of the wire (a_host's tx counter and z_host's rx counter for the
same direction). The reverse direction (Z → A, i.e. z_host's own tx / a_host's
own rx) is never queried on either side.
Impact
Confirmed live against the iperf3 traffic generator (dc-server2/4 as
iperf3 -s, campus-host1/2 as clients):access→leaflinks appeared to carry traffic in the weathermapbecause campus hosts are the iperf3 clients (upload direction = A→Z,
the one direction that's queried).
campus-access1Et2 tx andcampus-leaf2Et1 rx both read ~20.2 Mbps — same flow, counted twice ateach endpoint, not two opposing flows.
access→leaflinks appeared idle (~500 Kbps, i.e. TCP ACKs only)because DC hosts are the iperf3 servers (download direction = Z→A,
never queried). The real payload (
dc-leaf3Et1 tx /dc-access2Et1rx) measured ~20.1 Mbps at the same time.
So today the panel can only ever show traffic in whichever direction
happens to align with a link's
a_host→z_hostordering — never truebidirectional utilization, and silently wrong (reads near-zero) whenever
the dominant flow runs the other way.
Fix
Wire up the missing reverse-direction query per side, e.g.:
a_host a_int tx(A→Z, existing) and/ora_host a_int rx(Z→A)z_host z_int rx(A→Z, existing) and/orz_host z_int tx(Z→A)so each link surfaces both directions instead of one direction measured
twice.