Most teams have SNMP configured and flow records collecting. Far fewer have either one configured well. This post goes operational on both — covering the polling decisions, vendor extensions, and traffic analysis workflows that separate useful telemetry from noise at scale.
Series 3 makes the pivot from “synthetic as the spine” to “synthetic is one pillar of a full telemetry stack.” The other pillars — SNMP, NetFlow, OpenTelemetry, Kubernetes, AI infrastructure — get full-length treatment, not supporting roles. SNMP and NetFlow are where most infrastructure teams have the most deployed and the most misconfigured.
Start Here: What the Videos Cover
▶ Video 37 — “SNMP Deep Dive: Vendor OID Profiles, MIB Walks, Polling Strategy”
▶ Video 38 — “NetFlow, sFlow, IPFIX: Reading the Traffic Story”
SNMP: The Polling Decisions That Actually Matter
SNMP has been in production networks since 1990. Most teams treat it as solved infrastructure — configure a community string, point a poller at the management interface, move on. In practice, there are three decisions embedded in “configure SNMP” that have significant operational consequences.
Polling Interval
The polling interval is the first decision and the one most often made carelessly. The tradeoffs are non-obvious:
| Interval | Resolution | Cost | Best For |
|---|---|---|---|
| 30 seconds | High — catches transient events | High agent load; UDP burst risk at scale; 2.88M data points/device/day | Critical interfaces, SLA-monitored paths only |
| 5 minutes | Operational — catches most incidents | Moderate; 288K data points/device/day | Most production monitoring |
| 1 hour | Low — trend analysis only | Minimal | Inventory and capacity planning only; useless for incident response |
The subtle risk at 30-second polling across large device estates is what the plan document calls “UDP storms”: if all polls fire simultaneously, the management network burst can cause the very timeouts you’re counting. Polling jitter — spreading requests randomly across the polling window — is the standard mitigation. It’s not glamorous, but its absence is what causes phantom outages at scale.
MIB-II vs. Vendor MIBs
MIB-II (RFC 1213) is the generic baseline — standard OIDs that work on any SNMP-capable device. It gives you interface tables, IP assignments, and system descriptions. It’s a common denominator, not a complete picture.
Vendor MIBs are where diagnostically useful data lives. Cisco IOS-XE, Juniper Junos, Arista EOS, Mikrotik RouterOS, and HPE/Aruba each publish proprietary MIBs with equipment-specific counters that don’t have MIB-II equivalents: chassis-level thermal data, optical signal strength per transceiver, per-ASIC queue depths. A platform that polls only MIB-II knows you have a device. One with vendor OID profiles knows what that device is actually doing.
The IF-MIB Metrics That Matter
Within the IF-MIB (RFC 2863), seven OIDs carry the majority of incident-response value. ifInErrors and ifOutDiscards are the most actionable: rising error rates indicate hardware or media issues; rising discards indicate congestion. ifHCInOctets and ifHCOutOctets — the high-capacity 64-bit variants — are essential for any interface above 32 Gbps where the standard 32-bit counters wrap in under a second. ifAlias is the most underrated: it’s the human-assigned label on each interface, and often the only way to map an abstract ifIndex to a physical link in your topology diagram.
The ifIndex stability problem. ifIndex — the integer that identifies each interface in SNMP — is not guaranteed to be stable across device reboots on all hardware. If a monitoring platform doesn’t handle ifIndex aliasing, a planned device restart can scramble interface history, breaking dashboard continuity and alerting baselines. This edge case is invisible until it happens during a maintenance window — and then it’s a diagnostic confusion event on top of the maintenance itself.
NetFlow, sFlow, IPFIX: Three Families, One Traffic Story
Flow monitoring answers a different question than synthetic monitoring or SNMP. Synthetic asks: is this endpoint available and performing? SNMP asks: what is this device doing? Flow asks: what traffic is actually moving through my network, and where? The three flow protocol families each represent a different architectural approach to capturing that answer.
| Protocol | Origin | Schema | Mechanism | Best For |
|---|---|---|---|---|
| NetFlow v5 | Cisco, mid-1990s | Fixed 7-tuple | Flow summary export | Legacy Cisco environments; simple analysis |
| NetFlow v9 / IPFIX | RFC 3954 / RFC 7011 | Template-based, flexible | Flow summary export | IPv6, MPLS, custom fields; modern deployments |
| sFlow | RFC 3176 | Sampled packets | Switch ASIC sampling | High-speed switches; lower CPU overhead |
The Sampling Rate Question
sFlow and sampled NetFlow deployments require explicit thinking about sampling rate. A 1:1000 ratio means 99.9% of packets are never examined. For identifying the top bandwidth consumers on a busy link, statistical sampling at 1:1000 is usually sufficient — the volume differences between the top 10 talkers are large enough to survive statistical approximation. For detecting a specific low-volume flow — a single malicious connection, a specific application protocol — 1:1000 may miss it entirely. Knowing your sampling rate, and what questions it can and cannot answer confidently, is a prerequisite for trusting traffic analysis results.
The Synthetic + Flow Correlation Workflow
The most operationally powerful use of flow data in a unified platform is synthetic correlation. A synthetic alert fires at 14:22. The flow data for the upstream interface shows a traffic surge beginning at 14:19 — three minutes before the first synthetic failure. That three-minute gap is diagnostic: the traffic event caused the latency degradation, not the other way around. That causal sequence is only visible if both data sources share a timestamp reference and a single query interface.
Next in the Series
Season 3, Part 2 — Cloud-Native Telemetry: OpenTelemetry and Kubernetes as First-Class Sources. The modern instrumentation standard and the container orchestration platform, treated with the depth they warrant.
SNMP Monitoring, NetFlowsFlow, IPFIXIF-MIB, Vendor OID Profiles, Traffic Analysis, Network Observability, SRE, NetOpsFlow Monitoring, SNMP Polling
About Parlon
Parlon is an infrastructure observability platform built for enterprise teams operating complex, hybrid environments. Parlon combines active synthetic validation, real-time telemetry normalization, and learning-based alerting into a single platform — shifting operations from firefighting to foresight. Learn more at parlon.io.