Network Monitoring — N10-009 Study Guide

Three data sources, three questions

Start with the question you need answered, and the right monitoring tool falls out of it. "Is this switch up and how busy is it?" is a device-health question, and SNMP (Simple Network Management Protocol)^[1] answers it by polling counters. "Which two hosts are saturating the uplink, and how much are they pushing?" is a traffic question, and flow data^[2] answers it from conversation metadata. "What exactly did that host send?" is a content question, and only full packet capture, which saves every byte, answers it.

These three sit on a deliberate cost ladder. SNMP and flow records are compact: a flow entry is a few hundred bytes summarizing a whole conversation, so you can keep weeks of it. Full capture stores the literal payload, so a busy link fills disks in hours and retention is short. The exam rewards reaching for the lightest tool that answers the question. If a flow record already shows host A pushed 40 GB to host B, you do not stand up a packet capture to learn the same thing at a thousand times the storage cost.

A fourth source, the event log, runs underneath all three. Devices emit log messages about what happened to them, and centralizing those logs (via syslog) and correlating them (via a SIEM) turns scattered events into one timeline. Sections below take each source in turn: SNMP first, then flow versus capture, then logging and baselines, then the exam tells that separate them.

Each monitoring data source answers a different question and sits on a different storage-cost rung; reach for the lightest one that answers the question.

SNMP: manager, agent, MIB, and traps

SNMP is a manager-agent system. The manager is the monitoring station, and an agent runs on each managed device (switch, router, firewall, printer, server). Every value the agent can report or accept lives in the Management Information Base (MIB)^[1], a hierarchical catalog of data points, and each individual value is named by an object identifier (OID), a dotted-number path such as the one for an interface's inbound byte count. When you point a monitoring tool at a device, it is walking that OID tree.

Three message patterns carry the work. The manager sends GET to read a value (poll the CPU, poll an interface counter) and SET to change one (rare, and a reason to lock SNMP down). Polling is scheduled, so it only sees a problem at the next interval. To close that gap the agent sends a TRAP: an unsolicited message it pushes the instant something notable happens, such as a link going down or a threshold being crossed. A TRAP is fire-and-forget; an INFORM is the same idea but acknowledged, so the agent resends if the manager does not confirm receipt. The exam tell is direction and trigger: scheduled pull is a GET poll; an unsolicited "device just went down" push is a TRAP.

Use v3, not v1 or v2c

Version choice is a security decision, not a feature decision. SNMPv1 and v2c authenticate with a community string, a shared secret sent in cleartext on the wire, so anyone sniffing the segment reads it and can then query or even reconfigure the device. SNMPv3^[1] replaces that with the User-based Security Model, adding per-message authentication (the message came from who it claims and was not altered) and privacy (the message is encrypted). When an answer choice contrasts the versions, v3 is the secure one; community strings are the cleartext liability.

SNMP manager-agent flow: scheduled GET polls pull status; the agent pushes an unsolicited TRAP on a notable event. RFC 3411.

Flow data versus full packet capture

Flow data and packet capture answer adjacent questions, and confusing them is a common exam trap, so fix the one-line difference first: flow data is metadata about conversations, packet capture is the conversation itself. A flow is a unidirectional sequence of packets sharing common properties, and a flow record summarizes it as source and destination IP, source and destination port, protocol, byte count, packet count, and timestamps. It deliberately omits the payload. That is exactly what you want for capacity planning and anomaly detection: you can see that a host suddenly opened thousands of small outbound flows (beaconing) or that one pair of hosts now dominates the link, cheaply and over a long window.

The flow family has three names worth knowing. NetFlow^[2] is Cisco's original export protocol (v9 is the common version). sFlow is a sampling-based alternative that exports every nth packet's header plus interface counters, trading exactness for very low overhead on high-speed switches. IPFIX (IP Flow Information Export)^[3] is the IETF standard built from NetFlow v9, so it is the vendor-neutral, standardized form of the same idea. For the exam, treat them as one category, flow data, and remember that none of them carry payload.

Full packet capture is the opposite trade. A protocol analyzer (a sniffer) saves every byte, header and payload, so you can read application content and reconstruct an entire session. That power costs storage and search time, so capture is for deep, targeted troubleshooting and forensics, not for always-on volume monitoring. To capture traffic that is not destined for the analyzer itself, you copy it to the analyzer using port mirroring, also called a SPAN (Switched Port Analyzer) session, which duplicates traffic from one or more ports to the analyzer port; a hardware tap does the same job inline. The decision rule: need volumes and conversations, use flow; need the actual bytes, capture; and never reach for capture just to measure how much traffic flowed.

