Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

15454 PM Code Explanations

Can someone please provide or direct me to a document or give some information on the CV-L, CV-S, ES-S, and ES-L performance monitor objects and how to correct them. I have already found documents that tell me what they are such as code violation line and code violation session. I am looking for something that will help me narrow done the cause such as padding or distance or a configuration, etc.


New Member

Re: 15454 PM Code Explanations


Here is some further detail regarding Sonet PM errors.

First, here is a brief explanation of Sonet errors:



SONET uses the B1 byte of the Section Overhead to detect parity errors on the

incoming SONET signal. A B1 error occurs when a parity error is detected at the Section layer of the incoming SONET signal. The parity error is known as a Bit Interleaved Parity, 8-bit (BIP-8).The B1 byte, which is part of the Section Overhead, contains 8 bits used to calculate even parity. Any error that occurs within those 8 bits is considered to be a B1 error. A B1 error is also known as a Section Code Violation (CV-S). It performs error monitoring by running an even parity check on the previous SONET frame.



A B2 error occurs when a parity error is detected at the Line layer of the incoming SONET signal. A B2 error is also known as a Line Code Violation (CV-L).

In general, the transmitting SONET equipment calculates the number of ones

transmitted in the data. This result is place into the Line Overhead’s B2 byte of

the following SONET frame. The receiving SONET equipment performs the same

calculation and compares the results. If the value calculated by the receiving

SONET equipment equals the value calculated by the transmitting SONET

equipment, then the data contains no errors. However, if the values are different,

then a parity error has occurred. B2 errors can be caused by dirty fiber connections, a faulty transmitter or receiver, or a low receive-signal level.



The B3 byte of the Path Overhead is used to detect parity errors at the Path layer

of the incoming SONET signal. A B3 error is also known as a Path Code Violation (CV-P). B3 errors are only reported by SONET equipment at each end of a SONET path.

This broad reporting means that an error may exist anywhere in the SONET

path. The causes of a B3 error are similar to those attributed to B1 and B2 errors

(faulty transmit and receive equipment, a low receive signal, or dirty fibers) with

the additional element of faulty Path Terminating Equipment. The first step in troubleshooting a B3 error is to look for B1 or B2 errors along the SONET path. If these errors exist, then there may be a problem with fibers or the transmit or receive equipment along the SONET path. If these errors are not present, then there may be a problem with the Path Terminating Equipment.

Troubleshooting the errors:

Sonet ADM’s are Line and Section terminating, and unless there is a DWDM node or EDFA terminating the section and passing the line, the 2 Sonet transmitters and receivers are both terminating the B1 and B2 overhead.

The line and section then encompass the full path, TX laser to RX laser. B1/Section B2 Line errors can be caused by dirty fiber connections, scratched or otherwise damaged connectors (including atten) poor splices, faulty fibers, sharp bends in fiber, too low a receive level, or a faulty transmitter or faulty receiver. (basically anything laser to laser!)

Are you receiving the errors at one end only? The easiest way to troubleshoot this is to swap cards at each end one at a time, if this does not clear up the errors, then the fiber path is the cause, and will have to be 100% routined. This would possibly include all or some of the following: Clean all fiber connections, take db level readings at the tx and rx ends, compare the loss to the known loss in the span, confirm the loss in the span with an OTDR if necessary, Scope fiber connections (including attenuators).

You can also test the fiber, using a test set with the appropriate nm optics. The test set can be placed on the span in lieu of replacing the TX or RX cards. This might determine 1 way or the other if the span is in deed the cause of the problem. (If no B1 errors are seen, then swap HW)

Sorry for the long winded answer. I hope this information helps,



CreatePlease to create content