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

{{ error }}

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

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 }}
No ranked talkers available Paste valid flow rows or relax Advanced filters to rebuild the top talker ledger.

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 }}
No flow ledger rows available The current source has no active rows after parsing and filters.

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Network traffic investigations often start with a simple complaint: a link is full, an internet bill jumped, a firewall is busier than expected, or one service feels slow. Packet captures can answer deep questions, but they are heavy to collect and sensitive to share. NetFlow and IPFIX records sit in the middle. They summarize conversations seen by routers, switches, firewalls, and collectors without carrying the full payload of each packet.

A flow row is usually a compact statement about who talked to whom, which protocol and ports were involved, and how many bytes, packets, or flow records were counted. That makes flow data well suited for top-talkers analysis, where the goal is to rank the busiest senders, receivers, services, protocols, or endpoint pairs during the observation window. The same rows can tell different stories depending on whether the ranking is based on bandwidth, packet count, or repeated sessions.

Common top-talkers questions and useful grouping views
Operational question	Useful view	What it can reveal
Which host is sending the most?	Source address	Noisy clients, backup jobs, scanners, or unexpected upload sources.
Which system is receiving the most?	Destination address	Busy servers, data sinks, cloud endpoints, or heavily used internal services.
Which pair dominates a path?	Conversation pair	Bulk transfers, repeated peer traffic, or a single path consuming a shared link.
Which application class is visible?	Protocol and destination port	HTTPS, DNS, SSH, VPN, database, tunnel, or other service concentration.

Bytes, packets, and flows are not interchangeable. Bytes point to bandwidth consumers and large transfers. Packets highlight chatty behavior, retransmits, scans, keepalives, or control traffic. Flow count catches repeated short-lived sessions that may not dominate byte volume. A useful review compares those counters instead of assuming the first ranked row explains the whole incident.

Flow counters grouped into talker rankings by host, service, or conversation.

Top-talkers output is also shaped by where the exporter sits. A firewall may see traffic after network address translation, while a switch or router may see internal addresses before translation. Asymmetric routing can split the two directions of a conversation across different devices. Sampling can understate small flows or make short bursts appear less certain than long steady transfers. Time windows matter too: a five-minute incident window and a full-day export answer different questions.

Flow data is strong evidence for volume and direction, not proof of intent or payload. A large HTTPS entry could be an approved backup, a software update, a proxy cache fill, or suspicious exfiltration. The numbers identify where to look first, then ownership records, change windows, firewall policy, endpoint telemetry, and packet-level checks supply the surrounding proof.

How to Use This Tool:

Use a collector export that matches the network segment and time period you want to explain. A first pass with the sample or a broad unfiltered paste is useful because it shows whether the columns parse before filters narrow the evidence.

Paste CSV, TSV, or whitespace-separated rows into Flow rows, browse for a CSV or TXT file up to 5 MiB, drop a file onto the input, or load the sample rows.
Check the source status below the input. If rows are skipped, keep one clear header row or use common columns such as srcaddr, dstaddr, proto, srcport, dport, bytes, pkts, and flows.
Choose Group flows by. Source and destination answer host questions, conversation keeps endpoint pairs together, service combines protocol with destination port, and protocol or destination-port views are useful for policy checks.
Choose Rank by. Use Bytes for bandwidth, Packets for chatter or packet-rate questions, and Flow count for repeated short sessions.
Set Top talkers from 3 to 25 rows. This limits the ranked table and Talker Share Ladder, while the totals still come from all active rows after filtering.
Open Advanced only when the initial result is too broad. Minimum bytes, Minimum packets, Protocol filter, and Destination scope remove rows before aggregation. If the page reports that all rows are filtered out, relax those settings.
Review Traffic Snapshot, Top Talkers, Traffic Findings, and Flow Ledger before exporting. The ledger is the row-level sanity check behind the ranked result.
Open Talker Share Ladder when you need a ranked visual for the selected metric, then compare Service Mix if the host view spreads traffic across many addresses.
Use the summary status, parser coverage row, and skipped-row count as the final readiness check. A clean parse with the expected active-row count is safer to share than a chart that looks convincing but hides rejected rows.

The result tables can be copied, downloaded as CSV, or exported as DOCX when document export is available. Chart tabs can be downloaded as image files or CSV, and the JSON tab keeps the parsed rows, filters, totals, findings, services, and top-talkers data together for follow-up analysis.

Advanced Tips:

Advanced settings are most useful after a broad pass proves the export parses correctly. Treat each filter as a change to the denominator, then label the narrowed view when handing the result to another operator.