Flow versus capture turns on one question: do you need payload content? Flow gives cheap metadata; capture gives the bytes at high storage cost.

Logs, syslog severity, SIEM, and baselines

Devices generate event messages constantly, and the value comes from getting them off the device and into one place. Syslog is the standard that does this: each device sends its log messages to a central syslog collector, which both protects the records (a copy already shipped off-host survives a local wipe by an attacker) and lets you search every device's events in one query. Two fields classify each message. The facility says which subsystem produced it (kernel, mail, authentication, and so on; facility values run 0 to 23). The severity ranks how urgent it is on a fixed 0-to-7 scale, and the direction surprises people: lower is worse. Severity 0 is Emergency^[4] (system unusable) and 7 is Debug, with Alert, Critical, Error, Warning, Notice, and Informational in between. A filter "severity 3 and below" therefore means Error, Critical, Alert, and Emergency, the messages you actually act on.

SIEM correlates; sensors detect

A Security Information and Event Management (SIEM) system is the aggregation and correlation hub, defined as software that provides centralized logging for many log types^[5]. It ingests syslog, flow records, and device logs, normalizes them, and correlates events across sources into one storyline, for example tying a firewall port scan to a later endpoint malware alert and a data upload. The SIEM is not a sensor: it does not itself scan for malware or block files, so an answer that names the SIEM as the thing that "blocks" traffic is using it as a distractor. Its job is to see the pattern no single device could.

Baselines and metrics

A performance baseline is a recorded picture of normal: CPU and memory utilization, interface throughput, error and discard counters, and round-trip latency, sampled over time. It is the reference an alert threshold is measured against, because "CPU at 70%" only means something once you know normal is 20%. Establish the baseline first, then alert on deviation from it. Modern platforms increasingly pull this telemetry through device APIs (streaming telemetry) instead of, or alongside, SNMP polling, which lets a device push fine-grained metrics continuously rather than waiting to be polled.

Syslog severity is inverted: 0 Emergency is most urgent and 7 Debug is least. RFC 5424.

Exam-pattern recognition

Questions in this area almost always describe a goal and ask which tool fits, so train on the keyword-to-tool mapping. "Which two hosts are talking and how much, without reading the data" points to flow data (NetFlow/sFlow/IPFIX); the giveaway is volume or top-talkers plus no payload. "You must see the actual contents of the packets" or "reconstruct what was sent" points to full packet capture, fed by a SPAN/port mirror. "An interface went down and the device sent an alert on its own" is an SNMP trap, because it is unsolicited; if instead the tool checks status "every five minutes," that is SNMP polling (a GET). "Centralized logging from all devices on one server" is syslog; "correlate events across the firewall, the endpoint, and the server into one incident" is the SIEM.

Watch three specific distractors. First, version security: if the stem worries about credentials being readable on the wire, the answer is SNMPv3, and SNMPv1/v2c (community strings in cleartext) is the wrong choice the question dangles. Second, severity direction: a question that treats severity 7 as the most critical is inverting the scale; 0 Emergency is the most urgent and 7 Debug the least. Third, role confusion: a SIEM aggregates and correlates, it does not scan for malware or block traffic, so an option that has the SIEM "blocking" a file is mislabeling a sensor's job. The overall meta-pattern is the cost ladder: when two tools could technically work, the exam wants the lighter one that still answers the question, so flow beats capture for volume, and a poll beats a capture for a simple up/down check.

SNMP vs flow data vs full packet capture

Attribute	SNMP	Flow data (NetFlow/sFlow/IPFIX)	Full packet capture
Question it answers	Is the device up and how loaded?	Who talked to whom and how much?	What exactly was sent?
Data collected	Device health counters via MIB/OID	Conversation metadata (IPs, ports, bytes, times)	Every byte, including payload
Payload visible	No	No	Yes
Storage cost	Low	Low to moderate	High (short retention)
How it is gathered	Manager polls agents; agents send traps	Device or sampler exports flow records	Analyzer reads a SPAN/mirror or tap copy
Typical use	Uptime and load monitoring, alerting	Baselining, top talkers, anomaly detection	Deep forensic / application troubleshooting

Decision tree

Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

Match the monitoring tool to the question: health, conversations, or content

Pick the monitoring data source by what you need to learn. SNMP answers whether a device is up and how loaded it is, flow data answers who talked to whom and how much, and full packet capture answers what exactly was sent. Reaching for a heavier tool than the question needs wastes storage and time, so when a flow record already shows which two hosts saturate a link, you do not stand up a full capture to learn the same thing.

Trap Running full packet capture to measure traffic volume; flow data answers who-and-how-much at a fraction of the storage cost.

