Table Of Contents

VNE Persistency Mechanism

Persistency Overview

Alarm Persistency

Initialization

Retrieving Events

Storing Events

Removing an Event

Removing an Event and Clearing an Alarm

Configuring Alarm Persistency

Alarm Persistency Default Configuration

Instrumentation Persistency

Configuring Instrumentation Persistency

persistencydir

persistencylevel

persistencystorageenabled

persistencystorageinterval

persistencytimeout

Topology Persistency

Configuring Topology Persistency

VNE Persistency Mechanism

---

This appendix describes the VNE persistency mechanism in Cisco ANA. Topics include:

•Persistency Overview

•Alarm Persistency

•Instrumentation Persistency

•Topology Persistency

---

Note Changes to the registry should be performed only with the support of Cisco. For details, contact the Cisco Project Manager or Cisco Account Team.

---

Persistency Overview

Persistency is the ability to store information in the unit for later use. This information is stored across unit, AVM, and VNE restarts.

Instrumentation persistency is used mainly to:

•Shorten the starting time of VNEs for devices. By using the information from the local file system, device response time and network latency is eliminated, thus the VNE finishes modeling its first state very quickly.

•If the VNE was unloaded for any reason, provide information about the old state of the VNE to initiate alarms if the status has changed. For example, a port down alarm is initiated only if the port status was up and changed to down. This ensures that an alarm is not issued on ports which should be down. By maintaining information about the old state of the port, the system understands whether or not the current state is valid.

•Help lower the CPU load on the device at startup when many get commands are generated. Also, when persistence data is loaded from the unit, traffic bandwidth between the unit and device is much lower than when the system is loaded ordinarily, using normal device discovery and modulation.

Topology persistency is used mainly to create topology between devices on startup when the VNE is loaded instead of performing the entire discovery process. Verification of the links is then performed.

Alarm persistency is used mainly to save information about the VNE components that send alarms. When a VNE sends an alarm, it can be configured to save this information (that it has sent an alarm of type X). This information can then be used by VNE components after restarts to verify whether the component needs to send clearing alarms when changes have occurred in the device while the VNE was down.

VNE data persists:

•During runtime when a VNE polls data from a device, and it updates the files in the file system for changes in the device response according to the persistency variables.

•When the VNE starts for the first time and reads the data from these files. For every normal polling or refresh after this first time, the data is read from the device itself and not from the files.

Beginning with Cisco ANA 3.6 Service Pack 4, the upgrade mechanism automatically clears all persistency files on Cisco ANA gateways and units. This option does not clear the alarm history that is stored in the Cisco ANA database.

Alarm Persistency

Alarm persistency enables the system to clear alarms that relate to events that occurred while the system was down. For example, assume that a link down alarm is generated, and then the system goes down. While the system is down, a link up event occurs in the network, but the system is down and does not monitor the network. When the system goes up, the alarm is cleared because the system remembers that a link down alarm exists and needs to be cleared by sending a corresponding alarm.

Persisting events are held in the AlarmPersistencyManager. Each VNE contains an AlarmPersistencyManager object. Alarms are added and removed from the AlarmPersistencyManager object to maintain the status of an event, whether it exists in the repository or not; that is, whether an up alarm has been generated or whether a clearing alarm has been generated. Two copies of alarm persistency information are maintained, one in the memory and the other on disk.

At startup, the AlarmPersistencyManager retrieves the events persisting for the containing VNE.

Event data in the files is updated:

•At shutdown.

•After a change, when a new event is added or removed.

•After a specific interval of time has passed. This prevents data from being rewritten to the persistency file when a stream of events is added, or removed during a short period of time because the data is saved only after the specified period of time has elapsed.

Initialization

The AlarmPersistencyManager reads the following configurable items:

•Enabled—The mechanism enabled for this VNE.

•Writing delay—The interval between the arrival of a new event or a removal of an existing event, and the writing activity of the persistency file.

•Maximum age—How long an event remains in the persistency files before it becomes obsolete.

---

Note This applies only when trying to retrieve data from the persistency files.

---

Retrieving Events

At startup, each VNE calls its AlarmPersistencyManager to load persisting events.

If the file does not exist or is corrupt, no events are loaded. Faulty event objects are not loaded. Events which have been in the file for longer than the configured maximum age are not loaded. No age tests are held during ordinary runtime.

Storing Events

At shutdown, events are saved to the VNE event persistency file as a precaution in case the events have not been saved.

Removing an Event

An event is searched for and removed using the same information which was used to add it. The event is removed from the memory because an up alarm (for example, a link up alarm) has been generated, and the persistency information is no longer required. After the removal, the AlarmPersistencyManager stores the events after a writing delay as specified in the registry.

