Monitoring a network and reading its signals

Why this matters

You cannot troubleshoot what you cannot see, and you cannot tell that something is abnormal without knowing what normal looked like. Monitoring is what supplies both.

Objective 3.2 is "given a scenario, use network monitoring technologies", and the scenarios are about choosing the right instrument. SNMP, flow data and packet capture answer different questions at wildly different costs, and picking the wrong one is how you end up with terabytes of capture and no answer.

The lesson

Monitoring solutions and network discovery

A monitoring solution is the platform that collects, stores, displays and alerts on data from across the estate. Whatever the product, it does the same four things: gather, store, visualise, notify.

Network discovery is how it learns what exists. Rather than someone typing in every device, the platform finds them — by scanning address ranges, by walking SNMP, by reading neighbour protocols such as LLDP and CDP, or by querying switches for their MAC and ARP tables.

Discovery matters for a reason beyond convenience: you cannot monitor what you do not know about, and the devices nobody remembers are exactly the ones that fail unnoticed. Scheduled rediscovery also surfaces devices that appeared without going through change management, which is a security control as much as an operational one.

Methods: SNMP

The objective groups the collection methods — SNMP, flow data and packet capture — because choosing between them is the skill. Each answers a different question at a different cost.

Simple Network Management Protocol is the oldest and most widely supported way to ask a device how it is. It runs on UDP 161 for queries and UDP 162 for traps.

The pieces:

An agent runs on the managed device. A manager — the monitoring platform — polls agents and receives their traps.

The MIB (Management Information Base) is the structured catalogue of what a device can report. Every value has an OID (object identifier), a dotted-numeric address in a hierarchy — interface counters, CPU, temperature, uptime. The MIB is what turns "ask the switch how it is" into a specific question with a specific answer.

Two directions of communication, and the distinction is examined:

Polling is the manager asking, on a schedule — every five minutes, say. It gives you regular data points suitable for graphing, and it means a problem arising just after a poll is invisible until the next one.

Traps are the agent telling the manager, unsolicited, the moment something happens — a link goes down, a power supply fails, a threshold is crossed. They are immediate, and because they are UDP they can be lost silently. Informs are acknowledged traps, which fixes that at the cost of more traffic.

The practical design uses both: polling for trends and capacity, traps for events you cannot wait five minutes to hear about.

SNMP versions, and the security difference

The version question is really a security question, and it is the most likely SNMP exam item.

v1 is the original. Community strings in plain text, limited counters. Obsolete.

v2c is the common one in the field. It adds better performance, 64-bit counters — which matter, because a 32-bit counter on a gigabit link wraps in seconds and produces nonsense graphs — and bulk retrieval. The "c" stands for community-based, and that is the problem: authentication is still a community string sent in clear text.

A community string is a shared password, and there are conventionally two: a read-only one and a read-write one. The defaults are public and private, and they are the first thing an attacker tries. A device left on defaults with read-write community access can be reconfigured by anyone who can reach it.

v3 is the secure version, and the reason to prefer it. It provides three things v2c does not:

• Authentication of the message, so the manager knows the data genuinely came from that device and vice versa.
• Integrity, so a message cannot be altered in flight.
• Encryption (privacy), so the contents cannot be read by an observer.

v3 has three security levels: noAuthNoPriv (neither), authNoPriv (authenticated, not encrypted) and authPriv (both). Only the last is genuinely secure, and it is what a question asking for "the most secure SNMP configuration" wants.

The summary: v2c sends a password in clear text; v3 authenticates and encrypts. If a scenario mentions SNMP over an untrusted path, or sensitive device data, the answer is v3 with authPriv.

Flow data

Flow data — NetFlow, sFlow, IPFIX and J-Flow — records conversations rather than contents. For each flow it captures source and destination address and port, protocol, start and end time, and byte and packet counts.

That is a deliberate middle ground:

• SNMP tells you an interface is 90% utilised. It cannot tell you by whom.
• Flow data tells you who is talking to whom, how much, and when.
• Packet capture tells you exactly what was said, at enormous cost.

So flow answers the question that actually gets asked when a link saturates: which host, which service, which destination. It is far smaller than full capture, can be kept for months, and is the right default for capacity planning, billing, and spotting a machine suddenly talking to somewhere unusual.

Note the sampling distinction, since it appears in comparisons: NetFlow typically examines every flow, while sFlow samples packets at a fixed rate, which is cheaper on the device and statistically representative rather than exact.

Packet capture

Packet capture records the actual frames — headers and payload. Tools are tcpdump at the command line and Wireshark for analysis.

It is the most detailed tool available and the most expensive. A busy link generates capture files faster than you can store them, so capture is targeted: a specific host, a specific port, a specific window of time, using capture filters to limit what is written.

Use it when you need to see inside the conversation: a handshake that is failing, a protocol negotiation, a malformed response, a retransmission pattern, which side sent a reset. Those questions cannot be answered by counts.

Two constraints worth carrying. Encrypted traffic stays encrypted — you see the handshake, the certificate and the sizes and timing, not the contents. And capture is privacy-sensitive: recording traffic can record credentials and personal data, so it needs authorisation and a retention policy. The next lesson covers how you get traffic to the capture device in a switched network, which is not as simple as plugging in.