Modern network switches and routers expose far more telemetry than a simple ICMP echo can show, yet plenty of shops still treat a green ping as proof the network is healthy. Network switch and router monitoring done properly means tracking interface errors, CRC counts, buffer drops, CPU and memory on the device itself, spanning-tree changes, and BGP or OSPF neighbor flaps – not just whether the box answers a ping every 60 seconds.
Why ping and basic SNMP walks fall short
A ping only confirms Layer 3 reachability at one instant. It tells you nothing about a switch port that’s throwing 200 CRC errors a minute because of a bad SFP, or a router whose BGP session to an upstream ISP is flapping every four hours due to a route-dampening misconfiguration. Both scenarios leave users complaining about “slow internet” while every ping check in the NOC shows green.
Basic SNMP walks pulling ifInOctets and ifOutOctets on a 5-minute polling interval have similar blind spots. A microburst that saturates a 1Gbps uplink for 8 seconds and drops packets never shows up when you’re averaging over 300 seconds. The graph looks flat at 40% utilization while users on that segment are seeing packet loss. This is one of the more persistent myths in network monitoring – that low average utilization means there’s no congestion problem. Bursty traffic patterns, common with backup jobs, video conferencing, or database replication, routinely cause drops well below the “safe” 70-80% utilization threshold most teams use for alerting.
Metrics that actually matter on switches
Interface-level counters deserve more attention than most teams give them. On a Cisco Catalyst 9300 or Juniper EX4400, check these per-port on at least a 1-minute interval:
Input/output errors and CRC errors – rising CRC counts almost always mean a physical layer problem: a bad cable, a failing transceiver, or a duplex mismatch.
Discards and drops – queue drops indicate the port is oversubscribed relative to its buffer depth.
Interface flaps – a port that goes up/down repeatedly points to a flaky NIC on the connected device or a power issue on a PoE port.
Spanning-tree topology changes – frequent TCNs (topology change notifications) usually mean something is plugging and unplugging on the network, or a misconfigured loop-prone connection.
Temperature and fan status – a 3750X sitting at 65°C in a poorly ventilated closet is a slow-motion hardware failure.
For chassis-level health, CPU utilization and memory fragmentation matter more on routers than switches, since routers do more per-packet processing (NAT, ACLs, QoS classification). A router pegged at 90% CPU during business hours because of an ACL with 400 lines evaluated sequentially is a real, recurring pattern – the fix is usually reordering rules by hit frequency, not just throwing more hardware at it.
Router-specific signals: routing protocol health
BGP and OSPF neighbor state changes deserve their own alert category, separate from generic interface monitoring. A BGP session that resets due to a hold-timer expiration, often caused by a congested control-plane CPU or an ISP-side MTU mismatch, can cause a full route withdrawal and 30-60 seconds of blackholed traffic before convergence. Watching for BGP state transitions (via SNMP traps on bgpBackwardTransition, or better, via streaming telemetry if the platform supports it) catches this before users report an outage.
OSPF adjacency flaps are frequently caused by mismatched hello/dead timers between two routers, or an MTU mismatch that only manifests once you cross a threshold packet size. These are worth catching in near real time since a flapping adjacency can trigger repeated SPF recalculations, spiking CPU on every router in the area.
Setting up monitoring that catches these patterns
Deploying SNMP polling at 30-60 second intervals for interface counters, combined with SNMP trap or syslog ingestion for state-change events, covers most of this. On devices that support it, gNMI or NETCONF streaming telemetry (available on newer Cisco IOS-XE and Juniper Junos releases) pushes counter updates every 1-10 seconds instead of waiting on a poll cycle, which is the difference between catching a microburst and missing it entirely.
SNMP trap monitoring is what catches the event-driven stuff – link down, cold start, authentication failure, BGP state change – as it happens rather than waiting for the next poll. Pairing that with baseline interface counter polling gives a fuller picture than either approach alone. For teams also running SNMP against non-network devices like UPS units or PDUs, the same trap infrastructure can be reused rather than standing up separate collectors, though it’s worth reviewing the platform’s approach in a guide on SNMP device monitoring beyond basic server metrics since alert thresholds differ by device class.
Common mistakes teams make
The most frequent mistake is alerting only on interface down/up state and ignoring error counters entirely, which means a degrading link with 5% packet loss from CRC errors goes unnoticed for weeks because the interface never actually goes down. A second common mistake is polling at 5-minute intervals and trusting the averages, which as covered above hides bursty congestion. A third is treating every SNMP trap as equally urgent – a linkDown trap on an access port connected to a printer doesn’t need to page anyone at 2am, but the same trap on a core uplink does. Without severity tiering based on port role or device criticality, teams either drown in noise or tune out traps altogether, which defeats the purpose.
An experienced network engineer first checks whether error counters are even being collected before trusting a “healthy” dashboard – a surprising number of monitoring setups only track bandwidth and uptime, leaving the actual failure signals uncollected. Establishing a baseline is the next step: knowing that a given switch normally sees 2-3 CRC errors a day means 200 in an hour is obviously a hardware problem, whereas without that baseline it’s just a number nobody looks at.
FAQ
Is SNMP polling still relevant given newer telemetry standards?
Yes, for most environments. SNMP remains the most widely supported method across switch and router vendors, and for interfaces that don’t need sub-10-second granularity, a 30-60 second poll is sufficient. Streaming telemetry (gNMI, NETCONF) is worth adopting where the hardware supports it and where microburst detection genuinely matters, such as trading floors or media production networks.
How often should interface error counters be checked?
A 1-minute polling interval is a reasonable default for production interfaces, with alerting configured on rate-of-change (e.g., CRC errors increasing by more than 50 in 5 minutes) rather than absolute thresholds, since normal baseline error rates vary by cable run length and connector quality.
What’s a realistic alert threshold for interface utilization?
Rather than a flat 80% threshold, look at 95th-percentile utilization over 5-minute windows alongside discard/drop counters. A link averaging 40% but with regular discards is a bigger problem than one sitting at 75% with zero drops.
Getting past ping-only monitoring doesn’t require replacing existing tools overnight – layering in error-counter polling and trap ingestion on top of what’s already running is usually enough to catch the failures that pings and averaged bandwidth graphs miss.