SNMP is a manager-agent system addressed through the MIB by OID

Simple Network Management Protocol (SNMP) has a manager (the monitoring station) talk to an agent on each managed device. Every readable or settable value lives in the Management Information Base (MIB), a hierarchical catalog, and each value is named by an object identifier (OID), a dotted-number path. Pointing a monitoring tool at a device walks that OID tree to collect counters like interface byte counts.

5 questions test this

GET polls, SET writes, TRAP and INFORM push events

SNMP uses GET to read a value on a schedule and SET to change one, while the agent uses TRAP to push an unsolicited notification the instant something notable happens, such as an interface going down. A TRAP is fire-and-forget; an INFORM carries the same content but is acknowledged, so the agent resends if the manager does not confirm. The exam tell is direction and trigger: a scheduled status pull is a GET poll, an unsolicited device-down push is a TRAP.

Trap Calling a scheduled, manager-initiated status check a trap; polling is a GET pull, a trap is the agent's unsolicited push.

6 questions test this

Use SNMPv3 because v1 and v2c send the community string in cleartext

SNMPv1 and v2c authenticate only with a community string, a shared secret transmitted in cleartext, so anyone sniffing the segment reads it and can then query or reconfigure the device. SNMPv3 replaces that with the User-based Security Model, adding per-message authentication and encryption (privacy). When a question contrasts the versions or worries about credentials readable on the wire, v3 is the secure answer.

Trap Choosing SNMPv2c for a security-sensitive segment; its community string is sent in cleartext, so only v3 provides authentication and encryption.

7 questions test this

Flow data is conversation metadata, never payload

A flow record summarizes a conversation as source and destination IP, source and destination port, protocol, byte count, packet count, and timestamps, and deliberately omits the payload. That makes it cheap to store over long windows and ideal for capacity planning, finding top talkers, and spotting anomalies like a host beaconing out or a sudden volume spike. Because it carries no payload, it can never show you what was inside a packet.

Trap Expecting flow data to reveal packet contents; flow records carry only metadata, so payload inspection needs full capture or IDS.

NetFlow, sFlow, and IPFIX are one category: flow export

Treat the flow family as one tool for the exam. NetFlow is Cisco's original export protocol (v9 the common version), sFlow is a sampling-based alternative that exports every nth packet's header plus interface counters for very low overhead on fast switches, and IPFIX (IP Flow Information Export) is the IETF-standardized, vendor-neutral form built from NetFlow v9. All three export flow metadata and none capture payload.

IPFIX is the IETF standard version of NetFlow v9

IPFIX (IP Flow Information Export) is the IETF standard for exporting flow data, defined in RFC 7011 and built directly from Cisco's NetFlow v9. It is the vendor-neutral form of the same flow-export idea, so a question asking for the open, standards-based flow protocol points to IPFIX rather than the vendor-specific NetFlow.

Full packet capture saves every byte at high storage cost

A protocol analyzer (a sniffer) performs full packet capture, saving headers and payload so you can read application content and reconstruct an entire session. That power costs heavy storage and slow search, which forces short retention, so capture is for targeted deep troubleshooting and forensics, not always-on volume monitoring. When the goal is to see the actual contents of the traffic, capture is the only source that shows it.

Trap Picking flow data when the question needs the actual packet contents; flow has no payload, so only full capture reads the bytes.

Port mirroring (SPAN) copies traffic to the analyzer

To capture traffic that is not addressed to the analyzer itself, you duplicate it with port mirroring, also called a SPAN (Switched Port Analyzer) session, which copies traffic from one or more source ports to the analyzer port. A hardware tap does the same job inline. Without a mirror or tap, a switch only forwards frames to their destination port, so the analyzer would see nothing.

Syslog centralizes event logs off the originating host

Syslog ships each device's event messages to a central collector, which both protects the records and lets you search every device's events in one place. Centralizing matters for security because a copy already shipped off-host survives an attacker wiping the local logs, and it matters for operations because one query spans the whole network instead of logging into each box.

2 questions test this

Syslog severity runs 0 Emergency to 7 Debug, where lower is worse

Each syslog message carries a severity on a fixed 0-to-7 scale, and the direction is inverted from intuition: 0 is Emergency (system unusable) and 7 is Debug, with Alert, Critical, Error, Warning, Notice, and Informational in between. A filter for severity 3 and below therefore captures Error, Critical, Alert, and Emergency, the messages you actually act on. The separate facility field (values 0 to 23) names which subsystem produced the message.

Trap Treating severity 7 as the most critical; the scale is inverted, so 0 Emergency is most urgent and 7 Debug is least.

2 questions test this

