Network Monitoring 101: SNMP, Syslog, NetFlow and Alerts That Matter

If your users are your monitoring system, you find out about problems last, and you find out with the least useful information possible: “the internet is slow.” Effective network monitoring flips that around. It tells you a link is saturating before calls start dropping, shows you which application filled the WAN, and records exactly when an interface flapped. This guide covers the three foundational data sources, SNMP, syslog and NetFlow, with secure configuration examples, the ports you need to allow, a syslog severity reference, and a practical approach to alerts that people actually respond to.

What network monitoring should achieve

Before choosing tools or protocols, be clear about the questions monitoring has to answer. Most of them fall into four groups:

• Availability: Is the device, link or service up and reachable right now?
• Performance: How busy are links and devices? Are there errors, drops, latency or jitter?
• Capacity: How is usage trending? When will this WAN circuit or uplink run out of headroom?
• Events and security: What changed, who logged in, what failed, and is traffic behaving unusually?

Each data source covers some of these questions well and others poorly. SNMP polling is the workhorse for availability, performance and capacity metrics. Syslog and SNMP traps capture events as they happen. Flow data such as NetFlow and IPFIX explains what traffic is on the network and who is sending it. Add basic synthetic checks, such as ICMP reachability and DNS or HTTP tests, and you have a complete picture. None of the three replaces the others, which is why a mature monitoring setup collects all of them and correlates them by time.

SNMP: polling metrics and receiving traps

The Simple Network Management Protocol lets a manager (your monitoring system) read values from an agent (the device). Each value is identified by an object identifier (OID) defined in a Management Information Base (MIB). For example, sysUpTime is 1.3.6.1.2.1.1.3.0 and the 64-bit inbound octet counter for an interface lives under ifHCInOctets, 1.3.6.1.2.1.31.1.1.1.6, from the IF-MIB defined in RFC 2863.

SNMP works in two directions:

• Polling: the manager sends Get, GetNext or GetBulk requests to the agent on UDP port 161 and receives responses.
• Notifications: the agent sends traps (unacknowledged) or informs (acknowledged and retransmitted) to the manager on UDP port 162 when something happens, such as a link going down.

SNMP versions

SNMPv3 defines three security levels: noAuthNoPriv (username only), authNoPriv (authenticated, not encrypted) and authPriv (authenticated and encrypted). Use authPriv everywhere you can. Community strings in v1 and v2c are effectively passwords sent in plain text, and a read-write community is a remote configuration interface for anyone who captures it.

Why 64-bit counters matter

Interface counters are cumulative; your monitoring system calculates throughput from the difference between two polls. A 32-bit octet counter wraps after 4,294,967,296 bytes. At a sustained 1 Gbps that takes only about 34 seconds, and at 10 Gbps about 3.4 seconds. With a five-minute polling interval, a 32-bit counter can wrap undetected on any link averaging more than roughly 114 Mbps, giving you nonsense graphs. Always poll the high-capacity counters (ifHCInOctets, ifHCOutOctets) and use ifHighSpeed, which reports interface speed in Mbps, for utilization calculations:

Utilization (%) = (delta octets × 8) ÷ (poll interval in seconds × interface speed in bits per second) × 100

For example, 3,000,000,000 octets transferred in a 300-second interval on a 1 Gbps interface is (3,000,000,000 × 8) ÷ (300 × 1,000,000,000) × 100 = 8% average utilization. Remember that a five-minute average hides short bursts; a link averaging 40% can still drop packets during microbursts.

Configuring SNMPv3 on Cisco IOS

The configuration below creates a read-only SNMPv3 group restricted by an access list, a user with SHA authentication and AES encryption, and trap delivery to the monitoring server. Replace the passphrases with long, unique values from your password manager.

ip access-list standard ACL-SNMP
 permit host 192.0.2.50
 deny any log
!
snmp-server view NMS-VIEW iso included
snmp-server group NMS-RO v3 priv read NMS-VIEW access ACL-SNMP
snmp-server user nmsuser NMS-RO v3 auth sha AUTH-PASSPHRASE priv aes 128 PRIV-PASSPHRASE
!
snmp-server location HQ, Floor 2, IDF-2B, Rack 03
snmp-server contact [email protected]
snmp-server ifindex persist
snmp-server trap-source Loopback0
snmp-server enable traps snmp linkdown linkup coldstart warmstart
snmp-server enable traps config
snmp-server enable traps envmon
snmp-server host 192.0.2.50 version 3 priv nmsuser