Removing an Event and Clearing an Alarm

The AlarmPersistencyManager can search for and remove an event, and send a clearing alarm for this event if it is found that this information is no longer required because the alarm has been cleared.

After an event has been added or removed from the AlarmPersistencyManager, a delayed message is sent to the AlarmPersistencyManager which, on its arrival, triggers the events to be stored to the file.

Configuring Alarm Persistency

You can define whether each subevent has a persisting or unpersisting alarm. This can be defined as both or none. An example of the LDP neighbor loss alarm is:

<key name="LDP neighbor loss">

<entry name="default">event-persistency-application/templates/generic persistency 
event</entry>

<key name="sub-types">

<key name="LDP neighbor down">

    <entry name="alarm-persistency">persist</entry>

</key>

<key name="LDP neighbor up">

    <entry name="alarm-persistency">unpersist</entry>

</key>

</key>

</key>

This persistency information is stored in event-persistency-application.xml.

Alarm Persistency Default Configuration

The following alarms are configured to be persistent:

•BGP neighbor loss

•LDP neighbor loss

•MPLS interface removed

•ascend link down trap

•card down

•card out

•component unreachable

•cpu utilization

•discard packets

•dropped packets

•drops exceed limit

•duplicate ip on vpn

•l2tp peer not established

•l2tp sessions threshold

•link down

•lsp removed

•memory utilization

•port down

•rx utilization

•tx utilization

Instrumentation Persistency

The instrumentation layer persists the information that was collected from the device to the file system. When the VNE restarts, it uses this information to emulate the device response. In this way, the VNE can be modeled according to its last persistent state. The next polling instance is performed against the real device.

Configuring Instrumentation Persistency

The following instrumentation parameters can be configured:

•persistencydir

•persistencylevel

•persistencystorageenabled

•persistencystorageinterval

•persistencytimeout

persistencydir

This is the directory in which the persistency information is saved on the local file system. This is a relative path.

•Allowed values—A string representing the relative directory in the file system.

•Default value—instrumentor-persistency

persistencylevel

This is the level of persistency to be used. The allowed values are:

•Full—It persists. This is the default value.

•Off—It does not persist.

•Partial—We recommend that you do not use this level.

These values can be used with certain commands to make sure some are persistent and some not.

---

Note This is a command-level parameter, meaning that you can decide that one command is persisted by using Full and another is not by using Off.

---

persistencystorageenabled

This defines whether to enable the whole mechanism or not.

•Allowed values—True or false.

•Default value—True.

persistencystorageinterval

This is the interval, in milliseconds, for which the data to be persisted is accumulated and then written to the persistent storage in bulk, so that there are fewer I/O operations.

•Allowed values—Within the user's discretion.

---

Note Small intervals cause more I/O operations on the local file system. Very long intervals means that the information that is stored is less current.

---

•Default value—600000 (10 minutes).

persistencytimeout

If the persistency mechanism is enabled when the instrumentation layer starts, it loads all data from the files, and this data can be used for the commands only the first time they are executed. Some commands can be used for the first time long after all other commands have finished multiple cycles; for example, commands that run only when the status on the device has changed. This initial data is marked obsolete after the persistency timeout has passed, and commands that are executed after this time, even if they are run for the first time, run directly on the device. The time is defined in milliseconds.

•Allowed values—Within the user's discretion, usually at least 1 minute.

---

Note A small value causes the instrumenting layer to ignore the persistent data. A large value causes old data to be retrieved long after the VNE has finished loading.

---

•Default value—60000 (1 minute).

Topology Persistency

Cisco ANA supports persistency for Layer 1 topological connections. Layer 1 topology supports one connection per DC, so the physical topology reflects a single port connected by a single link.

The following topologies are persisted:

•Layer 1 counter-based topologies.

•Static topologies.

•Path-based topologies for Alcatel-Lucent B-STDX, GX, and CBX switches.

Static topology, which identifies physical links configured by the user, is persisted once a user configures the static link between the two entities. This link is then stored in the registry in the AVM key that contains the specific VNE registrations.

For other topologies, every time a link is created, the persistency mechanism writes the link to this file. When a link is disconnected, the file representing the link is removed.

Configuring Topology Persistency

Physical topology persistency can be enabled or disabled in the registry. Topology has a registry entry entitled Persistency:

•The entry can be defined as true or false.

•The default value is true.

•We recommend that you define the value as true to enable topology persistency.

---

Note Topology persistency assumes that the XID (unique device component ID) can be persisted; that is, that the port XID remains the same XID after the device reboots or after the VNE reboots. This is not dependent on whether the ifIndex is changed from time to time.

---