Table Of Contents

Supported Service Alarms

Service Alarms

Adaptive polling

Correlation

Source OID

All ip interfaces down

Correlation

Source OID

BGP link down

Correlation

Source OID

BGP neighbor loss

Correlation

Impact Analysis

Source OID

BGP process down

Correlation

Source OID

Broken LSP discovered

Correlation

Impact Analysis

Source OID

Card down

Correlation

Source OID

Card out

Correlation

Source OID

Cloud problem

Correlation

Source OID

Component unreachable

Source OID

Checking Reachability

Correlation

Source OID

CPU utilization

Correlation

Source OID

Device unsupported

Correlation

Source OID

Dropped packets

Correlation

Impact Analysis

Source OID

Discard packets

Correlation

Impact Analysis

Source OID

GRE tunnel down

Correlation

Source OID

HSRP group status changed

Correlation

Source OID

Interface status

Correlation

Source OID

Investigation state

Correlation

Source OID

L2tp peer not established

Correlation

Source OID

L2tp sessions threshold

Correlation

Source OID

Layer 2 tunnel down

Correlation

Source OID

LDP neighbor loss

Correlation

Source OID

Link down

Correlation

Source OID

Link utilization

Correlation

Source OID

Logical port down

Correlation

Source OID

Memory utilization

Correlation

Source OID

MPLS black hole found

Correlation

Source OID

MPLS interface removed

Correlation

Source OID

MPLS TE tunnel down

Correlation

Source OID

Port down

Correlation

Source OID

Rx dormant

Correlation

Source OID

Rx utilization

Correlation

Impact Analysis

Source OID

Shelf out

Correlation

Source OID

Tx dormant

Correlation

Source OID

Tx utilization

Correlation

Impact Analysis

Source OID

Registry Parameters

Adaptive polling

All ip interfaces down

BGP link down

BGP link down vrf

BGP link up

BGP neighbor loss

BGP process down

Broken LSP discovered

Card down

Card out

Cloud problem

Component unreachable

CPU utilization

Device unsupported

Dropped packets

Discard packets

GRE tunnel down

HSRP group status changed

Interface status

Investigation state

L2tp peer not established

L2tp sessions threshold

Layer 2 tunnel down

LDP neighbor loss

Link down

Link utilization

Logical port down

Memory utilization

MPLS black hole found

MPLS interface removed

MPLS TE tunnel down

Port down

Rx dormant

Rx utilization

Shelf out

Tx dormant

Tx utilization

Supported Service Alarms

---

This chapter describes the service alarms supported by Cisco ANA. Each alarm is described in a section containing:

•A short description, including background about the network state or system (Cisco ANA) state that caused the alarm. The short description of the service alarm is what appears in the ticket, in the Service tab of Cisco ANA EventVision. The short description for each type and subtype can be viewed in the Registry Parameters section.

When a flapping event occurs, the short description is changed.

---

Note The name of the service alarm is the same as the short description.

---

•A table of all the subtype events that represent one of the states the alarm can be, and a description of when they are issued. For example, the Link down alarm can have multiple subtype events (states) which include: Link down due to admin down, Link down due to oper down and Link up. The description also shows if the event is a clearing event.

•Information related to the correlation of the alarm, mainly:

–The alarm issue correlation process and location (Local or Network).

–If other alarms can correlate to this alarm.

–The keys that are used in the correlation process.

–The specific correlation filters in use for the alarm, if any. The filter indicates if a specific event cannot be selected as the root cause event in the correlation process.

•By default, any new event filters the following events: Cloud problem, BGP process down, LDP neighbor down, MPLS interface removed, the event itself, and events with lower or equal correlation weight.

Each section describes a group of alarms sharing the same event type.

---

Note Some of the alarms have Impact Analysis (IA) processing. This process is not described in detail in this Guide.

---

This chapter includes the following details:

•Service Alarms

•Registry Parameters

Service Alarms

The following service alarms are supported in Cisco ANA:

•Adaptive polling

•All ip interfaces down

•BGP link down

•BGP neighbor loss

•BGP process down

•Broken LSP discovered

•Card down

•Card out

•Cloud problem

•Component unreachable

•CPU utilization

•Device unsupported

•Dropped packets

•Discard packets

•GRE tunnel down

•HSRP group status changed

•Interface status

•Investigation state

•L2tp peer not established

•L2tp sessions threshold

•Layer 2 tunnel down

•LDP neighbor loss

•Link down

•Link utilization

•Logical port down

•Memory utilization

•MPLS black hole found

•MPLS interface removed

•MPLS TE tunnel down

•Port down

•Rx dormant

•Rx utilization

•Shelf out

•Tx dormant

•Tx utilization

Adaptive polling

Adaptive polling is a mechanism that handles situations in which the device CPU is crossing a predefined (and configurable) threshold. It reduces the polling when the CPU reaches high threshold values for a configurable sample, and returns the polling to a normal rate when the CPU reaches the lower threshold. Where the CPU stays high for several samplings, the VNE is automatically set to maintenance state to avoid continuous polling of the device.

In all cases, alarms are issued on the device or the VNE state changes.

The source OID of this alarm is the Managed Element OID (IManagedElementOid).

Table 16-1 Adaptive Polling—Subtype Events 

Subtype Event Name	Description
VNE switched to low polling rate due to CPU high usage.	When the CPU level has been above the high threshold (configurable, default=90%) for several samplings (configurable, default=5), this subalarm is issued. The polling rate of the device is lowered by adding a delay between requests (default delay is 500 msec).
VNE switched back to regular polling rate.	Clearing event When the CPU level has been below the lower threshold (configurable, default=70%) for several samplings (configurable, default=2), this subalarm is issued. The polling rate of the device is changed back to normal (no delay between requests).
VNE switched to maintenance mode due to CPU high usage.	Where the VNE polling rate is lower but the CPU stays high for several samplings (configurable, default=10), the VNE is automatically set to maintenance mode which means it stops polling the device. This state cannot be cleared automatically when the CPU usage decreases, the user must manually change the VNE state from the maintenance state to Start.

Correlation

The alarm correlates to other alarms using the local correlation mechanism with the ManagedElement key. No other alarms might correlate to it.

Source OID

Managed Element OID (IManagedElementOid), page 17-2.

All ip interfaces down

There might be situations where one or more (but not all) IP interfaces on a physical port are down, or all the IP interfaces are down. The All ip interfaces down alarm is used when all IP interfaces configured on the same port are down, and implies that another fault occurs in lower layers, for example, in the physical layer. In this case, one alarm is issued, and all IP interface status alarms are correlated to it.

Table 16-2 All ip interfaces down—Subtype Events 

Subtype Event Name	Description
All ip interfaces down.	Issued when all the IP interfaces configured above a physical interface change their state to down.
Active ip interfaces found.	Clearing event Issued when at least one of the IP interfaces changes its state to up.

Correlation

The alarm correlates to other alarms using the local correlation mechanism with the PortLayer1 key representing the physical layer. The PortLayer1 key is the port that all the IP interfaces were configured on.

Other alarms might correlate to this alarm using the physical port key, in particular the Interface status down alarm.

Source OID

Physical Layer OID (IPhysicalLayerOid), page 17-4.

BGP link down

When a connection between two BGP peers is lost, no route information is exchanged between the two peers. This situation affects the network connectivity because route entries which are not refreshed start to be dropped from the routing table causing packets to be dropped.

In this scenario, when a BGP neighbor has an adjacent peer (meaning that it is connected to another BGP neighbor with a discovered link), a BGP link down alarm is issued. When the adjacent peer is not managed, a BGP neighbor loss alarm is issued. A VNE identifies this situation based on changes in the BGP neighbor table of the device.

Due to the nature of this fault, it is possible that one of the devices is unreachable. In this case, the respective VNE does not identify the changes in the BGP neighbor table of the unreachable device, yet a BGP link down is issued.

A negotiation process between the two link edges is issued when the BGP neighbor entry state changes from Established to identify that a BGP link down should be invoked.

Table 16-3 BGP link down—Subtype Events 

Subtype Event Name	Description
BGP link down.	Issued when a BGP neighbor entry has changed its state from Established to another state, or a BGP neighbor entry that had an Established state has been removed from the BGP neighbors table and the entry has an adjacent peer. BGP neighbor state complies to the definitions in BGP4-MIB::bgpPeerState (1.3.6.1.2.1.15.3.1.2). In the case of a state change, any state other than Established implies the connection between the BGP peers is not fully functioning meaning route information is not exchanged.
BGP link down vrf.	Issued in the same conditions as the BGP link down alarm except that the neighbor is defined in the context of a VRF (BGP connection between PE router and CE router).
BGP link up.	Clearing event Issued when one of the edge BGP neighbor entries has changed its state from any state other than Established to Established. This is the clearing alarm for both the BGP link down alarms described above.

Correlation

The alarm correlates to other alarms using the network correlation mechanism that runs a forward IP flow to the BGP neighbor peer IP. This flow runs a forward flow from each of the BGP neighbors to its peer IP, and might collect the following alarms: Interface status down, Port down, Link down, Device unreachable, and so on.

Other alarms might correlate to it using the MPBgp key or the MPBgp key concatenated with the neighbor peer IP. Furthermore, the relevant BGP neighbor down syslogs are correlated to the service alarm.

---

Note The alarms BGP link down and BGP link down vrf do not filter out the BGP process down alarm in the correlation process.

---

Source OID

MpBgp OID (IMpBgpOid), page 17-6.

BGP neighbor loss

A BGP neighbor loss alarm is issued, when a BGP neighbor has an adjacent peer which is not managed.

When a connection between two BGP peers is lost, no route information is exchanged between the two peers. This situation affects the network connectivity because route entries which are not refreshed start to be dropped from the routing table after a while, causing packets to be dropped.

In this scenario, if only one of the peers is managed, a BGP neighbor loss alarm is issued instead of a BGP link down alarm. A VNE identifies this situation based on changes in the BGP neighbor table of the device.