Use the byte floor to remove low-volume rows before grouping. It can suppress background noise, but it may hide the rows that matter when packet count or connection churn is the real symptom.
Use the packet floor for scan, retry, keepalive, or control-traffic reviews. A packet floor can hide large low-packet transfers, so compare it against a byte-ranked pass before drawing a bandwidth conclusion.
Apply the protocol filter to match the incident question. TCP is usually the first cut for web, SSH, database, and file-transfer paths; UDP is useful for DNS, VPN, discovery, and media traffic; ICMP and GRE need separate review because their ports may be absent.
Treat destination scope as an address-text filter, not a routing lookup. Private and external views help separate east-west traffic from internet-facing traffic, while hostnames, reserved ranges, and ambiguous values need a separate inventory or DNS review.
Keep the flow ledger limit modest for screen review. It only controls how many row-level records are displayed, so use exports when a larger audit trail is needed.

For repeat investigations, keep one unchanged baseline export and make one change at a time: grouping, then ranking, then filters. That makes it easier to explain why a source address moved down the list, why a service became dominant, or why the external-share percentage changed.

Interpreting Results:

Start with parser coverage and active row count. Percentages, totals, top-three concentration, and external destination share are calculated from rows that parsed successfully and survived the current filters. If the active set is narrow, mention the filter context when sharing the result.

Top talker is the highest-ranked group for the selected grouping and metric. It is a lead for investigation, not a final root cause.
Top-three concentration shows whether a few groups explain most of the byte volume. High concentration usually makes the next review more focused.
External destination share separates routable-looking destination addresses from private-looking ones. Unknown hostnames and ambiguous values are not forced into an external or private bucket.
Dominant service describes the protocol and destination-port label with the largest active byte share, such as TCP/443 or UDP/53.
Average packet size is a clue about traffic shape. A small average can point toward scans, keepalives, control traffic, or retries, but it is not a protocol diagnosis by itself.

The Traffic Findings states are deliberately cautious. Focused, Service-heavy, Internet-heavy, Packet-heavy, and Rows skipped point to checks an operator should make next. They do not label traffic as safe, malicious, approved, or broken.

When byte, packet, and flow rankings disagree, keep all three views in the investigation. A bulk transfer can dominate bytes, DNS or scanning can dominate packets, and short repeated sessions can dominate flow count. The disagreement often explains why one team sees a link problem while another sees a policy or endpoint problem.

Technical Details:

NetFlow and IPFIX describe observed flows rather than individual packets. A classic flow key includes source address, destination address, source port, destination port, and protocol, but exporters and collectors may add timestamps, ingress or egress interface data, sampling details, application fields, or vendor-specific elements. The rows used for a top-talkers review are usually an already-flattened collector view of that larger record model.

Top-talkers analysis has two separate steps. First, valid rows are filtered by minimum counters, protocol family, and destination address scope. Second, the remaining rows are aggregated by the selected key and sorted by the selected rank metric. The byte share shown for a talker remains a byte share even when the table is sorted by packets or flows, so the ranking metric and traffic-share percentage can answer different questions.

Aggregation Core:

\begin{array}{lcl} B_{g} & = & \sum_{r \in g}^{} B_{r} \\ P_{g} & = & \sum_{r \in g}^{} P_{r} \\ F_{g} & = & \sum_{r \in g}^{} F_{r} \\ byte share & = & \frac{B_{g}}{\sum_{active rows}^{} B} \times 100 \\ average bytes per packet & = & \frac{B_{g}}{P_{g}} \end{array}

Accepted flow field families and their role
Field family	Representative labels	How it affects analysis
Endpoints	`srcaddr`, `sourceip`, `dstaddr`, `destinationip`	Build source, destination, and conversation groupings.
Protocol	`proto`, `protocol`, numeric IP protocol values	Normalizes common values such as TCP, UDP, ICMP, GRE, ESP, AH, IGMP, and ICMPv6.
Ports	`srcport`, `dstport`, `dport`, `port`	Creates service labels and destination-port groupings.
Counters	`bytes`, `octets`, `pkts`, `packets`, `flows`	Drive ranking, shares, totals, and packet-size clues.
Timing	`duration`, `firstswitched`, `lastswitched`	Supplies visible duration values when a duration or start-end pair can be parsed.

Ranking metrics and common interpretation traps
Rank metric	Best for	Common trap
Bytes	Bandwidth, egress cost, large transfers, saturation checks.	Small-packet storms may stay low in the ranked list.
Packets	Chatter, scans, retries, control-plane-looking traffic.	Many small packets can outrank the traffic that consumes most bandwidth.
Flow count	Repeated short sessions and connection churn.	A high count may represent normal polling or health checks rather than abuse.

Destination-scope filtering relies on address classification, not live routing knowledge. Private IPv4 ranges, loopback, link-local, carrier-grade NAT, and common private IPv6 patterns are treated as private-like. Public-looking IPv4 and many global IPv6 values are treated as external-like. Reserved, multicast, unknown, and hostname values need human review because the text alone does not prove where the traffic went.

