Accelerate Your Path to Full-Stack Monitoring and Alerting
Register for this live webinar featuring Zenoss and VictorOps today!
Why Customers Choose Us
Discover why the largest companies in the world choose Zenoss.
Customer Support Portal
Zenoss Learning Center
Zenoss Partner Portal
Become a Partner
Top 5 Focus Areas to Succeed With DevOps
Forrester shares the tools, technologies and best practices to meet the challenges of today's modern IT environments.
Learn. Discuss. Participate.
Join thousands of Zenoss users and experts to learn, discuss and participate in the Zenoss Community.
Hybrid IT Monitoring
Zenoss provides complete visibility into physical, virtual, cloud and converged environments.
Request A Demo
This ZenPack provides status and performance monitoring of Cisco routers and switches.
Compatible with Zenoss Resource Manager 4.2.x, Zenoss Resource Manager 5.0.x, Zenoss Resource Manager 5.1.x, and Zenoss Resource Manager 5.2.x
Compatible with Zenoss Resource Manager 4.2.x, Zenoss Resource Manager 5.0.x, and Zenoss Resource Manager 5.1.x
Compatible with Zenoss Resource Manager 4.2.x, Zenoss Resource Manager 5.0.x
The CiscoMonitor ZenPack extends Zenoss Service Dynamics to provide additional support for monitoring faults and performance of a wide range of Cisco equipment, including virtual resources such as virtual firewalls, virtual load balancers, and virtual extensible LANs.
Monitoring is supported for the following Cisco product lines.
The following common features are available across the supported products where available.
The following additional features are supported for specific product lines:
Zenoss will model QoS class maps associated with network interfaces using CISCO-CLASS-BASED-QOS-MIB. You will be able find all modeled class maps for a device by clicking QoS Class Maps under Components in the device's left navigation pane.
Interface Class Maps
Since the QoS component require the associated interfaces to be already modeled via the cisco.snmp.Interfaces modeler, you may need to model your device twice initially for the QoS components to model. If QoS Class Maps is not shown it means no class maps were modeled.
If you believe service policies have been configured and Zenoss should have found them, verify that the cisco.snmp.QoSClassMaps modeler plugin is enabled, you have interface components, and then remodel the device.
To see just the class maps associated with a specific interface you can find the interface in question then choose QoS Class Maps in the Display drop-down instead of Graphs.
QoS Class Maps
The following datapoints are monitored for all class maps:
The following datapoints are monitored for class maps with queueing configurations:
The following datapoints are monitored for class maps with traffic shaping configurations.
The following datapoints are monitored for class maps with policing configurations.
The 64bit versions of all of the above counters will be used if Zenoss is monitoring the device with SNMPv2c or greater, and if the device supports them. Otherwise, the 32bit versions of the counters will be used.
To ensure that the most appropriate discovery and monitoring is being performed for a device it must be placed into the appropriate device class. The following table maps the type of Cisco device to the device class to which it should be assigned.
Zenoss uses different network protocols to monitor different types of Cisco devices. In many cases Zenoss will use multiple protocols for the same device. The following table describes the supported device types and the protocol(s) are used to discover and monitor them:
The following configuration properties should be set to provide the necessary credentials for the management protocols listed above:
The firewall access to and from the Zenoss collector server to the monitored devices can depend on the type of device being monitored. The following table provides a consolidated view of all required network access.
Several of the supported device types have the ability to create logical contexts of various kinds. In these cases, Zenoss has the ability to identify the logical contexts and associate them with the admin or parent context. The following is a list of device types that support logical contexts and how Zenoss refers to them.
For Zenoss to be able to discover and associate these types of logical contexts with the admin or parent context, the management IP address of each logical context must itself be discovered as a separate device in Zenoss. The logical contexts should be placed into the same device class as the device they're a context of. For example, a Nexus 7000 VDC should be placed in the /Network/Cisco/Nexus/7000 device class.
Certain SNMP traps will cause Zenoss to schedule an immediate remodeling of the device from which the trap was sent. The traps that will cause this automatic remodeling by default are:
This list can be modified by using changing the ''zCiscoRemodelEventClassKeys'' configuration property.
Monitoring detailed memory buffer pool statistics is not enabled. When enabled, the following statistics can be monitored on any Cisco devices that support OLD-CISCO-MEMORY-MIB.
Buffer elements and small, medium, big, large and huge buffer pools are included for each of these categories.
To enable memory buffer pool monitoring you must bind the ''Memory Buffer Pools'' monitoring template to the desired device class or device. You will then find the associated graphs on the ''Graphs'' screen for each device to which the monitoring template has been bound.
While extensive CPU monitoring is done by default for most Cisco devices and applicable modules on those devices, it can sometimes be desirable to monitor CPUs directly using CISCO-PROCESS-MIB. If Zenoss isn't already capturing CPU information you know exists in CISCO-PROCESS-MIB, you can enable further support by enabling the cisco.snmp.CPUs modeler plugin.
If you want Zenoss to model and monitor all memory pools on your Cisco device using the CISCO-MEMORY-POOL-MIB, enable the cisco.snmp.MemoryPools modeler plugin.
The following potential limitations should be noted.
This ZenPack installs the following MIBs. Any SNMP traps defined in these MIBs will be decoded by Zenoss.
IP-SLA refers to Cisco IOS IP Service Level Agreement monitoring. This ZenPack provides limited IP-SLA support for IP-SLA Probes found in the component grid for devices that support the CISCO-RTTMON-MIB MIB. RTTMON refers to Round Trip Time Monitor.
Templates that use IP-SLA are all in the /Network/Cisco device class:
We discuss each of these templates in order.
Provides generic metrics round time packet traversal.
This template provides stats, for ICMP Jitter rrtType probes.
Jitter metrics from CISCO-RTTMON-MIB
Fix ciscoEnvMonTempStatusChangeNotif Transform error. (ZPS-1638)
Add unit test for SNMP event summary after transforms.
View the discussion thread.
This ZenPack is developed and supported by Zenoss Inc. Commercial ZenPacks are available to Zenoss commercial customers only. Contact Zenoss to request more information regarding this or any other ZenPacks. Click here to view all available Zenoss Commercial ZenPacks.