Due to the nature of this fault, it is possible that one of the devices is unreachable. In this case, the respective VNE cannot identify the changes in the BGP neighbor table of the unreachable device, and thus does not issue the alarm although the BGP connection has been lost. Only one alarm is issued from the reachable side.

Table 16-4 BGP neighbor loss—Subtype Events 

Subtype Event Name	Description
BGP neighbor loss.	Issued when a BGP neighbor entry has changed its state from Established to another state, or when a BGP neighbor entry with the Established state has been removed from the BGP neighbors table. BGP neighbor state complies to the definitions in BGP4-MIB::bgpPeerState (1.3.6.1.2.1.15.3.1.2). In the case of a state change, any state other than Established implies that the connection between the BGP peers is not fully functioning, meaning that the route information is not exchanged.
BGP neighbor loss vrf.	Issued in the same conditions as the BGP neighbor loss alarm, except that the neighbor is defined in the context of a VRF (BGP connection between PE router and CE router).
BGP neighbor found.	Clearing event Issued when a BGP neighbor entry has changed its state from any state other than Established to the Established state, or a new BGP neighbor entry that has an Established state has been discovered in the BGP neighbors table. This is the clearing alarm of both neighbor loss alarms described above.

Correlation

The alarm correlates to other alarms using the network correlation mechanism that runs a forward IP flow to the BGP neighbor peer IP. This flow runs a forward flow from each of the BGP neighbors to its peer IP, and might collect the following alarms: Interface status down, Port down, Link down, Device unreachable, and so on.

Other alarms might correlate to it using the MPBgp key or the MPBgp key concatenated with the neighbor peer IP. Furthermore, the relevant BGP neighbor down syslogs are correlated to the service alarm.

---

Note The alarms BGP neighbor loss and BGP neighbor loss vrf do not filter out the BGP process down alarm in the correlation process.

---

Impact Analysis

The alarm issues an impact analysis process that calculates the affected services of this fault. In this case, the affected service is represented as a pair of VRFs that cannot communicate due to this BGP neighbor loss fault.

The affected pair (service) can be marked as potentially affected or real affected. In this case, because the BGP reports on a neighbor loss only, after a hold-time interval (the default value is 180 sec) in which it did not get the hello message from its neighbor, it assumes that the connection was lost and cannot be recovered. The identified affected pairs are marked as real affected.

Source OID

MpBgp OID (IMpBgpOid), page 17-6.

BGP process down

BGP process down is issued when the BGP process/service running on a device goes down. If such an alarm is not issued, a separate BGP neighbor loss alarm is created for each BGP neighbor, and these alarms are not correlated.

Table 16-5 BGP process down—Subtype Events 

Subtype Event Name	Description
BGP process down.	Issued when the BGP process/service is down after it was up. The BGP component in the VNE identifies this change and updates its state and issues the alarm.
BGP process up.	Clearing event Issued when the BGP process/service changes its state back to up. The BGP component in the VNE identifies this change, updates its state and issues the clearing alarm.

Correlation

Due to the nature of this alarm it cannot be correlated to other alarms, thus this alarm does not try to run any correlation process.

Other alarms might correlate to it using the MPBgp key, in particular BGP neighbor loss alarms caused by this failure correlate to it.

Source OID

MpBgp OID (IMpBgpOid), page 17-6.

Broken LSP discovered

MPLS Broken LSPs is issued as a companion to the MPLS black hole alarm. For more information on MPLS black hole, see MPLS black hole found.

MPLS Broken LSP means that a LSP at some point goes through a MPLS black hole that means that all the MPLS labels are removed from the packet, and one of the following scenarios occurs:

1. If the packet contains more than one MPLS label (this is the case where the data contained in the packet is VPN traffic), the packet is dropped or is forwarded to an incorrect destination. This happens because the IP header in the packet belongs to a different routing domain.

2. If the packet contains only one MPLS label (this is the case where the data contained in the packet belongs to the same routing domain), the packet continues to be forwarded based on the IP header information instead of the MPLS labels. This is not a problem.

The following information applies to the Broken LSP discovered alarm:

1. This alarm does not have a clearing alarm that means that after it is issued its severity cannot be changed.

2. To overcome the previous limitation the alarm auto-clear flag is set to true. This means that this alarm severity does not have an impact on the severity of other alarms that it correlates to.

3. Though the Broken LSP discovered alarm is issued as a companion to the MPLS black hole, it does not imply that it is issued from the same device that issued the MPLS black hole alarm.

After an MPLS black hole alarm is issued, a process starts that looks for broken LSPs that go through this MPLS black hole. The process of discovering the broken LSPs is as follows:

1. At the VNE on which the MPLS black hole was issued, all label switching entries that were destined for the black hole, have an untagged out label. All MPLS labels are removed from packets traversing using this label switching entry.

2. Each untagged label switching entry starts traversing the LSP using a backward flow.

---

Note Backward flow is a flow on the virtual network model that traverses the model in the opposite direction to a standard packet flow traversing the network.

---

3. On each device traversed in the backward flow, check if the device contains a configuration of MPLS-based services. Currently, the following identification services are supported:

–Existence of VRFs (BGP/MPLS VPN services based on RFC2547).

–Existence of MPLS Layer2 tunnels (PWE3 services based on RFC4448).

4. If the device contains such services, a Broken LSP discovered alarm is issued for each LSP traversed backwards to that point.

This means that only PE routers issue such alarms. It is possible that the same LSP have entry points in multiple devices, and thus multiple alarms are issued for it.

5. Information that is important for each Broken LSP alarm issued is the entry point: label switching entry, and the exit point: the IP subnet destination.

This information is used in the impact analysis process to identify the relevant affected pairs (services).

Table 16-6 Broken LSP discovered—Subtype Events 

Subtype Event Name	Description
Broken LSP discovered.	Issued as a companion to the MPLS black hole alarm as described above. For every LSP traversing the black hole, a Broken LSP discovered alarm is issued. There is no clearing event.

Correlation

This alarm is correlated by definition to one of the following:

1. The MPLS black hole that triggered the discovery of this Broken LSP.

2. Link down alarm, if the link down caused the MPLS traffic to change its course and pass through the black hole.

No other alarms might correlate to it.

Impact Analysis

The alarm issues an impact analysis process that identifies the local affected services of this fault. In this case, affected services can be of two types:

1. A pair of VRFs that cannot communicate due to this broken LSP, for BGP/MPLS VPN services.

2. A pair of MPLS Layer 2 tunnel edges representing a PWE3 service endpoint.

The affected pairs in this alarm are marked as potentially affected.

---

Note The system can be configured to present the affected pairs for BGP/MPLS VPN services as pairs of VRF IP interfaces instead of just the VRFs. This creates, in most cases, additional pairs that might cause a load on the system. This is disabled by default.

---

Source OID

LSE Entry OID (IMplsEntryOid), page 17-8

The LSE entry that is the entry point to the broken LSP.

Card down

The Card down alarm represents a state in which the card is not operational. This can be caused by a hardware failure, or by configuring the card's administrative state.

Table 16-7 Card down—Subtype Events 

Subtype Event Name	Description
Card down.	Issued when the card's operational state is changed to down. This can be caused by a hardware failure, or by configuring the card administrative state.
Card up.	Clearing event Issued when the operational state of the card changes back to up.

Correlation

Due to the nature of this alarm, the event does not try to correlate to another event, and creates a new ticket in the gateway where the event is the root cause alarm of the ticket.

Other alarms might correlate to it using the Card key.

Source OID

Module OID (IModuleOid), page 17-5.

Card out

The Card out alarm represents a state where the card is removed from the device. The Card out alarm is also issued when a device stops reporting on the existence of a card due to another failure, even if the card is actually still in the device. It is assumed that any functionality that was implemented by the card is not working anymore if the card had no redundancy configuration.

Table 16-8 Card out—Subtype Events 

Subtype Event Name	Description
Card out.	Issued when a card is removed from the device. It is possible that some card failures are identified as Card out because the device does not report on the card's existence after a failure.
Sub-card out.	Issued when a card that is contained in another card is removed from the device. When a card which contains other cards is removed then, in addition to the Card out alarm issued on the main card, a Subcard out alarm is issued for each of its subcards. It is possible that some failures of cards that contain subcards are identified as Card down of the parent card and Subcard out for the subcards, because the device stops reporting on the existence of the subcards.
Card in.	Clearing event Issued when the card is inserted back into the device.

Correlation

Due to the nature of the Card out alarm, the event does not try to correlate to another event, and creates a new ticket in the gateway where the event is the root cause alarm of the ticket. The Subcard out alarm correlates to other alarms using the local correlation mechanism with Subcard key and its parent Card key.

Other alarms might correlate to it using the Card and Subcard keys.

Source OID

Module OID (IModuleOid), page 17-5.

Cloud problem

Cisco ANA uses a Cloud VNE to represent unmanaged network segments so that operations like Path Trace and Root Cause Analysis (RCA) are viewed or processed end-to-end. A Cloud VNE represents the unmanaged segment of a network as a single device to which two or more managed segments of the network can be connected.

In a network in which a segment of the network is unmanaged, Cisco ANA runs a correlation flow to find the root cause. If no root cause is found within the managed segment, a Cloud problem service alarm is created, to which events are correlated.

Table 16-9 Cloud problem—Subtype Events 

Subtype Event Name

Description

Cloud problem.

An alarm might use network correlation using IP-based forward flow to a destination. During the flow, the alarm collects possible alarms with which to correlate. If it can not find no such alarms, and the flow has traversed a Cloud VNE (that is a network segment which is unmanaged by Cisco ANA), at the end of the flow a Cloud problem alarm is issued. The original alarm is correlated to it. This alarm does not have a clearing alarm, thus the severity of the Cloud problem alarm is INFO.

Correlation

Due to the nature of the Cloud problem alarm, the event does not try to correlate to another event, but creates a new ticket in the gateway where the event is the root cause alarm of the ticket.

