SNMP: cbsalarmmond[xx]: [W] log_snmp_response Timeout: No Response from SNMP Agent
The SNMP daemon on the CPM is not able to respond in a timely manner. This issue seems to be specific to gigabitethernet ports with copper GBICs configured at gigabit speed (autonegotiate). The issue has not been observed when the ports were configured for (no autonegotiate) 100 full. This issue is not related to the amount of traffic or CPU utilization being used.
The more gigabitethernet ports configured, the more likely it is that you will get this warning message. This configuration had operating-mode quad-np.
There are 3 octal gig NPMs and most of the ports are configured.
It takes between 3 and 4 seconds for the SNMP agent to:
- Retrieve the interface table from the database
- Get the stats for each entry
- Load the cache, and
- Generate a response for a query to the interface table
The cache will be updated if it is 3 seconds old. However the default timeout value is one second for snmpwalk
, it would generate four identical requests before getting a response for the first request. It would further tie up the SNMP agent and the cbsalarmmond
daemon is more likely to get an SNMP timeout.
As far as Gigabit posts concerned, there are more entries per port to be updated in the interface table as defined in stats_if_tbl.cpp
.entry->tx_broadcast = 0; /* Gig Mac only. */
entry->rx_pause = 0; /* Gig Mac only. */
entry->rx_bad_opcode = 0; /* Gig Mac only. */
entry->rx_short_err = 0; /* Gig Mac only. */
entry->rx_long_err = 0; /* Gig Mac only. */
entry->rx_crc_err = 0; /* Gig Mac only. */
entry->rx_phy_err = 0; /* Gig Mac only. */
entry->rx_skipped = 0; /* Gig Mac only. */
entry->rx_runts = 0; /* Gig Mac only. */
entry->tx_pause = 0; /* Gig Mac only. */
It will take longer to update the interface table if there are many Gigabit ports enabled comparing with fast Ethernet ports. EMS imposes a minimal 5-second polling interval for polling the interface stats.