Table Of Contents

Introduction

Introduction to VNEs

Understanding the Tables

Software Versions

Product Versions

Device Package (DP) Version

Expedited Legend

Correlation Flows

Correlation by Key

Correlation by Flow

Obtaining Prime Network Third-Party VNE Drivers

Introduction

---

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

•Correlation Flows

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

•Software Versions

•Product Versions

•Device Package (DP) Version

•Expedited Legend

Software Versions

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.

Product Versions

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.

Expedited Legend

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 

Value	Descriptions
Y	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.
N	The service event is not expedited.This means that the VNE will poll this device during the next regularly scheduled polling cycle.

Correlation Flows

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.