To monitor Cisco devices, SNMP access is all that is required.
Troubleshooting SNMP Access
To monitor Cisco devices, SNMP access is all that is required. If Active Discovery and monitoring is not working, the possibilities are:
- SNMP is not set up on the device. For a switch or router, there should be a configuration line such as “snmp-server community public RO” that usually will enable the SNMP daemon.
- The SNMP community string configured in LogicMonitor is not correct for the device. To configure this, please refer to Defining Properties and Authentication Credentials.
- The device has a restriction configured in the snmp-server command, which restricts the IP’s that it will respond to. E.g. a snmp-server configuration line may in the form “snmp-server community public RO 2” would inclusively restrict SNMP responses to addresses included in access-list 2. In this case, the IP address of the Collector would have to be permitted by adding it to access-list 2.
- There is a firewall–either on the device itself, applied to one of the interfaces, or a separate device between the LogicMonitor Collector and the switch–that is preventing SNMP traffic on port 161 UDP. For devices that require SNMP TRAP traffic to function, port 162 UDP may need to be unrestricted as well
For other Cisco devices, such as their Aggregation Services Routers (ASR) series, it may be necessary to enable the sending SNMP TRAPs in the device configuration in order to enable SNMPd for queries by our Collector. From the CLI of the Cisco device, enter:
If after examining the configuration on the router you cannot see why SNMP is not working, it may help to run debugging to see if the requests are getting to the device, and if they are being answered. From the CLI of the Cisco device, enter:
This will display all SNMP packets that are arriving and being replied to. Also, please ensure that SNMP TRAP traffic on port 162 UDP is unrestricted between your Collector machine and the monitored device.
Troubleshooting SNMP64_if Metrics on Cisco Switches
If abnormally large interface utilization is being observed via SNMP on Cisco switches, you may need to set up your Cisco device to support 64-bit interface counters.
Affected Devices and iOS Versions include:
- Catalyst 2950 and 3550 – Support begins in Cisco IOS Software Release 12.1(11) EA1 since Cisco bug ID CSCdx67611 and Cisco bug ID CSCdw52807
- Catalyst 2900XL and 3500XL – Support begins in Cisco IOS Software Release 12.0(5) WC3 since Cisco bug ID CSCds45300
- Catalyst 5000/6000 ATM modules – Since Cisco IOS Software Release 12.0(14) W05 (20), refer to Cisco bug ID CSCds07238
Cause of Issue
The ifTable in RFC1213 is the traditional interface counters that almost all SNMP devices support. It defines 32-bit counters for inbound and outbound octets (ifInOctets/ifOutOctets) that are used for bandwidth calculation. These 32-bit counters for high speed devices can wrap over too quickly. For example, a 10 Mbps stream of back-to-back, full-size packets causes ifInOctets to wrap in just over 57 minutes. At 100 Mbps, the minimum wrap time is 5.7 minutes, and at 1 Gbps, the minimum wrap time is 34 seconds. If the counter wraps more than once between Relator interval, the calculation is no longer valid.
There are two potential courses of action for resolving this issue:
- In order to support 64-bit interface counters, the device must be configured to use SNMPv2c or SNMPv3 protocol, and explicitly set to use option RFC2233 or option ‘Dynamically Determined’ to allow Engine to determine
- Upgrade the iOS software to the latest supported version from Cisco
Note: See also the SNMP Counters: Frequently Asked Questions Cisco support document for more information.
NTP is also checked on many Cisco devices to ensure that time is correctly synchronized. So, if you use NTP access-groups, ensure the LogicMonitor Collector is allowed to query the Cisco device and that port 123 TCP/UDP is unrestricted between the host and your Collector machine.