---

Note When required a correlation filter, filters the Cloud problem alarm. This enables or disables the ability of an alarm to create a Cloud problem alarm, and to correlate to it. The default value is false for all alarms in the system, meaning that an alarm does not correlate to the Cloud problem alarm by default. However, there are several events that override the default configuration (these events are specific to Cisco devices) and are set to true, as follows:
BGP neighbor down syslog
OSPF neighbor loss syslog
EIGRP router query to neighbors timeouted syslog

---

As described above, other alarms might be correlated to it using the logic in the Cloud problem subalarm. See Cloud problem.

---

Note The Cloud problem alarm does not filter the BGP process down alarm in the correlation process.

---

Source OID

Managed Element OID (IManagedElementOid), page 17-2.

Component unreachable

A VNE might be configured to poll its respective device in multiple network protocols, for example SNMP and Telnet. In addition, each protocol might be configured for reachability testing. This means that when the VNE stops responding using a protocol, the device is considered unreachable.

Table 16-10 Component Unreachable—Subtype Events 

Subtype Event Name	Description
Device unreachable.	Issued when the device is not responding to at least one of the network protocols that are configured for reachability. The VNE uses a retries mechanism to make sure the problem persists for a certain (configurable) duration before issuing an alarm. This means that it is resilient to short periods of network packet loss. Note ANA will generate "Device unreachable" events, with corresponding "SNMP timeout" messages in the AVM log file, for devices with non-unique SNMP Engine IDs. These IDs are normally derived from the device's unique MAC address and assigned automatically. They can also be user-customized. We recommend that you avoid custom SNMP Engine IDs. If you do use them, make sure they are unique.
Device reachable.	Clearing event Issued when the device responds to all the network protocols that are configured for reachability.

Source OID

The Managed Element of the Cloud VNE (Managed Element OID (IManagedElementOid), page 17-2).

Checking Reachability

Reachability used by the VNEs (checks the reachability between the VNEs and NEs) depends on the configuration of the VNE, and involves multiple connectivity tests using SNMP, Telnet/SSH and ICMP, as appropriate.

The following table describes the various situations where a NE fails to respond to the protocols:

Table 16-11 Unreachable Network Elements 

VNE Type	Checks reachability using	When the NE fails to respond	When the NE is reachable
ICMP VNE	ICMP only. During the ICMP test the unit pings the NE every configured interval.	ICMP ping is suspended, and a VNE Unreachable event is sent to the Cisco ANA Gateway. Only the reachability tests are run thereafter to detect when the device is reachable again.	ICMP ping is restarted, and the alarm is cleared.
Generic VNE	•SNMP only (default). Polls the sysoid of the NE using an SNMP get command during the SNMP reachability test, and expects to receive a response or •SNMP only (default), and adding an ICMP test.	General polling is suspended, and a VNE Unreachable event is sent to the Cisco ANA Gateway. Only the reachability tests are run thereafter to detect when the device is reachable again. If more than one protocol is used, it is enough for one of them to become unreachable to generate the event. The event is generic to all the protocols.	•General polling is restarted, and all commands are sent to the device, smoothed across the polling interval. •The alarm is cleared.
Full VNE	•SNMP only (default). Polls the sysoid of the NE using an SNMP get command during the SNMP reachability test, and expects to receive a response or •SNMP only (default), and adding ICMP and Telnet. During the Telnet test, the unit sends Enter via the open session and expects to get a prompt back.	General polling is suspended, and a VNE Unreachable event is sent to the Cisco ANA Gateway. Only the reachability tests are run thereafter to detect when the device is reachable again. If more than one protocol is used, it is enough for one of them to become unreachable to generate the event. The event is generic to all the protocols.	•General polling is restarted, and all commands are sent to the device, smoothed across the polling interval. •The alarm is cleared.

Each of these scenarios has two possible settings in the registry, namely:

•Track reachability (true/false). The default is true.

When this parameter is true, reachability is tracked according to the specific protocol, for example, ICMP, SNMP, Telnet, and so on.

When this parameter is false, the test is not performed.

•Lazy reachability (true/false). The default is false. This parameter determines whether there is a dedicated reachability command in charge of tracking reachability or whether reachability is determined by the regular polled commands.

When this parameter is true, reachability is based on polling, and a dedicated command is not activated.

When this parameter is false, a dedicated SNMP command is activated, and this test verifies the response from a specific SNMP OID (sysoid is the default that can be changed).

After the first failure of a command and all its retries, the device is considered unreachable. At this time, Cisco ANA starts to poll the device using the dedicated reachability command (see Table 16-11). In normal track reachability mode (lazy=false), the reachability commands run all the time. When the reachability test succeeds for the first time, it stops running and the device is considered reachable again.

---

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

---

Correlation

The alarm correlates to other alarms using the network correlation mechanism, which runs a forward IP flow from the global Routing Entity to the management IP, that is to the IP of the unit on which the VNE resides. This flow might collect the following alarms: Device unreachable, Link down, Port down, Interface status down, BGP neighbor loss, and so on.

Other alarms might correlate to it using the ManagedElement key.

---

Note The Device unreachable alarm filters out the Link down on unreachable alarm in the correlation process. Events with the same weight are not filtered out.

---

Source OID

Managed Element OID (IManagedElementOid), page 17-2.

CPU utilization

A VNE is configured to trace its device CPU utilization. An alarm is issued when the device CPU utilization crosses the configured thresholds. The upper and lower thresholds are defined in the registry under the ManagedElement.

Table 16-12 CPU utilization—Subtype Events 

Subtype Event Name	Description
CPU over utilized.	Issued when the device CPU is above the configured upper threshold.
CPU normal utilization.	Clearing event Issued when the device CPU returns to below the lower threshold.

Correlation

Due to the nature of the CPU utilization alarm, the event does not try to correlate to another event, it creates a new ticket in the gateway where the event is the root cause alarm of the ticket.

No other alarm tries to correlate to this alarm.

Source OID

Managed Element OID (IManagedElementOid), page 17-2.

Device unsupported

A VNE identifies various loading situations that prevent regular operation of the VNE. When such a situation occurs the VNE issues a Device unsupported alarm.

Table 16-13 Device unsupported—Subtype Events 

Subtype Event Name

Description

Device unsupported.

Issued for the following scenarios: •The device type identified by its sysOid is not identified by the system. •The device software version is not supported and the VNE is configured to react when a device is unsupported. Other possible actions are: use the default version, load generic VNE, or load ICMP VNE. •Registry problems occur when trying to load generic or ICMP VNEs. •The VNE failed to retrieve the device sysOid or software version.

Correlation

Due to the nature of the Device unsupported alarm, the event does not try to correlate to another event and creates a new ticket in the gateway where the event is the root cause alarm of the ticket.

No other alarm tries to correlate to this alarm.

Source OID

Managed Element OID (IManagedElementOid), page 17-2.

Dropped packets

A VNE is configured to trace the dropped packets counters on its device ports. An alarm is issued when a dropped counter from a port crosses the configured thresholds. The upper and lower thresholds are defined in the registry under the PortLayer1.

Table 16-14 Dropped packets—Subtype Events 

Subtype Event Name	Description
Dropped packets on port.	Issued when the dropped packets on a device's port are above the configured threshold.
Stopped dropping packets on port.	Clearing event Issued when the dropped packets on a device's port are below the configured threshold.

Correlation

Due to the nature of the Dropped packets on port alarm, the event does not try to correlate to another event and creates a new ticket in the gateway where the event is the root cause alarm of the ticket.

No other alarm tries to correlate to this alarm.

Impact Analysis

By default, impact analysis is not supported for this alarm, but it can be enabled. If enabled, a flow starts to collect all the affected services passing this port. The endpoint of such services can be any termination point, for example IP Interface, VC, Port, VRF, and so on.

Source OID

Physical Layer OID (IPhysicalLayerOid), page 17-4.

Discard packets

A VNE is configured to trace the discarded packets counters on its device ports. An alarm is issued when a port's discarded counter crosses the configured thresholds. The upper and lower thresholds are defined in the registry under the PortLayer1.

Table 16-15 Discard packets—Subtype Events 

Subtype Event Name	Description
Discard packets.	Issued when the discarded packets on a device's port are above the configured threshold.
Normal discard packets.	Clearing alarm Issued when the discarded packets on a device's port are below the configured threshold.

Correlation

Due to the nature of the Discard packets alarm, the event does not try to correlate to another event, and creates a new ticket in the gateway where the event is the root cause alarm of the ticket.

No other alarm tries to correlate to this alarm.

Impact Analysis

By default, impact analysis is not supported for this alarm, but it can be enabled. If enabled, a flow starts to collect all the affected services passing this port. The endpoint of such services can be any termination point, for example IP Interface, VC, Port, VRF, and so on.

Source OID

Physical Layer OID (IPhysicalLayerOid), page 17-4.

GRE tunnel down

GRE (Generic Routing Encapsulation) tunnels are basically stateless that means that when the tunnel is down the tunnel edges might not identify this situation and keeps reporting the tunnel as up. To overcome this, the GRE tunnel edge can be configured to send keep-alive messages. If at some point a GRE tunnel edge does not receive keep-alive messages it can change its state to down.

The GRE tunnel down alarm is supported only on GRE tunnels that are configured with keep-alive messages. When keep alive is configured on the GRE tunnel edge, if a failure occurs in the GRE tunnel at any point, both IP interfaces of the GRE tunnel edges changes their state to down. This makes sure that the alarm is identified. If keep-alive is not configured on the GRE tunnel edge, because the alarm creation is triggered by the state change of the IP interface of the GRE tunnel, the GRE tunnel down alarm might not be generated.

Table 16-16 GRE Tunnel Down—Subtype Events 