A few details are worth knowing. The priv keyword on the group enforces authPriv, so a request without encryption is rejected. The access clause limits which source addresses can poll. SNMPv3 users are not displayed in show running-config; verify them with show snmp user and show snmp group, and remember that a configuration restored from backup will not recreate them. snmp-server ifindex persist keeps interface indexes stable across reloads so your graphs do not jump between interfaces. Where both your devices and monitoring platform support them, use stronger options such as AES-256 and SHA-2 family authentication. Finally, remove any legacy community strings with no snmp-server community.

Test from the monitoring server with the Net-SNMP tools before adding the device to your platform:

snmpwalk -v3 -l authPriv -u nmsuser -a SHA -A 'AUTH-PASSPHRASE' \
  -x AES -X 'PRIV-PASSPHRASE' 192.0.2.11 1.3.6.1.2.1.1

snmpget -v3 -l authPriv -u nmsuser -a SHA -A 'AUTH-PASSPHRASE' \
  -x AES -X 'PRIV-PASSPHRASE' 192.0.2.11 1.3.6.1.2.1.31.1.1.1.6.1

Syslog: severity levels and central logging

Syslog is the event log of your network. Every interface flap, configuration change, login, routing adjacency change and hardware warning produces a message. The modern message format is defined in RFC 5424, transport over UDP in RFC 5426 and transport over TLS in RFC 5425. By default devices send to UDP port 514; syslog over TLS uses TCP port 6514.

Syslog severity levels 0 to 7

Every message carries a severity. Lower numbers are more severe, and when you configure a logging level on a device, it sends that level and everything more severe.

Sending level 6 (informational) to your central log server is a sensible default: you capture configuration changes, adjacency changes and interface events without debug noise. Keep the console at a low verbosity so a flood of messages cannot make the console unusable during an incident.

Syslog configuration on Cisco IOS

ntp server 192.0.2.123
service timestamps log datetime msec localtime show-timezone
service sequence-numbers
!
logging buffered 64000 informational
logging console critical
logging trap informational
logging origin-id hostname
logging source-interface Loopback0
logging host 192.0.2.60

Millisecond timestamps with the time zone shown make correlation across devices possible, sequence numbers reveal lost messages, and a fixed source interface means the log server always sees the same address for each device. The local buffer gives you recent history even if the log server is unreachable. Because UDP syslog is unacknowledged and unencrypted, consider TLS transport for sensitive environments where both ends support it, and always restrict who can send to your collector.

NetFlow and IPFIX: who is using the network

SNMP tells you a link is 95% utilized. Flow data tells you why. A flow is a set of packets sharing common properties, typically source and destination addresses, ports, protocol, type of service and input interface. The device keeps a cache of active flows and exports summary records, such as byte and packet counts and timestamps, to a collector.

• NetFlow v5 has a fixed IPv4-only record format; it is still widely supported but inflexible.
• NetFlow v9 (described in RFC 3954) introduced templates, so records can carry IPv6 and other fields.
• IPFIX (RFC 7011) is the IETF standard derived from v9 and is the best choice where supported.
• sFlow takes a different approach, exporting sampled packet headers plus interface counters, and is common on high-speed switches.

Flow data answers questions like which hosts are the top talkers on the WAN, which applications consume the most bandwidth, whether a host is scanning the network, and what traffic crossed a boundary during a security incident. It is equally valuable for capacity planning and for proving whether a performance complaint is a network issue at all.

Flexible NetFlow configuration on Cisco IOS-XE

Flexible NetFlow separates the flow definition (record), the destination (exporter) and the cache settings (monitor), then applies the monitor to interfaces:

flow record FR-IPV4
 match ipv4 tos
 match ipv4 protocol
 match ipv4 source address
 match ipv4 destination address
 match transport source-port
 match transport destination-port
 match interface input
 collect interface output
 collect counter bytes long
 collect counter packets long
 collect timestamp sys-uptime first
 collect timestamp sys-uptime last
!
flow exporter FE-COLLECTOR
 destination 192.0.2.70
 source Loopback0
 transport udp 2055
 export-protocol netflow-v9
 template data timeout 60
