Cisco ONS 15600 Troubleshooting Guide, Release 5.0
Chapter 4, Performance Monitoring
Downloads: This chapterpdf (PDF - 519.0KB) The complete bookPDF (PDF - 4.41MB) | Feedback

Performance Monitoring

Table Of Contents

Performance Monitoring

4.1  Threshold Performance Monitoring

4.2  Intermediate-Path Performance Monitoring

4.3  Pointer Justification Count

4.4  Performance-Monitoring Parameter Definitions

4.5  Optical Card Performance Monitoring

4.5.1  OC-48/STM16 and OC-192/STM64 Card Performance Monitoring Parameters

4.5.2  Physical Layer Parameters

4.6  ASAP Card Performance Monitoring

4.6.1  ASAP Card Optical Performance Monitoring Parameters

4.6.2  ASAP Card Ethernet Performance Monitoring Parameters


Performance Monitoring



Note The terms "Unidirectional Path Switched Ring" and "UPSR" may appear in Cisco literature. These terms do not refer to using Cisco ONS 15xxx products in a unidirectional path switched ring configuration. Rather, these terms, as well as "Path Protected Mesh Network" and "PPMN," refer generally to Cisco's path protection feature, which may be used in any topological network configuration. Cisco does not recommend using its path protection feature in any particular topological network configuration.


Use performance monitoring (PM) parameters to gather, store, threshold, and report performance data for early detection of problems. This chapter defines PM parameters and concepts for Cisco ONS 15600 optical cards.


Note For additional information regarding PM parameters, refer to Telcordia documents GR-1230-CORE, GR-820-CORE, GR-499-CORE, and GR-253-CORE and the ANSI T1.231 document entitled Digital Hierarchy - Layer 1 In-Service Digital Transmission Performance Monitoring.


For information about enabling and viewing PM values, refer to the Cisco ONS 15600 Procedure Guide.

Chapter topics include:

Threshold Performance Monitoring

Intermediate-Path Performance Monitoring

Pointer Justification Count

Performance-Monitoring Parameter Definitions

Optical Card Performance Monitoring

ASAP Card Performance Monitoring

4.1  Threshold Performance Monitoring

Thresholds are used to set error levels for each PM. You can program PM threshold ranges from the Provisioning > SONET Thresholds tabs on the Cisco Transport Controller (CTC) card view. To provision card thresholds, such as line, path, and SONET thresholds, refer to the Cisco ONS 15600 Procedure Guide.

During the accumulation cycle, if the current value of a performance monitoring parameter reaches or exceeds its corresponding threshold value, a threshold crossing alert (TCA) is generated by the node and sent to CTC. TCAs provide early detection of performance degradation. When a threshold is crossed, the node continues to count the errors during a given accumulation period. If 0 is entered as the threshold value, the performance monitoring parameter is disabled. Figure 4-1 shows the Provisioning > SONET Thresholds tabs for an OC-48/STM-16 card.

Figure 4-1 SONET Thresholds Tab for Setting Threshold Values

Change the threshold if the default value does not satisfy your error monitoring needs. For example, customers with a critical STS-1 installed for 911 calls must guarantee the best quality of service on the line; therefore, they lower all thresholds so that the slightest error raises a TCA.

4.2  Intermediate-Path Performance Monitoring

Intermediate-path performance monitoring (IPPM) allows a nonterminating node to transparently monitor a constituent channel of an incoming transmission signal. ONS 15600 networks only use line terminating equipment (LTE), not path terminating equipment (PTE). Table 4-1 shows ONS 15600 cards that are considered LTEs.

Table 4-1 Line Terminating Traffic Cards

Line Terminating Equipment

OC48/STM16 SR/SH 16 Port 1310

OC48/STM16 LR/LH 16 Port 1550

OC192/STM64 SR/SH 4 Port 1310

OC192/STM64 LR/LH 4 Port 1550


Figure 4-2 shows the Provisioning > SONET STS tabs for an OC-48 card.

Figure 4-2 STS Tab for Enabling IPPM

Software Release 1.0 and later allows LTE cards to monitor near-end path PM data on individual Synchronous Transport Signal (STS) payloads by enabling IPPM. After enabling IPPM on provisioned STS ports, service providers can monitor large amounts of STS traffic through intermediate nodes, thus making troubleshooting and maintenance activities more efficient.