Subtype Event Name	Description
GRE tunnel down.	Issued when GRE link exists between the two tunnel edges and the state of the IP interface of one of the GRE tunnel edges changes to down. A simple negotiation procedure is done to avoid sending the alarm from both edges of the GRE tunnel, and a GRE tunnel down alarm is issued.
GRE tunnel up.	Clearing event Issued when the IP interface state changes back to up. The clearing alarm is issued even if the GRE link does not exist. For example, if the user has executed clear&remove on the alarm.

Correlation

The GRE tunnel alarm tries to correlate to other alarms using the network correlation mechanism that runs a forward IP flow from the local GRE tunnel edge to the tunnel destination IP. This flow might collect the following alarms: Link down, Port down, Interface status down, and more.

Other alarms might correlate to it using the TunnelGre key.

Source OID

Topological Link OID (ITopologicalLinkOid), page 17-2 where each endpoint is Layer 2 GRE Tunnel OID (ITunnelGreOid).

HSRP group status changed

HSRP (Hot Standby Router Protocol) is used in IP networks and allows one router to automatically assume the function of the second router if the second router fails. The current support relates to the instance where only one backup router is configured in the HSRP group, though it is possible to configure more than one.

Table 16-17 HSRP group status changed—Subtype Events 

Subtype Event Name	Description
Primary HSRP interface is not active.	Issued when the primary interface within an HSRP group changed its state to down. This means that one of the other interfaces in the group becomes the active interface in the group. This alarm tries to correlate to other alarms using the network correlation mechanism that runs a forward IP flow from the local global Routing Entity to the HSRP group backup interface IP. Alarms can correlate to this alarm using the local IPInterface key.
Primary HSRP interface is active.	Clearing event Issued when the primary interface within a HSRP group changed its state back to up after it was down. This means that if one of the other interfaces in the group was currently active it becomes secondary. This alarm is the clearing alarm for the Primary HSRP interface is not active alarm.
Secondary HSRP interface is active.	Issued when a secondary interface within an HSRP group changed its state to up. This happens when the original active interface changes its state to down and the backup interface takes over. This alarm tries to correlate to other alarms using the network correlation mechanism that runs a forward IP flow from the local global Routing Entity to the HSRP group virtual IP. Alarms can correlate to this alarm using the local IPInterface key.
Secondary HSRP interface is not active.	Clearing event for the Secondary HSRP interface is active alarm. Issued when a secondary interface within a HSRP group changed its state back to down after it was up. This means that the original active interface in that group changed its state to up.

Correlation

For correlation to work, there must be a correlation path between the routers. Correlation details are described in the relevant subtype events in Table 16-17.

Source OID

IP Interface of the active or secondary interface IP Interface OID (IPInterfaceOid), page 17-6.

Interface status

A VNE is configured to trace the operational state of its IP interfaces. When the status of an IP interface changes, the VNE issues the relevant alarm. There are multiple subtype events for Interface status down that are issued in different scenarios. Each has a different behavior; these are described in Table 16-18.

Table 16-18 Interface status—Subtype Events 

Subtype Event Name	Description
Interface status down (GRE tunnel).	Issued when the IP interface on a GRE tunnel changes its state to down. Correlation—This alarm issues a local correlation process and tries to correlate to the GRE tunnel down alarm. If the GRE tunnel down does not exist (for example, in the case where no GRE link exists) the alarm is issued as the root cause. When the GRE tunnel is issued from the other edge of the tunnel, it uses the local alarm to correlate to it. Other alarms might correlate to it using the IPInterface key. This includes alarms such as Device unreachable or any other alarms that perform network correlation and where the correlation flow traverses the IP interface.
Interface status down (connection that is a point-to-point connection).	Issued when a point-to-point IP interface changes its state to down. The identification of this type of interface is done using the following: 1. The subnet mask is /30 or /31. 2. The IP interface is on one VC encapsulation. Correlation—The alarm correlates to other alarms using the network correlation mechanism that runs a forward down IP flow from the IP interface to other IP addresses in the IP interface's IP address subnet. This flow might collect the following alarms: Link down, Port down, and so on. Other alarms might correlate to it using the IPInterface or the Physical port (PortLayer1) keys.
Interface status down (non-connection that is multi-point connection).	Issued when a point-to-point IP interface changes its state to down. The identification of this type of interface is done using the following: 1. The number of encapsulations under the IP interface/MPLS is greater than one. 2. Any other case not covered in the above scenarios. Correlation—The alarm correlates to other alarms using the network correlation mechanism that runs a forward down flow from the IP interface to the Physical port (PortLayer1) under this interface.
Interface status up.	Clearing event Issued when an IP interface changes its operational state from down to up.

Correlation

Correlation details are described in the relevant subtype events in Table 16-18.

Source OID

IP Interface OID (IPInterfaceOid), page 17-6.

Investigation state

Situations might occur where one or more physical components (specifically modules) are not identified by the VNE's physical investigation component. This is not an unusual scenario because many devices have large sets of supported modules where not all of the modules are supported by the VNE. The alarm is issued in this scenario.

Table 16-19 Investigation state—Subtype Events 

Subtype Event Name	Description
Investigation state.	Issued when one or more modules are not identified by the physical investigation component of the VNE. There is no clearing event.

Correlation

Due to the nature of the Investigation state alarm, the event does not try to correlate to another event, and creates a new ticket in the gateway where the event is the root cause alarm of the ticket.

No other alarm tries to correlate to this alarm.

Source OID

Managed Element OID (IManagedElementOid), page 17-2.

L2tp peer not established

This alarm is specific to the Redback Networks implementation of L2TP and is based on the state of an L2TP Peer that is basically a logical entity from which L2TP tunnels are created. It is also used as a container for these L2TP tunnels. The alarm is issued when the L2TP Peer has an incorrect tunnel configuration and the tunnels between the LAC and the LNS cannot be created.

Table 16-20 L2tp peer not established—Subtype Events 

Subtype Event Name	Description
l2tp peer not established.	Issued when the L2TP Peer has an incorrect configuration and L2TP tunnels cannot be created between the LAC and the LNS. This is identified by querying the state of the L2TP Peer tunnels that does not change to Established.
l2tp peer is removed.	Issued when the L2TP Peer is removed from the L2TP Peer list, or when the first tunnel in the Peer changes its state from Established to another state.
l2tp peer established.	Clearing event Issued when at least one tunnel of L2TP Peer is in an Established state.

Correlation

The alarm correlates to other alarms using the network correlation mechanism that runs a forward down flow from the L2TP Peer to the remote IP.

Other alarms can correlate to this alarm using the local L2TPPeer key.

Source OID

L2TP Peer OID (IL2tpPeerOid), page 17-9.

L2tp sessions threshold

This alarm is specific to the Redback Networks implementation of L2TP and is implemented as a TCA of the number of sessions in a L2TP Peer. The alarm is issued when the number of L2TP sessions related to L2TP Peer crosses a configurable threshold.

Table 16-21 L2tp sessions threshold—Subtype Events 

Subtype Event Name	Description
l2tp sessions count exceeds max threshold.	Issued when the number of active sessions associated with L2TP Peer crosses a configurable threshold (the default is 80%). The calculation is done as follows: active-sessions/(max-session-per-tunnel * max-tunnels-per-peer) * 100.
l2tp sessions count has returned to normal.	Clearing event Issued when the number of active sessions associated wit h L2TP Peer drops below the lower threshold (the default is 70%).

Correlation

Due to the nature of the L2tp sessions count exceeds max threshold alarm, the event does not try to correlate to another event, and creates a new ticket in the gateway where the event is the root cause alarm of the ticket.

No other alarm tries to correlate to this alarm.

Source OID

L2TP Peer OID (IL2tpPeerOid), page 17-9.

---

Note This alarm is implemented as TCA, which means that no information about this alarm is found in the standard event-related registry.

---

Layer 2 tunnel down

A Layer 2 tunnel represents a point-to-point pseudo-wire in the network, also known as a Martini tunnel or AToM. The alarm is issued when the operational state of a Layer 2 tunnel changes.

Table 16-22 Layer 2 tunnel down—Subtype Events 

Subtype Event Name	Description
Layer 2 tunnel down.	Issued when the operational state of the Layer 2 tunnel changes its state to down. This can happen due to a problem between the two edges of the tunnel or on the local tunnel interface. A simple negotiation procedure is done to avoid sending the alarm from both edges of the Layer 2 tunnel, when the state changes on both edges.
Layer 2 tunnel up.	Clearing event Issued when the Layer 2 tunnel changes its state back to up.

Correlation

As this alarm can be caused by multiple reasons, it issues multiple network correlation flows which runs:

1. A network flow from the Layer 2 tunnel to the remote IP to identify problems that occur between the tunnel edges.

This flow might collect the following alarms: Link down, Port down, MPLS related alarms, and so on.

2. A network flow from the local Layer 2 tunnel edge to the physical port on which it is configured, to identify problems that occur on the local physical interface.

This flow might collect the following alarms: Link down, Port down, and so on.

3. A network flow from the remote Layer 2 tunnel edge to the physical port on which it is configured, to identify problems that occur on the remote physical interface.

This flow might collect the following alarms: Link down, Port down, and so on.

Any alarm can correlate to this alarm using the PTPLayer2MplsTunnel (which represents the Layer 2 tunnel edge) key.

---

Note The alarm Layer 2 tunnel down does not filter out the LDP neighbor down alarm in the correlation process.

---

Source OID

Topological Link OID (ITopologicalLinkOid), page 17-2 where each endpoint is Layer 2 Mpls Tunnel OID (IPTPMplsLayer2TunnelOid).

LDP neighbor loss

The VNE is configured to trace the state of the current LDP neighbor of its device. The VNE issues the relevant alarm when it identifies that an existing LDP neighbor has been removed, or that an LDP neighbor that was removed has been restored.

The identification of this alarm is expedited by notifications such as syslogs or traps.

Table 16-23 LDP neighbor loss—Subtype Events 

