NetFlow Top Talkers Analyzer

Flow rows:

CSV, TSV, or whitespace rows work best. Common headers such as srcaddr, dstaddr, dport, bytes, pkts, and flows are recognized.

Group flows by:

Source and destination find hosts; conversation preserves both endpoints; service groups protocol plus destination port.

Rank by:

The selected metric controls table order and the Talker Share Ladder chart.

Top talkers:

Show the busiest grouped rows in the talker table and chart.

rows

Minimum bytes:

Use 0 for no byte floor.

bytes

Minimum packets:

Use 0 for no packet floor.

packets

Protocol filter:

All is neutral; TCP, UDP, ICMP, GRE, and Other narrow the parsed rows.

Destination scope:

All is neutral; Private and External help isolate internal or internet-facing destinations.

Flow ledger limit:

Keep the source ledger readable for larger collector exports.

rows

{{ error }}

Metric	Value	Operator read	Copy
{{ row.metric }}	{{ row.value }}	{{ row.note }}

Rank	Talker	Bytes	Packets	Flows	Traffic share	Avg B/pkt	Top peer	Dominant service	Copy
{{ row.rank }}	{{ row.label }}	{{ row.bytesDisplay }}	{{ row.packetsDisplay }}	{{ row.flowsDisplay }}	{{ row.trafficShareDisplay }}	{{ row.avgPacketDisplay }}	{{ row.topPeer }}	{{ row.dominantService }}

Signal	State	Evidence	Operator action	Copy
{{ row.signal }}	{{ row.state }}	{{ row.evidence }}	{{ row.action }}

#	Source	Destination	Protocol	Src port	Dst port	Bytes	Packets	Flows	Duration	Copy
{{ row.index }}	{{ row.source }}	{{ row.destination }}	{{ row.protocol }}	{{ row.sourcePort }}	{{ row.destinationPort }}	{{ row.bytesDisplay }}	{{ row.packetsDisplay }}	{{ row.flowsDisplay }}	{{ row.durationDisplay }}

Export to PDF Fullscreen

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

NetFlow and IPFIX records summarize network traffic as flow rows instead of full packet captures. A row usually keeps the source and destination, protocol, port information, byte count, packet count, flow count, and sometimes timing. That makes a top-talkers view useful when a link is busy and the next question is which host, peer, service, protocol, or conversation is carrying the most traffic.

Top-talkers analysis is common during bandwidth triage, incident response, change validation, and capacity review. A network engineer might need to know whether a backup host, database client, VPN peer, scanner, or unexpected external destination is dominating an observation window. The answer depends on how the records are grouped. The same rows can show a busy source host, a busy destination, a heavy source-to-destination conversation, or a protocol and port combination that explains the volume.

Flow records are counters, not payload inspection. They can show volume, direction, protocol, and service clues, but they do not prove user intent, application content, or whether traffic is malicious. Sampling, exporter configuration, NAT, asymmetric routing, and the selected time window can all change what appears as a top talker. A high share is a reason to investigate, not a verdict by itself.

The most useful reading comes from comparing several counters at once. Bytes identify bandwidth consumers. Packets reveal chatty traffic, retries, scans, and control traffic. Flow count highlights repeated short conversations. When those signals disagree, the disagreement is often the finding.

Technical Details:

A traffic flow is a set of packets observed at a network point during a time interval that share common properties. The familiar five-part key is source address, destination address, source port, destination port, and transport protocol. Exporters may include more fields, but the counters most often used for first-pass traffic triage are bytes, packets, and flow records.

Top-talkers analysis aggregates those records by a chosen key and sorts the resulting groups by a chosen counter. Grouping by source asks which senders produced the most active traffic. Grouping by destination asks which receivers collected it. Conversation grouping preserves both endpoints. Service grouping combines protocol and destination port so traffic such as TCP/443 or UDP/53 can be compared across many hosts.

Flow records grouped by key and ranked by bytes, packets, or flows

Aggregation should be read as a sum across the active records after filters. The totals are not recomputed from packets, and no payload sampling is inferred. If the exporter already sampled traffic or rolled several packets into a flow record, the analysis reflects the counters in the rows you provide.

\begin{matrix} B_{g} & = & \sum_{r \in g}^{} B_{r} \\ P_{g} & = & \sum_{r \in g}^{} P_{r} \\ traffic share & = & \frac{B_{g}}{\sum_{all active rows}^{} B} \times 100 \\ avg bytes per packet & = & \frac{B_{g}}{P_{g}} \end{matrix}