IPPM occurs only on STS paths that have IPPM enabled, and TCAs are raised only for PM parameters on the selected IPPM paths. The monitored IPPMs are STS CV-P, STS ES-P, STS SES-P, STS UAS-P, and STS FC-P. To enable IPPM, refer to the Cisco ONS 15600 Procedure Guide.

The ONS 15600 performs IPPM by examining the overhead in the monitored path and reading all of the near-end path performance monitoring parameters in the incoming transmission direction. The IPPM process allows the path overhead to pass bidirectionally through the node completely unaltered.

For detailed information about specific performance monitoring parameters, see the "Performance-Monitoring Parameter Definitions" section.

4.3  Pointer Justification Count

Pointers are used to compensate for frequency and phase variations. Pointer justification counts indicate timing differences on SONET networks. When a network is not synchronized, frequency and phase variations occur on the transported signal. Excessive frequency and phase variations can cause terminating equipment to slip. These variations also cause slips at the SDH and PDH boundaries.

Slips cause different effects in service. Voice service has intermittent audible clicks. Compressed voice technology has short transmission errors or dropped calls. Fax machines lose scanned lines or experience dropped calls. Digital video transmission has distorted pictures or frozen frames. Encryption service loses the encryption key, which causes data to be transmitted again.

Pointers align the phase variations in STS and Virtual Tributary (VT) payloads. The STS payload pointer is located in the H1 and H2 bytes of the line overhead. Clocking differences are measured by the offset in bytes from the pointer to the first byte of the STS synchronous payload envelope (SPE) called the J1 byte. A small number of pointer justification counts per day is not cause for concern. If the pointer justification count continues to rise or becomes large, action must be taken to correct the problem.

Figure 4-3 shows pointer justification count parameters on the performance monitoring window. You can enable positive pointer justification count (PPJC) and negative pointer justification count (NPJC) performance monitoring parameters for LTE cards.

Figure 4-3 Viewing Pointer Justification Count Parameters

PPJC is a count of path-detected (PPJC-Pdet) or path-generated (PPJC-Pgen) positive pointer justifications depending on the specific PM name. NPJC is a count of path-detected (NPJC-Pdet) or path-generated (NPJC-Pgen) negative pointer justifications depending on the specific PM name.

A consistent pointer justification count indicates clock synchronization problems between nodes. A difference between the counts means the node transmitting the original pointer justification has timing variations with the node detecting and transmitting this count. Positive pointer adjustments occur when the frame rate of the SPE is too slow in relation to the rate of the STS-1.

For pointer justification count definitions, see the "Performance-Monitoring Parameter Definitions" section. On CTC, the PM count fields for PPJC and NPJC appear white and blank unless IPPM is enabled.

4.4  Performance-Monitoring Parameter Definitions

Table 4-2 gives definitions for each type of performance-monitoring parameter found in this chapter.

Table 4-2 Performance-Monitoring Parameters

Parameter
Definition

CV-L

Line Code Violation (CV-L) indicates the number of coding violations occurring on the line. This parameter is a count of bipolar violations (BPVs) and excessive zeros (EXZs) occurring over the accumulation period.

CV-LFE

Far-End Line Code VIolation (CV-LFE) is a count of BIP errors detected by the far-end LTE and reported back to the near-end LTE using the Line remote error indication (REI-L) in the line overhead. For SONET signals at rates below OC-48, up to 8 x n BIP errors per STS-N frame can be indicated using the REI-L indication. For OC-48 signals, up to 255 BIP errors per STS-N frame can be indicated. The current CV-L second register is incremented for each BIP error indicated by the incoming REI-L.

CV-P

Near-End STS Path Coding Violations (CV-P) is a count of BIP errors detected at the STS path layer (that is, using the B3 byte). Up to eight BIP errors can be detected per frame; each error increments the current CV-P second register.

CV-PFE

Far-End STS Path Coding Violations (CV-PFE) is a count of BIP errors detected at the STS path layer (that is, using the B3 byte). Up to eight BIP errors can be detected per frame; each error increments the current CV-PFE second register.

CV-S

Section Coding Violation (CV-S) is a count of bit interleaved parity (BIP) errors detected at the section-layer (that is, using the B1 byte in the incoming SONET signal). Up to eight section BIP errors can be detected per STS-N frame; each error increments the current CV-S second register.