Parser tolerance improves first-pass triage, but it cannot repair a misleading export. Rows without usable endpoint evidence and at least one counter are rejected. Magnitude suffixes such as K, M, G, T, and P are interpreted with binary scaling, numeric protocol values are mapped where known, and port values are normalized where possible. Source collector semantics still matter, especially for sampled flow data, NAT placement, ingress versus egress observation, and devices that export only selected interfaces.

Privacy and Accuracy Notes:

Flow exports can disclose internal addresses, public peers, service ports, VPN paths, business partners, and traffic volumes. Pasted text and selected CSV or TXT files are read in the browser after the page loads, so the rows do not need a tool-specific upload for parsing.

Evidence can still leak through what people copy or download. CSV tables, chart images, DOCX exports, JSON files, screenshots, and shared URLs may reveal the same network details. Redact addresses and partner names before moving results outside the operations or security audience that needs them.

Accuracy depends on the collector export. Sampling, dropped exports, stale templates, row truncation, clock mismatch, duplicate collection points, and pre- or post-NAT visibility can all change the ranking. Treat the result as a triage view of the supplied rows, then confirm important findings against device counters, monitoring history, firewall logs, endpoint data, or a targeted packet capture.

Worked Examples:

Checking a saturated uplink

Paste rows from the alert window and keep Group flows by on Source address with Rank by set to Bytes. If one internal host has a large byte share, check its Top peer and Dominant service. A backup client moving data to TCP/443 should be handled differently from an unknown host sending to an unexpected external peer.

Finding packet-heavy chatter

Change Rank by to Packets when the symptom is device CPU, firewall session load, retransmission noise, or a small-packet flood. A low Average packet size plus a packet-heavy finding suggests reviewing DNS, ICMP, keepalive, scan, or retry patterns before focusing on large transfers.

Separating service concentration from host concentration

When source ranking spreads traffic across many clients, switch Group flows by to Service. If one service such as TCP/443, UDP/53, or TCP/1433 dominates active bytes, the next question is ownership and expected use of that service, not only which individual host appears first.

Narrowing internet-facing traffic

Use Destination scope set to External destinations when the task is egress review. The denominator changes because private and unknown destinations are excluded, so exported evidence should say the view was limited to external-looking destination addresses.

FAQ:

What row formats are supported?

CSV, TSV, and whitespace-separated rows are supported. A header row is recommended, but positional rows can parse when they follow a common endpoint, protocol, port, bytes, packets, and flow-count order.

Why did rows get skipped?

Rows are skipped when their column shape is not recognized or when endpoint and counter evidence are missing. Remove banners and separator lines, keep one header, and make sure the rows include endpoints plus bytes, packets, or flow count.

Should I group by source, destination, service, or conversation?

Use source for noisy senders, destination for busy receivers, service for protocol and destination-port concentration, and conversation when the endpoint pair itself is the key evidence.

Why does byte share remain important when I rank by packets?

Packet ranking changes the order, but byte share still shows bandwidth contribution. A packet-heavy source can be operationally important even when it carries a small share of total bytes.

Does external destination scope perform a live lookup?

No. It classifies literal address text with local private, reserved, and public-looking address rules. Hostnames and unknown values stay available only when all destinations are included.

Does a high top-talker share prove misuse?

No. A high share means one grouped result dominates the active rows. Confirm ownership, maintenance windows, expected transfers, firewall policy, endpoint activity, and surrounding monitoring before treating it as misuse or compromise.

Glossary:

NetFlow: A flow-export technology commonly used to report traffic counters and endpoint fields from network devices.
IPFIX: The IETF standard for exporting IP flow information between exporters and collectors.
Flow record: A row that summarizes an observed conversation or traffic event with endpoints, protocol data, counters, and optional timing.
Top talker: The highest-ranked grouped result after active flow rows are aggregated and sorted.
Conversation pair: A source-to-destination relationship kept together as one ranked group.
Service: A protocol and destination-port label such as TCP/443, UDP/53, or GRE/any.
Traffic share: The percentage of active bytes carried by one grouped talker.
Flow count: The number of flow records represented by the active rows, useful for repeated short-session patterns.

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 7012: Information Model for IP Flow Information Export (IPFIX), Internet Engineering Task Force, September 2013.
Cisco IOS NetFlow Command Reference: show ip flow top-talkers, Cisco.
Assigned Internet Protocol Numbers, IANA.
RFC 1918: Address Allocation for Private Internets, Internet Engineering Task Force, February 1996.
RFC 6598: IANA-Reserved IPv4 Prefix for Shared Address Space, Internet Engineering Task Force, April 2012.