Skip to main content

Network Flows

Enterprise Feature

Network Flows is available exclusively with an Enterprise license. The required feature flag is sflow_monitoring.

The Network Flows page shows which guests talk to whom, over which ports, and how much. It is built on sFlow: the Open vSwitch instances on your nodes sample a fraction of the traffic they switch and send those samples to the ProxCenter orchestrator, which decodes them and attributes each flow to a guest.

Requirements​

Three things must be true before any data appears.

Open vSwitch on the bridges that carry guest traffic. Only those bridges need to be OVS. Linux bridges elsewhere in the node, including the one carrying the management address, are irrelevant and can stay as they are. Nodes without OVS are listed as No OVS and skipped.

The collector must be reachable. The agents send UDP datagrams to the collector target you configure, port 6343 by default. That is one-way traffic from each node to ProxCenter, and it must be permitted by any firewall in between. A common surprise: a ProxCenter instance behind NAT can reach the nodes while the nodes cannot reach it back, and sFlow then produces nothing at all with no error anywhere.

Guest traffic must be visible where sampling happens. This is the part that decides whether your guests appear by name, and it is explained below.

How a flow is attributed to a guest​

Sampling happens on the OVS bridge. ProxCenter attributes each sampled packet to a guest in two ways, in this order.

  1. By interface. When the guest's own interface is a port of the sampled bridge, the port name carries the guest id: tap100i0 for a VM, veth109i0 for a container, and fwpr100p0 or fwln100i0 when the firewall is enabled on that NIC. This is exact.
  2. By MAC address. When the guest's interface is not a port of the sampled bridge, ProxCenter falls back to the source and destination MAC addresses carried in the sampled packet, matched against the NIC addresses read from your guest configurations.

The second path exists because of SDN. When a guest sits on an SDN VNet, the VNet is a Linux bridge and only a single shared uplink named ln_ plus the VNet name is a port of the OVS bridge. No per-guest interface is ever sampled, so interface naming alone can never identify the guest. MAC attribution is what makes the page work in that configuration.

The one blind spot​

Traffic between two guests on the same VNet and the same node is switched by the Linux bridge and never reaches Open vSwitch. It cannot be sampled, and no ProxCenter setting changes that.

The practical consequence: on a lab where two guests of the same VNet on one node ping each other, the flow panels stay empty and everything is working as designed. Move one guest to another node, or look at traffic that leaves the VNet, and it appears.

Configuring the agents​

Open Operations, Network Flows. The agents table lists every node of every Proxmox connection with SSH enabled, along with whether OVS is present, whether sFlow is configured, the collector target, the sampling rate, and how many guest ports the orchestrator has mapped for that node.

Use Configure sFlow on all nodes to apply the configuration everywhere, or the per-row action to apply it to a single node. You choose:

  • Collector target, as host:port. It must be an address the nodes can reach.
  • Sampling rate, meaning one packet sampled out of N. The default of 512 suits production. On a quiet lab, lower it so that the little traffic there is actually gets sampled.
  • Polling interval, in seconds, for interface counters.

The result is reported per node, including the reason when a node fails. A run where no node succeeded is an error, not a silent no-op.

Configuration does not survive a bridge rebuild​

Open vSwitch stores its sFlow configuration in its own database, and that configuration is lost whenever the bridges are recreated, which happens on a network reload or a node reboot. Nothing on the Proxmox side puts it back.

ProxCenter re-applies it for you. Every ten minutes it probes each node, and any node that has OVS bridges but no collector configured is reconfigured with the last settings you applied. You can also press Configure again at any time.

When samples arrive but no guest appears​

If the panels say that samples are arriving while no flow can be attributed, the agents are healthy and the problem is visibility, not sFlow. Check, in this order:

  1. Is any guest interface a port of the sampled bridge? Run ovs-vsctl list-ports followed by the bridge name on the node. If you see only physical interfaces and ln_ entries, your guests are behind SDN VNets and attribution depends on MAC matching.
  2. Is the guest traffic crossing the bridge at all? Two guests of the same VNet on the same node never cross it. See the blind spot above.
  3. Are the mapped ports non-zero? The agents table shows the count per node. Zero everywhere with samples arriving points at the previous two questions.
  4. Is sFlow actually configured? Run ovs-vsctl list sflow on the node. Empty output means no collector is set, whatever the page said before the last reboot.

What the numbers mean​

The flow counter in the Top Talkers header is the collector's raw lifetime count of decoded samples. It rises as soon as datagrams arrive, whether or not anything could be attributed, so it is a liveness indicator for the agents rather than a measure of what the panels show.

Bandwidth figures are derived from sampled packets multiplied by the sampling rate. They are statistically representative over a busy link and coarse over a quiet one.