ES-L

Line Errored Seconds (ES-L) is a count of the seconds containing one or more anomalies (BPV+EXZ) and/or defects (that is, loss of signal) on the line.

ES-LFE

Far-End Line Errored Seconds (ES-LFE) is a count of the seconds when at least one line-layer BIP error was reported by the far-end LTE or a RDI-L defect was present.

ES-P

Near-End STS Path Errored Seconds (ES-P) is a count of the seconds when at least one STS path BIP error was detected. An AIS-P defect (or a lower-layer, traffic-related, near-end defect) or an LOP-P defect can also cause an ES-P.

ES-PFE

Far-End STS Path Errored Seconds (ES-PFE) is a count of the seconds when at least one STS path BIP error was detected. An AIS-P defect (or a lower-layer, traffic-related, far-end defect) or an LOP-P defect can also cause an STS ES-PFE.

ES-S

Section Errored Seconds (ES-S) is a count of the number of seconds when at least one section-layer BIP error was detected or an SEF or LOS defect was present.

FC-L

Line Failure Count (FC-L) is a count of the number of near-end line failure events. A failure event begins when an AIS-L failure is declared or when a lower-layer, traffic-related, near-end failure is declared. This failure event ends when the failure is cleared. A failure event that begins in one period and ends in another period is counted only in the period where it begins.

FC-LFE

Far-End Line Failure Count (FC-LFE) is a count of the number of far-end line failure events. A failure event begins when Line remote fault indication (RFI-L) failure is declared, and it ends when the RFI-L failure clears. A failure event that begins in one period and ends in another period is counted only in the period where it began.

FC-P

Near-End STS Path Failure Counts (FC-P) is a count of the number of near-end STS path failure events. A failure event begins when an AIS-P failure, an LOP-P failure, a UNEQ-P failure, or a TIM-P failure is declared. A failure event also begins if the STS PTE that is monitoring the path supports ERDI-P for that path. The failure event ends when these failures are cleared.

FC-PFE

Far-End STS Path Failure Counts (FC-PFE) is a count of the number of near-end STS path failure events. A failure event begins when an AIS-P failure, an LOP-P failure, a UNEQ-P failure, or a TIM-P failure is declared. A failure event also begins if the STS PTE that is monitoring the path supports ERDI-P for that path. The failure event ends when these failures are cleared.

LBC

Laser bias current (LBC) is represented by the percentage of the normal (100%) laser bias current of the laser on the card port. The high laser bias current (LBC-HIGH) threshold is the percentage of the normal laser bias current when a high current TCA occurs. The low laser bias current (LBC-LOW) threshold is the percentage of the normal laser bias current when a low current TCA occurs.

NPJC-PDET

Negative Pointer Justification Count, STS Path Detected (NPJC-Pdet-P) is a count of the negative pointer justifications detected on a particular path in an incoming SONET signal.

NPJC-PGEN

Negative Pointer Justification Count, STS Path Generated (NPJC-Pgen-P) is a count of the negative pointer justifications generated for a particular path to reconcile the frequency of the SPE with the local clock.

OPT

Optical power transmitted (OPT) is represented by the percentage of the normal (100%) optical transmit power of the laser on the card port. The high optical power transmitted (OPT-HIGH) threshold is the percentage of the normal transmit optical power when a high transmit power TCA occurs. The low optical power transmitted (OPT-LOW) threshold is the percentage of the normal transmit optical power when a low transmit power TCA occurs.

OPR

Optical power received (OPR) is represented by the percentage of the normal optical receive power of the card port. The high optical power received (OPR-HIGH) threshold is the percentage of the calibrated receive optical power when a high receive power TCA occurs. The low optical power received (OPR-LOW) threshold is the percentage of the calibrated receive optical power when a low receive power TCA occurs.

PPJC-PDET

Positive Pointer Justification Count, STS Path Detected (PPJC-Pdet-P) is a count of the positive pointer justifications detected on a particular path in an incoming SONET signal.

PPJC-PGEN

Positive Pointer Justification Count, STS Path Generated (PPJC-Pgen-P) is a count of the positive pointer justifications generated for a particular path to reconcile the frequency of the SPE with the local clock.

PSC (1+1)

In a 1+1 protection scheme for a working card, Protection Switching Count (PSC) is a count of the number of times service switches from a working card to a protection card plus the number of times service switches back to the working card.

