Find what is using the link right now#

You will end up knowing which host is responsible for what is happening to your link at this moment. At this moment is the important part: this is a live view of the connection tracking table, not a history.

Before you start#

Any role. This is a read, and reads never need a licence.
The problem happening now. If it happened last Tuesday, this page cannot help and flow export is what you needed to have set up.

Step 1 — Look at the flows#

Services → Sessions. Two views of the same data:

Flows — every connection in the tracking table: source, destination, protocol, state and byte counts, filterable. Connection states are coloured: established, time-wait, close-wait, syn-sent, fin-wait.

Top talkers — the same flows aggregated per host, which is the view that answers "who".

The page refreshes every three seconds.

Step 2 — Narrow it#

The filter box matches across the row, so a partial address, a port or a protocol all work. Start broad, then narrow:

Top talkers, to find the host.
Flows, filtered to that host, to find what it is doing.
The destination, to find out what it is talking to.

Step 3 — Confirm it is the link and not something else#

Throughput per interface is on the Dashboard, sampled by the agent and drawn as a sparkline per interface. A link at capacity and a link with a problem look different: the first is flat at a number, the second is not.

If the link really is full, shaping is what stops one upload adding half a second of latency to everything else.

What this view cannot tell you#

Platform gap

Byte counters can be missing entirely. They require nf_conntrack_acct to be enabled on the router; without it the flows are there and the byte columns are not. It is a kernel tunable:

set system sysctl parameter net.netfilter.nf_conntrack_acct value 1

When the table itself is the problem#

A router that has run out of connection tracking slots drops connections and looks like a network fault. Diagnostics → Health shows per-CPU connection-tracking pressure, which is the page that tells you whether that is what is happening.

bash

sysctl net.netfilter.nf_conntrack_max
cat /proc/sys/net/netfilter/nf_conntrack_count

Raising the limit is a kernel tunable. Find out what filled it first — usually one host, and this page names it.

Check it worked#

You have found the answer when you can name the host and the destination. Then:

Stop it, with a firewall rule — A default-drop ruleset.
Shape it, so it stops mattering — Shape a link with CAKE.
Or find out why, on the host itself.