CiscoMonitor

Discovery and monitoring are additionally supported for the following specific product lines:

Virtana will model QoS class maps associated with network interfaces using the SNMP MIB:

CISCO-CLASS-BASED-QOS-MIB.

You can 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

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 Virtana monitors 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.

Virtana uses different network protocols to monitor different types of Cisco devices. In many cases Virtana will use multiple protocols for the same device. The following table describes the supported device types and the protocol(s) that 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 Virtana 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 supported device types have the ability to create logical contexts of various kinds. In these cases, Virtana has the ability to identify the logical contexts and associate them with the admin or parent context. The following list of device types that support logical contexts and how Virtana refers to them.

For Virtana 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 Virtana. 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 Virtana 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 are not enabled by default. 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 Virtana 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: 1.3.6.1.4.1.9.9.109.1.1.1.1 OID), Device-Legacy monitoring template will be used instead of Device-Modern one.

If you want Virtana to model and monitor all memory pools on your Cisco device using the CISCO-MEMORY-POOL-MIB, enable the cisco.snmp.MemoryPools modeler plugin.

This ZenPack provides a feature to detect and alert you when one or multiple dropped IPsec tunnels are in an ASA device. In this case, you receive the warning event with a list of dropped IPsec tunnels and notifications to remodel the target device. After device is remodeled, the event is cleared.

NOTE: To control the severity, event class, and cycle time of the event creation, you can change the corresponding fields under the tunnelDroppedAlert data source for IPSec Tunnels components.

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:

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 Virtana 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:

Nexus Devices

The following covers Nexus devices in general, including Nexus 7000 and Nexus 9000 switches.

DVI Relations for Nexus Series

NOTE: Port refers to all network interfaces except PortChannel and VLAN.

• Device impacts VTEP/NVE and LineCard modules

• Device impacts Port (if no module)

• VTEP/NVE impacts VNI

• LineCard impacts network Port

• Port impacts PortChannel or VLAN

• PortChannel impacts VLAN

• VLAN impacts VNI

• Interface (all types) impacts its containing VRF

• Port impacts its child SubPort

The following diagram outlines extra DVI relationships. The first two are repeated from above for clarity:

Extra DVI Relations for Nexus

• Port impacts SubPort

• Interface (all types) impacts its containing VRF

• Port impacts its containing MPLS V3 VPN

Multicast Groups

Multicast Groups have impact relations between VRFs and VNIs. These relations augment the generic Nexus relations above. Note the usual Device-Module-Interface relations:

DVI Relations for Multicast Group, VRF, VNI

• Device impacts MulticastGroup (if not part of a VRF)

• Interface impacts VRF

• VRF impacts MulticastGroup

• MulticastGroup impacts VNI

Nexus 1000V and 1010 Devices

The following is specific to Nexus 1000V and 1010:

DVI Relations for Nexus1000V and Nexus1010

• VirtualServiceAppliance (AKA: Nexus 1010) impacts VirtualSericeBlade

• VirtualSericeBlade impacts VSM (aka: Nexus 1000V or VirtualServiceModule)

• External Port impacts VSM

• VSM impacts VEM (VirtualEthernetModule)

• VSM impacts VEI (VirtualEthernetInterface)

• VEI impacts assigned vSphere VMs

VSG and VMZone

The following is specific to Virtual Security Group (VSG) and VMZone. Portions of the Nexus 1010 and VirtualServiceBlade are similar to above:

DVI Relations for VSG and VMZone

• VirtualServiceAppliance (aka: VSA) impacts VirtualSericeBlade

• VirtualSericeBlade impacts VSG

• VSG impacts VMZone

Application Control Engine (ACE)

The following is specific to ACE. Note that ACE hardware components are also identified as ACE Contexts:

DVI Relations for ACE

• ServiceModule impacts ACE

• ACE impacts ACE Context

• ACE impacts ACE Service Policy

• ACE Real Server impacts ACE Server Farm

• ACE Server Farm impacts ACE Service Policy

Multilayer Director Switch: MDS 9000 Series

The following is specific to MDS 9000, FibreChannel, VSAN, Zone and ZoneSet:

DVI Relations for MDS 9000

• MDS9000 impacts FC-Module

• MDS9000 impacts FC port (if no module)

• FC port impacts VSAN

• VSAN impacts Zone

• VSAN impacts ZoneSet

• Zone impacts ZoneSet

ASA and FWSM

The ASA (Adaptive Security Appliance) and FWSM (Firewall Services Module) are covered here. Their architecture is nearly identical:

DVI Relations for ASA and FWSM

• Module impacts ASA/FWSM

• ASA/FWSM impacts Context

QoS Class Maps

QoS Class Maps affect their interface:

DVI Relations QoS Class Map

• Device (or module) impacts Interface

• Interface impacts QoSClassMap

Fans, Power Supplies, and Temperature Sensors

All Fans, Power Supplies, Fan Modules and Temperature Sensors affect device directly:

DVI Relations for Fans, Power Supplies, and Temperature Sensors

• Fan impacts Device

• PowerSupply impacts Device

• TemperatureSensor impacts Device

Firepower FXOS

• Fan Modules impacts Device

• Module Fans impacts Fan Modules