For a protection card, PSC is a count of the number of times service switches to a working card from a protection card plus the number of times service switches back to the protection card. The PSC PM is only applicable if revertive line-level protection switching is used.

PSC (BLSR)

For a protect line in a two-fiber ring, Protection Switching Count (PSC) refers to the number of times a protection switch has occurred either to a particular span's line protection or away from a particular span's line protection. Therefore, if a protection switch occurs on a two-fiber BLSR, the PSC of the protection span to which the traffic is switched will increment, and when the switched traffic returns to its original working span from the protect span, the PSC of the protect span will increment again.

PSC-W

For a working line in a two-fiber BLSR, Protection Switching Count-Working (PSC-W) is a count of the number of times traffic switches away from the working capacity in the failed line and back to the working capacity after the failure is cleared. PSC-W increments on the failed working line and PSC increments on the active protect line.

PSD (1+1)

In a 1+1 protection scheme, Protection Switching Duration (PSD) applies to the length of time, in seconds, that service is carried on another line. For a working line, PSD is a count of the number of seconds that service was carried on the protection line.

For the protection line, PSD is a count of the seconds that the line was used to carry service. The PSD PM is only applicable if revertive line-level protection switching is used.

PSD (BLSR)

For a protect line in a two-fiber BLSR, Protection Switching Duration (PSD) applies to the length of time, in seconds, that service is carried on a particular span's line protection. Therefore, if a protection switch occurs on a two-fiber BLSR, the PSD of the protection span to which the traffic is switched will increment, and when the switched traffic returns to its original working span from the protect span, the PSD of the protect span will stop incrementing.

PSD-W

For a working line in a two-fiber BLSR, PSD-W is a count of the number of seconds that service was carried on the protection line. PSD-W increments on the failed working line and PSD increments on the active protect line.

SEFS-S

Severely Errored Framing Seconds (SEFS-S) is a count of the seconds when an SEF defect was present. An SEF defect is expected to be present during most seconds when an LOS or loss of frame (LOF) defect is present. However, there can be situations when the SEFS-S parameter is only incremented based on the presence of the SEF defect.

SES-L

Line Severely Errored Seconds (SES-L) is a count of the seconds containing more than a particular quantity of anomalies (BPV + EXZ > 1544) and/or defects on the line.

SES-LFE

SES-LFE is a count of the seconds when K (see Telcordia GR-253-CORE for values) or more line-layer BIP errors were reported by the far-end LTE or an RDI-L defect was present.

SES-P

Near-End STS Path Severely Errored Seconds (SES-P) is a count of the seconds when K (2400) or more STS path BIP errors were detected. An AIS-P defect (or a lower-layer, traffic-related, near-end defect) or an LOP-P defect can also cause an SES-P.

SES-PFE

Far-End STS Path Severely Errored Seconds (SES-PFE) is a count of the seconds when K (2400) or more STS path BIP errors were detected. An AIS-P defect (or a lower-layer, traffic-related, far-end defect) or an LOP-P defect can also cause an SES-PFE.

SES-S

Section Severely Errored Seconds (SES-S) is a count of the seconds when K (see Telcordia GR-253-CORE for value) or more section-layer BIP errors were detected or an SEF or LOS defect was present.

UAS-L

Line Unavailable Seconds (UAS-L) is a count of the seconds when the line is unavailable. A line becomes unavailable when ten consecutive seconds occur that qualify as SES-Ls, and it continues to be unavailable until ten consecutive seconds occur that do not qualify as SES-Ls.

UAS-LFE

UAS-LFE is a count of the seconds when the line is unavailable at the far end. A line becomes unavailable at the onset of ten consecutive seconds that qualify as SES-LFEs, and continues to be unavailable until the onset of ten consecutive seconds occurs that do not qualify as SES-LFEs.

UAS-P

Near-End STS Path Unavailable Seconds (UAS-P) is a count of the seconds when the STS path was unavailable. An STS path becomes unavailable when ten consecutive seconds occur that qualify as SES-Ps, and continues to be unavailable until ten consecutive seconds occur that do not qualify as SES-Ps.

UAS-PFE

Far-End STS Path Unavailable Seconds (UAS-PFE) is a count of the seconds when the STS path was unavailable. An STS path becomes unavailable when ten consecutive seconds occur that qualify as SES-PFEs, and continues to be unavailable until ten consecutive seconds occur that do not qualify as SES-PFEs.


