Dashboard: Network tab

Top row: four stat cards

Three interface groups

Below the top row, three cards split the inventory by role. Each card has its own active-count badge in the header. Interface type is identified at a glance by a coloured badge on every row:

• Blue Physical — real NIC.
• Green Bridge — Linux bridge or OVS bridge (vmbr*).
• Purple Bond — bond / LACP / active-backup aggregator.
• Cyan VLAN — VLAN sub-interface (vmbr0.10, eno1.42, …).

Every row is clickable — physical, virtual, bridge or bond — and opens the per-interface drill-in described further down (basic info, IPs, traffic counters, historical RX/TX chart from Proxmox's RRD store).

Physical Interfaces

Every NIC the kernel sees as a real device — eno1, enp4s0, eth0, wlp3s0, etc. One row per device with the blue Physical badge and the link state. Bond members (NICs enslaved to a bond) are shown here too, with a hint pointing to the parent bond.

Bridge Interfaces

Linux bridges (vmbr0, vmbr1, …) and the OVS bridges Proxmox manages. Each row shows the green Bridge badge, the underlying physical interface (when it's a single-port bridge), and the bridge state. Bonds visible at this layer get the purple Bond badge; VLAN sub-interfaces get the cyan VLAN badge.

VM / LXC Interfaces

The tap* and veth* interfaces created when guests start — one per virtual NIC. The card header shows X / Y Active; rows are linked to the VM/CT they belong to so you can jump directly to the guest in the VMs & LXCs tab. Inactive entries hang around briefly after a guest stops; they age out within a refresh cycle.

Per-interface drill-in

Clicking any row opens a modal with five blocks:

Network Latency modal

Clicking the Network Latency card in the top row opens a dedicated modal. It has two modes (historical and on-demand test), three target options and a downloadable PDF report.

Targets

A target dropdown at the top of the modal selects what gets pinged:

• Gateway — your LAN router. Tests the local-network leg only; useful when you suspect a switch / cabling issue and want to rule out the WAN.
• Cloudflare (1.1.1.1) — public DNS resolver, anycast network. Tests the WAN leg.
• Google (8.8.8.8) — alternative public target, useful as a sanity check or when Cloudflare is regionally degraded.

Mode 1 — Historical view

The default mode when the modal opens. A second dropdown picks the timeframe (1 Hour / 24 Hours / 7 Days / 30 Days / 1 Year); data resolution drops with the window so the chart stays readable. Headline stats — Current / Min / Avg / Max — render above the chart, with a status pill (Excellent / Good / Fair / Poor) reflecting the current value against the thresholds below.

Source: the same latency samples the Health Monitor uses to detect persistent network slowdowns — sampled every 60 seconds against the gateway by the background _temperature_collector_loop thread, written to a local SQLite history.

Mode 2 — Real-time test

Switching the target to Cloudflare or Google starts an on-demand ping test. Behaviour:

• Duration — 2 minutes per run, with a progress bar and a remaining-seconds counter.
• Cadence — one reading every 5 seconds (24 readings per run).
• Method — ICMP Echo Request (ping), 3 consecutive pings per sample, latency averaged.
• Stop — ends the test immediately; partial data is preserved.
• Test Again — appends new samples to the existing dataset rather than starting fresh, so you can build a longer record across several runs.
• Live status pill — re-evaluates after every sample using the same Excellent / Good / Fair / Poor thresholds.

Performance thresholds

Network Latency Report (PDF)

Both modes have a Report button next to the target selector. Clicking it generates a PDF with everything you'd send to your ISP if you wanted to make a case for poor service.

The report has six sections:

1. Executive Summary — gauge dial (0–300+ ms with green / yellow / red zones), the status verdict (EXCELLENT / GOOD / FAIR / POOR), the target / mode / sample count and a one-line packet-loss summary.
2. Latency Statistics — Current / Min / Avg / Max as four large tiles, plus Sample Count, Packet Loss (avg) and Test Period.
3. Latency Graph — area chart of every sample over the test window with a min/avg/max y-axis grid.
4. Performance Thresholds — the same four-tier scale documented above, with a coloured dot per tier.
5. Detailed Test Results — numbered table with timestamp, latency, packet loss and status for every sample. Useful for spotting micro-bursts that the headline averages hide.
6. Methodology — test method (ICMP Echo Request), samples per test (3 consecutive pings), target name, target IP and a final "Performance Assessment" paragraph derived from the verdict.

Excluding noisy interfaces

Like storages, individual interfaces can be excluded from health monitoring — useful for intentionally disabled bridges, test interfaces or NICs that are physically removed but still in the config. The flag is stored in the excluded_interfaces table and respected by the Health Monitor cycle: no warnings, no notifications, no contribution to the header status pill.

From the row's context menu, pick Exclude from monitoring. The interface stays visible in the dashboard with a purple excluded badge, and you can re-enable monitoring from the same menu.

How the data is collected

# Cross-check the interface state seen by the dashboard
ip -br link
ip -br addr

# Verify a current latency probe end-to-end
curl -H "Authorization: Bearer <token>" \
  http://<host>:8008/api/network/latency/current | jq

Where to next

• Health Monitor — the Network category and the latency-history thresholds.
• API Reference — the network and latency endpoints.
• Integrations — Prometheus scrape exposes the same network metrics.
• Dashboard index — the other tabs.
• ProxMenux → Network — the actions side: bridge analysis, persistent interface names, backup & restart, iperf3.