Subtype Event Name	Description
LDP neighbor down.	Issued when a LDP neighbor of the device that was previously discovered is removed.
LDP neighbor up.	Clearing event Issued when the LDP neighbor that was previously removed is restored and is currently active.

Correlation

This alarm issues a network correlation flow that runs a forward down flow from the global Routing Entity to the LDP peer IP address.

This flow might collect the following alarms: MPLS interface removed, Link down, Port down, and so on.

Any alarm can correlate to this alarm using the LDPPeer or LDPPeerDiscoverySources keys.

---

Note The alarm LDP neighbor down does not filter out the MPLS interface removed alarm in the correlation process.

---

Source OID

Label Switching Entity (LSE OID (ILseOid), page 17-7) with the differentiator object of the LDP Peer.

Link down

This is one of the basic service alarms supported in the system. When a port has an adjacent peer, (it is connected to another port and has a discovered link) and its operational state changes from up to down or from down to up, the alarm is issued. When the port is not adjacent, a Port down alarm is issued instead of a Link down alarm. See Port down.

The negotiation process between the two link edges occurs when the port's operational state changes to down to identify the exact event that should be issued.

Table 16-24 Link down—Subtype Events 

Subtype Event Name	Description
Link down due to admin down.	Issued when the admin state of at least one of the link ports changes to down. Correlation—Due to the nature of this alarm, the event does not try to correlate to another event, and creates a new ticket in the gateway that is the root cause alarm of the ticket.
Link down due to oper down.	Issued when the admin state is up on both ports and none of the scenarios described below occur. Correlation—This alarm issues a local correlation process and tries to correlate to other alarms using the physical port (PortLayer1) key.
Link down due to Card event.	Issued when at least one of the ports is on a card that was removed from the device, or is currently in an operational down state. Correlation—This alarm issues a local correlation process and tries to correlate to other alarms (specifically Card out or Card down) using the Module key.
Link down on unreachable.	Issued when at least one of the ports is on a device that is currently unreachable by its VNE. Correlation—This alarm issues a local correlation process in order to correlate to the Device unreachable alarm (using the ManagedElement key).
Link up.	Clearing event Issued when the port operational state changes back to up.

Link down supports flapping with the following sub-events:

•Link down flapping

•Link down flapping update

•Link down stopped flapping cleared

•Link down stopped flapping non cleared

---

Note The names of the flapping sub-events above are the same as the short description that appears for them in Cisco ANA EventVision.

---

Correlation

Other alarms can try to correlate to any link down alarm using the Physical port (PortLayer1) key.

Source OID

Topological Link OID (ITopologicalLinkOid), page 17-2 where each endpoint is Physical Layer OID (IPhysicalLayerOid), page 17-4.

Link utilization

A VNE is configured to trace the Rx and Tx counters on its device ports, where a port has an adjacent peer (that is, it is connected to another port) and it already issued a Rx over utilized or Tx over utilized alarm. For more information on these alarms, see Rx utilization and Tx utilization. This alarm has complementary functionality so that all the utilization alarms from both ports of the link correlate to it, instead of issuing multiple root cause alarms.

Table 16-25 Link utilization—Subtype Events 

Subtype Event Name	Description
Link over utilized.	Issued after Tx over utilized or Rx over utilized alarms are issued on a physical port, if the port has an adjacent peer to enable correlation of all port level utilizations alarms from the ports on both sides of the link to one Link utilization alarm.
Link utilization normal.	Clearing event Issued if both sides of the link send clearing alarms on the Tx/Rx utilization alarm.

Correlation

Due to the nature of this alarm, the event does not try to correlate to another event, and creates a new ticket in the gateway where the event is the root cause alarm of the ticket.

Other alarms can correlate to this alarm using the physical port (PortLayer1) key.

Source OID

Topological Link OID (ITopologicalLinkOid), page 17-2 where each endpoint is Physical Layer OID (IPhysicalLayerOid), page 17-4.

Logical port down

Logical ports are basically logical interfaces that are defined on physical ports. Logical ports are used to logically separate the traffic of the physical port, and control the separated traffic differently. Logical ports are currently implemented in Cisco ANA for specific VNE types (for example, Lucent WAN Switches) and specific technologies (ATM and Frame Relay). Each logical port has an independent administrative and operational state. When the operational state of a logical port changes, the VNE issues an alarm.

Table 16-26 Logical port down—Subtype Events 

Subtype Event Name	Description
Logical port down.	Issued when the operational state of a logical port changes to down.
Logical port up.	Clearing event Issued when the operational state of a logical port changes back to up.

Correlation

This alarm issues a local correlation process and tries to correlate to alarms on the physical port using the physical port (PortLayer1) key. Possible alarms that this alarm can correlate to are: Link down, Port down, or any alarm on the physical port.

Other alarms might correlate to it using the Logical port key, this include alarms that perform network correlation and the correlation flow traverses the logical port.

---

Note The alarm Logical port down does not filter out the BGP process down alarm in the correlation process.

---

Source OID

Logical Port OID (ILogicalPortOid), page 17-9.

Memory utilization

A VNE is configured to trace its device memory utilization. The alarm is issued when the device memory utilization crosses the configured thresholds. The upper and lower thresholds are defined in the registry under the ManagedElement.

Table 16-27 Memory utilization—Subtype Events 

Subtype Event Name	Description
Memory over utilized.	Issued when the device memory usage is above the configured upper threshold.
Memory OK.	Clearing event Issued when the device memory usage is back below the lower threshold.

Correlation

Due to the nature of the Memory utilization alarm, the event does not try to correlate to another event, and creates a new ticket in the gateway where the event is the root cause alarm of the ticket.

No other alarm tries to correlate to this alarm.

Source OID

Managed Element OID (IManagedElementOid), page 17-2.

MPLS black hole found

A MPLS black hole is defined as an abnormal termination of a MPLS path (LSP) inside a MPLS network. A MPLS black hole exists when there are untagged entries destined for a known PE router on a specific interface. Note that the untagged interfaces might exist in the network in normal situations. For example, where the boundary of the MPLS cloud has untagged interfaces this is still considered normal. The existence of a MPLS black hole results in a loss of all the MPLS labels on a packet, including the VPN information that lies in the inner MPLS label. So if a packet goes through an untagged interface, the VPN information is lost. The VPN information loss translates directly to VPN sites losing connectivity.

Black hole alarms are detected either:

•When the system is loaded for the first time and performs the initial discovery of the network

or

•Changes in the network are identified through the ongoing discovery process.

Table 16-28 MPLS black hole found—Subtype Events 

Subtype Event Name	Description
MPLS Black hole found.	Issued when an MPLS interface has at least one untagged LSP leading to a known PE router, that is, a LSE entry changed to an Untagged action with a PE as a next hop. After a MPLS black hole alarm is issued, a process that looks for broken LSPs which go through this MPLS black hole is started. See Broken LSP discovered.
MPLS Black hole cleared.	Clearing event Issued when the MPLS interface that had untagged LSPs to a known PE router has no more untagged entries to any known PE neighbor.

Correlation

The MPLS black hole can correlate to MPLS interface removed and LDP neighbor loss.

Broken LSP discovered can correlate to MPLS black hole found.

---

Note The alarm MPLS Black hole found does not filter out the MPLS interface removed and LDP neighbor down alarms in the correlation process.

---

Source OID

LSE OID (ILseOid) appended with a differentiator of the next hop interface name.

MPLS interface removed

The MPLS interface is basically a representation of the MPLS sub-layer in an interface configuration. The interface can be configured with or without MPLS capabilities. If this type of configuration change takes place while the VNE is loaded, it issues MPLS interface removed or added alarms.

Table 16-29 MPLS interface removed—Subtype Events 

Subtype Event Name	Description
MPLS interface removed.	Issued when an MPLS interface has at least one untagged LSP leading to a known PE router (that is, a LSE entry changed to an Untagged action with a PE as a next hop). After a MPLS black hole alarm is issued, a process that looks for broken LSPs that go through this MPLS black hole is started. See Broken LSP discovered.
MPLS interface added.	Clearing event Issued when the MPLS capabilities of an interface are enabled after they were disabled.

Correlation

The alarm correlates to other alarms using the network correlation mechanism which runs a forward flow to the underlying physical port. This flow might collect the following alarms: Card out, Card down, because the only other cases when it happens are due to other faults that are hardware related.

Other alarms might correlate to it using the MPLS key, this includes MPLS blackhole alarm, MPLS TE tunnel down alarm and so on.

Source OID

Label Switching Entity (LSE OID (ILseOid)) with differentiator object of the MPLS interface description.

MPLS TE tunnel down

A VNE is configured to trace the operational state of its MPLS TE tunnel interfaces. When the state of the tunnel changes the VNE issues the relevant alarm.

Table 16-30 MPLS TE tunnel down—Subtype Events 

Subtype Event Name	Description
MPLS-TE tunnel down.	Issued when the tunnel changes it state to down. MPLS-TE tunnel down supports flapping with the following sub-events: •MPLS-TE tunnel flapping •MPLS-TE tunnel update •MPLS-TE tunnel stopped flapping cleared •MPLS-TE tunnel stopped flapping non-cleared Note The names of the flapping sub-events above are the same as the short description that appears for them in Cisco ANA EventVision.
MPLS-TE tunnel up.	Clearing event Issued when a MPLS-TE tunnel changes its operational state from down to up.

Correlation

For all the down alarms, any other alarm can try to correlate to this alarm using the MPLS TE Tunnel OID (IMplsTETunnelOid) key. The alarm correlates to other alarms using the network correlation mechanism that runs a forward down IP flow from the MPLS-TE tunnel to its tunnel destination IP address. This flow might collect the following alarms: Link down, Port down and so on.

The alarm MPLS-TE tunnel down does not filter out the BGP process down alarm in the correlation process.

Source OID

MPLS TE Tunnel OID (IMplsTETunnelOid)

Port down

