Network Monitoring Explained: SNMP, NetFlow and Syslog
A network you cannot see is a network you cannot manage. SNMP, NetFlow and Syslog form the three pillars of network monitoring, each providing a different lens through which to observe device health, traffic patterns and security events. This guide explains how each protocol works, how they complement one another, and which tools can bring them all together.
Why Network Monitoring Matters
Organisations depend on their network for everything from email and cloud applications to IP telephony, security cameras and building automation. When performance degrades or a link goes down, every minute of downtime costs money, productivity and reputation. Proactive monitoring lets IT teams detect anomalies before users notice, plan capacity based on real data, and investigate security incidents with confidence.
The three protocols most widely used for network monitoring are SNMP (Simple Network Management Protocol), NetFlow (and its relatives sFlow and IPFIX), and Syslog. Each answers a different question: SNMP tells you how is the device doing?, NetFlow tells you what is the traffic doing?, and Syslog tells you what happened?. Together, they provide a comprehensive view of the network.
SNMP: Device Health and Performance
SNMP has been the backbone of network management since the late 1980s. It uses a manager-agent model: a management station (your monitoring server) polls agents running on switches, routers, firewalls, servers and other devices. Agents can also send unsolicited traps (or informs in v2c/v3) to alert the manager when something noteworthy occurs — such as an interface going down or a CPU exceeding a threshold.
SNMP Versions
There are three major versions of SNMP, each improving on security:
- SNMPv1 — the original version. Uses plain-text community strings (essentially passwords) for authentication. Offers no encryption. Still found on legacy devices.
- SNMPv2c — adds support for 64-bit counters (critical for high-speed interfaces) and bulk retrieval operations, but still relies on community strings with no encryption. The most widely deployed version today.
- SNMPv3 — introduces proper authentication (SHA/MD5) and encryption (AES/DES). SNMPv3 should be used whenever security is a concern, particularly over untrusted networks. It replaces community strings with username-based security.
Never use the default community strings "public" and "private" in production. These are well-known defaults that attackers probe for routinely. If your devices only support SNMPv2c, at minimum change the community string to something unique and restrict SNMP access via ACLs.
MIBs and OIDs
SNMP data is organised in a tree structure called the Management Information Base (MIB). Each piece of data — an interface's traffic counter, a device's uptime, a fan's RPM — is identified by an Object Identifier (OID). Standard MIBs (like IF-MIB for interface statistics) are shared across vendors, while enterprise MIBs contain vendor-specific data. Your monitoring tool loads MIB files so it can translate numeric OIDs into human-readable names.
NetFlow: Traffic Analysis and Visibility
Where SNMP tells you how much traffic passes through an interface, NetFlow tells you what kind of traffic it is. Originally developed by Cisco, NetFlow (and the IETF-standardised successor IPFIX) exports metadata about every conversation (flow) traversing a router or switch. A flow record typically includes source/destination IP addresses, ports, protocol, byte count, packet count and timestamps.
This data allows you to answer questions like: Which application is consuming the most bandwidth? Which user is generating the most traffic? Is there an unusual spike to an unexpected destination? NetFlow is invaluable for capacity planning, billing, quality-of-service tuning and security forensics.
sFlow is an alternative that uses packet sampling rather than tracking every flow. It is lighter on device resources and is commonly implemented on switches from vendors like Ubiquiti, HP/Aruba and Juniper. While sFlow provides slightly less granularity than full NetFlow, it scales better on high-throughput devices and is perfectly adequate for most monitoring use cases.
Syslog: Centralised Event Logging
Syslog is the universal mechanism for network devices and servers to send log messages to a centralised collector. Every router reboot, every failed login attempt, every firewall rule match, and every configuration change can generate a syslog message. By aggregating these messages on a central server, you create a searchable audit trail that is essential for troubleshooting and compliance.
Syslog messages are categorised by facility (the source subsystem, such as kernel, auth or local0–local7) and severity (from 0/Emergency to 7/Debug). Most organisations configure devices to send messages at severity 6 (Informational) or lower to their syslog server, reserving debug-level logging for active troubleshooting sessions.
Always configure NTP (Network Time Protocol) on every device before enabling syslog. Accurate, synchronised timestamps are critical for correlating events across multiple devices during an incident investigation.
SNMP vs NetFlow vs Syslog
| Feature | SNMP | NetFlow / IPFIX | Syslog |
|---|---|---|---|
| Primary Purpose | Device health and metrics | Traffic flow analysis | Event and log aggregation |
| Data Type | Counters, gauges, status | Flow records (IP, port, bytes) | Timestamped text messages |
| Direction | Poll (manager to agent) + traps | Export (device to collector) | Push (device to server) |
| Typical Transport | UDP 161 (queries), UDP 162 (traps) | UDP 2055 / 9995 / 9996 | UDP 514 or TCP 514 (TLS: 6514) |
| Answers the Question | How is the device performing? | What is the traffic doing? | What events occurred? |
| Security Considerations | Use SNMPv3 for encryption | Flow data can reveal traffic patterns | Use TLS syslog for sensitive logs |
How They Work Together
The real power of network monitoring comes from combining all three protocols. Consider a scenario where a user complains about slow application performance:
- SNMP shows you that the uplink on a core switch is consistently hitting 95% utilisation during business hours.
- NetFlow reveals that a single workstation is streaming large backup jobs to a cloud provider during peak hours, consuming 40% of the link.
- Syslog confirms that the backup agent on that workstation was reconfigured yesterday, changing its schedule from overnight to midday.
Without all three data sources, you would struggle to diagnose this issue quickly. SNMP identifies the symptom, NetFlow pinpoints the cause, and Syslog provides the context.
Monitoring Tools: Free and Paid Options
A wide range of tools can ingest SNMP, NetFlow and Syslog data. Here are some of the most popular options:
- Zabbix (free, open-source) — excellent SNMP monitoring with templates for thousands of devices. Supports syslog ingestion. NetFlow requires a plugin or separate collector.
- LibreNMS (free, open-source) — auto-discovers devices via SNMP, includes syslog and basic alerting. Lightweight and easy to deploy on Linux.
- PRTG Network Monitor (commercial, free tier for 100 sensors) — all-in-one solution supporting SNMP, NetFlow, syslog, packet sniffing and more. Great for small to mid-sized organisations that prefer a polished GUI.
- Nagios / Nagios XI (open-source core, commercial XI) — the original infrastructure monitoring tool. Highly extensible through plugins. Steeper learning curve.
- Grafana + InfluxDB + Telegraf (free, open-source stack) — a modern approach using Telegraf to collect SNMP data, InfluxDB to store time-series metrics, and Grafana for beautiful dashboards.
Getting Started with Basic Monitoring
If you are starting from scratch, begin with these steps:
- Enable SNMPv2c or v3 on all managed switches, routers and firewalls. Configure a non-default community string and restrict access to your monitoring server's IP.
- Deploy a monitoring server — Zabbix or LibreNMS on a Linux VM is an excellent starting point. Import vendor templates and let auto-discovery find your devices.
- Point syslog from all devices to your monitoring server. Configure severity level 6 (Informational) or 5 (Notice) as the threshold.
- Enable NetFlow or sFlow on your core router or firewall. Install a compatible collector (ntopng, Elastiflow or the built-in collector in PRTG).
- Set up alerts for critical thresholds: interface down, CPU over 90%, link utilisation over 80%, and authentication failures in syslog.
SNMPv2c transmits community strings in plain text, so it is not safe over untrusted networks. On a dedicated management VLAN with ACLs restricting access to the monitoring server, SNMPv2c is acceptable for many organisations. For environments with strict compliance requirements, upgrade to SNMPv3 with authentication and encryption.
NetFlow (and IPFIX) tracks every flow passing through a device, providing detailed per-conversation metadata. sFlow samples packets at a configurable rate (e.g., 1 in 1000) and exports the sampled headers. sFlow is lighter on CPU but provides statistical rather than exact data. For most monitoring purposes, both are more than adequate.
Yes. Traditional syslog uses UDP port 514, which is fast but unreliable — messages can be lost during congestion. RFC 5424 defines syslog over TCP, and RFC 5425 adds TLS encryption on port 6514. Most modern syslog servers and network devices support TCP and TLS transport. Use TCP/TLS for compliance-sensitive environments.
It depends on the number of active flows and your retention policy. As a rough guide, a mid-sized network generating 10,000 flows per second produces approximately 25–50 GB of raw flow data per month. Aggregation, compression and shorter retention periods reduce storage significantly. Start with 30 days of retention and adjust based on your needs.