Recognized flow row fields and their purpose
Field family	Recognized examples	How it affects the analysis
Source and destination	`srcaddr`, `dstaddr`, `sourceip`, `destinationip`	Define host and conversation groupings.
Protocol	`proto`, `protocol`, numeric IP protocol values	Supports protocol grouping and TCP, UDP, ICMP, GRE, or other filtering.
Ports	`srcport`, `dstport`, `dport`, `port`	Builds service labels such as `TCP/443` and destination-port views.
Counters	`bytes`, `octets`, `pkts`, `packets`, `flows`	Drive ranking, traffic share, packet-size clues, and flow-count views.
Timing	`duration`, `firstswitched`, `lastswitched`	Appears in the flow ledger when duration can be parsed or derived.

Grouping choices and questions answered
Grouping	Question it answers	Common use
Source address	Which sender produced the most active traffic?	Find heavy clients, noisy hosts, scanners, or backup sources.
Destination address	Which receiver collected the most active traffic?	Find busy servers, external peers, or data sinks.
Conversation pair	Which source-to-destination pair dominates?	Validate one bulk transfer or isolate a repeated peer path.
Service	Which protocol and destination port consume traffic?	Separate web, DNS, VPN, database, SSH, and tunnel traffic.
Protocol	Which transport or IP protocol is busiest?	Spot TCP, UDP, ICMP, GRE, or other protocol skew.
Destination port	Which destination port is busiest regardless of protocol label?	Check policy, firewall, or application-port concentration.

Everyday Use & Decision Guide:

Start with the smallest source that still answers the operational question. A recent collector export for the affected link, VLAN, router, or firewall zone is better than a whole-day dump when you are chasing a short congestion event. Paste rows into Flow rows, drop a CSV or TXT file onto the textarea, or use Browse for a local file. The source helper line should show how many rows parsed and how many were skipped.

The default first pass is source address ranked by bytes with no advanced filters. That quickly identifies bandwidth-heavy senders. Change Group flows by before changing filters if the first result is too broad. For example, a busy source can become more useful as a Conversation pair view, and a busy conversation can become more actionable as a Service view.

Use Rank by: Bytes when link utilization, data movement, or egress volume is the concern.
Use Rank by: Packets when the issue looks like chatter, scans, retries, or small control packets.
Use Rank by: Flow count when many short sessions matter more than raw volume.
Use Top talkers to keep the table and Talker Share Ladder readable without changing the active totals.
Use Minimum bytes, Minimum packets, Protocol filter, and Destination scope only after the first unfiltered result shows what you are removing.

Read the summary before exporting. Top Talkers Ranked means the active rows produced a ranked result. Filtered Top Talkers means valid rows were removed by Advanced filters. Flow Rows Need Review means the source is empty, no valid rows parsed, or all parsed rows were filtered out.

The result tabs support different follow-up tasks. Traffic Snapshot is the quick brief. Top Talkers is the ranked evidence table. Traffic Findings flags concentration, service skew, external destination share, packet-size clues, and parser coverage. Flow Ledger keeps row-level context. Talker Share Ladder and Service Mix turn the active result into chart views, and JSON preserves the normalized analysis state.

Flow data often contains internal addressing, partner addresses, ports, and traffic volumes. Rows are parsed in the browser after the page loads, and selected files are read into the page rather than uploaded for analysis. Exports, screenshots, and shared page URLs can still reveal the same details, so treat them as operational evidence.

Step-by-Step Guide:

Work from raw rows to a ranked view, then narrow only when the first result is understood.

Paste CSV, TSV, or whitespace-separated rows into Flow rows, or load a local CSV/TXT file with Browse. A valid row needs at least an endpoint plus bytes, packets, or flow count.
Check the Source helpers status. If many rows are skipped, use Normalize after a successful parse, or adjust the header names toward common fields such as srcaddr, dstaddr, proto, dport, bytes, pkts, and flows.
Choose Group flows by. Start with Source address for noisy senders, Destination address for busy receivers, Conversation pair for endpoint pairs, or Service for protocol and port concentration.
Choose Rank by. After changing the metric, confirm that the first badge and the Top Talkers table are ranking by bytes, packets, or flow count as intended.
Set Top talkers between 3 and 25 rows. This trims the visible ranked artifact and chart while the totals in Traffic Snapshot still describe the active filtered set.
Open Advanced only when you have a reason to narrow the rows. If the page reports that all parsed rows are filtered out, relax Minimum bytes, Minimum packets, Protocol filter, or Destination scope.
Review Traffic Snapshot, then check Top Talkers and Traffic Findings. Use Flow Ledger to confirm that the top row is backed by plausible source rows.
Copy or download the table, chart, DOCX, CSV, or JSON export that matches the handoff. Use JSON when another process needs the parsed rows, filters, totals, findings, and top-talkers data together.

If the parser warning remains, fix the source rows before treating the ranked result as evidence.

Interpreting Results:

The first number to judge is Total traffic in Traffic Snapshot. Every share, chart slice, and top-talker percentage is based on the active rows after filters. If the active row count is much smaller than the parsed row count, the filters are shaping the result and should be documented with any export.

