Network Monitoring

Network Monitoring Scope

A large computer network contains many devices, links, and services whose state changes over time. Administrators need data from these elements to assess availability, performance, and security. Regular measurements of interfaces, resources, and events help reveal deviations and identify their causes.

A computer network, from a small business to a global corporation, includes routers, switches, servers, printers, and services that transport data. Network Monitoring continuously collects and analyzes information about these elements. The results help determine whether the network is operating, where a slowdown occurs, what causes it, and whether suspicious events are taking place. Monitoring can include device metrics, flow records, log messages, alerts, and selected packet captures. Each source describes a different part of the situation, so interpretation must account for measurement scope, sampling frequency, and recording time.

Part 1: SNMP, Monitoring Network Devices

The Simple Network Management Protocol, or SNMP, is used to query devices about their state and operating parameters. It supports data collection from routers, switches, servers, and other network devices.

A central monitoring station queries SNMP agents running on devices. Queries can cover CPU utilization, interface throughput, memory usage, temperature, and error counts. The agent returns values described by the MIB.

SNMP Architecture and Components

The SNMP framework is built upon three core components that work in concert:

1. SNMP Manager:

   This is the central application that actively queries devices. A Network Management Station (NMS) stores and processes collected data, displays graphs and dashboards, and generates alerts. Example NMS platforms include Zabbix, Nagios, and SolarWinds Orion.

2. SNMP Agent:

   The agent is software running on a managed device. It is available in routers, switches, servers, printers, and uninterruptible power supplies (UPS). It collects and maintains device data, listens for SNMP Manager queries, and returns responses.

3. Management Information Base (MIB):

   The meaning of objects and the interpretation of responses are defined by the Management Information Base (MIB). A MIB is a formal, structured description of variables reported by an agent. Objects form a hierarchical tree, and each has an Object Identifier (OID). The sequence $.1.3.6.1.2.1.1.1.0$ identifies sysDescr, the system description object.

How SNMP Communicates: Core Operations

The Manager and agent use several core operations:

• GET Request: The Manager requests the value of a specific OID from the agent.
• GET-NEXT Request: The Manager asks the Agent for the value of the OID that comes after a specific one in the MIB tree. This allows a Manager to "walk" the entire MIB tree of a device without knowing all the OIDs in advance. In SNMPv2 and SNMPv3, GET-BULK can retrieve a larger range of objects in one request, reducing the exchanges needed to read tables.
• SET Request: The Manager instructs the agent to change a writable variable. The operation can change configuration, so access is usually restricted by policy.
• TRAP: This is an unsolicited message sent by the agent to the Manager. The agent reports an event such as an interface failure, a device reboot, or CPU utilization exceeding a threshold.

The Evolution of SNMP Security

In practice, three main SNMP variants are encountered, and the protocol family has also evolved to add security mechanisms.

• SNMPv1:The original version. Authentication used an unencrypted "community string" sent with the request. Someone monitoring the traffic could capture it and read data or, with write permission, change the device configuration.
• SNMPv2c: This version introduced some protocol enhancements but continued to use the same flawed community string security model as v1. It remains insecure for modern use.
• SNMPv3: This version includes security mechanisms, including the User-based Security Model (USM), which provides three protection areas:
  • Authentication: Verifies message origin and integrity with an HMAC mechanism. Modern implementations may support HMAC-SHA-2.
  • Privacy: Provides data confidentiality through encryption. AES is used for this purpose; DES should be treated as an older algorithm.
  • Replay protection: USM checks message timeliness and rejects messages outside the permitted time window.
  SNMPv3 offers three security levels: 'noAuthNoPriv' (no authentication or privacy), 'authNoPriv' (authentication without encryption), and 'authPriv' (authentication and privacy). For management across an untrusted network, use 'authPriv' and restrict access with VACM. VACM determines which MIB objects a user may read, write, or receive in notifications. Algorithm choices depend on implementation support and organizational policy, so the configuration should be reviewed before deployment. The SNMPv3 architecture includes an SNMP engine, a message-processing subsystem, a security subsystem, and an access-control subsystem. This separates message authentication from permissions to MIB objects. Using SNMPv3 alone does not give a user permission to change configuration. An SNMP deployment also depends on managers, agents, and MIB modules. The manager can poll values at a chosen interval, while an agent can send an unsolicited notification for an event. Polling intervals and notification handling should be chosen so that monitoring does not overload a device or conceal short-lived failures.

Part 2: NetFlow and Flow Records

SNMP describes device state and interface counters, but it does not record the details of individual flows. A traffic-volume value alone does not identify which sources, destinations, and protocols account for the load.

