SNMP Polling Collapse After EVPN-VXLAN Rollout
A network team manages 240 Juniper EX and QFX switches from one Nagios XI server. Polling uses SNMPv3 authPriv at a 60-second interval and walks ifDescr, ifHCInOctets, jnxOperatingTable, and jnxCosIfqStatsTable on every device. After EVPN-VXLAN is enabled on two QFX5120 spines, the collector reports timeouts on 38 EX4650 leaf switches. On one leaf, show snmp stats shows a high GetNext count and zero GetBulk requests; Routing Engine CPU is 78%, and OSPF hellos are missed every 3–4 minutes. The collector is configured for GetNext, not GetBulk, and polls all four tables every cycle. Operations proposes raising the SNMP timeout from 2 s to 10 s and adding a second collector. Security requires SNMPv3 authPriv and will not permit SNMPv2c. The management VLAN is separate, but SNMP runs on the same Routing Engine as routing protocols. The next maintenance window is in two weeks.
1. Diagnose the root cause and decide whether raising the SNMP timeout is the right fix. Show the reasoning that leads to your recommendation.
Read the worked answer
Raising the timeout treats the symptom and makes the load worse. The collector is using GetNext, so each object is fetched in a separate PDU. jnxCosIfqStatsTable alone has roughly 48 ports × 8 queues = 384 rows on an EX4650, each with multiple counters; walking that every 60 seconds for 240 devices creates a large PDU rate on the Routing Engine. EVPN-VXLAN adds BGP, EVPN, and VXLAN work to the same RE, so SNMP now competes with control-plane processing. A 10-second timeout leaves each walk in progress longer and can increase concurrent sessions.
Use show snmp stats and show system processes extensive | match snmp to confirm the PDU rate and process CPU. The fix is to change the polling design: enable GetBulk on the SNMPv3 manager with a max-repetitions value of 10–25, restrict the SNMP view to required OIDs, poll ifHCInOctets at 60 seconds but move jnxOperatingTable to 300 seconds, and stop polling queue statistics every cycle. Use streaming telemetry for queue drops. Do not add a second collector until the first one uses GetBulk and a restricted view; two collectors would double the RE load.
2. Design the monitoring split across SNMP, traps, syslog, and streaming telemetry for these 240 switches. Justify which data goes where.
Read the worked answer
Use each mechanism for what it is good at, not as a default collector for everything.
- SNMP: inventory, interface counters at a coarse interval, and on-demand troubleshooting. Keep an SNMPv3 authPriv view that excludes large tables.
- SNMP traps: event-driven faults such as link down, power supply failure, fan failure, and routing protocol state changes. Traps are small and do not create a polling load.
- Syslog: configuration changes, authentication failures, commit events, and protocol adjacency messages. Send to a central syslog server with severity filtering.
- Streaming telemetry: high-rate queue statistics, drop counters, and interface latency. Native Junos sensors under
/junos/system/linecard/interface/queue/export only the needed data at the needed rate.
For example, keep a 60-second ifHCInOctets poll for capacity planning, but export queue drops every 1–5 seconds via telemetry only on WAN and uplink interfaces. This preserves SNMPv3 security requirements while removing the table walk that is overloading the RE.
3. What verification steps would you perform after the change to prove the RE is no longer overloaded, without waiting for an OSPF flap?
Read the worked answer
Verify at three layers: SNMP behavior, RE load, and control-plane stability.
- On the switch:
show snmp statsshould show GetBulk increasing and GetNext dropping sharply. Checkshow system processes extensive | match snmpand confirm SNMP CPU is low. - On the collector: confirm bulk requests complete within the polling interval and that no device exceeds the timeout threshold.
- On the network:
show ospf neighborshould remain Full, andshow log messages | match ospfshould show no new adjacency changes. Usemonitor interfaceon a leaf uplink to confirm no unexpected drops.
Do not declare success from a single poll. Run for at least one full polling cycle across all 240 devices, then compare RE CPU and OSPF log events before and after. If timeouts persist, reduce the view before adding collectors.