A SIEM aggregates and correlates logs; it is not a sensor

A Security Information and Event Management (SIEM) system provides centralized logging for many log types, ingesting syslog, flow records, and device logs and correlating events across sources into one storyline, for example tying a firewall port scan to a later endpoint alert and a data upload. The SIEM sees the cross-source pattern no single device could, but it does not itself scan for malware or block traffic, which are sensor jobs.

Trap Naming the SIEM as the component that scans for malware or blocks a file; those are sensor jobs, the SIEM only aggregates and correlates.

Establish a performance baseline before setting alert thresholds

A performance baseline is a recorded picture of normal CPU and memory utilization, interface throughput, error and discard counters, and latency, sampled over time. It is the reference an alert is measured against, because a reading like 70% CPU only means something once you know normal is 20%. Establish the baseline first, then alert on deviation from it; without a baseline a threshold is a guess.

Trap Setting alert thresholds from intuition with no baseline; deviation from recorded normal, not an arbitrary number, is what signals a problem.

4 questions test this

Key performance metrics: utilization, errors, discards, and latency

The core health metrics to watch are CPU and memory utilization, interface bandwidth utilization, interface error and discard (drop) counters, and round-trip latency. Rising error or discard counters on an interface point to a physical or congestion problem, and tracking utilization against the baseline shows whether a link needs upgrading. These are the counters SNMP polling typically collects.

Streaming telemetry pushes metrics through device APIs

Modern platforms increasingly collect metrics through device APIs as streaming telemetry, where the device pushes fine-grained data continuously instead of waiting to be polled. This complements or replaces scheduled SNMP polling, giving denser, more timely data, and is the answer when a question describes continuous API-driven metric streaming rather than interval polling.

Flow beats capture for volume; a poll beats a capture for up/down

When two tools could technically work, the exam wants the lighter one that still answers the question. To learn which hosts dominate a link and by how much, flow data answers it without the storage burden of full capture. To confirm a device or interface is up, an SNMP poll or trap answers it without capturing any traffic at all. Capture is reserved for when you genuinely need the payload.

Trap Defaulting to packet capture because it sees everything; its storage and search cost make it the wrong first reach when metadata answers the question.

SNMP polls on UDP 161 and receives traps on UDP 162

The manager polls agents with GET and SET requests over UDP port 161, and agents push asynchronous trap and inform notifications back to the manager on UDP port 162. A firewall must allow inbound UDP 162 at the NMS for traps to arrive, which is the usual cause of polling working while traps silently vanish.

Trap Swapping the two ports, expecting traps on 161; 161 is for polling, 162 is for the unsolicited notifications.

4 questions test this

Syslog forwards log messages on UDP port 514

Standard syslog uses UDP port 514 as its well-known destination port for forwarding event messages to a centralized collector. A firewall rule permitting devices to log centrally must allow UDP 514 inbound to the syslog server.

2 questions test this

SNMPv3 has three security levels: noAuthNoPriv, authNoPriv, authPriv

noAuthNoPriv neither authenticates nor encrypts; authNoPriv verifies the sender's identity but sends the payload in the clear; authPriv both authenticates the sender and encrypts the payload. Match the level to the policy: authentication-only requirements call for authNoPriv, while requirements to also stop eavesdropping call for authPriv.

Trap Choosing authPriv when the policy asks only to verify the sender; encryption is extra overhead the requirement did not ask for, so authNoPriv is the precise answer.

5 questions test this

RSPAN carries mirrored traffic between switches over a dedicated VLAN

Remote SPAN extends port mirroring across separate switches by tagging the copied frames into a dedicated RSPAN VLAN. That VLAN must be allowed on every trunk link between the source switch and the switch hosting the analyzer, so the mirror can reach a destination in another wiring closet or building.

2 questions test this

A capture NIC needs promiscuous mode to see mirrored traffic

By default a network adapter discards frames not addressed to its own MAC. Promiscuous mode makes the adapter accept every frame that arrives on the interface, which is required for a protocol analyzer plugged into a SPAN destination port to display the mirrored traffic rather than only its own.

1 question tests this

A technician connects a laptop running a protocol analyzer to a switch port configured as a SPAN destination. The analyzer only displays…

Also tested in

References

RFC 3411 — An Architecture for Describing SNMP Management Frameworks Whitepaper
RFC 3954 — Cisco Systems NetFlow Services Export Version 9 Whitepaper
RFC 7011 — Specification of the IP Flow Information Export (IPFIX) Protocol Whitepaper
RFC 5424 — The Syslog Protocol Whitepaper
NIST Glossary — Security Information and Event Management (SIEM) Whitepaper