Version 5.12.1-Download Released on 2021/07/12 Requires PythonCollector ZenPack, ZenPackLib ZenPack Compatible with Zenoss 6.x and Zenoss CloudVersion 5.12.0-Download Released on 2020/10/12 Requires PythonCollector ZenPack, ZenPackLib ZenPack Compatible with Zenoss 6.x and Zenoss Cloud
The CiscoMonitor ZenPack provides health and performance monitoring for a wide range of Cisco switches, routers, and network devices, 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 supported products:
Discovery and monitoring are additionally supported for the following specific product lines:
Zenoss will model QoS class maps associated with network interfaces using the SNMP 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.
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 component are 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.
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.
NOTE: It is not always necessary to manually assign devices to device classes. When adding devices using the Add Multiple Devices wizard, you will have a reduced set of choices that are intuitive based on the type of device.
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:
Relevant CiscoMonitor zProperties, their descriptions, and defaults are presented.
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.
Devices with multiple CPUs will be monitored via Cisco SNMP datasource, which uses the zenpython service to collect SNMP metrics for each CPU and calculates the average utilization basing on the collected values.
NOTE: For Cisco ASA Devices (/Network/Cisco/ASA device class), if device doesn't support modern CPU metrics (e.g. cpmCPUTotal5minRev: 184.108.40.206.220.127.116.11.18.104.22.168.1 OID), Device-Legacy monitoring template will be used instead of Device-Modern one.
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.
In case you experience a lot of the event transformations, caused by SNMP traps or other activity from your Cisco devices, the speed of event processing might be affected. There are several things which you can do to mitigate the effect:
Controlling Automatic Remodeling
If the amount of RAM installed on your Cisco ASR 9000 device is less than 4GB, the Memory Utilization graph and all the related datasources will be available on the device's level, and can be modified under DeviceMemoryUsage32Bit monitoring template. Otherwise, the Memory Utilization graph and all the related datasources will be shown on Supervisor Modules component level and available for modifications under SupModuleExtended monitoring template.
In CiscoMonitor we provide a custom component type called Ethernet Interfaces which shows a type of ethernetCsmacd_64 but binds the EthernetInterface template which is not matching the standard behavior described in the Zenoss documentation.
CiscoMonitor supports a wide variety of devices and therefore a variety of DynamicView/Impact (DVI) relationships exist.
NOTE: An interface can be attached to a module, or a directly to a device.
The following diagrams summarize Impact/DynamicView support:
The following covers Nexus devices in general, including Nexus 7000 and Nexus 9000 switches.
NOTE: Port refers to all network interfaces except PortChannel and VLAN.
The following diagram outlines extra DVI relationships. The first two are repeated from above for clarity:
Multicast Groups have impact relations between VRFs and VNIs. These relations augment the generic Nexus relations above. Note the usual Device-Module-Interface relations:
The following is specific to Nexus 1000V and 1010:
The following is specific to Virtual Security Group (VSG) and VMZone. Portions of the Nexus 1010 and VirtualServiceBlade are similar to above:
The following is specific to ACE. Note that ACE hardware components are also identified as ACE Contexts:
The following is specific to MDS 9000, FibreChannel, VSAN, Zone and ZoneSet:
The ASA (Adaptive Security Appliance) and FWSM (Firewall Services Module) are covered here. Their architecture is nearly identical:
QoS Class Maps affect their interface:
All Fans, power supplies, and temperature sensors affect device directly:
DynamicView displays are available for the following components:
NOTE: There are no DynamicView views for QoS Class Maps , Fans, Temperature Sensors, Power Supplies components.
NOTE: Ensure you are using DynamicView 1.6.1 or newer, otherwise you may see this error in a DynamicView view:
[Error with zenjserver, please check log for errors.]
The following network icons are used in Impact and DynamicView diagrams in the UI:
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
The CiscoStatus threshold is a special threshold that uses preconfigured maps of numeric values returned by SNMP datasources to Zenoss event severities. The following OIDs and values are supported: