Network Monitoring: SNMP, Syslog and NetFlow

Monitoring data types

No single source is enough. Interface utilisation without flow data cannot identify the consumers; flow data without logs may not explain a routing flap; logs without time synchronisation can be misleading.

SNMP concepts

SNMP managers query or receive notifications from agents. Managed objects are identified by OIDs organised in MIB modules. Common operations include GET, GETNEXT, GETBULK, SET and notifications such as traps/informs.

Use read-only access where possible, restrict manager source addresses, rotate credentials, use SNMPv3 authPriv when supported and avoid exposing SNMP to untrusted networks.

Syslog severity and design

Lower numeric values are more severe. Centralise logs, use reliable transport/TLS where appropriate, normalise device time with NTP and retain logs according to operational, legal and privacy requirements.

NetFlow and IPFIX

Flow exporters summarise packets sharing selected keys, such as source/destination addresses, ports, protocol and interface. A collector stores and analyses records; a reporting platform produces top talkers, conversations, trends and anomaly views.

• Ingress and egress observation points answer different questions.
• Sampling reduces exporter and collector load but affects exact counts.
• Short active/inactive timeouts improve visibility for long or completed flows at a storage cost.
• NAT devices may expose pre-translation and post-translation fields depending on exporter support.
• Encrypted payloads still reveal useful metadata, but application identity may be limited.

Baselines and useful alerts

A baseline captures normal variation by device, interface, hour and business cycle. Static thresholds alone create noise: 80% utilisation may be normal for a backup window but abnormal at another time.

• Alert on sustained interface errors/discards, not one isolated counter change.
• Correlate peer-down alerts with interface, power and upstream events.
• Use dependency suppression so one failed core device does not generate hundreds of duplicate alerts.
• Alert on missing telemetry, because silence can mean the monitor or path has failed.
• Route alerts to an owner with a runbook and meaningful context.

Useful device checks

show interfaces counters errors
show processes cpu
show memory statistics
show logging
show snmp
show snmp user
show flow exporter
show flow monitor
show ntp associations

Telemetry troubleshooting

1. Verify source interface/address and routing from device to collector.
2. Check ACL/firewall policy and expected UDP/TCP transport.
3. Confirm credentials, SNMP view, engine ID and time window for SNMPv3.
4. Check collector listening port and parser/template support.
5. For flow, verify monitor attachment, direction, exporter and template refresh.
6. For syslog, confirm severity threshold and facility/filter rules.
7. Check NTP and timezone before correlating events.
8. Measure packet loss and collector capacity during event storms.

Interview focus

Use these points to practise concise, operations-focused answers. Explain the concept first, then give a verification or troubleshooting example.

• What is the difference between SNMP polling and a trap? Polling is manager-initiated retrieval; a trap is an unsolicited notification from the agent.
• Why is SNMPv3 preferred? It supports user-based authentication and privacy/encryption options.
• Which syslog severity is more urgent: 2 or 6? Severity 2 is more urgent; lower numbers are more severe.
• What does flow telemetry provide? Metadata summarising conversations, endpoints, ports, volume and timing.
• Why is NTP important for monitoring? Accurate shared time is necessary to correlate events across devices.

Quick self-check

Frequently asked questions

Standards and further reading

• RFC 3411 — Architecture for SNMP Management Frameworks
• RFC 5424 — The Syslog Protocol
• RFC 7011 — IP Flow Information Export (IPFIX) Protocol

Continue learning