4.5  Optical Card Performance Monitoring

The following sections define performance monitoring parameters for the OC-48/STM16 and OC-192/STM64 optical cards.

4.5.1  OC-48/STM16 and OC-192/STM64 Card Performance Monitoring Parameters

Figure 4-4 shows where overhead bytes detected on the ASICs produce performance monitoring parameters for the OC-48/STM16 and OC-192/STM64 optical cards.

Figure 4-4 PM Read Points on the OC-48/STM16 and OC-192/STM64 Cards


Note For PM locations relating to protection switch counts, see the Telcordia GR-1230-CORE document.


Table 4-3 lists the near-end and far-end section layer PMs.

Table 4-3 OC48/STM16 and OC-192/STM64 Card PMs 

Section (NE)
Line (NE)
STS Path (NE) 1 2
Line (FE)
Optics (NE) 3 4
STS Path (FE)

CV-S
ES-S
SES-S
SEF-S

CV-L
ES-L
SES-L
UAS-L
FC-L
PSC (1+1)
PSC (BLSR)
PSD
PSC-W
PSD-W

CV-P
ES-P
SES-P
UAS-P
FC-P
PPJC-PDET
NPJC-PDET
PPJC-PGEN
NPJC-PGEN

CV-LFE
ES-LFE
SES-LFE
UAS-LFE
FC-LFE

OPT
OPR
LBC5

CV-PFE
ES-PFE
SES-PFE
UAS-PFE
FC-PFE

1 SONET path performance monitoring parameters increment only if IPPM is enabled. For additional information, see the "Intermediate-Path Performance Monitoring" section. To monitor SONET path performance monitoring parameters, log into the far-end node directly.

2 For information about troubleshooting path protection switch counts, refer to the Cisco ONS 15600 Troubleshooting Guide. For information about creating circuits with protection switching, refer to the Cisco ONS 15600 Reference Manual.

3 The normalized physical layer performance parameters are represented as a percentage of the nominal operating value, with 100 representing the nominal value

4 To set the threshold values for LBC, OPT, and OPR, and to reset the OPR nominal value for future calculation, refer to the Cisco ONS 15600 Procedure Guide.

5 As stated in Telcordia GR-253-CORE, the LBC (TCA) PM value is not appropriate for use with some optical transmitter technologies. Such is the case for Cisco's uncooled SR optical transmitters. The default LBC TCA provides safe operating parameter for both of Cisco's cooled and uncooled transmitters.


4.5.2  Physical Layer Parameters

The ONS 15600 retrieves the optical power received (OPR), optical power transmitted (OPT), and laser bias current (LBC) from the line card and stores these values with the PM counts for the 15-minute and 1-day periods. You can retrieve current OPR, OPT, and LBC values for each port by displaying the card view in CTC and clicking the Maintenance > Transceiver tabs.

The physical layer performance parameters consist of normalized and non-normalized values of LBC, OPT, and OPR. Table 4-4 defines the non-normalized values.

Table 4-4 Non-Normalized Transceiver Physical Optics for the OC-48/STM16 and OC-192/STM64 Cards 

Parameter
Definition

Non-normalized LBC (mA)1

The actual operating value of laser bias current (mA) for the specified card port.

Non-normalized OPR (dbm)2

The actual operating value of optical power received (dBm) for the specified card port.

Non-normalized OPT (dbm)1

The actual operating value of optical power transmitted (dBm) for the specified card port.

1 This value should be somewhat consistent from port to port and cannot be configured.

2 This value will vary from port to port because of received optical signal power differences. This value can be configured by calibrating the nominal value to the initial receive power level when the port is put in service


4.6  ASAP Card Performance Monitoring

The following sections define performance monitoring parameters for the Any Service Any Port (ASAP) card.

4.6.1  ASAP Card Optical Performance Monitoring Parameters

Table 4-5 lists the near-end and far-end section layer PMs.

Table 4-5 ASAP Card PMs 

Section (NE)
Line (NE)
STS Path (NE) 1 2
Line (FE)
Optics (NE) 3 4
STS Path (FE)

CV-S
ES-S
SES-S
SEF-S

CV-L
ES-L
SES-L
UAS-L
FC-L
PSC (1+1)
PSC (BLSR)
PSD (1+1)
PSD (BLSR)
PSC-W
PSD-W