When a physical port does not have an adjacent peer (that is, it is connected to another port) and its operational state changes from up to down, or from down to up, the alarms are issued. When the port does have an adjacent peer, instead of a port down alarm a similar link down alarm is issued. See Link down.

Table 16-31 Port down—Subtype Events 

Subtype Event Name	Description
Port down.	Issued when the operational state of a physical port changes to down. MPLS-TE tunnel down support flapping with the following sub-events: •MPLS-TE tunnel flapping •MPLS-TE tunnel update •MPLS-TE tunnel stopped flapping cleared •MPLS-TE tunnel stopped flapping non-cleared
Port down due to Card event.	Issued when the port is on a card that was removed from the device or is currently in an operational down state. Correlation—This alarm issues a local correlation process and tries to correlate to other alarms (specifically Card out or Card down) using the Module key.
Port up.	Clearing event Issued when the operational state of a logical port changes back to up.

Port down supports flapping with the following sub-events:

•Port down flapping

•Port down flapping update

•Port down stopped flapping cleared

•Port down stopped flapping non cleared.

Correlation

For all the down alarms, any other alarm can try to correlate to this alarm using the Physical port (PortLayer1) key.

Source OID

Physical Layer OID (IPhysicalLayerOid)

Rx dormant

A VNE is configured to trace the Rx packets counters on its device's ports. An alarm is issued where a port's Rx counter drops below the configured thresholds.

---

Note This alarm is disabled by default.

---

Table 16-32 Port down—Subtype Events 

Subtype Event Name	Description
rx dormant.	Issued when the Rx packets on a device's port are below the configured threshold.
rx dormant normal.	Clearing event Issued when the Rx packets on a device's port return to above the configured threshold.

Correlation

The Rx dormant on port alarm does not start a correlation process and is always issued as a root cause alarm.

Source OID

Physical Layer OID (IPhysicalLayerOid)

Rx utilization

A VNE is configured to trace the Rx packets counters on its device's ports. An alarm is issued when a port's Rx counter crosses the configured thresholds. The upper and lower thresholds are defined in the registry under the PortLayer1. Where the port has an adjacent peer (that is, it is connected to another port) a Link utilization alarm is also issued. For more information on these alarms, see Link utilization.

Table 16-33 Rx utilization—Subtype Events 

Subtype Event Name	Description
Rx over utilized.	Issued when the Rx packets on a device's port are above the configured threshold.
Rx utilization normal.	Clearing event Issued when the Rx packets on a device's port return to below the configured threshold.

Correlation

The Rx utilization on port alarm does not start a correlation process. No other alarm tries to correlate to this alarm as currently there are no supported alarms that can be affected by the Rx utilization alarm.

Impact Analysis

Impact analysis is not supported by default for this alarm, but can be enabled. If it is enabled, a flow starts to collect all the affected services passing this port. The endpoint of such services can be any termination point, for example IP Interface, VC, Port, VRF, and so on.

Source OID

Physical Layer OID (IPhysicalLayerOid)

Shelf out

The Shelf out alarm represents a state in which the shelf is removed from the device. The Shelf out alarm is also issued when the device stops reporting on the existence of a shelf due to another failure, even if the shelf is actually still in the device. It is assumed, that any functionality that was implemented by the shelf is not working anymore if the shelf had no redundancy configuration.

Table 16-34 Shelf out—Subtype Events 

Subtype Event Name	Description
Shelf out.	Issued when a shelf is removed from the device. It is possible that some shelf failures are identified as Shelf out, because the device does not report on the shelf's existence after the failure.
Shelf in.	Clearing event Issued when the shelf is inserted back into the device.

Correlation

Due to the nature of the Shelf out alarm it does not start a correlation process and is always issued as a root cause alarm.

Other alarms might correlate to it using the Shelf key, for example Card out alarm.

Source OID

Shelf OID (IShelfOid)

Tx dormant

A VNE is configured to trace the Tx packets counters on its device's ports. An alarm is issued when a port's Rx counter is drops below the configured thresholds. The upper and lower thresholds are defined in the registry under the PortLayer1.

---

Note This alarm is disabled by default.

---

Table 16-35 Shelf out—Subtype Events 

Subtype Event Name	Description
tx dormant.	Issued when the Tx packets on a device's port are below the configured threshold.
tx dormant normal.	Clearing event Issued when the Tx packets on a device's port return to above the configured threshold.

Correlation

The Tx dormant on port alarm does not start a correlation process and is always issued as a root cause alarm.

Source OID

Physical Layer OID (IPhysicalLayerOid)

Tx utilization

A VNE is configured to trace the Tx packets counters on its device's ports. An alarm is issued when a port's Rx counter crosses the configured thresholds. The upper and lower thresholds are defined in the registry under the PortLayer1. Where the port has an adjacent peer (that is, it is connected to another port) a Link utilization alarm is also issued. For more information on these alarms, see Link utilization.

Table 16-36 Shelf out—Subtype Events 

Subtype Event Name	Description
Tx over utilized.	Issued when the Tx packets on a device's port is above the configured threshold.
Tx utilization normal.	Clearing event Issued when the Tx packets on a device's port return to below the configured threshold.

Correlation

The Tx utilization on port alarm does not start a correlation process. No other alarm tries to correlate to this alarm, as currently there are no supported alarms that can be affected by the Tx utilization alarm.

Impact Analysis

Impact analysis is not supported by default for this alarm, but can be enabled. If impact analysis is enabled, a flow starts to collect all the affected services passing this port. The endpoint of such services can be any termination point (for example, IP Interface, VC, Port, VRF, and so on).

Source OID

Physical Layer OID (IPhysicalLayerOid)

Registry Parameters

The following registry parameters are included in this section:

•Adaptive polling

•All ip interfaces down

•BGP link down

•BGP neighbor loss

•BGP process down

•Broken LSP discovered

•Card down

•Card out

•Cloud problem

•Component unreachable

•CPU utilization

•Device unsupported

•Dropped packets

•Discard packets

•GRE tunnel down

•HSRP group status changed

•Interface status

•Investigation state

•L2tp peer not established

•L2tp sessions threshold

•Layer 2 tunnel down

•LDP neighbor loss

•Link down

•Link utilization

•Logical port down

•Memory utilization

•MPLS black hole found

•MPLS interface removed

•MPLS TE tunnel down

•Port down

•Rx dormant

•Rx utilization

•Shelf out

•Tx dormant

•Tx utilization

Adaptive polling

Table 16-37 VNE switched to low polling rate due to CPU high usage 

Type	Adaptive Polling
Subtype	high polling interval
Correlation information	activate-flow=false
	correlate=true
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=124
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=MAJOR
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=VNE switched to low polling rate due to CPU high usage

Table 16-38 VNE switched to maintenance mode due to CPU high usage 

Type	Adaptive Polling
Subtype	maintenance
Correlation information	activate-flow=false
	correlate=true
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=124
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=CRITICAL
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=VNE switched to maintenance mode due to CPU high usage

Table 16-39 VNE switched back to regular polling rate 

Type	Adaptive Polling
Subtype	regular polling interval
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=124
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=CLEARED
	gw-correlation-timeout=1200000
	is-ticketable=false
	send-to-gw=true
	short-description=VNE switched back to regular polling rate

All ip interfaces down

Table 16-40 Active ip interfaces found 

Type	all ip interfaces down
Subtype	active ip interfaces found
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=837
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=CLEARED
	gw-correlation-timeout=1200000
	is-ticketable=false
	send-to-gw=true
	short-description=Active ip interfaces found
Flapping information	clear-interval=240000
	flapping-interval=60000
	flapping-threshold=5
	update-interval=200000
	update-threshold=20

Table 16-41 All ip interfaces down 

Type	all ip interfaces down
Subtype	all ip interfaces down
Correlation information	activate-flow=false
	correlate=true
	is-correlation-allowed=true
	weight=750
Northbound metadata	alarm-type=837
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=MAJOR
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=All ip interfaces down
Flapping information	clear-interval=240000
	flapping-interval=60000
	flapping-threshold=5
	update-interval=200000
	update-threshold=20

BGP link down

Table 16-42 BGP link down 

Type	BGP link down
Subtype	BGP link down
Correlation information	activate-flow=true
	correlate=true
	is-correlation-allowed=true
	weight=599
Northbound metadata	alarm-type=1221
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=MAJOR
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=BGP link down

BGP link down vrf

Table 16-43 BGP link down vrf 

Type	BGP link down
Subtype	BGP link down vrf
Correlation information	activate-flow=true
	correlate=true
	is-correlation-allowed=true
	weight=400
Northbound metadata	alarm-type=1221
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=MAJOR
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=BGP link down vrf

BGP link up

Table 16-44 BGP link up 

Type	BGP link down
Subtype	BGP link up
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=1221
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=CLEARED
	gw-correlation-timeout=1200000
	is-ticketable=false
	send-to-gw=true
	short-description=BGP link up

BGP neighbor loss

Table 16-45 BGP neighbor found 

Type	BGP neighbor loss
Subtype	BGP neighbor found
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=127
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=CLEARED
	gw-correlation-timeout=1200000
	is-ticketable=false
	send-to-gw=true
	short-description=BGP neighbor found

Table 16-46 BGP neighbor loss 

Type	BGP neighbor loss
Subtype	BGP neighbor loss
Correlation information	activate-flow=true
	correlate=true
	is-correlation-allowed=true
	weight=800
Northbound metadata	alarm-type=127
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=MAJOR
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=BGP neighbor loss

Table 16-47 BGP neighbor loss vrf 

Type	BGP neighbor loss
Subtype	bgp-neighbor-loss-vrf
Correlation information	activate-flow=true
	correlate=true
	is-correlation-allowed=true
	weight=400
Northbound metadata	alarm-type=127
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=MAJOR
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=BGP neighbor loss vrf

BGP process down

Table 16-48 BGP process down 

Type	bgp-process-down
Subtype	bgp-process-down
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=true
	weight=850
Northbound metadata	alarm-type=1501
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=CRITICAL
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=BGP process down