!
flow monitor FM-IPV4
 exporter FE-COLLECTOR
 record FR-IPV4
 cache timeout active 60
 cache timeout inactive 15
!
interface GigabitEthernet0/0/1
 description WAN
 ip flow monitor FM-IPV4 input
 ip flow monitor FM-IPV4 output

Verify with show flow monitor FM-IPV4 cache and show flow exporter statistics. The active timeout of 60 seconds makes long-lived flows report regularly rather than only when they end, which keeps graphs accurate. Create a matching IPv6 record if you run dual-stack, as described in our IPv6 guide. On busy links or platforms with limited resources, use sampled flow export; you lose some precision but keep the trends.

Ports and firewall rules for monitoring

Monitoring traffic often crosses firewalls between the management network and devices in other zones. Allow only what is needed, only between the specific monitoring hosts and devices:

Our port lookup tool is handy when you need to check other services quickly. Treat the management plane as sensitive: restrict SNMP with access lists on the device as well as the firewall, as recommended in our firewall hardening checklist.

Designing alerts that matter

Collecting data is the easy part. The hard part is turning it into alerts that are rare enough to be taken seriously and reliable enough that nothing important is missed. An alert that fires every day and is always ignored trains your team to ignore alerts, including the one that matters.

Principles for good alerts

• Every alert must be actionable. If the response is “nothing, it will clear on its own,” it should not be an alert. Put it on a dashboard instead.
• Use duration and hysteresis. Alert when a WAN link exceeds 85% utilization for 15 minutes, not on a single sample, and clear only when it falls below a lower threshold such as 70%, so the alert does not flap.
• Model dependencies. If a branch router is down, suppress alerts for every switch and access point behind it. One alert with the root cause beats forty symptoms.
• Separate urgency levels. Pages are for issues that hurt users now. Tickets are for issues that need attention within a business day. Everything else is a report.
• Link to a runbook. Every alert should tell the responder what it means and where the procedure is.
• Respect maintenance windows. Planned reloads should not wake anyone up.
• Review regularly. Once a month, look at which alerts fired most and which were ignored, then tune or delete them.

A starter alert set

When an alert does fire, the data you have collected becomes your evidence: utilization graphs, the syslog sequence around the event and flow records for the affected link. Use it with a disciplined troubleshooting methodology instead of guessing.

Building your monitoring stack step by step

There are capable open-source and commercial monitoring platforms, and the right choice depends on your size, skills and budget. Whatever you choose, the rollout follows the same order:

1. Fix the foundations: NTP everywhere, consistent hostnames, a dedicated management network or VLAN, and loopback or management source interfaces.
2. Start with availability: ICMP and SNMPv3 polling of every infrastructure device, plus traps for link and hardware events.
3. Centralize logs: send syslog from every device at informational level, retain it for a period that satisfies your security and compliance needs, and alert on key messages.
4. Add performance and capacity: interface utilization, errors and discards on uplinks and WAN links, CPU and memory, with at least a few weeks of baseline before setting thresholds.
5. Add flow data on internet and WAN edges first, then expand to data center or core links as needed.
6. Tune alerts continuously and automate device onboarding so new equipment is monitored from day one; the techniques in our network automation guide help here.

A baseline is the most underrated part of this process. Knowing that a link normally peaks at 40% on Monday mornings is what makes 80% meaningful, and it is the only defensible basis for a capacity upgrade request.

Key takeaways

• SNMP, syslog and flow data answer different questions; a complete monitoring setup uses all three, correlated by accurate NTP time.
• Use SNMPv3 with authPriv, restrict it with access lists, and always poll 64-bit interface counters.
• Know the ports: SNMP UDP 161 and 162, syslog UDP 514 or TCP 6514 for TLS, IPFIX 4739, and conventional NetFlow ports such as 2055.
• Syslog severities run from 0 (emergency) to 7 (debug); send informational (6) to a central server and alert on key messages.
• Flow data explains what traffic is on a link, which turns “the network is slow” into a specific, solvable problem.
• Make every alert actionable, use durations and dependencies, separate pages from tickets, and review alert noise regularly.

Not sure whether your monitoring would catch the next outage before your users do? Our Network Health Assessment reviews your visibility, configuration and alerting and gives you a prioritized improvement plan. For anything else, get in touch.