|
|
This chapter explains how to diagnose and handle ATM fabric events generated by the Cisco 6100 Series system. The following information is presented for each of the events:
If none of the actions presented for the event are successful, contact the Cisco Technical Assistance Center (TAC) for additional support.
Table 10-1 lists ATM fabric events and their IDs, definition, severity, and description. A detailed explanation of these events and corrective actions required (if any) is located in subsections in this chapter.
| ID | Definition | Severity | Description |
|---|---|---|---|
0 | FC_ALM_EXT_MEM_PAR_ERR | Minor | ATM Chipset: external memory parity error |
1 | FC_ALM_IN_RCV_PAR_ERR | Minor | ATM Chipset: cell dropped due to ingress receive UTOPIA bus parity error |
2 | FC_ALM_EG_RCV_PAR_ERR | Minor | ATM Chipset: cell dropped due to egress receive side UTOPIA bus parity error |
3 | FC_ALM_UTOPIA_SYNC_ERR | Minor | ATM Chipset: UTOPIA bus synchronization error detected |
4 | FC_ALM_POL_EU_TIMEOUT_ERR | Minor | ATM Chipset: parity error detected on policing EU word access |
5 | FC_ALM_VCI_SIZE_ERR | Minor | ATM Chipset: ingress VCI value above max value |
6 | FC_ALM_VPI_SIZE_ERR | Minor | ATM Chipset: ingress VPI value above max value |
7 | FC_ALM_MPHY_PORT_OVERRUN | Minor | ATM Chipset: ingress UTOPIA synchronization error detected |
8 | FC_ALM_IN_FIFO_FULL | Minor | ATM Chipset: ingress cells are being dropped due to ingress capture FIFO full condition |
9 | FC_ALM_EG_CAP_SYNC_ERR | Minor | ATM Chipset: an egress capture FIFO synchronization error is detected |
10 | FC_ALM_IN_CAP_SYNC_ERR | Minor | ATM Chipset: an ingress capture FIFO synchronization error is detected |
11 | FC_ALM_INSERT_SYNC_ERR | Minor | ATM Chipset: ingress insertion FIFO synch error |
12 | FC_ALM_FULL_MEM_TEST_FAILURE | Minor | ATM Chipset: diagnostic memory test detects memory failure |
13 | FC_ABM_SEQ_ERROR_ILL | Minor | ATM Chipset: a sequence error in the ingress linked list was detected |
14 | FC_ABM_PAR_ERR_ING_CELL | Minor | ATM Chipset: cell dropped due to ingress parity error |
15 | FC_ABM_SEQ_ERROR_ELL | Minor | ATM Chipset: sequence error in egress linked list detected |
16 | FC_ABM_PAR_ERR_ING_STORED | Minor | ATM Chipset: parity error detected in ingress buffer RAM |
17 | FC_ABM_PAR_ERR_EG_STORED | Minor | ATM Chipset: parity error detected in egress buffer RAM |
18 | FC_ABM_PAR_ERR_PRAM | Minor | ATM Chipset: external pointer RAM parity error detected |
19 | FC_ABM_PRAM_ILL_ERROR | Minor | ATM Chipset: ingress linked list empty---cell processing halts until pointers become available |
20 | FC_ABM_PRAM_ELL_ERROR | Minor | ATM Chipset: egress linked list empty---cell processing halts until pointers become available |
21 | FC_ABM_PRAM_EIPLL_ERROR | Minor | ATM Chipset: egress IP free list empty---cell processing halts until pointers become available |
22 | FC_ABM_ING_SYNC_ERROR | Minor | ATM Chipset: cell dropped due to ingress UTOPIA sync error |
23 | FC_ABM_EG_SYNC_ERROR | Minor | ATM Chipset: cell dropped due to egress UTOPIA sync error |
24 | FC_ABM_PTR_MEM_TEST_FAILURE | Minor | ATM Chipset: diagnostic detected external memory failure |
25 | FC_ASX_CRCERR | Minor | ATM Chipset: CRC error detected on incoming cell---cell dropped |
26 | FC_ASX_IPRTOERR | Minor | ATM Chipset: input port overrun error |
27 | FC_ASX_LLERR | Minor | ATM Chipset: linked list error detected |
28 | FC_ASX_PARITY_ERR | Minor | ATM Chipset: input parity error detected---cell dropped |
29 | FC_CD_INIT_FAILURE | Minor | Cell Delineator: initialization failure |
30 | FC_SONET_INIT_FAILURE | Minor | OC-3c hardware initialization failure |
31 | NO_IPC_QUEUE_DEFINED | Minor | IPC does not recognize User Plane queue request |
32 | FC_CD_RX_ERROR | Minor | Cell Delineator: receive error |
33 | FC_CD_TX_ERROR | Minor | Cell Delineator: transmit error |
34 | FC_CD_CFG_FAILURE | Minor | Cell Delineator: initialization failed |
35 | FC_OS_ERROR | Minor | Operating system resource allocation failed |
36 | FC_ALM_INIT_FAILURE | Minor | Fabric control init software was unable to acquire necessary resources |
37 | FC_OC3_ERROR | Minor | General fault |
38 | FC_ABM_BP_OVERRIDE | Minor | ATM Chipset: backpressure indications from switch are being overridden to prevent cell loss |
39 | FC_ATM_CNX_FAIL_ERROR | Info | Fabric control was unable to complete a requested connection |
40 | FC_ATM_ERROR | Minor | Unspecified error or problem on ATM switch |
41 | FC_ALM_HEC_ERROR | Minor | ALM HEC error |
42 | FC_SUBTEND_PORT_BUFFER_OVERFLOW | Info | Buffer overflow in the cell buffer on the subtend module |
43 | FC_SUBTEND_PORT_UTOPIA_ERROR | Info | Error in UTOPIA chip |
44 | FC_SUBTEND_PORT_INGRESS_HEC | Info | Subtend port ingress HEC error |
45 | FC_FUBTEND_PORT_INGRESS_2_HEC | Info | Subtend port ingress HEC error |
46 | FC_SUBTEND_PORT_EGRESS_PARITY | Info | Parity error in cell egress path |
| ID | Event Name | Severity |
|---|---|---|
0 | FC_ALM_EXT_MEM_PAR_ERR | Minor |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
ATM Chipset: external memory parity errorAn alarm event of this type is likely the result in loss of a single cell. Loss of a single cell is a transient event, affecting only one subscriber. Recovery is possible at higher layers in the protocol stack. Multiple occurrences of the alarm event are more serious and typically indicate the failure of a hardware component on the ATM switch module (ASM).
The term multiple occurrences is applied if several occurrences take place within a few seconds. If a problem with cell loss, and ultimately subscriber traffic throughout is suspected, service personnel should review the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser for multiple occurrences. In a future software release, multiple occurrences of events in this category will generate a higher severity alarm.
Alarm events of this type are typically caused by short-term (milliseconds in duration) incidents that clear as part of the normal course of traffic management. Examples of traffic management events include the freeing of buffer space, recovery from parity errors at a higher level, and recover after a brief loss of signal.
Each of these alarm events is followed by an additional event showing a Cleared event status, meaning the alarm event has been corrected.
Step 1 If a Cleared event status is not received within 1 minute, reinsert the module.
Step 2 If a problem persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
1 | FC_ALM_IN_RCV_PAR_ERR | Minor |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
ATM Chipset: cell dropped due to ingress receive side UTOPIA bus parity errorAn alarm event of this type is likely the result in loss of a single cell. Loss of a single cell is a transient event, affecting only one subscriber. Recovery is possible at higher layers in the protocol stack. Multiple occurrences of the alarm event are more serious and typically indicate the failure of a hardware component on the ATM switch module (ASM).
The term multiple occurrences is applied if several occurrences take place within a few seconds. If a problem with cell loss, and ultimately subscriber traffic throughout is suspected, service personnel should review the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser for multiple occurrences. In a future software release, multiple occurrences of events in this category will generate a higher severity alarm.
Alarm events of this type are typically caused by short-term (milliseconds in duration) incidents that clear as part of the normal course of traffic management. Examples of traffic management events include the freeing of buffer space, recovery from parity errors at a higher level, and recover after a brief loss of signal.
Each of these alarm events is followed by an additional event showing a Cleared event status, meaning the alarm event has been corrected.
Step 1 If a Cleared event status is not received within 1 minute, reinsert the module.
Step 2 If a problem persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
2 | FC_ALM_EG_RCV_PAR_ERR | Minor |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
ATM Chipset: cell dropped due to egress receive side UTOPIA bus parity errorAn alarm event of this type is likely the result in loss of a single cell. Loss of a single cell is a transient event, affecting only one subscriber. Recovery is possible at higher layers in the protocol stack. Multiple occurrences of the alarm event are more serious and typically indicate the failure of a hardware component on the ATM switch module (ASM).
The term multiple occurrences is applied if several occurrences take place within a few seconds. If a problem with cell loss, and ultimately subscriber traffic throughout is suspected, service personnel should review the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser for multiple occurrences. In a future software release, multiple occurrences of events in this category will generate a higher severity alarm.
Alarm events of this type are typically caused by short-term (milliseconds in duration) incidents that clear as part of the normal course of traffic management. Examples of traffic management events include the freeing of buffer space, recovery from parity errors at a higher level, and recover after a brief loss of signal.
Each of these alarm events is followed by an additional event showing a Cleared event status, meaning the alarm event has been corrected.
Step 1 If a Cleared event status is not received within 1 minute, reinsert the module.
Step 2 If a problem persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
3 | FC_ALM_UTOPIA_SYNC_ERR | Minor |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
ATM Chipset: UTOPIA bus synchronization error detectedAn alarm event of this type is likely the result in loss of a single cell. Loss of a single cell is a transient event, affecting only one subscriber. Recovery is possible at higher layers in the protocol stack. Multiple occurrences of the alarm event are more serious and typically indicate the failure of a hardware component on the ATM switch module (ASM).
The term multiple occurrences is applied if several occurrences take place within a few seconds. If a problem with cell loss, and ultimately subscriber traffic throughout is suspected, service personnel should review the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser for multiple occurrences. In a future software release, multiple occurrences of events in this category will generate a higher severity alarm.
Alarm events of this type are typically caused by short-term (milliseconds in duration) incidents that clear as part of the normal course of traffic management. Examples of traffic management events include the freeing of buffer space, recovery from parity errors at a higher level, and recover after a brief loss of signal.
Each of these alarm events is followed by an additional event showing a Cleared event status, meaning the alarm event has been corrected.
Step 1 If a Cleared event status is not received within 1 minute, reinsert the module.
Step 2 If a problem persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
4 | FC_ALM_POL_EU_TIMEOUT_ERR | Minor |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
ATM Chipset: parity error detected on policing EU word accessAn alarm event of this type is likely the result in loss of a single cell. Loss of a single cell is a transient event, affecting only one subscriber. Recovery is possible at higher layers in the protocol stack. Multiple occurrences of the alarm event are more serious and typically indicate the failure of a hardware component on the ATM switch module (ASM).
The term multiple occurrences is applied if several occurrences take place within a few seconds. If a problem with cell loss, and ultimately subscriber traffic throughout is suspected, service personnel should review the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser for multiple occurrences. In a future software release, multiple occurrences of events in this category will generate a higher severity alarm.
Alarm events of this type are typically caused by short-term (milliseconds in duration) incidents that clear as part of the normal course of traffic management. Examples of traffic management events include the freeing of buffer space, recovery from parity errors at a higher level, and recover after a brief loss of signal.
Each of these alarm events is followed by an additional event showing a Cleared event status, meaning the alarm event has been corrected.
Step 1 If a Cleared event status is not received within 1 minute, reinsert the module.
Step 2 If a problem persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
5 | FC_ALM_VCI_SIZE_ERR | Minor |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
ATM Chipset: ingress VCI value above max valueAn alarm event of this type is likely the result in loss of a single cell. Loss of a single cell is a transient event, affecting only one subscriber. Recovery is possible at higher layers in the protocol stack. Multiple occurrences of the alarm event are more serious and typically indicate the failure of a hardware component on the ATM switch module (ASM).
The term multiple occurrences is applied if several occurrences take place within a few seconds. If a problem with cell loss, and ultimately subscriber traffic throughout is suspected, service personnel should review the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser for multiple occurrences. In a future software release, multiple occurrences of events in this category will generate a higher severity alarm.
Alarm events of this type are typically caused by short-term (milliseconds in duration) incidents that clear as part of the normal course of traffic management. Examples of traffic management events include the freeing of buffer space, recovery from parity errors at a higher level, and recover after a brief loss of signal.
Each of these alarm events is followed by an additional event showing a Cleared event status, meaning the alarm event has been corrected.
Step 1 If a Cleared event status is not received within 1 minute, reinsert the module.
Step 2 If a problem persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
6 | FC_ALM_VPI_SIZE_ERR | Minor |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
ATM Chipset: ingress VPI value above max valueAn alarm event of this type is likely the result in loss of a single cell. Loss of a single cell is a transient event, affecting only one subscriber. Recovery is possible at higher layers in the protocol stack. Multiple occurrences of the alarm event are more serious and typically indicate the failure of a hardware component on the ATM switch module (ASM).
The term multiple occurrences is applied if several occurrences take place within a few seconds. If a problem with cell loss, and ultimately subscriber traffic throughout is suspected, service personnel should review the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser for multiple occurrences. In a future software release, multiple occurrences of events in this category will generate a higher severity alarm.
Alarm events of this type are typically caused by short-term (milliseconds in duration) incidents that clear as part of the normal course of traffic management. Examples of traffic management events include the freeing of buffer space, recovery from parity errors at a higher level, and recover after a brief loss of signal.
Each of these alarm events is followed by an additional event showing a Cleared event status, meaning the alarm event has been corrected.
Step 1 If a Cleared event status is not received within 1 minute, reinsert the module.
Step 2 If a problem persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
7 | FC_ALM_MPHY_PORT_OVERRUN | Minor |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
ATM Chipset: ingress UTOPIA synchronization error detectedAn alarm event of this type is likely the result in loss of a single cell. Loss of a single cell is a transient event, affecting only one subscriber. Recovery is possible at higher layers in the protocol stack. Multiple occurrences of the alarm event are more serious and typically indicate the failure of a hardware component on the ATM switch module (ASM).
The term multiple occurrences is applied if several occurrences take place within a few seconds. If a problem with cell loss, and ultimately subscriber traffic throughout is suspected, service personnel should review the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser for multiple occurrences. In a future software release, multiple occurrences of events in this category will generate a higher severity alarm.
Alarm events of this type are typically caused by short-term (milliseconds in duration) incidents that clear as part of the normal course of traffic management. Examples of traffic management events include the freeing of buffer space, recovery from parity errors at a higher level, and recover after a brief loss of signal.
Each of these alarm events is followed by an additional event showing a Cleared event status, meaning the alarm event has been corrected.
Step 1 If a Cleared event status is not received within 1 minute, reinsert the module.
Step 2 If a problem persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
8 | FC_ALM_IN_FIFO_FULL | Minor |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
ATM Chipset: ingress cells are being dropped due to ingress capture FIFO full conditionAn event of this type causes an automatic recovery attempt by the ATM switch module (ASM) fabric control driver software. The automatic recovery should take no more than milliseconds. Service is only momentarily impaired, and recovery is possible at higher layers. The problem is likely to be transparent to the user.
Alarm events of this type are typically caused by short-term (milliseconds in duration) incidents that clear as part of the normal course of traffic management. Examples of traffic management events include the freeing of buffer space, recovery from parity errors at a higher level, and recover after a brief loss of signal.
Each of these alarm events is followed by an additional event showing a Cleared event status, meaning the alarm event has been corrected.
Step 1 If a Cleared event status is not received within 1 minute, reinsert the module.
Step 2 If a problem persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
9 | FC_ALM_EG_CAP_SYNC_ERR | Minor |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
ATM Chipset: an egress capture FIFO synchronization error is detectedAn event of this type causes an ATM switch module (ASM) reset. Service is usually affected for about 45 seconds. ADSL layer 1 connections are not lost, but subscriber data traffic (ATM AAL5 cells) does not move across the switch fabric during this period.
In some cases, a module forces itself into a self-test based on the alarm condition. In other cases, the system controller (SC) module forces the alarmed module to reset. A module reset forces the module to be power cycled, self-tested, and reconfigured into the slot by the SC module.
Several alarm event conditions are cleared by a module reset. Look for the alarm event to clear within 1 minute. An alarm event is cleared when the SC module faceplate alarm LED changes from red to off.
In the ViewRunner management software, two actions show that an alarm event is cleared:
If the alarm event does not clear:
Step 1 Remove and reinsert the module. This forces a module to reset if neither the module nor the SC module could force a reset. A module reset usually clears all alarm conditions.
Step 2 Observe the SC module alarm LED or the ViewRunner ejector tabs to see if the alarm condition returns. If the previous problem persists, the condition will probably reoccur within 1 minute.
Step 3 If the alarm condition persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
10 | FC_ALM_IN_CAP_SYNC_ERR | Minor |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
ATM Chipset: an ingress capture FIFO synchronization error is detectedAn event of this type causes an ATM switch module (ASM) reset. Service is usually affected for about 45 seconds. ADSL layer 1 connections are not lost, but subscriber data traffic (ATM AAL5 cells) does not move across the switch fabric during this period.
In some cases, a module forces itself into a self-test based on the alarm condition. In other cases, the system controller (SC) module forces the alarmed module to reset. A module reset forces the module to be power cycled, self-tested, and reconfigured into the slot by the SC module.
Several alarm event conditions are cleared by a module reset. Look for the alarm event to clear within 1 minute. An alarm event is cleared when the SC module faceplate alarm LED changes from red to off.
In the ViewRunner management software, two actions show that an alarm event is cleared:
If the alarm event does not clear:
Step 1 Remove and reinsert the module. This forces a module to reset if neither the module nor the SC module could force a reset. A module reset usually clears all alarm conditions.
Step 2 Observe the SC module alarm LED or the ViewRunner ejector tabs to see if the alarm condition returns. If the previous problem persists, the condition will probably reoccur within 1 minute.
Step 3 If the alarm condition persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
11 | FC_ALM_INSERT_SYNC_ERR | Minor |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
ATM Chipset: ingress insertion FIFO synch errorAn event of this type causes an automatic recovery attempt by the ATM switch module (ASM) fabric control driver software. The automatic recovery should take no more than milliseconds. Service is only momentarily impaired, and recovery is possible at higher layers. The problem is likely to be transparent to the user.
Alarm events of this type are typically caused by short-term (milliseconds in duration) incidents that clear as part of the normal course of traffic management. Examples of traffic management events include the freeing of buffer space, recovery from parity errors at a higher level, and recover after a brief loss of signal.
Each of these alarm events is followed by an additional event showing a Cleared event status, meaning the alarm event has been corrected.
Step 1 If a Cleared event status is not received within 1 minute, reinsert the module.
Step 2 If a problem persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
12 | FC_ALM_FULL_MEM_TEST_FAILURE | Minor |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
ATM Chipset: diagnostic memory test detects memory failureEvents of this type are not run-time events. They occur only during module power up and self-test, and they do not affect service (because subscriber service is typically not active yet). The module fails self-test as a result of this event, and immediately retries the self-test, but no self-test will end in success. A failure message is generated with each failure. Without a successful self-test, the module cannot be put into service, so the node does not complete its installation cycle.
Software update events fall into this description, because it is assumed that the updates are always monitored by an operator. Consequently, the events need not be coded as critical. In any case, the goal is to monitor the node status until the node becomes fully operational.
Alarm events of this type are typically caused by short-term (milliseconds in duration) incidents that clear as part of the normal course of traffic management. Examples of traffic management events include the freeing of buffer space, recovery from parity errors at a higher level, and recover after a brief loss of signal.
Each of these alarm events is followed by an additional event showing a Cleared event status, meaning the alarm event has been corrected.
Step 1 If a Cleared event status is not received within 1 minute, reinsert the module.
Step 2 If a problem persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
13 | FC_ABM_SEQ_ERROR_ILL | Minor |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
ATM Chipset: a sequence error in the ingress linked list was detectedAn event of this type causes an ATM switch module (ASM) reset. Service is usually affected for about 45 seconds. ADSL layer 1 connections are not lost, but subscriber data traffic (ATM AAL5 cells) does not move across the switch fabric during this period.
Alarm events of this type are generated only during module initialization and automatically force a module reset.
Step 1 If the reset condition continues (the module does not exit self-test mode), reinsert the module.
Step 2 If a problem persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
14 | FC_ABM_PAR_ERR_ING_CELL | Minor |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
ATM Chipset: cell dropped due to ingress parity errorAn alarm event of this type is likely the result in loss of a single cell. Loss of a single cell is a transient event, affecting only one subscriber. Recovery is possible at higher layers in the protocol stack. Multiple occurrences of the alarm event are more serious and typically indicate the failure of a hardware component on the ATM switch module (ASM).
The term multiple occurrences is applied if several occurrences take place within a few seconds. If a problem with cell loss, and ultimately subscriber traffic throughout is suspected, service personnel should review the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser for multiple occurrences. In a future software release, multiple occurrences of events in this category will generate a higher severity alarm.
Alarm events of this type are typically caused by short-term (milliseconds in duration) incidents that clear as part of the normal course of traffic management. Examples of traffic management events include the freeing of buffer space, recovery from parity errors at a higher level, and recover after a brief loss of signal.
Each of these alarm events is followed by an additional event showing a Cleared event status, meaning the alarm event has been corrected.
Step 1 If a Cleared event status is not received within 1 minute, reinsert the module.
Step 2 If a problem persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
15 | FC_ABM_SEQ_ERROR_ELL | Minor |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
ATM Chipset: sequence error in egress linked list detectedAn event of this type causes an ATM switch module (ASM) reset. Service is usually affected for about 45 seconds. ADSL layer 1 connections are not lost, but subscriber data traffic (ATM AAL5 cells) does not move across the switch fabric during this period.
Alarm events of this type are generated only during module initialization and automatically force a module reset.
Step 1 If the reset condition continues (the module does not exit self-test mode), reinsert the module.
Step 2 If a problem persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
16 | FC_ABM_PAR_ERR_ING_STORED | Minor |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
ATM Chipset: parity error detected in ingress buffer RAMAn alarm event of this type is likely the result in loss of a single cell. Loss of a single cell is a transient event, affecting only one subscriber. Recovery is possible at higher layers in the protocol stack. Multiple occurrences of the alarm event are more serious and typically indicate the failure of a hardware component on the ATM switch module (ASM).
The term multiple occurrences is applied if several occurrences take place within a few seconds. If a problem with cell loss, and ultimately subscriber traffic throughout is suspected, service personnel should review the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser for multiple occurrences. In a future software release, multiple occurrences of events in this category will generate a higher severity alarm.
Alarm events of this type are typically caused by short-term (milliseconds in duration) incidents that clear as part of the normal course of traffic management. Examples of traffic management events include the freeing of buffer space, recovery from parity errors at a higher level, and recover after a brief loss of signal.
Each of these alarm events is followed by an additional event showing a Cleared event status, meaning the alarm event has been corrected.
Step 1 If a Cleared event status is not received within 1 minute, reinsert the module.
Step 2 If a problem persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
17 | FC_ABM_PAR_ERR_EG_STORED | Minor |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
ATM Chipset: parity error detected in egress buffer RAMAn alarm event of this type is likely the result in loss of a single cell. Loss of a single cell is a transient event, affecting only one subscriber. Recovery is possible at higher layers in the protocol stack. Multiple occurrences of the alarm event are more serious and typically indicate the failure of a hardware component on the ATM switch module (ASM).
The term multiple occurrences is applied if several occurrences take place within a few seconds. If a problem with cell loss, and ultimately subscriber traffic throughout is suspected, service personnel should review the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser for multiple occurrences. In a future software release, multiple occurrences of events in this category will generate a higher severity alarm.
Alarm events of this type are typically caused by short-term (milliseconds in duration) incidents that clear as part of the normal course of traffic management. Examples of traffic management events include the freeing of buffer space, recovery from parity errors at a higher level, and recover after a brief loss of signal.
Each of these alarm events is followed by an additional event showing a Cleared event status, meaning the alarm event has been corrected.
Step 1 If a Cleared event status is not received within 1 minute, reinsert the module.
Step 2 If a problem persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
18 | FC_ABM_PAR_ERR_PRAM | Minor |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
ATM Chipset: external pointer RAM parity error detectedAn event of this type causes an ATM switch module (ASM) reset. Service is usually affected for about 45 seconds. ADSL layer 1 connections are not lost, but subscriber data traffic (ATM AAL5 cells) does not move across the switch fabric during this period.
Alarm events of this type are typically caused by short-term (milliseconds in duration) incidents that clear as part of the normal course of traffic management. Examples of traffic management events include the freeing of buffer space, recovery from parity errors at a higher level, and recover after a brief loss of signal.
Each of these alarm events is followed by an additional event showing a Cleared event status, meaning the alarm event has been corrected.
Step 1 If a Cleared event status is not received within 1 minute, reinsert the module.
Step 2 If a problem persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
19 | FC_ABM_PRAM_ILL_ERROR | Minor |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
ATM Chipset: ingress linked list empty---cell processing halts until pointers become availableAn event of this type causes an automatic recovery attempt by the ATM switch module (ASM) fabric control driver software. The automatic recovery should take no more than milliseconds. Service is only momentarily impaired, and recovery is possible at higher layers. The problem is likely to be transparent to the user.
Alarm events of this type are typically caused by short-term (milliseconds in duration) incidents that clear as part of the normal course of traffic management. Examples of traffic management events include the freeing of buffer space, recovery from parity errors at a higher level, and recover after a brief loss of signal.
Each of these alarm events is followed by an additional event showing a Cleared event status, meaning the alarm event has been corrected.
Step 1 If a Cleared event status is not received within 1 minute, reinsert the module.
Step 2 If a problem persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
20 | FC_ABM_PRAM_ELL_ERROR | Minor |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
ATM Chipset: egress linked list empty---cell processing halts until pointers become availableAn event of this type causes an automatic recovery attempt by the ATM switch module (ASM) fabric control driver software. The automatic recovery should take no more than milliseconds. Service is only momentarily impaired, and recovery is possible at higher layers. The problem is likely to be transparent to the user.
Alarm events of this type are typically caused by short-term (milliseconds in duration) incidents that clear as part of the normal course of traffic management. Examples of traffic management events include the freeing of buffer space, recovery from parity errors at a higher level, and recover after a brief loss of signal.
Each of these alarm events is followed by an additional event showing a Cleared event status, meaning the alarm event has been corrected.
Step 1 If a Cleared event status is not received within 1 minute, reinsert the module.
Step 2 If a problem persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
21 | FC_ABM_PRAM_EIPLL_ERROR | Minor |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
ATM Chipset: egress IP free list empty---cell processing halts until pointers become availableAn event of this type causes an automatic recovery attempt by the ATM switch module (ASM) fabric control driver software. The automatic recovery should take no more than milliseconds. Service is only momentarily impaired, and recovery is possible at higher layers. The problem is likely to be transparent to the user.
Alarm events of this type are typically caused by short-term (milliseconds in duration) incidents that clear as part of the normal course of traffic management. Examples of traffic management events include the freeing of buffer space, recovery from parity errors at a higher level, and recover after a brief loss of signal.
Each of these alarm events is followed by an additional event showing a Cleared event status, meaning the alarm event has been corrected.
Step 1 If a Cleared event status is not received within 1 minute, reinsert the module.
Step 2 If a problem persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
22 | FC_ABM_ING_SYNC_ERROR | Minor |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
ATM Chipset: cell dropped due to ingress UTOPIA sync errorAn alarm event of this type is likely the result in loss of a single cell. Loss of a single cell is a transient event, affecting only one subscriber. Recovery is possible at higher layers in the protocol stack. Multiple occurrences of the alarm event are more serious and typically indicate the failure of a hardware component on the ATM switch module (ASM).
The term multiple occurrences is applied if several occurrences take place within a few seconds. If a problem with cell loss, and ultimately subscriber traffic throughout is suspected, service personnel should review the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser for multiple occurrences. In a future software release, multiple occurrences of events in this category will generate a higher severity alarm.
Alarm events of this type are typically caused by short-term (milliseconds in duration) incidents that clear as part of the normal course of traffic management. Examples of traffic management events include the freeing of buffer space, recovery from parity errors at a higher level, and recover after a brief loss of signal.
Each of these alarm events is followed by an additional event showing a Cleared event status, meaning the alarm event has been corrected.
Step 1 If a Cleared event status is not received within 1 minute, reinsert the module.
Step 2 If a problem persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
23 | FC_ABM_EG_SYNC_ERROR | Minor |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
ATM Chipset: cell dropped due to egress UTOPIA sync errorAn alarm event of this type is likely the result in loss of a single cell. Loss of a single cell is a transient event, affecting only one subscriber. Recovery is possible at higher layers in the protocol stack. Multiple occurrences of the alarm event are more serious and typically indicate the failure of a hardware component on the ATM switch module (ASM).
The term multiple occurrences is applied if several occurrences take place within a few seconds. If a problem with cell loss, and ultimately subscriber traffic throughout is suspected, service personnel should review the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser for multiple occurrences. In a future software release, multiple occurrences of events in this category will generate a higher severity alarm.
Alarm events of this type are typically caused by short-term (milliseconds in duration) incidents that clear as part of the normal course of traffic management. Examples of traffic management events include the freeing of buffer space, recovery from parity errors at a higher level, and recover after a brief loss of signal.
Each of these alarm events is followed by an additional event showing a Cleared event status, meaning the alarm event has been corrected.
Step 1 If a Cleared event status is not received within 1 minute, reinsert the module.
Step 2 If a problem persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
24 | FC_ABM_PTR_MEM_TEST_FAILURE | Minor |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
ATM Chipset: diagnostic detected external memory failureEvents of this type are not run-time events. They occur only during module power up and self-test, and they do not affect service (because subscriber service is typically not active yet). The module fails self-test as a result of this event, and immediately retries the self-test, but no self-test will end in success. A failure message is generated with each failure. Without a successful self-test, the module cannot be put into service, so the node does not complete its installation cycle.
Software update events fall into this description, because it is assumed that the updates are always monitored by an operator. Consequently, the events need not be coded as critical. In any case, the goal is to monitor the node status until the node becomes fully operational.
Alarm events of this type are generated only during module initialization and automatically force a module reset.
Step 1 If the reset condition continues (the module does not exit self-test mode), reinsert the module.
Step 2 If a problem persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
25 | FC_ASX_CRCERR | Minor |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
ATM Chipset: CRC error detected on incoming cell---cell droppedAn alarm event of this type is likely the result in loss of a single cell. Loss of a single cell is a transient event, affecting only one subscriber. Recovery is possible at higher layers in the protocol stack. Multiple occurrences of the alarm event are more serious and typically indicate the failure of a hardware component on the ATM switch module (ASM).
The term multiple occurrences is applied if several occurrences take place within a few seconds. If a problem with cell loss, and ultimately subscriber traffic throughout is suspected, service personnel should review the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser for multiple occurrences. In a future software release, multiple occurrences of events in this category will generate a higher severity alarm.
Alarm events of this type are typically caused by short-term (milliseconds in duration) incidents that clear as part of the normal course of traffic management. Examples of traffic management events include the freeing of buffer space, recovery from parity errors at a higher level, and recover after a brief loss of signal.
Each of these alarm events is followed by an additional event showing a Cleared event status, meaning the alarm event has been corrected.
Step 1 If a Cleared event status is not received within 1 minute, reinsert the module.
Step 2 If a problem persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
26 | FC_ASX_IPRTOERR | Minor |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
ATM Chipset: input port overrun errorAn alarm event of this type is likely the result in loss of a single cell. Loss of a single cell is a transient event, affecting only one subscriber. Recovery is possible at higher layers in the protocol stack. Multiple occurrences of the alarm event are more serious and typically indicate the failure of a hardware component on the ATM switch module (ASM).
The term multiple occurrences is applied if several occurrences take place within a few seconds. If a problem with cell loss, and ultimately subscriber traffic throughout is suspected, service personnel should review the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser for multiple occurrences. In a future software release, multiple occurrences of events in this category will generate a higher severity alarm.
Alarm events of this type are typically caused by short-term (milliseconds in duration) incidents that clear as part of the normal course of traffic management. Examples of traffic management events include the freeing of buffer space, recovery from parity errors at a higher level, and recover after a brief loss of signal.
Each of these alarm events is followed by an additional event showing a Cleared event status, meaning the alarm event has been corrected.
Step 1 If a Cleared event status is not received within 1 minute, reinsert the module.
Step 2 If a problem persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
27 | FC_ASX_LLERR | Minor |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
ATM Chipset: linked list error detectedAn event of this type causes an ATM switch module (ASM) reset. Service is usually affected for about 45 seconds. ADSL layer 1 connections are not lost, but subscriber data traffic (ATM AAL5 cells) does not move across the switch fabric during this period.
In some cases, a module forces itself into a self-test based on the alarm condition. In other cases, the system controller (SC) module forces the alarmed module to reset. A module reset forces the module to be power cycled, self-tested, and reconfigured into the slot by the SC module.
Several alarm event conditions are cleared by a module reset. Look for the alarm event to clear within 1 minute. An alarm event is cleared when the SC module faceplate alarm LED changes from red to off.
In the ViewRunner management software, two actions show that an alarm event is cleared:
If the alarm event does not clear:
Step 1 Remove and reinsert the module. This forces a module to reset if neither the module nor the SC module could force a reset. A module reset usually clears all alarm conditions.
Step 2 Observe the SC module alarm LED or the ViewRunner ejector tabs to see if the alarm condition returns. If the previous problem persists, the condition will probably reoccur within 1 minute.
Step 3 If the alarm condition persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
28 | FC_ASX_PARITY_ERR | Minor |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
ATM Chipset: input parity error detected---cell droppedAn alarm event of this type is likely the result in loss of a single cell. Loss of a single cell is a transient event, affecting only one subscriber. Recovery is possible at higher layers in the protocol stack. Multiple occurrences of the alarm event are more serious and typically indicate the failure of a hardware component on the ATM switch module (ASM).
The term multiple occurrences is applied if several occurrences take place within a few seconds. If a problem with cell loss, and ultimately subscriber traffic throughout is suspected, service personnel should review the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser for multiple occurrences. In a future software release, multiple occurrences of events in this category will generate a higher severity alarm.
Alarm events of this type are typically caused by short-term (milliseconds in duration) incidents that clear as part of the normal course of traffic management. Examples of traffic management events include the freeing of buffer space, recovery from parity errors at a higher level, and recover after a brief loss of signal.
Each of these alarm events is followed by an additional event showing a Cleared event status, meaning the alarm event has been corrected.
Step 1 If a Cleared event status is not received within 1 minute, reinsert the module.
Step 2 If a problem persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
29 | FC_CD_INIT_FAILURE | Minor |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
Cell Delineator: initialization failureEvents of this type are not run-time events. They occur only during module power up and self-test, and they do not affect service (because subscriber service is typically not active yet). The module fails self-test as a result of this event, and immediately retries the self-test, but no self-test will end in success. A failure message is generated with each failure. Without a successful self-test, the module cannot be put into service, so the node does not complete its installation cycle.
Software update events fall into this description, because it is assumed that the updates are always monitored by an operator. Consequently, the events need not be coded as critical. In any case, the goal is to monitor the node status until the node becomes fully operational.
Alarm events of this type are generated only during module initialization and automatically force a module reset.
Step 1 If the reset condition continues (the module does not exit self-test mode), reinsert the module.
Step 2 If a problem persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
30 | FC_SONET_INIT_FAILURE | Minor |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
OC-3c hardware initialization failureEvents of this type are not run-time events. They occur only during module power up and self-test, and they do not affect service (because subscriber service is typically not active yet). The module fails self-test as a result of this event, and immediately retries the self-test, but no self-test will end in success. A failure message is generated with each failure. Without a successful self-test, the module cannot be put into service, so the node does not complete its installation cycle.
Software update events fall into this description, because it is assumed that the updates are always monitored by an operator. Consequently, the events need not be coded as critical. In any case, the goal is to monitor the node status until the node becomes fully operational.
Alarm events of this type are generated only during module initialization and automatically force a module reset.
Step 1 If the reset condition continues (the module does not exit self-test mode), reinsert the module.
Step 2 If a problem persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
31 | NO_IPC_QUEUE_DEFINED | Minor |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
IPC does not recognize User Plane queue requestThe event is not propagated from the module to Fault Manager, and will not be registered in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser.
Alarm events of this type are generated only during module initialization and automatically force a module reset.
Step 1 If the reset condition continues (the module does not exit self-test mode), reinsert the module.
Step 2 If a problem persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
32 | FC_CD_RX_ERROR | Minor |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
Cell Delineator: receive errorAn alarm event of this type is likely the result in loss of a single cell. Loss of a single cell is a transient event, affecting only one subscriber. Recovery is possible at higher layers in the protocol stack. Multiple occurrences of the alarm event are more serious and typically indicate the failure of a hardware component on the ATM switch module (ASM).
The term multiple occurrences is applied if several occurrences take place within a few seconds. If a problem with cell loss, and ultimately subscriber traffic throughout is suspected, service personnel should review the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser for multiple occurrences. In a future software release, multiple occurrences of events in this category will generate a higher severity alarm.
Alarm events of this type are typically caused by short-term (milliseconds in duration) incidents that clear as part of the normal course of traffic management. Examples of traffic management events include the freeing of buffer space, recovery from parity errors at a higher level, and recover after a brief loss of signal.
Each of these alarm events is followed by an additional event showing a Cleared event status, meaning the alarm event has been corrected.
Step 1 If a Cleared event status is not received within 1 minute, reinsert the module.
Step 2 If a problem persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
33 | FC_CD_TX_ERROR | Minor |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
Cell Delineator: transmit errorAn alarm event of this type is likely the result in loss of a single cell. Loss of a single cell is a transient event, affecting only one subscriber. Recovery is possible at higher layers in the protocol stack. Multiple occurrences of the alarm event are more serious and typically indicate the failure of a hardware component on the ATM switch module (ASM).
The term multiple occurrences is applied if several occurrences take place within a few seconds. If a problem with cell loss, and ultimately subscriber traffic throughout is suspected, service personnel should review the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser for multiple occurrences. In a future software release, multiple occurrences of events in this category will generate a higher severity alarm.
Alarm events of this type are typically caused by short-term (milliseconds in duration) incidents that clear as part of the normal course of traffic management. Examples of traffic management events include the freeing of buffer space, recovery from parity errors at a higher level, and recover after a brief loss of signal.
Each of these alarm events is followed by an additional event showing a Cleared event status, meaning the alarm event has been corrected.
Step 1 If a Cleared event status is not received within 1 minute, reinsert the module.
Step 2 If a problem persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
34 | FC_CD_CFG_FAILURE | Minor |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
Cell Delineator: initialization failedEvents of this type are not run-time events. They occur only during module power up and self-test, and they do not affect service (because subscriber service is typically not active yet). The module fails self-test as a result of this event, and immediately retries the self-test, but no self-test will end in success. A failure message is generated with each failure. Without a successful self-test, the module cannot be put into service, so the node does not complete its installation cycle.
Software update events fall into this description, because it is assumed that the updates are always monitored by an operator. Consequently, the events need not be coded as critical. In any case, the goal is to monitor the node status until the node becomes fully operational.
Alarm events of this type are generated only during module initialization and automatically force a module reset.
Step 1 If the reset condition continues (the module does not exit self-test mode), reinsert the module.
Step 2 If a problem persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
35 | FC_OS_ERROR | Minor |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
Operating system resource allocation failedEvents of this type are not run-time events. They occur only during module power up and self-test, and they do not affect service (because subscriber service is typically not active yet). The module fails self-test as a result of this event, and immediately retries the self-test, but no self-test will end in success. A failure message is generated with each failure. Without a successful self-test, the module cannot be put into service, so the node does not complete its installation cycle.
Software update events fall into this description, because it is assumed that the updates are always monitored by an operator. Consequently, the events need not be coded as critical. In any case, the goal is to monitor the node status until the node becomes fully operational.
Alarm events of this type are generated only during module initialization and automatically force a module reset.
Step 1 If the reset condition continues (the module does not exit self-test mode), reinsert the module.
Step 2 If a problem persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
36 | FC_ALM_INIT_FAILURE | Minor |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
Fabric control init software was unable to acquire necessary resourcesEvents of this type are not run-time events. They occur only during module power up and self-test, and they do not affect service (because subscriber service is typically not active yet). The module fails self-test as a result of this event, and immediately retries the self-test, but no self-test will end in success. A failure message is generated with each failure. Without a successful self-test, the module cannot be put into service, so the node does not complete its installation cycle.
Software update events fall into this description, because it is assumed that the updates are always monitored by an operator. Consequently, the events need not be coded as critical. In any case, the goal is to monitor the node status until the node becomes fully operational.
Alarm events of this type are generated only during module initialization and automatically force a module reset.
Step 1 If the reset condition continues (the module does not exit self-test mode), reinsert the module.
Step 2 If a problem persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
37 | FC_OC3_ERROR | Minor |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
General faultEvents of this type are not run-time events. They occur only during module power up and self-test, and they do not affect service (because subscriber service is typically not active yet). The module fails self-test as a result of this event, and immediately retries the self-test, but no self-test will end in success. A failure message is generated with each failure. Without a successful self-test, the module cannot be put into service, so the node does not complete its installation cycle.
Software update events fall into this description, because it is assumed that the updates are always monitored by an operator. Consequently, the events need not be coded as critical. In any case, the goal is to monitor the node status until the node becomes fully operational.
Alarm events of this type are generated only during module initialization and automatically force a module reset.
Step 1 If the reset condition continues (the module does not exit self-test mode), reinsert the module.
Step 2 If a problem persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
38 | FC_ABM_BP_OVERRIDE | Minor |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
ATM Chipset: backpressure indications from switch are being overridden to prevent cell lossEvents of this type are not system problems; they occur as a result of normal ATM traffic congestion buildup. As cell buffers empty, a Cleared event is issued. The event is coded as minor, but continued events of this type may indicate that traffic-engineering assumptions need to be revisited. In a future software release, multiple occurrences of events in this category will generate a higher severity alarm.
Alarm events of this type are typically caused by short-term (milliseconds in duration) incidents that clear as part of the normal course of traffic management. Examples of traffic management events include the freeing of buffer space, recovery from parity errors at a higher level, and recover after a brief loss of signal.
Each of these alarm events is followed by an additional event showing a Cleared event status, meaning the alarm event has been corrected.
Step 1 If a Cleared event status is not received within 1 minute, reinsert the module.
Step 2 If a problem persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
39 | FC_ATM_CNX_FAIL_ERROR | Info |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
Fabric control was unable to complete a requested connectionEvents of this type do not affect service, because they occur only at configuration time. The event is coded as an information event, because there is no resource state change when the condition clears, and there is, therefore, no follow-up Cleared event.
None
| ID | Event Name | Severity |
|---|---|---|
40 | FC_ATM_ERROR | Minor |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
Unspecified error or problem on ATM switchEvents of this type are not run-time events. They occur only during module power up and self-test, and they do not affect service (because subscriber service is typically not active yet). The module fails self-test as a result of this event, and immediately retries the self-test, but no self-test will end in success. A failure message is generated with each failure. Without a successful self-test, the module cannot be put into service, so the node does not complete its installation cycle.
Alarm events of this type are generated only during module initialization and automatically force a module reset.
Step 1 If the reset condition continues (the module does not exit self-test mode), reinsert the module.
Step 2 If a problem persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
41 | FC_ALM_HEC_ERROR | Minor |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
ALM HEC errorAn alarm event of this type is likely the result in loss of a single cell. Loss of a single cell is a transient event, affecting only one subscriber. Recovery is possible at higher layers in the protocol stack. Multiple occurrences of the alarm event are more serious and typically indicate the failure of a hardware component on the ATM switch module (ASM).
The term multiple occurrences is applied if several occurrences take place within a few seconds. If a problem with cell loss, and ultimately subscriber traffic throughout is suspected, service personnel should review the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser for multiple occurrences. In a future software release, multiple occurrences of events in this category will generate a higher severity alarm.
Alarm events of this type are typically caused by short-term (milliseconds in duration) incidents that clear as part of the normal course of traffic management. Examples of traffic management events include the freeing of buffer space, recovery from parity errors at a higher level, and recover after a brief loss of signal.
Each of these alarm events is followed by an additional event showing a Cleared event status, meaning the alarm event has been corrected.
Step 1 If a Cleared event status is not received within 1 minute, reinsert the module.
Step 2 If a problem persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
42 | FC_SUBTEND_PORT_BUFFER_OVERFLOW | Info |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
Buffer overflow in the cell buffer on the subtend moduleAn alarm event of this type is likely the result in loss of a single cell. Loss of a single cell is a transient event, affecting only one subscriber. Recovery is possible at higher layers in the protocol stack. Multiple occurrences of the alarm event are more serious and typically indicate the failure of a hardware component on the ATM switch module (ASM).
The term multiple occurrences is applied if several occurrences take place within a few seconds. If a problem with cell loss, and ultimately subscriber traffic throughout is suspected, service personnel should review the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser for multiple occurrences. In a future software release, multiple occurrences of events in this category will generate a higher severity alarm.
Alarm events of this type are typically caused by short-term (milliseconds in duration) incidents that clear as part of the normal course of traffic management. Examples of traffic management events include the freeing of buffer space, recovery from parity errors at a higher level, and recover after a brief loss of signal.
Each of these alarm events is followed by an additional event showing a Cleared event status, meaning the alarm event has been corrected.
Step 1 If a Cleared event status is not received within 1 minute, reinsert the module.
Step 2 If a problem persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
43 | FC_SUBTEND_PORT_UTOPIA_ERROR | Info |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
Error in UTOPIA chipAn alarm event of this type is likely the result in loss of a single cell. Loss of a single cell is a transient event, affecting only one subscriber. Recovery is possible at higher layers in the protocol stack. Multiple occurrences of the alarm event are more serious and typically indicate the failure of a hardware component on the ATM switch module (ASM).
The term multiple occurrences is applied if several occurrences take place within a few seconds. If a problem with cell loss, and ultimately subscriber traffic throughout is suspected, service personnel should review the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser for multiple occurrences. In a future software release, multiple occurrences of events in this category will generate a higher severity alarm.
This is an information event, not an alarm event. Information events do not represent a state change and therefore are not followed by a Cleared event.
Information events are typically one-time occurrences that are corrected by the module without a reset. They do not cause service degradation.
No craft action is required.
| ID | Event Name | Severity |
|---|---|---|
44 | FC_SUBTEND_PORT_INGRESS_HEC | Info |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
Subtend port ingress HEC errorAn alarm event of this type is likely the result in loss of a single cell. Loss of a single cell is a transient event, affecting only one subscriber. Recovery is possible at higher layers in the protocol stack. Multiple occurrences of the alarm event are more serious and typically indicate the failure of a hardware component on the ATM switch module (ASM).
The term multiple occurrences is applied if several occurrences take place within a few seconds. If a problem with cell loss, and ultimately subscriber traffic throughout is suspected, service personnel should review the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser for multiple occurrences. In a future software release, multiple occurrences of events in this category will generate a higher severity alarm.
Alarm events of this type are typically caused by short-term (milliseconds in duration) incidents that clear as part of the normal course of traffic management. Examples of traffic management events include the freeing of buffer space, recovery from parity errors at a higher level, and recover after a brief loss of signal.
Each of these alarm events is followed by an additional event showing a Cleared event status, meaning the alarm event has been corrected.
Step 1 If a Cleared event status is not received within 1 minute, reinsert the module.
Step 2 If a problem persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
45 | FC_SUBTEND_PORT_INGRESS_2_HEC | Info |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
Subtend port ingress HEC errorAn alarm event of this type is likely the result in loss of a single cell. Loss of a single cell is a transient event, affecting only one subscriber. Recovery is possible at higher layers in the protocol stack. Multiple occurrences of the alarm event are more serious and typically indicate the failure of a hardware component on the ATM switch module (ASM).
The term multiple occurrences is applied if several occurrences take place within a few seconds. If a problem with cell loss, and ultimately subscriber traffic throughout is suspected, service personnel should review the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser for multiple occurrences. In a future software release, multiple occurrences of events in this category will generate a higher severity alarm.
Alarm events of this type are typically caused by short-term (milliseconds in duration) incidents that clear as part of the normal course of traffic management. Examples of traffic management events include the freeing of buffer space, recovery from parity errors at a higher level, and recover after a brief loss of signal.
Each of these alarm events is followed by an additional event showing a Cleared event status, meaning the alarm event has been corrected.
Step 1 If a Cleared event status is not received within 1 minute, reinsert the module.
Step 2 If a problem persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
46 | FC_SUBTEND_PORT_EGRESS_PARITY | Info |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
Parity error in cell egress pathAn alarm event of this type is likely the result in loss of a single cell. Loss of a single cell is a transient event, affecting only one subscriber. Recovery is possible at higher layers in the protocol stack. Multiple occurrences of the alarm event are more serious and typically indicate the failure of a hardware component on the ATM switch module (ASM).
The term multiple occurrences is applied if several occurrences take place within a few seconds. If a problem with cell loss, and ultimately subscriber traffic throughout is suspected, service personnel should review the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser for multiple occurrences. In a future software release, multiple occurrences of events in this category will generate a higher severity alarm.
Alarm events of this type are typically caused by short-term (milliseconds in duration) incidents that clear as part of the normal course of traffic management. Examples of traffic management events include the freeing of buffer space, recovery from parity errors at a higher level, and recover after a brief loss of signal.
Each of these alarm events is followed by an additional event showing a Cleared event status, meaning the alarm event has been corrected.
Step 1 If a Cleared event status is not received within 1 minute, reinsert the module.
Step 2 If a problem persists, replace the module.
Posted: Tue Nov 16 15:40:34 PST 1999
Copyright 1989-1999©Cisco Systems Inc.