Table 16-49 BGP process up 

Type	bgp-process-down
Subtype	bgp-process-up
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=1501
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=CLEARED
	gw-correlation-timeout=1200000
	is-ticketable=false
	send-to-gw=true
	short-description=BGP process up

Broken LSP discovered

Table 16-50 Broken LSP discovered 

Type	Broken LSP discovered
Subtype	Broken LSP discovered
Correlation information	activate-flow=false
	correlate=true
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=129
	auto-cleared=true
	auto-removed=true
	functionality-type=SERVICE
	severity=MAJOR
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=Broken LSP discovered

Card down

Table 16-51 Card down 

Type	card down
Subtype	card down
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=true
	weight=100000
Northbound metadata	alarm-type=11
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=MAJOR
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=Card down

Table 16-52 Card up 

Type	card down
Subtype	card up
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=11
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=CLEARED
	gw-correlation-timeout=1200000
	is-ticketable=false
	send-to-gw=true
	short-description=Card up

Card out

Table 16-53 Card in 

Type	card out
Subtype	card in
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=3
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=CLEARED
	gw-correlation-timeout=1200000
	is-ticketable=false
	send-to-gw=true
	short-description=Card in

Table 16-54 Card out 

Type	card out
Subtype	card out
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=true
	weight=100000
Northbound metadata	alarm-type=3
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=MAJOR
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=Card out

Table 16-55 Sub-card out 

Type	card out
Subtype	sub-card out
Correlation information	activate-flow=false
	correlate=true
	is-correlation-allowed=true
	weight=1000
Northbound metadata	alarm-type=3
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=MAJOR
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=Card out

Cloud problem

Table 16-56 Cloud problem 

Type	cloud problem
Subtype	cloud problem
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=true
	weight=2000
Northbound metadata	alarm-type=122
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=INFO
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=cloud problem

Table 16-57 Cloud problem fixed 

Type	cloud problem
Subtype	cloud up
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=122
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=CLEARED
	gw-correlation-timeout=1200000
	is-ticketable=false
	send-to-gw=true
	short-description=cloud problem fixed

Component unreachable

Table 16-58 Device reachable 

Type	component unreachable
Subtype	component reachable
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=5
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=CLEARED
	gw-correlation-timeout=1200000
	is-ticketable=false
	send-to-gw=true
	short-description=Device reachable

Table 16-59 Device unreachable 

Type	component unreachable
Subtype	component unreachable
Correlation information	activate-flow=true
	correlate=true
	is-correlation-allowed=true
	weight=600
Northbound metadata	alarm-type=5
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=MAJOR
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=Device unreachable

CPU utilization

Table 16-60 CPU normal utilization 

Type	cpu utilization
Subtype	cpu normal use
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=17
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=CLEARED
	gw-correlation-timeout=1200000
	is-ticketable=false
	send-to-gw=true
	short-description=CPU normal utilization

Table 16-61 CPU over utilized 

Type	cpu utilization
Subtype	cpu over utilized
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=17
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=MAJOR
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=CPU over utilized

Device unsupported

Table 16-62 Device initializing 

Type	device unsupported
Subtype	device initializing
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=16
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=CRITICAL
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=Device initializing

Table 16-63 Device unsupported 

Type	device unsupported
Subtype	device unsupported
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=16
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=CRITICAL
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=Device unsupported

Dropped packets

Table 16-64 Dropped packets on port 

Type	dropped packets
Subtype	dropped packets
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=10
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=MINOR
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=Dropped packets on port

Table 16-65 Stopped dropping packets on port 

Type	dropped packets
Subtype	normal dropped packets
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=10
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=CLEARED
	gw-correlation-timeout=1200000
	is-ticketable=false
	send-to-gw=true
	short-description=Stopped dropping packets on port

Discard packets

Table 16-66 Discard packets 

Type	discard packets
Subtype	discard packets
Correlation information	activate-flow=false
	correlate=true
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=9
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=MINOR
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=Drops exceed limit

Table 16-67 Normal discard packets 

Type	discard packets
Subtype	normal discard packets
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=9
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=CLEARED
	gw-correlation-timeout=1200000
	is-ticketable=false
	send-to-gw=true
	short-description=Drops don't exceed limit

GRE tunnel down

Table 16-68 GRE tunnel down 

Type	GRE tunnel down
Subtype	GRE tunnel down
Correlation information	activate-flow=true
	correlate=true
	is-correlation-allowed=true
	weight=830
Northbound metadata	alarm-type=358
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=MAJOR
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=GRE tunnel down

Table 16-69 GRE tunnel up 

Type	GRE tunnel down
Subtype	GRE tunnel up
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=358
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=CLEARED
	gw-correlation-timeout=1200000
	is-ticketable=false
	send-to-gw=true
	short-description=GRE tunnel up

HSRP group status changed

Table 16-70 Primary HSRP interface is active 

Type	hsrp group status changed
Subtype	Primary HSRP interface is active
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=22
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=CLEARED
	gw-correlation-timeout=1200000
	is-ticketable=false
	send-to-gw=true
	short-description=Primary HSRP interface is active

Table 16-71 Primary HSRP interface is not active 

Type	hsrp group status changed
Subtype	Primary HSRP interface is not active
Correlation information	activate-flow=true
	correlate=true
	is-correlation-allowed=true
	weight=720
Northbound metadata	alarm-type=22
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=MAJOR
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=Primary HSRP interface is not active

Table 16-72 Secondary HSRP interface is active 

Type	hsrp group status changed
Subtype	Secondary HSRP interface is active
Correlation information	activate-flow=true
	correlate=true
	is-correlation-allowed=true
	weight=720
Northbound metadata	alarm-type=22
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=MAJOR
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=Secondary HSRP interface is active

Table 16-73 Secondary HSRP interface is not active 

Type	hsrp group status changed
Subtype	Secondary HSRP interface is not active
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=22
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=CLEARED
	gw-correlation-timeout=1200000
	is-ticketable=false
	send-to-gw=true
	short-description=Secondary HSRP interface is not active

Interface status

Table 16-74 Interface status down 

Type	interface status
Subtype	interface status down GRE tunnel
Correlation information	activate-flow=false
	correlate=true
	is-correlation-allowed=true
	weight=825
Northbound metadata	alarm-type=700
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=MAJOR
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=Interface status down
Flapping information	clear-interval=240000
	flapping-interval=60000
	flapping-threshold=5
	update-interval=200000
	update-threshold=20

Table 16-75 Interface status down 

Type	interface status
Subtype	interface status down connection
Correlation information	activate-flow=true
	correlate=true
	is-correlation-allowed=true
	weight=500
Northbound metadata	alarm-type=700
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=MAJOR
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=Interface status down
Flapping information	clear-interval=240000
	flapping-interval=60000
	flapping-threshold=5
	update-interval=200000
	update-threshold=20

Table 16-76 Interface status down 

Type	interface status
Subtype	interface status down non connection
Correlation information	activate-flow=true
	correlate=true
	is-correlation-allowed=true
	weight=700
Northbound metadata	alarm-type=700
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=MAJOR
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=Interface status down
Flapping information	clear-interval=240000
	flapping-interval=60000
	flapping-threshold=5
	update-interval=200000
	update-threshold=20

Table 16-77 Interface status up 

Type	interface status
Subtype	interface status up
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=700
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=CLEARED
	gw-correlation-timeout=1200000
	is-ticketable=false
	send-to-gw=true
	short-description=Interface status up
Flapping information	clear-interval=240000
	flapping-interval=60000
	flapping-threshold=5
	update-interval=200000
	update-threshold=20

Investigation state

Table 16-78 Investigation state 

Type	investigation state
Subtype	investigation state module unsupported
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=262
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=CRITICAL
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=Module unsupported

L2tp peer not established

Table 16-79 l2tp peer established 

Type	l2tp peer not established
Subtype	l2tp peer established
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=185
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=CLEARED
	gw-correlation-timeout=1200000
	is-ticketable=false
	send-to-gw=true
	short-description=l2tp peer established
Flapping information	clear-interval=240000
	flapping-interval=60000
	flapping-threshold=5
	update-interval=200000
	update-threshold=20

Table 16-80 l2tp peer is removed 

Type	l2tp peer not established
Subtype	l2tp peer is removed
Correlation information	activate-flow=true
	correlate=true
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=185
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=MAJOR
	gw-correlation-timeout=1200000
	is-ticketable=false
	send-to-gw=true
	short-description=l2tp peer is removed
Flapping information	clear-interval=240000
	flapping-interval=60000
	flapping-threshold=5
	update-interval=200000
	update-threshold=20

Table 16-81 l2tp peer not established 

Type	l2tp peer not established
Subtype	l2tp peer not established
Correlation information	activate-flow=true
	correlate=true
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=185
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=MAJOR
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=l2tp peer not established
Flapping information	clear-interval=240000
	flapping-interval=60000
	flapping-threshold=5
	update-interval=200000
	update-threshold=20

L2tp sessions threshold

Table 16-82 l2tp sessions count exceeds max threshold 

Type	l2tp sessions threshold
Subtype	l2tp sessions count exceeds max threshold
Correlation information	activate-flow=false
	correlate=true
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=N/A (TCA alarm)
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=MINOR
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=l2tp sessions count exceeds max threshold

Table 16-83 l2tp sessions count has returned to normal 

Type	l2tp sessions threshold
Subtype	l2tp sessions count has returned to normal
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=N/A (TCA alarm)
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=CLEARED
	gw-correlation-timeout=1200000
	is-ticketable=false
	send-to-gw=true
	short-description=l2tp sessions count has returned to normal

Layer 2 tunnel down

Table 16-84 Layer 2 tunnel down 

Type	layer 2 tunnel down
Subtype	layer 2 tunnel down
Correlation information	activate-flow=true
	correlate=true
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=179
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=MINOR
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=Layer 2 tunnel down

Table 16-85 Layer 2 tunnel up 

