Junos SNMP Polling Timeouts and Slow Responses: The Definitive Fix List

"Router not responding to SNMP" or "response is slow" is the opening line of Juniper's SNMP troubleshooting checklist, and it matches the r/networking thread where an operator notes that JunOS devices are simply too slow at responding to SNMP while nothing else shows symptoms. The failure modes are few and testable — here they are, in the order that resolves them fastest.

Step 1: Prove the Path Before Blaming the Box

show snmp statistics
show snmp health-monitor
# from the NMS host:
snmpwalk -v2c -c PUBLIC -On <device> system

If snmpwalk from the poller works but the NMS reports timeouts, the problem is poller timing (Step 4). If the walk also times out, the problem is between the poller and snmpd — filtering, version or community mismatch. On an SRX, remember SNMP to the device itself is host-inbound traffic and must be allowed per zone: the zone logic is in our SRX zone and policy guide.

Step 2: Juniper Checklist Item — Change the Polling Method

The KB's headline recommendation for slow responses: change the NMS from column-by-column to row-by-row polling (or reduce simultaneous walks). A 48-port interface table walked column-by-column means dozens of separate mib2d round-trips; row-by-row retrieves whole rows per request. On busy boxes this alone converts timeouts into clean responses.

Step 3: Cut What You Poll — SNMP Views

Walking the full ifTable, ARP tables or the routing MIB on a large chassis is the classic self-inflicted load. Restrict each community to what the dashboard actually uses:

set snmp view IF-ONLY oid 1.3.6.1.2.1.2 include
set snmp community NMS view IF-ONLY

This mirrors the technique in the community guide on reducing SNMP CPU load with SNMP views — fewer OIDs, faster responses, less mib2d CPU. Watch the CPU side-effect with show system processes extensive: sustained snmpd/mib2d usage is the signature of over-polling, detailed in our routing engine high-CPU guide.

Step 4: Poller Timing — the Quiet Majority Cause

The NMS's own timeout and retry settings create most phantom timeouts: a 1-second timeout against a device whose tables take 2 seconds to assemble will fail regardless of device health. Align poller settings: timeout comfortably above real response time (the community threads converge on timeout = polling interval minus one second as a sane ceiling), one retry, and stagger large walks across the cycle instead of bursting them at every poll interval.

Step 5: Version and Counter Realities

• Prefer SNMPv3 in production — v2c communities are plaintext, and v1 lacks the bulk operations that make large tables affordable.
• 64-bit counters (ifHCInOctets) are mandatory on 10G+ links; 32-bit counters wrap between polls and produce nonsense deltas, which some NMSes then blame on "slow" responses.
• Health monitor thresholds (show snmp health-monitor) let the device itself warn about the resource exhaustion that slows MIB assembly.

Quick Reference

Fixing SNMP usually removes one whole class of "the device is unstable" tickets. If high CPU survives the SNMP cleanup, escalate with the RE process guide; if the devices being polled are clustered SRXes, node failovers during polls are a separate cluster-health issue covered in the reth and chassis-cluster troubleshooting guide.