A monitoring platform can display a red icon for almost any failure. The difficult part is understanding which evidence produced the alert and what that evidence can actually prove.
An interface counter can show drops without showing the application conversation that suffered. A flow record can show heavy communication between two endpoints without preserving the packet payload. A packet capture can reveal a failed TCP handshake, but it may be excessive when the question only asks whether an interface is up.
Fast rule: Use metrics for state and trends, logs for recorded events, flow data for conversation summaries, and packet captures for packet-level proof.
Evidence sources at a glance
| Source | Best question | Typical evidence | Main limitation |
|---|---|---|---|
| SNMP | What is the device or interface state, value, or counter? | Interface status, utilization, errors, temperature, CPU, memory | Usually does not preserve full application events or packet contents |
| Syslog or event log | What event did the system record, and when? | Authentication failures, configuration changes, service restarts, firewall actions | Quality depends on what the device was configured to log |
| Flow data | Who communicated with whom, using what protocol, and how much? | Source, destination, ports, protocol, byte and packet totals, timing | Summarizes conversations and normally omits payload |
| Packet capture | What exactly happened on the wire? | Headers, flags, sequence behavior, requests, responses, retransmissions, payload when visible | Storage, privacy, capture placement, and encryption can limit usefulness |
| Baseline | Is the current behavior unusual for this network? | Normal utilization, latency, error rates, device load, and traffic patterns | A poor or outdated baseline can normalize bad behavior |
SNMP: device state, counters, and notifications
Simple Network Management Protocol (SNMP) lets a management system read or change managed values exposed by an SNMP agent. The Management Information Base (MIB) organizes those values, and an object identifier (OID) identifies a specific managed object.
Use SNMP when the question asks for values such as:
- Interface operational status
- Inbound or outbound octets
- Errors and discards
- Processor or memory utilization
- Temperature, fan, or power-supply state
- Device uptime
A manager commonly polls agents on a schedule. Polling answers, “What is the value now?” A trap or inform is initiated by the device when a configured event occurs. That answers, “What event did the agent choose to report?”
Polling intervals matter. A five-minute average can hide a ten-second spike. Polling every second provides more detail but increases management traffic and storage. Choose an interval that matches how quickly the monitored condition can change and how quickly the organization needs to react.
SNMPv3 adds authentication and privacy protections that older community-string approaches do not provide. When a question asks for secure SNMP management, SNMPv3 is the stronger fit.
Syslog and event logs: recorded actions and conditions
Syslog carries event messages. A message can identify the device, application, timestamp, severity, and event text. Central collection allows an operator to compare events from routers, switches, firewalls, servers, and applications without signing in to each system separately.
Logs are useful for questions such as:
- Which administrator changed the configuration?
- When did a routing adjacency fail?
- Did the firewall deny the session?
- Did a service restart before users reported the outage?
- Were repeated authentication attempts recorded?
Time synchronization is essential. If a firewall is five minutes ahead of a server, the event sequence may appear reversed. Network Time Protocol (NTP) or another approved time source helps preserve a usable timeline.
Severity does not automatically equal business impact. A high-severity device message may affect an unused interface. A lower-severity warning repeated across every access switch may indicate a wider problem. Read the event in context.
Flow data: conversation summaries
Flow technologies such as IP Flow Information Export (IPFIX) summarize network conversations. A record can include source and destination addresses, source and destination ports, protocol, timestamps, and byte or packet totals.
Flow data is a strong choice when the question asks:
- Which hosts are the largest talkers?
- Which destination received unusual traffic volume?
- Did a host begin communicating with many external systems?
- Which application or port consumed a WAN link?
- When did a conversation begin and end?
Flow records are more compact than packet captures because they summarize traffic. That makes them practical for longer retention and network-wide visibility. The tradeoff is detail. A flow record may show a large HTTPS conversation but not the page request, certificate exchange, or application error inside it.
Packet capture: packet-level proof
A packet capture records packets observed at the capture point. It is appropriate when headers, flags, sequence behavior, or application exchanges are needed.
Examples include:
- Confirming whether a DNS query received a response
- Distinguishing a TCP reset from a timeout
- Seeing retransmissions or duplicate acknowledgments
- Confirming a DHCP discover, offer, request, and acknowledgment sequence
- Checking whether a VLAN tag or protocol field is present
Capture placement decides what you can see. A capture on the client side of a firewall may show the request leaving but not prove that the server received it. A capture after the firewall can answer a different question. Encrypted traffic still exposes some metadata, but application content may remain unreadable.
Packet capture is not automatically the best first step. If an interface is administratively down, SNMP state or a device command answers the question faster.
Port mirroring and network taps
A capture tool must receive a copy of the relevant traffic.
Port mirroring, sometimes called a switched port analyzer session, configures a switch to copy selected traffic to a monitoring port. It is flexible and uses existing infrastructure, but oversubscription or switch behavior can affect what is copied.
A network tap is a dedicated device placed in the traffic path to provide monitoring output. Taps can offer consistent visibility and are useful when the monitoring design requires a hardware observation point.
Neither tool analyzes traffic by itself. They deliver traffic to a packet analyzer, intrusion-detection sensor, or another monitoring system.
Baselines, thresholds, and alerts
A baseline records normal behavior for a meaningful period. Useful baselines can include:
- Interface utilization by time of day
- Typical latency between sites
- Normal packet-loss and error rates
- Expected CPU and memory ranges
- Common application traffic patterns
A fixed threshold is useful when a limit is known, such as storage above 90%. A deviation alert is useful when normal values vary by time or system. A branch WAN circuit at 70% utilization may be ordinary during backups and unusual at 3 a.m.
An alert should identify the condition, affected object, time, and useful context. Too many low-value alerts create alert fatigue. Operators begin ignoring messages, including the one that matters.
APIs, dashboards, and automation
An application programming interface (API) lets software request monitoring data or trigger an action without relying on a person clicking through a graphical interface. APIs are useful for collecting inventory, opening tickets, enriching alerts, or applying a repeatable response.
A dashboard presents selected information. It does not create evidence by itself. Ask which data source feeds the dashboard and how recent the data is.
Automation should have clear boundaries. Automatically opening a ticket from a verified interface-down alert is different from automatically changing routes based on one noisy sample.
Scenario comparisons
Identify the application consuming a WAN link
Use flow data first. It can rank conversations by addresses, ports, protocol, and volume. A packet capture may provide deeper detail later, but it is not necessary to identify the largest talkers.
Determine why a TCP session fails after the handshake begins
Use a packet capture at the correct observation point. SNMP can show that the interface is up, and flow data can show that a conversation existed, but the capture can reveal flags, resets, retransmissions, and timing.
Confirm when an administrator changed a switch configuration
Use centralized logs with synchronized timestamps. SNMP can expose the current configuration state or a change notification, but an audit-capable log is the stronger source for who changed what and when.
Detect that current latency is abnormal
Compare current measurements with a valid baseline. A latency value without historical context may be normal for a distant site and unacceptable for a local service.
Common exam traps
- Choosing packet capture whenever the word “traffic” appears. Use it only when packet detail is required.
- Treating flow data as full packet content. It summarizes conversations.
- Assuming a dashboard is the original evidence source.
- Confusing an SNMP poll with a trap. The manager initiates a poll; the agent initiates a trap or inform.
- Ignoring capture placement.
- Comparing timestamps from systems that are not synchronized.
- Treating an alert threshold as proof of root cause.
Rapid review grid
| Need | Best starting source | Reason |
|---|---|---|
| Interface state and counters | SNMP or device command | Directly exposes managed values |
| Recorded event and timestamp | Syslog or event log | Preserves the system's event message |
| Top talkers and traffic volume | Flow data | Summarizes conversations efficiently |
| TCP flags or protocol exchange | Packet capture | Preserves packet-level evidence |
| Current versus normal behavior | Baseline comparison | Adds historical context |