Type	layer 2 tunnel down
Subtype	layer 2 tunnel up
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=179
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=CLEARED
	gw-correlation-timeout=1200000
	is-ticketable=false
	send-to-gw=true
	short-description=Layer 2 tunnel up

LDP neighbor loss

Table 16-86 LDP neighbor down 

Type	LDP neighbor loss
Subtype	LDP neighbor down
Correlation information	activate-flow=true
	correlate=true
	is-correlation-allowed=true
	weight=670
Northbound metadata	alarm-type=557
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=MAJOR
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=LDP neighbor down

Table 16-87 LDP neighbor up 

Type	LDP neighbor loss
Subtype	LDP neighbor up
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=557
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=CLEARED
	gw-correlation-timeout=1200000
	is-ticketable=false
	send-to-gw=true
	short-description=LDP neighbor up

Link down

Table 16-88 Link down due to admin down 

Type	link down
Subtype	link down due to admin down
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=true
	weight=850
Northbound metadata	alarm-type=1
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=CRITICAL
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=Link down due to admin down
Flapping information	clear-interval=360000
	flapping-interval=150000
	flapping-threshold=5
	update-interval=200000
	update-threshold=20

Table 16-89 Link down due to Card event 

Type	link down
Subtype	link down due to card
Correlation information	activate-flow=false
	correlate=true
	is-correlation-allowed=true
	weight=850
Northbound metadata	alarm-type=1
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=CRITICAL
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=Link down due to Card event
Flapping information	clear-interval=360000
	flapping-interval=150000
	flapping-threshold=5
	update-interval=200000
	update-threshold=20

Table 16-90 Link down due to oper down 

Type	link down
Subtype	link down due to oper down
Correlation information	activate-flow=false
	correlate=true
	is-correlation-allowed=true
	weight=850
Northbound metadata	alarm-type=1
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=CRITICAL
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=Link down due to oper down
Flapping information	clear-interval=360000
	flapping-interval=150000
	flapping-threshold=5
	update-interval=200000
	update-threshold=20

Table 16-91 Link down on unreachable 

Type	link down
Subtype	link down on unreachable
Correlation information	activate-flow=false
	correlate=true
	is-correlation-allowed=true
	weight=850
Northbound metadata	alarm-type=1
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=CRITICAL
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=Link down on unreachable
Flapping information	clear-interval=360000
	flapping-interval=150000
	flapping-threshold=5
	update-interval=200000
	update-threshold=20

Table 16-92 Link up 

Type	link down
Subtype	link up
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=1
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=CLEARED
	gw-correlation-timeout=1200000
	is-ticketable=false
	send-to-gw=true
	short-description=Link up
Flapping information	clear-interval=360000
	flapping-interval=150000
	flapping-threshold=5
	update-interval=200000
	update-threshold=20

Link utilization

Table 16-93 Link over utilized 

Type	link utilization
Subtype	link over Utilized
Correlation information	activate-flow=false
	correlate=true
	is-correlation-allowed=true
	weight=0
Northbound metadata	alarm-type=642
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=MINOR
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=Link over utilized

Table 16-94 Link utilization normal 

Type	link utilization
Subtype	link utilization normal
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=true
	weight=0
Northbound metadata	alarm-type=642
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=CLEARED
	gw-correlation-timeout=1200000
	is-ticketable=false
	send-to-gw=true
	short-description=Link utilization normal

Logical port down

Table 16-95 Logical port down 

Type	logical port down
Subtype	logical port down
Correlation information	activate-flow=false
	correlate=true
	is-correlation-allowed=true
	weight=0
Northbound metadata	alarm-type=198
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=MAJOR
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=Logical port down

Table 16-96 Logical port up 

Type	logical port down
Subtype	logical port up
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=198
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=CLEARED
	gw-correlation-timeout=1200000
	is-ticketable=false
	send-to-gw=true
	short-description=Logical port up

Memory utilization

Table 16-97 Memory OK 

Type	memory utilization
Subtype	memory normal use
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=18
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=CLEARED
	gw-correlation-timeout=1200000
	is-ticketable=false
	send-to-gw=true
	short-description=Memory OK

Table 16-98 Memory over utilized 

Type	memory utilization
Subtype	memory over utilized
Correlation information	activate-flow=-
	correlate=-
	is-correlation-allowed=-
	weight=-
Northbound metadata	alarm-type=18
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=MAJOR
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=Memory over utilized

MPLS black hole found

Table 16-99 MPLS Black hole cleared 

Type	MPLS Black hole found
Subtype	MPLS Black hole cleared
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=128
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=CLEARED
	gw-correlation-timeout=1200000
	is-ticketable=false
	send-to-gw=true
	short-description=MPLS Black hole cleared

Table 16-100 MPLS Black hole found 

Type	MPLS Black hole found
Subtype	MPLS Black hole found
Correlation information	activate-flow=true
	correlate=true
	is-correlation-allowed=true
	weight=650
Northbound metadata	alarm-type=128
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=WARNING
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=MPLS Black hole found

MPLS interface removed

Table 16-101 MPLS interface added 

Type	MPLS interface removed
Subtype	MPLS interface added
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=972
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=CLEARED
	gw-correlation-timeout=1200000
	is-ticketable=false
	send-to-gw=true
	short-description=MPLS interface added

Table 16-102 MPLS interface removed

Type	MPLS interface removed
Subtype	MPLS interface removed
Correlation information	activate-flow=true
	correlate=true
	is-correlation-allowed=true
	weight=700
Northbound metadata	alarm-type=972
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=MAJOR
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=MPLS interface removed

MPLS TE tunnel down

Table 16-103 MPLS-TE tunnel down 

Type	mpls te tunnel down
Subtype	mpls te tunnel down
Correlation information	activate-flow=true
	correlate=true
	is-correlation-allowed=true
	weight=800
Northbound metadata	alarm-type=555
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=MAJOR
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=MPLS-TE tunnel down
Flapping information	clear-interval=240000
	flapping-interval=60000
	flapping-threshold=5
	update-interval=200000
	update-threshold=20

Table 16-104 MPLS-TE tunnel up 

Type	mpls te tunnel down
Subtype	mpls te tunnel up
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=555
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=CLEARED
	gw-correlation-timeout=1200000
	is-ticketable=false
	send-to-gw=true
	short-description=MPLS-TE tunnel up
Flapping information	clear-interval=240000
	flapping-interval=60000
	flapping-threshold=5
	update-interval=200000
	update-threshold=20

Port down

Table 16-105 Port down 

Type	port down
Subtype	port down
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=true
	weight=100000
Northbound metadata	alarm-type=2
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=MAJOR
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=Port down
Flapping information	clear-interval=360000
	flapping-interval=150000
	flapping-threshold=5
	update-interval=200000
	update-threshold=20

Table 16-106 Port down due to Card event 

Type	port down
Subtype	port down due to card
Correlation information	activate-flow=false
	correlate=true
	is-correlation-allowed=true
	weight=900
Northbound metadata	alarm-type=2
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=MAJOR
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=Port down due to Card event
Flapping information	clear-interval=360000
	flapping-interval=150000
	flapping-threshold=5
	update-interval=200000
	update-threshold=20

Table 16-107 Port up 

Type	port down
Subtype	port up
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=2
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=CLEARED
	gw-correlation-timeout=1200000
	is-ticketable=false
	send-to-gw=true
	short-description=Port up
Flapping information	clear-interval=360000
	flapping-interval=150000
	flapping-threshold=5
	update-interval=200000
	update-threshold=20

Rx dormant

Table 16-108 rx dormant 

Type	rx dormant
Subtype	rx dormant
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=378
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=MINOR
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=rx dormant

Table 16-109 rx dormant normal 

Type	rx dormant
Subtype	rx dormant normal
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=378
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=CLEARED
	gw-correlation-timeout=1200000
	is-ticketable=false
	send-to-gw=true
	short-description=rx dormant normal

Rx utilization

Table 16-110 Rx over utilized 

Type	rx utilization
Subtype	rx over Utilized
Correlation information	activate-flow=false
	correlate=true
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=8
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=MINOR
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=RX over utilized

Table 16-111 Rx utilization normal 

Type	rx utilization
Subtype	rx utilization normal
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=8
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=CLEARED
	gw-correlation-timeout=1200000
	is-ticketable=false
	send-to-gw=true
	short-description=RX utilization normal

Shelf out

Table 16-112 Shelf in 

Type	shelf out
Subtype	shelf in
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=33
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=CLEARED
	gw-correlation-timeout=1200000
	is-ticketable=false
	send-to-gw=true
	short-description=Shelf in

Table 16-113 Shelf out 

Type	shelf out
Subtype	shelf out
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=true
	weight=110000
Northbound metadata	alarm-type=33
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=MAJOR
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=Shelf out

Tx dormant

Table 16-114 tx dormant 

Type	tx dormant
Subtype	tx dormant
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=377
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=MINOR
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=tx dormant

Table 16-115 tx dormant normal 

Type	tx dormant
Subtype	tx dormant normal
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=377
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=CLEARED
	gw-correlation-timeout=1200000
	is-ticketable=false
	send-to-gw=true
	short-description=tx dormant normal

Tx utilization

Table 16-116 Tx over utilized 

Type	tx utilization
Subtype	tx over Utilized
Correlation information	activate-flow=false
	correlate=true
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=7
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=MINOR
	gw-correlation-timeout=1200000
	is-ticketable=true
	send-to-gw=true
	short-description=TX over utilized

Table 16-117 Tx utilization normal 

Type	tx utilization
Subtype	tx utilization normal
Correlation information	activate-flow=false
	correlate=false
	is-correlation-allowed=false
	weight=0
Northbound metadata	alarm-type=7
	auto-cleared=false
	auto-removed=true
	functionality-type=SERVICE
	severity=CLEARED
	gw-correlation-timeout=1200000
	is-ticketable=false
	send-to-gw=true
	short-description=TX utilization normal