CV-P
ES-P
SES-P
UAS-P
FC-P
PPJC-PDET
NPJC-PDET
PPJC-PGEN
NPJC-PGEN

CV-L
ES-L
SES-L
UAS-L
FC-L

OPT
OPR
LBC5

CV-P
ES-P
SES-P
UAS-P
FC-P

1 SONET path performance monitoring parameters increment only if IPPM is enabled. For additional information, see the "Intermediate-Path Performance Monitoring" section. To monitor SONET path performance monitoring parameters, log into the far-end node directly.

2 For information about troubleshooting path protection switch counts, refer to the Cisco ONS 15600 Troubleshooting Guide. For information about creating circuits with protection switching, refer to the Cisco ONS 15600 Reference Manual.

3 The normalized physical layer performance parameters are represented as a percentage of the nominal operating value, with 100 representing the nominal value

4 To set the threshold values for LBC, OPT, and OPR, and to reset the OPR nominal value for future calculation, refer to the Cisco ONS 15600 Procedure Guide.

5 As stated in Telcordia GR-253-CORE, the LBC (TCA) PM value is not appropriate for use with some optical transmitter technologies. Such is the case for Cisco's uncooled SR optical transmitters. The default LBC TCA provides safe operating parameter for both of Cisco's cooled and uncooled transmitters.


4.6.2  ASAP Card Ethernet Performance Monitoring Parameters

CTC provides Ethernet performance information, including line-level parameters, port bandwidth consumption, and historical Ethernet statistics. The ASAP card Ethernet performance information is divided into Ether Ports and POS Portswindows within the card view Performance tab window.

4.6.2.1  ASAP Card Ether Port Statistics Window

The Ethernet Ether Ports statistics window lists Ethernet parameters at the line level. The Statistics window provides buttons to change the statistical values. The Baseline button resets the displayed statistics values to zero. The Refresh button manually refreshes statistics. Auto-Refresh sets a time interval at which automatic refresh occurs. The ASAP Statistics window also has a Clear button. The Clear button sets the values on the card to zero, but does not reset the ASAP card.

During each automatic cycle, whether auto-refreshed or manually refreshed (using the Refresh button), statistics are added cumulatively and are not immediately adjusted to equal total received packets until testing ends. To see the final PM count totals, allow a few moments for the PM window statistics to finish testing and update fully. PM counts are also listed in the ASAP card Performance > History window.

Table 4-6 defines the ASAP card Statistics parameters.

Table 4-6 ASAP Ethernet Statistics Parameters 

Parameter
Meaning

Time Last Cleared

A time stamp indicating the last time statistics were reset.

Link Status

Indicates whether the Ethernet link is receiving a valid Ethernet signal (carrier) from the attached Ethernet device; up means present, and down means not present.

Rx Unicast Packets

Number of unicast packets received since the last counter reset.

Tx Unicast Packets

Number of unicast packets transmitted since the last counter reset.

Rx Multicast Packets

Number of multicast packets received since the last counter reset.

Tx Multicast Packets

Number of multicast packets transmitted since the last counter reset.

Rx Broadcast Packets

Number of broadcast packets received since the last counter reset.

Tx Multicast Packets

Number of broadcast packets transmitted since the last counter reset.

Rx Bytes

Number of bytes received since the last counter reset.

Tx Bytes

Number of bytes transmitted since the last counter reset.

Rx Errors

The number of inbound packets (or transmission units), that could not be delivered to a higher-layer protocol because of errors.

Tx Errors

The number of outbound packets (or transmission units), that could not be transmitted because of errors.

Rx FCS errors

Number of packets with a Frame Check Sequence (FCS) error. FCS errors indicate frame corruption during transmission.

Rx Align errors

Number of packets with received incomplete frames.

Rx Runts

The total number of packets received that were less than 64 bytes long (excluding framing bits, but including FCS bytes) and were otherwise well formed.

Rx Jabbers

The total number of packets received that were longer than 1518 bytes (excluding framing bits, but including FCS bytes), and had either a bad Frame Check Sequence (FCS) with an integral number of bytes (FCS Error) or a bad FCS with a non-integral number of bytes (Alignment Error)

Rx Giants

The total number of packets received that were longer than 1518 bytes (excluding framing bits, but including FCS bytes) and were otherwise well formed.