Top talker names the highest-ranked group for the selected grouping and metric. It does not prove that the host or service caused the incident.
Top-three concentration helps decide whether a few groups explain most of the traffic or whether the load is spread across many groups.
External destination share depends on address classification. Private ranges are separated from external IPv4 and IPv6 addresses, while hostnames or unknown values stay visible only when destination scope is All destinations.
Average packet size is a clue. A low value can point toward scans, retries, keepalives, or control traffic, but it should be checked against protocol and service rows.
Parser coverage is a trust check. Skipped rows mean the export shape should be reviewed before the result is attached to a ticket or report.

Ranked bytes and ranked packets can tell different stories. A single TCP/443 data transfer may dominate bytes, while UDP/53 or a scanning pattern may dominate packets with much less volume. Switch the rank metric and compare the top rows before deciding whether the issue is bandwidth, packet rate, repeated sessions, or policy drift.

A warning badge should slow the handoff down. Focused talker concentration, Service-heavy service mix, Internet-heavy external share, and Packet-heavy packet-size clues all deserve a second check in the ledger before action is assigned.

Worked Examples:

Finding a bandwidth-heavy source

The sample rows include several TCP/443 flows from 10.44.20.10. With Group flows by set to Source address and Rank by set to Bytes, Top talker becomes 10.44.20.10. The Top Talkers row shows about 491 MiB for that source and about 65% Traffic share. That is enough to start with the source host, but Top peer and Dominant service should still be checked before assigning cause.

Separating service volume from host volume

A link alert shows high egress volume, but the source host list is split across several clients. Change Group flows by to Service and keep Rank by on Bytes. If Dominant service in Traffic Snapshot reports TCP/443 with most of the active bytes, the next check is whether the HTTPS traffic is an expected transfer, CDN pull, or unscheduled upload. If the Service Mix chart instead spreads traffic across many services, host or conversation grouping may be more useful.

Narrowing external destinations

Set Destination scope to External destinations when the question is internet egress rather than internal east-west traffic. In the sample rows, the external subset keeps the documentation-network peers and removes private destinations. External destination share in the unfiltered snapshot is about one quarter of total bytes, so filtering to external destinations changes the denominator. Any exported table should mention that the active rows were filtered.

Fixing a failed collector paste

A pasted log contains banners, separators, and rows without byte or packet counters. The page may show No valid flow rows were parsed or a source helper status with many skipped rows. Remove the banner lines, keep one header row, and make sure each data row has endpoints plus at least one metric. After rows parse, Normalize can rewrite them into a consistent CSV shape for another pass.

FAQ:

What formats can I paste?

CSV, TSV, and whitespace-separated rows work. A header row is helpful, but positional rows can also parse when they follow common source, destination, protocol, port, bytes, packets, and flows order.

Why did some rows get skipped?

Rows are skipped when the column shape is not recognized or when both endpoint and metric evidence are missing. Check Parser coverage, then adjust headers or remove non-data lines before exporting.

Should I rank by bytes, packets, or flow count?

Use bytes for bandwidth, packets for chatty or packet-rate issues, and flow count for many repeated sessions. Switching the metric can legitimately change the top row.

What does destination scope do?

It filters active rows by destination address classification. Private destinations include RFC1918-style IPv4 ranges and common private IPv6 patterns. External destinations include routable-looking addresses. Unknown hostnames remain in the all-destinations view only.

Does a high top-talker share prove abuse?

No. A high Traffic share means one group dominates the active rows. Confirm expected transfers, maintenance windows, service ownership, and row-level evidence in Flow Ledger before treating it as abuse or compromise.

Are uploaded flow files sent to a server?

Selected CSV or TXT files are read into the page for parsing. The current analysis path does not upload the capture to a separate analysis service, but page assets still load from the site and a chart asset provider, and exports or shared URLs can expose the traffic details you entered.

Glossary:

NetFlow: A flow-export technology that reports traffic counters and endpoint fields from network devices.
IPFIX: The IETF flow-export protocol that standardizes how flow information is exchanged.
Flow record: A row describing an observed flow, usually with endpoints, protocol fields, counters, and optional timing.
Top talker: The highest-ranked group after active flow rows are aggregated by the selected key.
Conversation: A source-to-destination pair kept together as one grouped traffic relationship.
Service: The protocol and destination port label used to compare traffic such as TCP/443 or UDP/53.
Traffic share: The percentage of active bytes carried by one grouped talker.
Average bytes per packet: Grouped bytes divided by grouped packets, used as a rough packet-size clue.

References:

RFC 7011: Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information, Internet Engineering Task Force, September 2013.
RFC 3917: Requirements for IP Flow Information Export (IPFIX), Internet Engineering Task Force, October 2004.
Detecting and Analyzing Network Threats With NetFlow, Cisco, October 31, 2005.
Configuring NetFlow Top Talkers, Cisco.