This chapter introduces Virtual Network Elements (VNEs) and describes the types of information available in this guide.
This chapter contains the following topics:
•Introduction to VNEs
•Understanding the Tables
•Obtaining Prime Network Third-Party VNE Drivers
Introduction to VNEs
VNEs (Virtual Network Elements) are independent software processes that run on the Prime Network Unit Servers. Each VNE is assigned to manage a single network element (NE) using the NE's management interfaces (for example, SNMP and/or Telnet). The VNEs maintain a live model, or abstraction, of each NE and the entire network.
As the VNE loads, it starts investigating the NE and automatically builds a live model of the NE, including its physical and logical inventory, its configuration, and its status. After modeling the NE, the VNE begins negotiating with peer VNEs, which represent the peer NEs, in order to determine NE connectivity and topology at different layers. This model of the network topology, NE state, and NE inventory is constantly being updated by the VNEs, which track every change that occurs in the NEs and the network.
The VNEs communicate between themselves to analyze end-to-end flows, which provide information for root-cause and impact analysis, service path tracing, and more.
Understanding the Tables
This section describes key information that can be found in the VNE support information chapters in this guide.
This section contains the following topics:
•Device Package (DP) Version
The Software Version column in the tables in this guide identifies the third-party NE software versions that are compatible with Prime Network and that can be running on the third-party NEs that Prime Network supports.
When an NE software release is not explicitly supported, Prime Network attempts to model the NE using the default version for that device series. The default version is a device-specific fallback set of commands and MIB instrumentation that allows Prime Network to discover and query for basic device properties, including:
•Managed element information.
•Basic physical inventory.
•Logical Inventory (including the Routing Table, ARP, BGP and OSPF information). Modelling of other technologies is done on a best-effort basis.
The default version does not correspond to any specific supported NE software version. Building of the physical model and its containment structure depends on the instrumentation (MIB and CLI commands) used by the default version. The default version may show you different containment structures (modules and cards) from what you will see for an explicitly supported NE software version. You can discover whether the default version is being used for a particular VNE by looking in the AVM log located in install directory/main/logs (search for default version).
Cisco frequently qualifies new NE software versions for compatibility with Prime Network Third-Party VNEs, and updates the online version of this guide accordingly. If you are not sure whether the current version of Prime Network Third-Party VNE supports a recently released NE software version, check the online version of this guide on Cisco.com for an update. The NE software version should appear in the updated version of this guide if it has been qualified as compatible with this Prime Network Third-Party VNE release. If the online version of this guide does not list the new software version, contact Cisco Professional Services or your Cisco Sales Representative.
The Product Version column found in the tables in this guide lists the version of Cisco ANA or Cisco Prime Network that supports the NE.
Device Package (DP) Version
The DP Version column found in the tables in this guide lists the version of DP during which a VNE supporting the specified NE module, software, topology, or other feature was first introduced. It is therefore the earliest DP version that supports that NE. All later versions of DP also support the NE. For example: If the guide indicates that Juniper M-Series devices are supported on DP 1.0, they are also supported on DP 2.0, 3.0, and so on.
The latest DP is cumulative of previous DP releases and the latest DP contains greatest of the VNE drivers update until that particular date.
Table 1-1 describes the meaning of the Expedited column found in the service event (service alarm) tables in this guide.
Table 1-1 Expedited Legend in Service Event Tables
The service event is expedited by a syslog or trap generated by the device. This means that the syslog or trap causes the VNE to poll the device without waiting for the usual polling cycle, thus enabling quicker detection of the event.
The service event is not expedited.This means that the VNE will poll this device during the next regularly scheduled polling cycle.
VNEs utilize their internal device component model (DCM) in order to perform the actual correlation. This action is considered to be a correlation flow. There are two basic correlation mechanisms used by the VNE:
1. Correlation by Key (Device component level correlation).
2. Correlation by Flow (Neighboring Device Correlation).
Correlation by Key
When the root cause problem is at the box level, attempts to correlate to other events are restricted to the specific VNE. This means that the correlation flow does not cross the DCM models of more than one VNE. An example is a port-down syslog event correlating to a port-down event.
An exception for this behavior is the link-down alarm. Since a link entity connects two endpoints in the DCM model, it involves the DCM of two different VNEs, but on each VNE the events are correlated to their own copy of the link-down event.
Correlation by Flow
Network problems and their effects are not always restricted to one network element. This means that a certain event could have the capability of correlating to an alarm several hops away. To do this the correlation mechanism within the VNE uses an active correlation flow that runs on the internal VNE's DCM model and tries to correlate along a specified network path to an alarm. This is similar to the Cisco ANA PathTracer operation when it traces a path on the DCM model from point A to point Z, except that it is trying to correlate to a root-cause alarm along the way, rather than just tracing a path.
This method is usually applicable for problems in the network layer and above (OSI network model) that might be caused due to a problem upstream or downstream. An example is an OSPF Neighbor Down event caused by a link-down problem in an upstream router. Another important distinction between Cisco ANA PathTracer and the correlation flow is that the correlation flow may run on an historical snapshot of the network.
Obtaining Prime Network Third-Party VNE Drivers
To obtain Prime Network 3.9 Third-Party DP tar file for installation, contact a Cisco representative or download from Cisco Prime Network Software Download site on Cisco.com.