The sflow vs netflow choice is really a choice about what question you are asking: NetFlow tells you who talked to whom and for how long, sFlow tells you what was on the wire with almost no cost to the switch, and RMON tells you how the port behaved over time. On an industrial site the last two are usually enough, because the interesting failures are port-level and protocol-level rather than conversational. Putting full NetFlow on an access switch that also runs a control protocol is how a monitoring project becomes an outage.
Rayin (Shenzhen Rayin Technology) is a manufacturer of GPON OLTs and industrial Ethernet switches.
RMON is SNMP-polled statistics and alarms; sFlow samples packets and counters and pushes them to a collector over UDP 6343; NetFlow maintains per-flow state and exports records when a flow ends or times out.
The cost curve is what matters on a plant floor: RMON and sFlow are cheap enough for access switches, NetFlow is not. A flow table is memory and CPU that the control plane also needs.
None of the three replaces syslog. Monitoring tells you what happened to traffic; syslog tells you what the device decided. You need both, and they answer different questions.
Three different data models, often confused because they all end up in the same dashboard.
| Mechanism | Data model | Transport | Where the work happens | Typical polling or export interval |
|---|---|---|---|---|
| RMON (RFC 2819, RMON2 in RFC 2021) | Counters and statistics, organised into groups: statistics, history, alarm, event, host, matrix | SNMP, polled | Agent maintains counters; manager polls | 30–300 s |
| sFlow (RFC 3176, version 5 in practice) | Sampled packet headers plus interface counters | UDP 6343, pushed to a collector | Agent samples in hardware, exports datagrams | Sampling 1 in 512 to 1 in 2000; counters every 20–30 s |
| NetFlow (RFC 3954 v9) and IPFIX (RFC 7011) | Per-flow records built from a cached flow table | UDP or SCTP, pushed to a collector | Agent maintains flow state per conversation | Inactive timeout around 15 s, active timeout around 30 min |
The distinction that matters operationally: RMON is pull, sFlow and NetFlow are push. A pull model puts load on the device at poll time and depends on the manager being reachable. A push model puts load on the device continuously and depends on the collector. Industrial sites with intermittent WAN links to the NMS usually prefer push, because the device does not care whether anyone is listening.
By never keeping per-flow state.
sFlow takes a copy of one packet in every N and sends that header to the collector, along with interface counters. The collector does the aggregation. Because the switch does not maintain a conversation table, its memory and CPU cost is almost constant regardless of how many flows cross the device — which is why sFlow is available on switches that could never run NetFlow at line rate.
The trade is statistical rather than exact. With 1-in-1000 sampling on a 1 Gbps link carrying 100,000 packets per second, you see 100 packet headers per second. That is plenty to characterise protocol mix, top talkers and elephant flows. It is not enough to bill for traffic or to prove that a specific 40-byte packet was dropped at 14:32:07.
Two sFlow parameters decide whether it is useful:
Sampling rate. 1 in 512 is generous and gives good resolution on low-rate industrial traffic. 1 in 2000 is cheaper but can miss short bursts entirely, which is exactly the failure mode on a plant network.
Counter poll interval. 20–30 s is the practical range. Longer intervals miss microbursts; shorter intervals generate a lot of datagrams for a small site and can saturate the sFlow collector's ingest.
Note: Sampling and polling measure different things. Packet sampling tells you about composition; counter polling tells you about volume and errors. A monitoring design that only does one of the two will mislead you in a different way each time.
Because a flow table is state, and state is memory plus CPU plus expiry logic.
Every new conversation creates an entry. On a plant floor a single PLC can open dozens of short-lived TCP sessions per minute, and a camera VLAN adds hundreds more. Each entry occupies memory in a table that shares silicon with the MAC table and the buffers, and each packet has to be hashed, looked up and counted.
The consequence is a design constraint, not a preference: NetFlow belongs on the device where flow aggregation actually helps — a router or a Layer 3 boundary — and not on every access switch in the plant. In practice that means:
Aggregation and core switches may justify NetFlow, because that is where traffic from many segments converges and where a flow view is worth the cost.
Access switches on the plant floor should run sFlow or RMON, because the questions asked of them are port-level.
A Layer 3 industrial switch acting as a router between cells is the interesting middle case: it sees flows that matter, and its CPU may be sized for it. Verify rather than assume.
IPFIX is the IETF standardised successor to NetFlow v9, with a template-based record format. For the purposes of this comparison they behave the same way; the difference is who defined the field set. If a device claims NetFlow support, ask which version and whether it exports templates — v5 has a fixed format that cannot express IPv6 or VLAN fields.
Alarms, and history that lives on the device.
The nine groups defined in RFC 2819 cover statistics, history, alarm, host, hostTopN, matrix, filter, capture and event. RMON2 extends this to network-layer and application-layer statistics. The practically useful subset on an industrial switch is small and valuable:
History groups keep a rolling window of counter samples on the device itself. When a fault happened three hours ago and nobody was polling, the history is what tells you the port was erroring at the time.
Alarm and event groups let the device raise a trap when a counter crosses a threshold, instead of waiting for a poll. A rising CRC counter or a broadcast rate above threshold can generate an alarm before a user notices.
Host and matrix groups give a per-MAC and per-conversation view without any flow export at all — coarse compared with NetFlow, but free.
That history buffer is the reason RMON still earns its place. An SNMP poll every 60 seconds paints a dotted line; RMON history at 30-second intervals on the device fills in the gaps for the period when the NMS was not reachable.
| Question you are asking | Best tool | Why |
|---|---|---|
| Which port is erroring, and when did it start? | RMON history and alarms | Counters with timestamps, stored on the device |
| Which protocols dominate this segment? | sFlow | Sampled headers give a protocol mix cheaply |
| Which host is talking to which, and how much? | sFlow, or NetFlow where available | Conversations from sampled headers or flow records |
| Did a specific conversation complete? | NetFlow with a short inactive timeout | Per-flow records with byte and packet counts |
| What did the switch decide, and why? | Syslog | Monitoring shows effect, syslog shows intent |
| What was the traffic pattern during a 30-second stall? | sFlow with a fine sampling rate | Microburst resolution that polling cannot provide |
Three layers, in order of value per unit of effort.
Layer 1 — counters and alarms on every switch. Interface statistics, error counters, and RMON alarm thresholds on the few counters that matter: CRC errors, discards, broadcast rate, and link state changes. This costs almost nothing and catches the majority of real faults.
Layer 2 — one sFlow collector for the plant. A single sFlow collector receiving samples from the aggregation switches gives protocol mix and top talkers across the whole site. Sampling at 1 in 512 with 30-second counter polls is a reasonable starting configuration; increase the sampling detail only on the segment you are investigating.
Layer 3 — NetFlow or IPFIX at the Layer 3 boundary. Where the plant meets the enterprise or the DMZ, flow records answer the questions that matter for security and capacity: who is crossing the boundary, how much, and when. A netflow analyzer at this point is worth its cost; twenty of them on access switches are not.
The order matters. A site that deploys NetFlow first usually ends up with a large flow database and no answer to "which port was erroring", because nothing was watching the counters.
Tip: Time-synchronise everything before you build any of this. Sampled data from six switches is only correlatable if all six agree on the time to within a second or two. NTP is the cheapest monitoring improvement available.
Four blind spots worth knowing.
They see packets, not meaning. A PLC scan cycle that slips by 40 ms looks like ordinary traffic. Detecting it needs protocol-aware analysis or the PLC's own diagnostics, not flow records.
Sampling can miss the event. A 200 ms burst that saturates a port may be entirely absent from a 1-in-2000 sample. If microbursts are the suspected cause, increase the sampling rate on that port temporarily rather than buying a bigger collector.
Flow tables hide retransmissions. A TCP conversation that retransmits heavily shows as one flow with normal byte counts. The retransmission evidence is in the packet capture, or in the switch's own error counters.
Nothing replaces a capture. When three tools disagree, a port mirror and a capture at the disputed moment settles it in ten minutes. Keep a spare port configured for mirroring on the switches that matter.
Which is better for an industrial network, sFlow or NetFlow?
sFlow, for access and aggregation switches, because it costs almost nothing in memory and CPU and still answers protocol-mix and top-talker questions. NetFlow is worth its cost at a Layer 3 boundary where flow records support security and capacity decisions. Most plants need both, at different layers.
Does sFlow capture every packet?
No. It samples one packet in every N and sends the header to a collector, which extrapolates. With 1-in-512 sampling on low-rate industrial traffic the estimate is accurate enough for characterisation; it is not accurate enough for billing or for proving a specific packet was dropped.
What is RMON used for on a switch?
Statistics, history, alarms and per-host or per-matrix counters, all accessible over SNMP. Its practical value on an industrial switch is the on-device history buffer and threshold alarms, which keep working when the NMS is unreachable and preserve the record of a fault that happened hours ago.
Can I run all three at once?
Technically yes, and the CPU cost adds up. A sensible deployment runs RMON counters and alarms on every switch, sFlow to a single collector, and NetFlow or IPFIX only at the Layer 3 boundary. Enabling everything everywhere produces a monitoring system that competes with production traffic.
How much bandwidth does network traffic monitoring consume?
sFlow is the cheapest: a sampled header plus counters is a few hundred bytes per datagram, sent a few times per second per interface. NetFlow grows with the number of flows, not with traffic volume, and a busy boundary device can export tens of megabits per second. Always send exports on a management VLAN, not on the production path.
About the author: Sara — Sara is a Customer Manager at Rayin with over 10 years of experience in the communications field. In her free time, she enjoys badminton and swimming.
About Rayin: Shenzhen Rayin Technology Co., Ltd. — Company Profile