IPFIX is the IETF standard for exporting flow information, while NetFlow is a family of formats developed by Cisco. Both support flow-based monitoring, but record formats and available fields depend on the version and implementation.

NetFlow and IPFIX export records describing flows. A router or switch observes packets and creates metadata for successive flows. A flow is a sequence of packets traveling in one direction between the same endpoints and sharing key attributes.

The NetFlow Architecture

Similar to SNMP, NetFlow has several components:

• Exporter: The network device (e.g., a router) that observes the live traffic, creates the metadata records for each flow, and exports these records.
• Collector: A dedicated server that listens for, receives, and stores the flow records sent by one or more exporters.
• Analyzer: A software application that processes the vast amount of raw flow data stored in the collector. It correlates the data and presents it to administrators through visualizations, reports, and alerts.

In IPFIX terminology, an exporter performs the metering process and a collector receives records from the exporting process. A template describes the record fields, allowing the collector to interpret subsequent data correctly. A flow record describes metadata and statistics; it does not replace packet-content capture. Deployments may use sampling, aggregation, and filters to reduce exporter and collector load. These settings must be documented because the record count may not equal the number of packets. IPFIX can extend the field set without changing the basic export model. Flow records commonly support questions about top talkers, application ports, interface utilization, and communication with unusual destinations. Their timestamps and byte counters help reconstruct a sequence of events, while packet capture is reserved for inspecting protocol content.

The Anatomy of a Flow Record

A single flow record summarizes metadata and does not contain packet contents. A classic NetFlow v5 record contains a 7-tuple:

• Source IP Address
• Destination IP Address
• Source Port Number
• Destination Port Number
• Layer 3 Protocol Type (e.g., TCP, UDP)
• Type of Service (ToS) marking
• Input Logical Interface

In addition to these identifying keys, the record also includes statistics like the total number of bytes and packets in the flow, and the start and end timestamps. Newer, template-based versions like NetFlow v9 and IPFIX can include hundreds of additional fields, such as TCP flags, VLAN IDs, and much more.

Key Use Cases for Flow Data

Flow metadata supports performance and security analysis:

• Bandwidth Analysis: NetFlow shows which users, applications, and flows consume the most bandwidth. The data supports troubleshooting slowdowns, capacity planning, and enforcement of usage policies. For example, it can identify whether a slow connection is caused by a user running an unauthorized peer-to-peer application.
• Security Forensics and Anomaly Detection: Flow data provides an audit trail of network activity. If a host is infected with malware, flow records show other devices it contacted, the ports it used, and the amount of data it sent, helping to identify the scope of the compromise. They can also detect anomalies, such as a server that normally receives web traffic suddenly trying to send a large volume of email, which could indicate a spam-bot infection.

A Network Monitoring Strategy

SNMP and NetFlow/IPFIX provide different data and can be used together. An effective monitoring strategy combines device metrics with flow information.

SNMP for Device State, NetFlow for Flows. Use SNMP to monitor CPU load, memory usage, temperature, interface errors, and TRAP notifications about hardware events. Use NetFlow or IPFIX to describe communication peers, protocols, and suspicious traffic patterns.

These data sources can be supplemented with others:

• Syslog: A standard for forwarding log event messages. For example, SNMP may show CPU utilization at 95%, while Syslog may contain the process error that caused the increase.
• Packet Capture (e.g., Wireshark): For detailed troubleshooting, capturing full packet content can show protocol data that flow records omit. It does not scale to continuous network-wide monitoring, but it remains useful for forensic analysis of a specific problem.

Monitoring logs and flow records should be sent to a protected central store. The administrator defines event coverage, retention, time synchronization, alert rules, and read permissions. This preparation supports data correlation and evidence preservation after an incident. Useful events include logins, configuration changes, service errors, administrative operations, and firewall activity. Logs should have integrity protection and an off-system copy. Retention should match organizational requirements and the analysis purpose, while an alert should identify its source, time, and triggering condition. A baseline of normal device and flow behavior makes threshold selection more precise. Administrators can compare current values with historical intervals, document expected maintenance windows, and send priority alerts to an incident response process. Monitoring data should be protected from unauthorized changes because it may contain operational or security-sensitive information. Synchronized clocks help correlate records from different devices. Central storage should restrict administrative access, preserve an off-site copy, and record actions performed on the monitoring data.

Effective monitoring combines device metrics, flow records, logs, and packet captures. Centralizing and correlating these data sources helps detect deviations and reconstruct an incident.