Rx Discards

The number of inbound packets which were chosen to be discarded even though no errors had been detected to prevent their being deliverable to a higher-layer protocol. One possible reason for discarding such a packet could be to free up buffer space

Tx Discards

The number of outbound packets which were chosen to be discarded even though no errors had been detected to prevent their being transmitted. One possible reason for discarding such a packet could be to free up buffer space

Rx Pause Frames

Number of received Ethernet 802.3z pause frames.

Tx Pause Frames

Number of transmitted 802.3z pause frames.

Port Drop Counts

Number of received frames dropped at the port level.

etherStatsDropEvents

Number of received frames dropped at the port level.

etherStatsOctets

The total number of bytes of data (including those in bad packets) received on the network (excluding framing bits but including FCS bytes

etherStatsPkts

The total number of packets (including bad packets, broadcast packets, and multicast packets) received

etherStatsBroadcastPkts

The total number of good packets received that were directed to the broadcast address. Note that this does not include multicast packets

etherStatsMulticastPkts

The total number of good packets received that were directed to a multicast address. Note that this number does not include packets directed to the broadcast address

etherStatsFragments

The total number of packets received that were less than 64 bytes in length (excluding framing bits but including FCS bytes) and had either a bad Frame Check Sequence (FCS) with an integral number of bytes (FCS Error) or a bad FCS with a non-integral number of bytes (Alignment Error).

Note It is entirely normal for etherStatsFragments to increment. This is because it counts both runts (which are normal occurrences due to collisions) and noise hits.

etherStatsPkts64Octets

The total number of packets (including bad packets) received that were 64 bytes in length (excluding framing bits but including FCS bytes)

etherStatsPkts65to127Octets

The total number of packets (including bad packets) received that were between 65 and 127 bytes in length inclusive (excluding framing bits but including FCS bytes)

etherStatsPkts128to255Octets

The total number of packets (including bad packets) received that were between 128 and 255 bytes in length inclusive (excluding framing bits but including FCS bytes)

etherStatsPkts256to511Octets

The total number of packets (including bad packets) received that were between 256 and 511 bytes in length inclusive (excluding framing bits but including FCS bytes)

etherStatsPkts512to1023Octets

The total number of packets (including bad packets) received that were between 512 and 1023 bytes in length inclusive (excluding framing bits but including FCS bytes)

etherStatsPkts1024to1518Octets

The total number of packets (including bad packets) received that were between 1024 and 1518 bytes in length inclusive (excluding framing bits but including FCS bytes)

Rx Utilization

The percentage of receive (Rx) line bandwidth used by the Ethernet ports during consecutive time segments.

Tx Utilization

Same as Rx Utilization, except calculated over the Tx line bandwidth

Rx Alignment Errors

A count of frames received on a particular interface that are not an integral number of bytes in length and do not pass the FCS check.

Rx FCS Errors

A count of frames received on a particular interface that are an integral number of bytes in length but do not pass the FCS check.

dot3StatsInternalMacTransmitErrors

A count of frames for which transmission on a particular interface fails due to an internal MAC sublayer transmit error. A frame is only counted by an instance of this object if it is not counted by the corresponding instance of the dot3StatsLateCollisions object, the dot3StatsExcessiveCollisions object, or the dot3StatsCarrierSenseErrors object.

dot3StatsFrameTooLongs

A count of frames received on a particular interface that exceed the maximum permitted frame size.

dot3StatsInternalMacReceiveErrors

A count of frames for which reception on a particular interface fails due to an internal MAC sublayer receive error. A frame is only counted by an instance of this object if it is not counted by the corresponding instance of the dot3StatsFrameTooLongs object, the dot3StatsAlignmentErrors object, or the dot3StatsFCSErrors object. The precise meaning of the count represented by an instance of this object is implementation-specific. In particular, an instance of this object may represent a count of receive errors on a particular interface that are not otherwise counted.

dot3StatsSymbolErrors

A count of frames for which transmission on a particular interface fails due to an internal

MAC sublayer transmit error. A frame is only counted by an instance of this object if it is not counted by the corresponding instance of either the dot3StatsLateCollisions object, the dot3StatsExcessiveCollisions object, or the dot3StatsCarrierSenseErrors object. The precise meaning of the count represented by an instance of this object is implementation-specific. In particular, an instance of this object may represent a count of transmission errors on a particular interface that are not otherwise counted


4.6.2.2  ASAP Card Ether Ports Utilization Window

The Ether Ports Utilization window shows the percentage of transmit (Tx) and receive (Rx) line bandwidth used by the Ethernet ports during consecutive time segments. The Utilization window provides an Interval menu that enables you to set time intervals of 1 minute, 15 minutes, 1 hour, and 1 day. Line utilization is calculated with the following formulas:

Rx = (inOctets + inPkts * 20) * 8 / 100% interval * maxBaseRate.

Tx = (outOctets + outPkts * 20) * 8 / 100% interval * maxBaseRate.

The interval is defined in seconds. The maxBaseRate is defined by raw bits per second in one direction for the Ethernet port (that is,1 Gbps). Table 4-7 provides the maxBaseRate for ASAP Ethernet cards.

Table 4-7 maxBaseRate for STS Circuits 

STS
maxBaseRate

STS-1

51840000

STS-3c

155000000

STS-6c

311000000

STS-12c

622000000



Note Line utilization numbers express the average of ingress and egress traffic as a percentage of capacity.


4.6.2.3  ASAP Card Ether Ports History Window

The Ethernet Ether Ports History window lists past Ethernet statistics for the previous time intervals. The History window displays the statistics for each port for the number of previous time intervals as shown in Table 4-8. The listed parameters are defined in Table 4-6.

Table 4-8 Ethernet History Statistics per Time Interval

Time Interval
Number of Intervals Displayed

1 minute

60 previous time intervals

15 minutes

32 previous time intervals

1 hour

24 previous time intervals

1 day (24 hours)

7 previous time intervals


4.6.2.4  ASAP Card POS Ports Statistics Parameters

The Ethernet POS Ports statistics window lists Ethernet POS parameters at the line level.

Table 4-9 defines the ASAP card Ethernet POS Ports parameters.

Table 4-9 ASAP Card POS Ports Parameters 

Parameter
Meaning

Time Last Cleared

A time stamp indicating the last time statistics were reset.

Link Status

Indicates whether the Ethernet link is receiving a valid Ethernet signal (carrier) from the attached Ethernet device; up means present, and down means not present.

Framing Type

 

Rx Packets

Number of packets received since the last counter reset.

Tx Packets

Number of packets transmitted since the last counter reset.

Rx Octets

Number of bytes received (from the SONET/SDH path) prior to the bytes undergoing HLDC decapsulation by the policy engine

Tx Octets

Number of bytes transmitted (to the SONET/SDH path) after the bytes undergoing HLDC encapsulation by the policy engine

Rx Shorts

Number of packets below the minimum packet size received.

Rx Runts

Total number of frames received that are less than 5 bytes

Rx Longs

Number of received frames that exceed the MTU

Rx CRC Errors/HDLC Errors

High-level data link control (HDLC) errors received from SONET/SDH.

Rx Single Bit Errors

Number of received frames with single bit errors.

Rx Multi Bit Errors

Number of received frames with multi bit errors.

Rx Type Invalid

Number of received frames with invalid type.

Rx Input Abort Packets

Number of received packets aborted before input.

Rx Input Drop Packets

Number of received packets dropped before input.


4.6.2.5  ASAP Card POS Ports Utilization Window

The POS Ports Utilization window shows the percentage of transmit (Tx) and receive (Rx) line bandwidth used by the POS ports during consecutive time segments. The Utilization window provides an Interval menu that enables you to set time intervals of 1 minute, 15 minutes, 1 hour, and 1 day. Line utilization is calculated with the following formulas:

Rx = (inOctets * 8) / interval * maxBaseRate.

Tx = (outOctets * 8) / interval * maxBaseRate.

The interval is defined in seconds. The maxBaseRate is defined by raw bits per second in one direction for the Ethernet port (that is,1 Gbps). The maxBaseRate for ASAP cards is shown in Table 4-7.


Note Line utilization numbers express the average of ingress and egress traffic as a percentage of capacity.


4.6.2.6  ASAP Card Ether Ports History Window

The Ethernet POS Ports History window lists past Ethernet POS Ports statistics for the previous time intervals. The History window displays the statistics for each port for the number of previous time intervals as shown in Table 4-8. The listed parameters are defined in Table 4-9.